# VPC Peering Setup Documentation

## Overview
This document explains how I set up VPC Peering between two Virtual Private Clouds (VPCs) in AWS.
The goal was to enable private communication between resources in different VPCs without traversing the internet.

## Steps Taken
- Create Two VPCs
- VPC A: `12.0.0.0/16`
- VPC B: `13.0.0.0/16`
- Configure Networking in Each VPC
- Created **route tables** to manage traffic.
- Created **subnets** within each VPC.
- Associated subnets with their respective route tables.
- Enable Internet Access (for testing)
- Created an **Internet Gateway (IGW)** and attached it to each VPC.
- Updated the route table with a default route (`0.0.0.0/0 → IGW`).
- Launch EC2 Instances
- Deployed one EC2 instance in each VPC.
- Chose the correct **VPC** and **subnet** during network configuration.
- Create VPC Peering Connection
- From **VPC A**, created a **peering connection** request to VPC B.
- The **acceptor VPC** (VPC B) accepted the request.
- Update Route Tables for Peering
- In VPC A’s route table → Added route to `13.0.0.0/16` via the peering connection.
- In VPC B’s route table → Added route to `12.0.0.0/16` via the peering connection.
- Test Connectivity
- SSH into the EC2 instance in VPC A.
- Run:

  curl <Private_IP_of_VPC_B_EC2>
  
  
## Use Cases of VPC Peering

- **Connect VPCs in the same account**  
  Example: Keep databases in one VPC and application servers in another, then connect them securely over private IPs.

- **Connect VPCs across different accounts**  
  Example: Collaborating with a partner company — peering allows secure communication without exposing services to the internet.

- **Inter-Region Communication**  
  Use **inter-region peering** to connect workloads across AWS regions for disaster recovery or global applications.

- **Network Isolation with Connectivity**  
  Keep workloads in separate VPCs for security/compliance, while still enabling controlled communication.

---

## Limitations of VPC Peering

- **No transitive routing** → If VPC A peers with VPC B, and VPC B peers with VPC C, A cannot automatically talk to C.  
- **Overlapping CIDR blocks are not allowed** → Peering won’t work if IP ranges overlap.  
- **Not ideal for many-to-many connections** → For large-scale hub-and-spoke networks, use **AWS Transit Gateway** instead.

---

## Summary
VPC Peering is best for **simple, secure, low-latency connectivity between two VPCs**.  
For more complex multi-VPC architectures, consider **AWS Transit Gateway**.  
  
  

### Key Concepts In VPC

- Virtual private cloud (VPC) is a virtual network dedicated to your AWS account.
- A subnet becomes public when its route table has a route to the Internet Gateway.
- VPC Peering connections are not transitive — traffic only flows between directly peered VPCs.
- Subnet: A is a range of IP address in your VPC.
- Route Table: A set of rules, called route that are used to determine where network is directed.
- Internet gateway (IGW): A gateway that you attach to your vpc to enable communication between your resources in your vpc and the internet.
- VPC Endpoint: Enables you to privately connect your VPC to supported AWS services powered by private link without requiring an internet gateway, NAT devive, VPN connectionn or AWS direct connect connection.
- CIDR block: Classless inter domain routing. An internet protocol address allocation and route aggregation methology.
- NAT Gateway: Network Address Translation service. This is used so that instances in a Private Subnet can communicate to services outside your your VPC, but external services cannot initiate a connection with those instances.