We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Cloud Infrastructure
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Cloud Infrastructure
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You have a production VPC (10.0.0.0/16) and a shared-services VPC (10.1.0.0/16) that hosts your logging infrastructure, monitoring, and . An application in the production VPC needs to send logs to the shared-services VPC. But they are isolated, that is the whole point of a VPC. Resources in one VPC have no route to resources in another.
VPC peering creates a direct network connection between two VPCs. After peering, resources in either VPC can communicate using private IP addresses as if they were on the same network. Traffic flows over the AWS backbone, it never touches the public internet. is low. Bandwidth is high. There is no single point of failure.
This is how multi-VPC architectures work. Production, staging, and shared services each get their own VPC for isolation, then peering connections are created where communication is needed. You get the isolation benefits of separate VPCs with the connectivity of a single network, but only where you explicitly allow it.
AWS internal networking benchmarks show that VPC peering adds less than 0.1ms of latency compared to intra-VPC communication. For cross-region peering, the latency matches the inter-region fiber path (typically 10-80ms depending on distance), but traffic stays on the AWS backbone rather than traversing the public internet.
How it works:
Critical requirement: The two VPCs must have non-overlapping CIDR ranges. If both use 10.0.0.0/16, peering is impossible. The routing table cannot distinguish between local and remote addresses.
Key limitations:
| Limitation | Implication |
|---|---|
| No transitive peering | If A peers with B and B peers with C, A cannot reach C through B |
| No overlapping CIDRs | Plan IP ranges upfront across the organization |
| Cross-region peering | Supported, but data transfer costs apply (~$0.01/GB) |
| Cross-account peering | Supported, common in enterprise multi-account setups |
| Max peering per VPC | 125 (soft limit, can request increase) |
The "no transitive peering" problem is the biggest architectural constraint. If you have 10 VPCs that all need to communicate, you need 45 individual peering connections (n*(n-1)/2). At 20 VPCs, that is 190 connections. This is why Transit Gateway exists, it solves the N-squared peering problem.
Cost: VPC peering itself is free within the same region. You only pay for data transfer, which is the same rate as intra-region data transfer ($0.01/GB). Cross-region peering charges standard inter-region data transfer rates.