Excellent — this question touches on the core mechanics of VPC Peering and how AWS handles inter-VPC connectivity. Let’s unpack it clearly and precisely.
🔹 1. What is VPC Peering?
VPC Peering is a networking connection between two Amazon Virtual Private Cloud (VPCs) that enables routing traffic between them using private IP addresses, as if they were part of the same network.
It’s a point-to-point connection that works over the Amazon network backbone, not the public internet.
🔹 2. Can VPC Peering connect VPCs in different accounts?
✅ Yes, absolutely.
VPC Peering can connect:
Two VPCs in the same AWS account
Two VPCs in different AWS accounts
Even VPCs in different AWS Regions (called inter-region VPC peering)
Requirements:
Both VPC owners must accept the peering request.
Proper route tables, security groups, and network ACLs must allow traffic.
🔹 3. Are there IP range restrictions?
Yes — this is critical.
❌ Overlapping CIDR blocks are not allowed.
The IP address ranges (CIDR blocks) of the two VPCs must not overlap.
Example:
VPC-A:
10.0.0.0/16VPC-B:
10.1.0.0/16✅ OKVPC-B:
10.0.1.0/24❌ Overlaps, not allowed
AWS enforces this restriction because overlapping ranges would break routing determinism.
🔹 4. Is VPC Peering transitive?
🚫 No, VPC Peering is not transitive.
That means:
If VPC-A is peered with VPC-B
and VPC-B is peered with VPC-C
Then:
A cannot automatically communicate with C.
You would need to create a separate peering connection between A and C if you want traffic to flow between them.
🧠 Example:
| Connection | Works? |
|---|---|
| A ↔ B | ✅ |
| B ↔ C | ✅ |
| A ↔ C (via B) | ❌ Not transitive |
| A ↔ C (direct peering) | ✅ Works |
🔹 5. Routing Behavior
Once peering is established:
You must manually update route tables in each VPC to send traffic through the peering connection.
No implicit routing is created by AWS.
Example:
VPC-A Route Table:
Destination: 10.1.0.0/16 → Target: pcx-xxxxxxx
VPC-B Route Table:
Destination: 10.0.0.0/16 → Target: pcx-xxxxxxx
Where pcx-xxxxxxx is your VPC peering connection ID.
🔹 6. When to Use Other Options
For large or multi-VPC environments, peering doesn’t scale well — because it’s a mesh model (N×(N-1)/2 connections needed).
👉 In those cases, AWS recommends:
AWS Transit Gateway (TGW):
Supports transitive routing
Can connect hundreds of VPCs and on-prem networks
Simplifies management and routing
AWS PrivateLink:
For service-specific private connectivity (not full mesh routing)
🔹 7. Summary Table
| Feature | Description |
|---|---|
| Cross-account support | ✅ Yes |
| Cross-region support | ✅ Yes (inter-region peering) |
| Overlapping CIDRs | ❌ Not allowed |
| Transitive routing | ❌ Not supported |
| Bandwidth cost | Same-region: data transfer cost per GB |
| Routing | Must be added manually in both route tables |
| Scalability | Limited — point-to-point only |
| Alternative | Use AWS Transit Gateway for transitive multi-VPC routing |
✅ Example Summary Diagram
[VPC-A 10.0.0.0/16]
|
| Peering Connection (pcx-1a2b3c)
|
[VPC-B 10.1.0.0/16]
|
| Peering Connection (pcx-4d5e6f)
|
[VPC-C 10.2.0.0/16]
➡ A ↔ B ✅
➡ B ↔ C ✅
➡ A ↔ C ❌ (Needs direct peering or TGW)
Would you like me to show a Terraform or AWS CLI example of setting up cross-account VPC peering and route configuration? It can help you see exactly how to implement this end-to-end.
