AWS Networking: VPC Peering vs. Transit Gateway

This guide explores the critical architectural decisions behind selecting the right interconnection service in AWS, focusing on the trade-offs between VPC Peering and AWS Transit Gateway for the Advanced Networking Specialty (ANS-C01) exam.

Learning Objectives

After studying this guide, you should be able to:

• Distinguish between the point-to-point architecture of VPC Peering and the hub-and-spoke model of Transit Gateway.
• Analyze network requirements to select the most cost-effective and scalable connectivity solution.
• Identify specific feature requirements (like Multicast or SD-WAN integration) that mandate the use of Transit Gateway.
• Evaluate the impact of regional and account boundaries on architectural complexity.

Key Terms & Glossary

• VPC Peering: A networking connection between two VPCs that enables you to route traffic between them using private IPv4 or IPv6 addresses.
• Transit Gateway (TGW): A network transit hub that connects VPCs and on-premises networks through a central managed gateway.
• Hub-and-Spoke: A network topology where a central node (the hub) connects to multiple peripheral nodes (the spokes).
• Full Mesh: A network topology where every node is connected directly to every other node.
• Transit Gateway Connect: A feature that enables native integration of SD-WAN appliances into AWS.

The "Big Idea"

The core challenge of AWS networking is managing complexity at scale. While VPC Peering is highly efficient and performant for simple, one-to-one connections, it becomes a management nightmare as the number of VPCs grows (the $n(n-1)/2$ problem). Transit Gateway solves this by introducing a central administration point, trading off slightly higher latency and cost for significantly simplified operations and advanced routing capabilities.

Formula / Concept Box

Hierarchical Outline

• VPC Peering Fundamentals
  • Direct Connectivity: Traffic stays on the AWS global backbone.
  • Regional Scope: Primary use case is intra-region, though inter-region is supported.
  • Cost Efficiency: No hourly charge; you only pay for data transfer.
• AWS Transit Gateway Fundamentals
  • Centralized Management: Simplifies complex peering grids.
  • Advanced Features: Supports Multicast, GRE tunnels, and SD-WAN (TGW Connect).
  • Security: Centralized inspection patterns (Traffic Mirroring, Appliance VPCs).
• Decision Criteria
  • Scale: Choose TGW if > 10 VPCs.
  • Compliance: Use Peering for strict isolation requirements where no central hub is permitted.
  • Cost Sensitivity: Use Peering for high-volume data transfer between two specific VPCs.

Visual Anchors

Architecture Decision Flow

Conceptual Topology Comparison

\begin{tikzpicture}[scale=0.8] % VPC Peering (Mesh) \draw (0,2) circle (0.5) node {VPC A}; \draw (2,2) circle (0.5) node {VPC B}; \draw (1,0.5) circle (0.5) node {VPC C}; \draw[<->, thick, blue] (0.5,2) -- (1.5,2); \draw[<->, thick, blue] (0.2,1.6) -- (0.8,0.9); \draw[<->, thick, blue] (1.8,1.6) -- (1.2,0.9); \node at (1,-0.5) {\textbf{VPC Peering (Mesh)}};

% Transit Gateway (Hub-Spoke) \begin{scope}[shift={(6,0)}] \draw[fill=orange!20] (1,1.5) rectangle (2,2.5) node[midway] {TGW}; \draw (0,3.5) circle (0.5) node {VPC A}; \draw (3,3.5) circle (0.5) node {VPC B}; \draw (0,0) circle (0.5) node {VPC C}; \draw (3,0) circle (0.5) node {VPC D}; \draw[->, thick, red] (0.4,3.1) -- (1,2.5); \draw[->, thick, red] (2.6,3.1) -- (2,2.5); \draw[->, thick, red] (0.4,0.4) -- (1,1.5); \draw[->, thick, red] (2.6,0.4) -- (2,1.5); \node at (1.5,-0.5) {\textbf{Transit Gateway (Hub)}}; \end{scope} \end{tikzpicture}

Definition-Example Pairs

• Transitive Routing: The ability for a central hub to pass traffic between two spokes.
  • Example: In a Transit Gateway setup, VPC A can talk to VPC B through the TGW. VPC Peering does not support this; you cannot peer VPC A to B and B to C to allow A to talk to C.
• Route Propagation: Automatically updating route tables via BGP.
  • Example: When a new VPN is connected to a Transit Gateway, the TGW can propagate that on-premises route to all attached VPC route tables automatically.

Worked Examples

Example 1: The Cost-Conscious Startup

Scenario: A company has two VPCs in us-east-1 (Production and Analytics). They transfer 50TB of data monthly for ETL processes. They have no plans to expand beyond 3 VPCs.

• Recommendation: VPC Peering.
• Reasoning: Since there are only two VPCs, management is simple. Peering has no hourly attachment fee, and data transfer is charged at the same rate as TGW, but without the TGW data processing fee ($0.02/GB processing fee would add $1,000/month in this case).

Example 2: The Global Enterprise

Scenario: An organization has 40 accounts with 2 VPCs each across 3 regions. They need to connect their on-premises data center via Direct Connect to all VPCs.

• Recommendation: AWS Transit Gateway.
• Reasoning: Managing 80 VPCs in a mesh would require over 3,000 peering connections. TGW allows for a central hub in each region, which can be peered together (Inter-Region TGW Peering), and a single Direct Connect Gateway association for all VPCs.

Checkpoint Questions

1. Does VPC Peering support transitive routing between three VPCs (A $\leftrightarrow$ B $\leftrightarrow$ C)?
2. Which service is required if you need to implement IP Multicast between VPCs?
3. True or False: Transit Gateway is generally more cost-effective than VPC Peering for very high throughput between two specific VPCs.
4. Which service integrates natively with SD-WAN vendors using GRE tunnels?

[!NOTE] Answers: 1. No. 2. Transit Gateway. 3. False (TGW adds a processing fee per GB). 4. Transit Gateway Connect.

Muddy Points & Cross-Refs

• Quotas: Remember that VPC Peering has a hard limit of 125 active peering connections per VPC. If your architecture requires 126 connections, you must migrate to Transit Gateway.
• Route Table Updates: For VPC Peering, you must manually update VPC route tables. For TGW, while the TGW has its own dynamic route tables, you still need to add static routes in the VPC subnets pointing to the TGW ID.
• Security Groups: You can reference Security Groups across VPC Peering connections (within the same region), but you cannot reference SGs across a Transit Gateway.

Comparison Tables

[!TIP] For the exam, if the question mentions "thousands of VPCs," "Multicast," or "Centralized Management," the answer is almost always Transit Gateway. If it emphasizes "Lowest possible cost" or "Lowest latency" for a few VPCs, look at VPC Peering.