Multi-Account and Multi-Region AWS Connectivity Architecture

This study guide focuses on designing scalable, resilient, and efficient routing strategies across multiple AWS accounts and Regions. Mastering these patterns is critical for the AWS Certified Advanced Networking - Specialty (ANS-C01) exam.

Learning Objectives

• Evaluate connectivity options (VPC Peering, Transit Gateway, PrivateLink) based on scale and performance.
• Design hub-and-spoke architectures to simplify management in multi-account environments.
• Implement strategies for managing overlapping IP addresses using PrivateLink or NAT patterns.
• Understand the use of AWS RAM for sharing network resources (Subnets, Transit Gateways) across accounts.

Key Terms & Glossary

• Transitive Routing: The ability for traffic to pass through one network entity to get to another (e.g., A → B → C). VPC Peering does not support this; Transit Gateway does.
• AWS RAM (Resource Access Manager): A service that allows you to share AWS resources (like TGWs or subnets) with other AWS accounts or within an Organization.
• Interface VPC Endpoint (PrivateLink): A technology that enables private connectivity between VPCs and AWS services without exposing traffic to the public internet.
• Quotas/Limits: Constraints such as the maximum number of VPC Peering connections (typically 125) or TGW route table entries.

The "Big Idea"

In the early stages of cloud adoption, companies often use VPC Peering for simple 1-to-1 connections. However, as organizations grow to hundreds of accounts and VPCs, the "mesh" of peering connections becomes unmanageable ($N(N-1)/2$ complexity). The transition to AWS Transit Gateway provides a centralized "hub" that acts as a cloud router, enabling a simpler management model and supporting complex routing logic like centralized inspection and egress.

Formula / Concept Box

Hierarchical Outline

1. VPC Peering Architecture
   • Intra-Region vs. Inter-Region: Low latency, encrypted at the physical layer.
   • Limitations: No transitive routing; cannot overlap CIDRs.
2. AWS Transit Gateway (TGW)
   • Attachments: VPCs, VPNs, Direct Connect Gateways.
   • Routing: Multiple route tables allow for complex traffic segmentation (e.g., Prod vs. Dev).
   • TGW Peering: Connects TGWs across Regions with support for static routing.
3. AWS PrivateLink
   • Architecture: Service Provider (NLB) → Service Consumer (Interface Endpoint).
   • Use Case: Sharing a specific service across overlapping VPC CIDRs.
4. VPC Sharing (Multi-account)
   • Mechanism: Owner account shares subnets with Participant accounts via AWS RAM.
   • Benefit: Simplifies IP management and allows resource isolation within the same VPC infrastructure.

Visual Anchors

Transit Gateway Hub-and-Spoke

Inter-Region TGW Peering

\begin{tikzpicture}[scale=0.8, every node/.style={transform shape}] \draw[thick, blue] (0,0) circle (2cm); \node at (0,2.3) {Region A (us-east-1)}; \draw[thick, orange] (6,0) circle (2cm); \node at (6,2.3) {Region B (eu-west-1)};

% TGW A \draw[fill=gray!20] (-0.5,-0.5) rectangle (0.5,0.5); \node at (0,0) {TGW A};

% TGW B \draw[fill=gray!20] (5.5,-0.5) rectangle (6.5,0.5); \node at (6,0) {TGW B};

% Peering Connection \draw[dashed, thick, <->] (0.5,0) -- (5.5,0); \node at (3,0.5) {TGW Peering};

% Spoke VPCs \draw[fill=green!10] (-3,-3) rectangle (-1.5,-2); \node at (-2.25,-2.5) {VPC 1}; \draw[->] (-2.25,-2) -- (-0.4,-0.4);

\draw[fill=green!10] (7.5,-3) rectangle (9,-2); \node at (8.25,-2.5) {VPC 2}; \draw[->] (8.25,-2) -- (6.4,-0.4); \end{tikzpicture}

Definition-Example Pairs

• Resource Access Manager (RAM): A service that shares resources between accounts.
  • Example: Sharing a Transit Gateway created in a Network Services account with 50 Spoke accounts to centralize connectivity.
• TGW Connect: A feature that enables high-bandwidth connectivity using GRE tunnels over TGW attachments.
  • Example: Integrating an SD-WAN virtual appliance in a VPC directly with the Transit Gateway to extend the corporate WAN into AWS.

Worked Examples

Scenario: Managing Overlapping IPs

Problem: Your company acquired a startup. Both companies use 10.0.0.0/16. You need the startup's "Order API" to be accessible by your main application without re-addressing the startup's entire network.

Step-by-Step Solution:

1. Start-up Side: Create a Network Load Balancer (NLB) in front of the Order API instances.
2. Start-up Side: Create an Endpoint Service configuration pointing to the NLB.
3. Main App Side: Whitelist the Main App's Account ID in the Startup's Endpoint Service permissions.
4. Main App Side: Create an Interface VPC Endpoint (PrivateLink) in a local subnet.
5. Result: The Main App accesses the API via a local IP address (e.g., 10.0.1.50) assigned to the endpoint, bypassing the IP overlap conflict entirely.

Checkpoint Questions

1. Can traffic flow from VPC A to VPC C if they are both peered to VPC B, but not to each other? (No, VPC peering is non-transitive).
2. Which AWS service allows two accounts to use the exact same VPC CIDR while still communicating between specific services? (AWS PrivateLink).
3. What is the maximum bandwidth of a single VPC-to-TGW attachment? (50 Gbps).
4. True or False: Inter-Region TGW peering supports BGP for route propagation. (False: Currently requires static routes).

Muddy Points & Cross-Refs

• Transitive Routing: Often confused with VPC Peering. If you see "transitive" on the exam, think Transit Gateway or Transit VPC (Software VPN).
• MTU Sizes: VPC Peering supports 9001 bytes (Jumbo frames) within a region. Transit Gateway supports Jumbo frames only for VPC attachments, but decreases to 1500 for TGW Peering across regions.
• Route Propagation: TGW can propagate routes automatically from VPCs, but VPC Peering requires manual route table updates.

Comparison Tables