AWS VPC Connectivity Decision Guide — Overview
Connecting VPCs is one of the most frequently tested networking decisions on SAP-C02. AWS offers four primary options: VPC Peering, Transit Gateway, PrivateLink, and VPC Sharing (RAM). Each has distinct use cases, limitations, and cost implications. Choosing wrong can result in scalability issues, security gaps, or excessive costs.
Detailed Comparison
| Feature | VPC Peering | Transit Gateway | PrivateLink | VPC Sharing |
|---|---|---|---|---|
| Topology | Point-to-point mesh | Hub-and-spoke | Consumer→Provider | Shared VPC |
| Transitive routing | ❌ No | ✅ Yes | N/A (service access) | N/A (same VPC) |
| Overlapping CIDRs | ❌ Not supported | ❌ Not supported | ✅ Works (uses ENI IP) | N/A (same VPC) |
| Cross-account | ✅ | ✅ (via RAM) | ✅ | ✅ (via RAM) |
| Cross-region | ✅ | ✅ (TGW Peering) | ✅ (inter-region) | ❌ Same region only |
| Bandwidth | No limit (AWS backbone) | 50 Gbps per attachment | Limited by NLB + ENIs | No limit (same VPC) |
| Scalability | N² connections (messy at 5+ VPCs) | Linear (N attachments) | Per-service endpoints | Per-subnet sharing |
| Security control | Security Groups + NACLs | Route tables + SGs + NACLs | Endpoint policies + SGs | SGs per resource per account |
| Cost | $0.01/GB cross-AZ/region only | $0.05/hr per attachment + $0.02/GB processed | $0.01/hr per AZ + $0.01/GB | Free (no extra charges) |
Decision Guide
| Scenario | Best Option | Why |
|---|---|---|
| Connect 2-3 VPCs with full bidirectional access | VPC Peering | Simple, no cost (same region/AZ), no bandwidth limit, no single point of failure |
| Connect 10+ VPCs + on-premises | Transit Gateway | Scales linearly, transitive routing, supports VPN/DX, route table segmentation |
| Expose one service to many consumer VPCs | PrivateLink | Unidirectional, works with CIDR overlap, no route table changes for consumers |
| Multiple accounts need resources in same network | VPC Sharing (RAM) | Free, centralized network management, no peering/TGW needed |
| Access AWS services without internet (S3, DynamoDB) | Gateway VPC Endpoint | Free, route table entry only (S3 + DynamoDB) |
| Access AWS services without internet (other services) | Interface VPC Endpoint (PrivateLink) | ENI in your VPC, private DNS resolution |
| VPCs have overlapping CIDR ranges | PrivateLink | Only option that works with CIDR overlap (uses endpoint ENI IP) |
| Third-party SaaS access privately | PrivateLink (Partner endpoint) | Access partner services without internet, traffic stays on AWS network |
Key Limitations (Exam Traps)
| Limitation | Affects | Workaround |
|---|---|---|
| No transitive routing | VPC Peering | Use Transit Gateway for transitive, or create full mesh of peering connections |
| No overlapping CIDRs | VPC Peering, Transit Gateway | Use PrivateLink (only option for overlapping CIDRs) |
| Unidirectional only | PrivateLink | Consumer initiates → Provider responds. If both need to initiate, use Peering/TGW |
| Data processing charge ($0.02/GB) | Transit Gateway | For VPC-to-VPC within same region, peering is cheaper (no processing charge) |
| Same region only | VPC Sharing (RAM) | Cross-region requires Peering/TGW |
Common Architecture Patterns
Pattern 1: Hub-and-Spoke with Transit Gateway
- Central Network VPC → TGW → Spoke VPCs (Prod, Dev, Staging)
- On-premises → VPN/DX → TGW → All VPCs
- Route tables isolate Prod from Dev while both access Shared Services
Pattern 2: Shared Services via PrivateLink
- Shared Services VPC exposes services (APIs, databases) via NLB + PrivateLink
- Consumer VPCs create Interface Endpoints → access services without route changes
- Works even if consumer VPCs have overlapping CIDRs
Pattern 3: VPC Sharing for Centralized Networking
- Network account owns VPCs/subnets → shares specific subnets to workload accounts via RAM
- Workload accounts deploy resources (EC2, Lambda, RDS) into shared subnets
- Network team retains control of routing, NACLs, flow logs. Workload teams manage their Security Groups.
Pattern 4: Hybrid — TGW + PrivateLink + Peering
- TGW for general VPC-to-VPC + on-premises connectivity
- PrivateLink for specific high-security services (overlapping CIDRs, third-party SaaS)
- Peering for high-bandwidth, latency-sensitive connections between 2 specific VPCs (avoids TGW processing charge)
Exam Tips
| Exam | Key Points |
|---|---|
| SAP-C02 | “Connect many VPCs + on-prem” → Transit Gateway. “Overlapping CIDRs” → PrivateLink only. “No transitive routing” = VPC Peering limitation. “Centralize network, multiple accounts share subnets” → VPC Sharing (RAM). “Expose service without full network access” → PrivateLink. “Reduce cost for VPC-to-VPC” → Peering (no TGW processing fee). “Access S3 without internet” → Gateway VPC Endpoint (free). |
AWS Certification Exam Practice Questions
Question 1:
A company has 3 VPCs: VPC-A peered to VPC-B, and VPC-B peered to VPC-C. Resources in VPC-A need to communicate with resources in VPC-C, but traffic is failing. What is the issue and the BEST solution?
- Security groups are blocking traffic. Update SG rules to allow VPC-C CIDR in VPC-A.
- VPC Peering does not support transitive routing. Create a direct peering connection between VPC-A and VPC-C.
- VPC Peering does not support transitive routing. Replace all peering with a Transit Gateway.
- Route tables are missing entries. Add VPC-C CIDR route to VPC-A route table pointing to VPC-B peering connection.
Show Answer
Answer: B — VPC Peering is non-transitive: traffic cannot flow A→B→C even if both peering connections exist. For 3 VPCs, the simplest fix is to create a third peering connection (A↔C). If you have many VPCs (5+), Transit Gateway (C) would be better, but for just 3 VPCs, direct peering is simpler and cheaper. Route table entries through another peering (D) won’t work — AWS drops traffic that attempts transitive routing.
Question 2:
Two VPCs in different AWS accounts use overlapping CIDR ranges (both use 10.0.0.0/16). VPC-A needs to access an API service hosted in VPC-B. Peering and Transit Gateway both fail because of the CIDR overlap. Which connectivity option works?
- Re-IP one of the VPCs to remove the overlap
- AWS PrivateLink — VPC-B exposes the API via NLB + VPC Endpoint Service, VPC-A creates an Interface Endpoint
- Transit Gateway with a NAT instance to translate addresses
- Site-to-Site VPN between the two VPCs with NAT
Show Answer
Answer: B — PrivateLink is the only AWS-native connectivity option that works with overlapping CIDRs. The consumer VPC creates an Interface Endpoint which gets a private IP from the consumer’s VPC CIDR (not the provider’s). Traffic is routed through the endpoint ENI to the provider’s NLB. No route table changes or CIDR conflicts. Re-IPing (A) may not be feasible at scale.
Question 3:
A company has 50 AWS accounts in an Organization. They want all accounts to launch resources in a shared network managed by the networking team, without each account managing their own VPCs. What is the MOST operationally efficient approach?
- Create VPC Peering between every account’s VPC and a central VPC
- Share subnets from the Network account to workload accounts using AWS Resource Access Manager (VPC Sharing)
- Transit Gateway with one VPC per account
- Create a VPN mesh between all accounts
Show Answer
Answer: B — VPC Sharing via RAM allows the Network account to own the VPCs/subnets and share specific subnets to workload accounts. Workload accounts deploy resources (EC2, RDS, Lambda) into shared subnets without managing VPCs. The networking team retains full control of routing, NACLs, and flow logs. No peering/TGW needed (free). This is the multi-account networking pattern recommended by AWS.
Question 4:
Two VPCs exchange 5TB/day of data. They currently use Transit Gateway, costing $100/day in TGW data processing charges ($0.02/GB × 5000 GB). Both VPCs are in the same region and same account. How can they reduce this cost?
- Compress data before transfer
- Replace Transit Gateway with VPC Peering for this specific connection
- Use PrivateLink instead of Transit Gateway
- Move to the same VPC
Show Answer
Answer: B — VPC Peering has no data processing charge (only cross-AZ transfer costs apply, $0.01/GB each way). Removing TGW from this high-volume path eliminates the $0.02/GB processing fee entirely, saving ~$100/day. Keep TGW for other VPCs that need transitive routing, but use peering for this high-bandwidth pair. This is a common hybrid pattern — TGW for general connectivity, peering for high-volume specific pairs.
Question 5:
A company wants member accounts to access a centralized monitoring service (Prometheus) hosted in the Shared Services VPC, without giving those accounts any network access to other resources in that VPC. How should this be implemented?
- VPC Peering with restrictive Security Groups
- Transit Gateway with route table limiting access to Prometheus IP only
- PrivateLink — expose Prometheus via NLB + VPC Endpoint Service, member accounts create Interface Endpoints
- VPC Sharing — share only the Prometheus subnet to member accounts
Show Answer
Answer: C — PrivateLink exposes only the specific service (Prometheus behind NLB) without granting any broader network access. Consumer accounts create an Interface Endpoint that connects only to that service. They cannot reach other resources in the Shared Services VPC. VPC Peering (A) gives full network path (too broad). TGW (B) requires route management at IP level (fragile). VPC Sharing (D) gives access to the subnet (too broad).
Related Posts
- AWS Virtual Private Cloud (VPC)
- Hybrid Cloud Networking – Transit Gateway & Direct Connect
- Multi-Account Architecture
- Zero Trust – VPC Lattice
- VPC Explained – Beginners Guide
References
- VPC Peering Guide — AWS Docs
- Transit Gateway Guide — AWS Docs
- AWS PrivateLink Guide — AWS Docs
- VPC Sharing — AWS Blog
- Evolving VPC Design — AWS Architecture Blog
Frequently Asked Questions
VPC Peering vs Transit Gateway — which is cheaper?
VPC Peering is cheaper for data transfer — no processing charge (just standard cross-AZ fees). Transit Gateway charges $0.05/hr per attachment + $0.02/GB processed. For high-volume connections between 2-3 VPCs, peering is significantly cheaper. For 5+ VPCs or need for on-premises connectivity, TGW is operationally simpler despite higher cost.
What does “no transitive routing” mean?
If VPC-A is peered with VPC-B, and VPC-B is peered with VPC-C, traffic from A cannot reach C through B. Each VPC pair needs its own peering connection. This creates an N² scaling problem (10 VPCs = 45 peering connections). Transit Gateway solves this — all VPCs connect to TGW and traffic routes transitively through the hub.
When should I use VPC Sharing vs Transit Gateway?
Use VPC Sharing when you want a single centrally-managed network where multiple accounts deploy resources into shared subnets (simplest, cheapest). Use Transit Gateway when accounts need their own isolated VPCs but need connectivity between them (more isolation, more complex). VPC Sharing = shared network. TGW = connected separate networks.