AWS Advanced Networking: Connectivity Patterns & Multi-VPC Design
Different connectivity patterns and use cases (for example, VPC peering, Transit Gateway, AWS PrivateLink)
AWS Advanced Networking: Connectivity Patterns & Multi-VPC Design
This study guide focuses on the architectural decisions and implementation strategies for connecting multiple Virtual Private Clouds (VPCs) and on-premises environments within the AWS ecosystem, a core component of the ANS-C01 exam.
Learning Objectives
By the end of this chapter, you should be able to:
- Differentiate between VPC Peering, Transit Gateway, and AWS PrivateLink based on use case and scale.
- Architect a hub-and-spoke network topology using AWS Transit Gateway.
- Implement private service connectivity using PrivateLink to avoid IP address overlap issues.
- Evaluate the benefits of VPC Sharing via AWS Resource Access Manager (RAM).
- Resolve IP address exhaustion and overlapping CIDR blocks in multi-account environments.
Key Terms & Glossary
- Transitive Routing: The ability of traffic to pass through an intermediate network hop to reach a destination. (VPC Peering is not transitive; Transit Gateway is transitive).
- Interface VPC Endpoint: A private entry point (ENI) for services powered by AWS PrivateLink, using a private IP address from your subnet.
- Resource Access Manager (RAM): A service that allows you to share AWS resources (like subnets or Transit Gateways) across accounts within an AWS Organization.
- CIDR Overlap: A situation where two connected networks use the same IP address range, preventing standard Layer 3 routing.
- Hub-and-Spoke: A network topology where all "spoke" VPCs connect to a central "hub" (Transit Gateway) to communicate with each other.
The "Big Idea"
As AWS environments grow from a single VPC to hundreds of accounts, simple point-to-point connectivity becomes unmanageable. The "Big Idea" is the progression from VPC Peering (simple, high performance, but complex at scale) to Transit Gateway (centralized management and scalability) and PrivateLink (secure, service-specific access that bypasses routing complexities like IP overlaps).
Formula / Concept Box
| Feature | VPC Peering | Transit Gateway | AWS PrivateLink |
|---|---|---|---|
| Topology | Point-to-Point (Mesh) | Hub-and-Spoke | Client-Server (Unidirectional) |
| Transitive? | No | Yes | N/A (Abstraction) |
| Performance | No Aggregate Limit | 50 Gbps per VPC Attach | 10 Gbps+ per ENI |
| IP Overlap | Not Supported | Not Supported (Requires NAT) | Supported (Uses ENI in consumer) |
| Cost | Data Transfer Only | Hourly + Data Processing | Hourly + Data Processing |
Hierarchical Outline
- VPC Peering (Point-to-Point)
- Direct Interconnect: Uses AWS internal infrastructure; no single point of failure.
- Scope: Supports Inter-Region and Cross-Account peering.
- Constraint: No transitive routing (A ↔ B and B ↔ C does not mean A ↔ C).
- AWS Transit Gateway (Central Hub)
- Centralized Router: Connects VPCs, SD-WAN, and Direct Connect Gateways.
- Scalability: Reduces the number of peering relationships from to .
- Routing: Supports route tables for traffic segmentation (e.g., isolating Prod from Dev).
- AWS PrivateLink (Service Connectivity)
- Abstraction: Exposes a specific service (NLB-backed) rather than the whole VPC.
- Security: Traffic never leaves the AWS network; no Internet Gateway (IGW) required.
- Overlapping IPs: Since it uses an ENI in the consumer VPC, source/destination CIDRs can overlap.
- VPC Sharing (Multi-Account)
- Centralized VPC: One account owns the VPC (CIDR, subnets, IGW) and shares subnets with others.
- Efficiency: Reduces the number of VPCs to manage; participants manage their own EC2/RDS resources.
Visual Anchors
Non-Transitive Peering vs. Transit Gateway
Transit Gateway Architecture
\begin{tikzpicture}[node distance=2.5cm, every node/.style={draw, rectangle, rounded corners, minimum height=1cm, fill=white, align=center}] \node (tgw) [fill=orange!20, line width=1pt] {\textbf{Transit Gateway}\ (Central Router)}; \node (vpc1) [above left of=tgw] {Spoke VPC A$Finance)}; \node (vpc2) [above right of=tgw] {Spoke VPC B$HR)}; \node (vpc3) [below left of=tgw] {Spoke VPC C$Dev)}; \node (dx) [below right of=tgw, fill=blue!10] {Direct Connect$On-Prem)};
\draw[<->, thick] (tgw) -- (vpc1); \draw[<->, thick] (tgw) -- (vpc2); \draw[<->, thick] (tgw) -- (vpc3); \draw[<->, thick, dashed] (tgw) -- (dx); \end{tikzpicture}
Definition-Example Pairs
- VPC Peering
- Definition: A networking connection between two VPCs that enables you to route traffic between them using private IPv4 or IPv6 addresses.
- Example: A legacy monolith in VPC A needs to access a specific database in VPC B. A simple peering connection is created for high-throughput, low-latency access.
- AWS PrivateLink
- Definition: A technology that provides high-availability connectivity between VPCs without requiring traffic to traverse the public internet or requiring VPC Peering.
- Example: A SaaS provider hosts a security scanning service. Instead of peering with 100 customers (and dealing with 100 IP overlaps), they provide a PrivateLink Endpoint Service.
Worked Examples
Scenario: The Mesh Mess to Hub Success
Problem: A company has 10 VPCs that all need to communicate. Using VPC Peering, how many connections are needed? What is the alternative?
Step-by-Step Breakdown:
- Calculate Peering Connections: Using the formula , for 10 VPCs: individual peering connections to manage.
- Identify Scale Issues: Each connection requires manual route table updates in both VPCs. If a new VPC is added, 10 more connections are needed.
- Implement Transit Gateway:
- Create a Transit Gateway in the central network account.
- Attach all 10 VPCs to the TGW.
- Total connections to manage: 10.
- Result: Adding an 11th VPC only requires 1 new attachment to the TGW, rather than 10 new peering links.
Checkpoint Questions
- Does VPC Peering support transitive routing between three VPCs (A-B-C)?
- Which service allows you to connect two VPCs with overlapping CIDR blocks without using NAT?
- True or False: A Transit Gateway can connect VPCs across different AWS Regions.
- What AWS service is used to share a Transit Gateway or a Subnet with other accounts in an Organization?
▶Click to see answers
- No.
- AWS PrivateLink (Interface Endpoints).
- True (using TGW Peering).
- AWS Resource Access Manager (RAM).
Muddy Points & Cross-Refs
[!WARNING] The "No Overlap" Rule: Remember that VPC Peering and Transit Gateway do not work if the VPCs have overlapping CIDR blocks (unless you use complex NAT configurations). If you see "overlapping IPs" in an exam question, your mind should immediately go to AWS PrivateLink.
- Peering vs. TGW for Cost: Peering has no hourly charge, only data transfer. TGW has an hourly charge per attachment plus data processing fees. For high-bandwidth, 2-VPC links, Peering is cheaper.
- DNS across VPCs: PrivateLink often requires Route 53 Private Hosted Zones for the endpoint DNS names to resolve correctly within the consumer VPC.
Comparison Tables
Choosing Your Connection Strategy
| Requirement | Use VPC Peering | Use Transit Gateway | Use PrivateLink |
|---|---|---|---|
| Lowest Latency | Best (No extra hops) | Good (One extra hop) | Good (Proxy/ENI based) |
| Ease of Management | Hard (at scale) | Excellent (Centralized) | Moderate (Per service) |
| Security Isolation | Full L3 connectivity | Full L3 connectivity | L4 (Port/Service only) |
| Service Provider Model | No | No | Yes (Endpoint Services) |
| Cost (Small Scale) | Lowest | Higher | Moderate |