Cargando...
Cargando...
Stop guessing which to use — master the decision framework that separates passing candidates from failing ones
Three tools, three problems — knowing which solves which is the entire exam
| Feature | VPC Peering Direct 1-to-1 VPC networking | Transit Gateway Hub-and-spoke network transit hub | PrivateLink Private service exposure via NLB |
|---|---|---|---|
Primary Use Case The question stem will reveal the use case: '2 VPCs' → Peering; 'hundreds of VPCs' → TGW; 'expose a service without VPC access' → PrivateLink | Connect two VPCs for full bidirectional private communication | Connect many VPCs, VPNs, and Direct Connect attachments through a central hub | Expose a specific service/application privately to consumers without full network access |
Architecture Pattern N VPCs with full mesh peering requires N*(N-1)/2 connections. 10 VPCs = 45 peering connections. TGW needs only 10 attachments. This math appears on SAP-C02. | Mesh (point-to-point) — every pair needs its own peering connection | Hub-and-spoke — all VPCs attach to one central TGW | Service-oriented — consumer VPC connects to a specific endpoint, not the full provider VPC |
Transitive Routing CRITICAL: VPC Peering does NOT support transitive routing. This is the #1 peering trap on all exams. If a question says 'VPC A peers with B, B peers with C — can A reach C?' the answer is NO. | NOT supported — traffic cannot flow A→B→C through a peered VPC | Fully supported — TGW acts as the transit point for all attached networks | Not applicable — consumer accesses a service endpoint, not a network path |
Cross-Account Support TGW cross-account sharing requires AWS RAM. This integration appears on SAP-C02 and DOP-C02 multi-account architecture questions. | Yes — requires acceptance from the peer account owner | Yes — via Resource Access Manager (RAM) sharing | Yes — service provider and consumer can be in different accounts |
Cross-Region Support PrivateLink is REGIONAL ONLY. For cross-region private service access, you need a different pattern (e.g., TGW peering + PrivateLink, or Global Accelerator). This is a common SAA-C03 trap. | Yes — Inter-Region VPC Peering supported, traffic traverses AWS backbone | Yes — via Transit Gateway Peering (TGW-to-TGW), not native cross-region attachment | No — PrivateLink endpoints are regional; consumer and provider must be in the same region |
Overlapping CIDR Handling CRITICAL: If the scenario mentions overlapping IP ranges between VPCs and asks how to connect them, PrivateLink is the correct answer. This is a frequently tested differentiator. | NOT supported — VPCs with overlapping CIDRs cannot be peered | NOT supported natively — overlapping CIDRs cause routing conflicts; requires NAT or careful design | SUPPORTED — consumer and provider can have identical/overlapping CIDRs because only the endpoint IP matters |
Network Exposure Level PrivateLink is the principle of least privilege for networking. Use it when you want to expose a service (e.g., your SaaS API) without giving customers access to your VPC. SCS-C02 loves this distinction. | Full network access — all resources in both VPCs can communicate (subject to Security Groups/NACLs) | Full network access — all attached VPCs can route to each other (subject to TGW route tables) | Service-level access only — consumer can only reach the specific endpoint service, not the provider's entire VPC |
Requires Internet Gateway / NAT All three keep traffic off the public internet. The differentiator is NOT about internet exposure — it is about topology, scale, and access granularity. | No — traffic stays on AWS private network | No — traffic stays on AWS private network | No — traffic stays on AWS private network; this is the entire point |
Underlying Infrastructure Required PrivateLink REQUIRES an NLB on the provider side. If a question asks what must be deployed to expose a service via PrivateLink, the answer is NLB. This is tested on SAA-C03 and SAP-C02. | None — managed by AWS, no gateway or appliance needed | TGW resource + attachments + route tables | Network Load Balancer (NLB) on the provider side + VPC Endpoint on the consumer side |
Bandwidth / Throughput TGW has a per-attachment bandwidth limit. For very high throughput between two specific VPCs, direct peering may outperform TGW. | No aggregate bandwidth limit — limited by instance network bandwidth | Up to 50 Gbps per VPC attachment (burst); aggregate depends on attachments | Limited by NLB throughput on provider side |
Pricing Model For cost optimization questions: VPC Peering is cheapest for small-scale (few VPCs, same region/AZ). TGW becomes cost-effective at scale despite per-attachment cost because it eliminates N*(N-1)/2 peering connections. PrivateLink has predictable per-endpoint pricing. | Data transfer charges only — no hourly fee for the peering connection itself; intra-region peering between AZs incurs charges, cross-region incurs higher charges | Per attachment-hour + per GB data processed — costs add up significantly at scale | Per endpoint-hour + per GB data processed through the endpoint |
Security Group Support Cross-VPC Security Group referencing only works with VPC Peering in the same region. This is a nuanced point tested on SCS-C02. | Yes — Security Groups can reference peer VPC Security Group IDs (same-region only) | Yes — Security Groups apply at the ENI level within each VPC | Yes — consumer endpoint has Security Groups; provider NLB has Security Groups |
DNS Resolution PrivateLink with private DNS enabled means instances in the consumer VPC resolve the service's public DNS name to the private endpoint IP automatically. This is key for AWS service Interface Endpoints. | Requires enabling DNS resolution options on both sides of the peering connection | DNS handled within each VPC independently; Route 53 Resolver needed for cross-VPC DNS | Private DNS supported — endpoint can override the public DNS name of AWS services or custom services |
Supported Connection Types TGW is the ONLY option that consolidates VPC, VPN, and Direct Connect into one routing domain. This is a major SAP-C02 architecture pattern for hybrid connectivity. | VPC-to-VPC only | VPC, Site-to-Site VPN, Direct Connect Gateway, TGW Peering, SD-WAN (via Connect attachment) | VPC endpoint to NLB-backed service (also used for AWS managed service Interface Endpoints) |
Route Table Management TGW route table segmentation allows network isolation between groups of VPCs (e.g., prod VPCs cannot reach dev VPCs) without complex peering rules. This is a SAP-C02 advanced networking pattern. | Manual — must add routes to VPC route tables in both VPCs pointing to the peering connection | Centralized TGW route tables — can have multiple route tables for segmentation; supports blackhole routes | No route table changes needed in consumer VPC — endpoint is accessed via its DNS name or private IP |
Typical Scale Scale is the primary decision driver. Questions with 'hundreds of VPCs' or 'growing number of connections' point to TGW. | Best for small numbers of VPCs (< 10); becomes unmanageable at scale | Designed for large scale — hundreds of VPCs and on-premises connections | Scales to thousands of consumer endpoints for a single service |
On-Premises Connectivity If the question involves connecting on-premises + multiple VPCs, TGW is almost always the answer. PrivateLink can be accessed from on-premises via DX/VPN but requires a VPC as the entry point. | Not applicable — does not extend to on-premises networks | Yes — attach Site-to-Site VPN or Direct Connect Gateway to TGW for on-premises access | Not directly — on-premises can access PrivateLink endpoints via Direct Connect or VPN into the consumer VPC |
Summary
Use VPC Peering for simple, low-count, direct VPC-to-VPC connections where cost matters and you do not need transitive routing. Use Transit Gateway when you have many VPCs, need hub-and-spoke topology, require on-premises connectivity, or need centralized routing control. Use PrivateLink when you want to expose a specific service privately without granting full VPC access — especially when overlapping CIDRs exist or you are a SaaS provider serving multiple customer VPCs.
🎯 Decision Tree
If 2 VPCs, same region, no overlap → VPC Peering | If many VPCs OR on-premises needed OR transitive routing needed → Transit Gateway | If exposing a specific service/API privately OR overlapping CIDRs OR SaaS multi-tenant pattern → PrivateLink | If AWS managed service (S3, DynamoDB) → Gateway Endpoint (free) or Interface Endpoint (PrivateLink-based) depending on the service
VPC Peering has NO transitive routing — ever. If VPC-A peers with VPC-B and VPC-B peers with VPC-C, traffic from A cannot reach C through B. This is the single most tested VPC Peering concept across SAA-C03, SAP-C02, and SCS-C02. When you see a scenario with a 'shared services VPC' that needs to be reachable by all other VPCs, Transit Gateway (not peering) is the answer.
PrivateLink requires an NLB (Network Load Balancer) on the provider/service side — NOT an ALB, NOT a CLB, NOT an Application Load Balancer. If a question asks what infrastructure the service provider must deploy to expose their service via PrivateLink, the answer is always NLB. Additionally, PrivateLink is the ONLY solution when consumer VPCs have overlapping CIDRs with the provider VPC.
Know the difference between Gateway Endpoints and Interface Endpoints (PrivateLink): Gateway Endpoints are FREE, only support S3 and DynamoDB, and work by modifying VPC route tables — they do NOT use PrivateLink. Interface Endpoints use PrivateLink, cost money (per-hour + per-GB), support most other AWS services, and create ENIs in your subnet. A question asking how to privately access S3 without cost → Gateway Endpoint. A question asking how to privately access SQS, SNS, or Secrets Manager → Interface Endpoint (PrivateLink).
Transit Gateway is the correct answer for ANY scenario involving: (a) connecting more than ~5-10 VPCs, (b) needing on-premises connectivity shared across multiple VPCs, (c) needing centralized network inspection via a security appliance, or (d) needing to connect VPNs and VPCs in the same routing domain. The key cost consideration: TGW charges per attachment-hour AND per GB processed — for very high-bandwidth, low-VPC-count scenarios, direct peering may be cheaper.
For multi-account architectures on SAP-C02 and DOP-C02: Transit Gateway is shared across accounts using AWS Resource Access Manager (RAM). VPC Peering requires manual acceptance per connection. PrivateLink allows SaaS-style service sharing where the consumer account only needs to create a VPC endpoint — they never get access to the provider's VPC, making it the most secure multi-tenant pattern.
On SCS-C02 security questions: PrivateLink provides the most granular network isolation — consumers access only a specific service, not the entire VPC. This aligns with least-privilege networking. VPC Peering gives full bidirectional access (controlled only by Security Groups/NACLs). If a question asks how to expose a service to a partner account with the minimum network exposure, PrivateLink is always the answer.
Candidates confuse 'VPC Endpoint' with 'PrivateLink' — they are related but not identical. All Interface Endpoints USE PrivateLink technology, but PrivateLink also refers to the endpoint service framework for custom services. Gateway Endpoints (S3, DynamoDB) do NOT use PrivateLink. The #1 exam trap is choosing PrivateLink/Interface Endpoint for S3 when a Gateway Endpoint is cheaper and simpler, OR choosing a Gateway Endpoint for a service that only supports Interface Endpoints (e.g., SQS, SNS, SSM). Always check: is it S3 or DynamoDB? → Gateway Endpoint. Everything else? → Interface Endpoint.
CertAI Tutor · SAA-C03, SAP-C02, SCS-C02, DEA-C01, DOP-C02, AIF-C01 · 2026-02-22
Services
Comparisons
Guides & Patterns