AWS Multi-Account and Multi-Region Connectivity Guide

This guide covers the architectural patterns and implementation strategies for interconnecting VPCs, AWS accounts, and Regions. It focuses on selecting the right tool (Peering, Transit Gateway, or PrivateLink) based on requirements for scalability, transitive routing, and security.

Learning Objectives

By the end of this study guide, you should be able to:

• Differentiate between VPC Peering, AWS Transit Gateway, and AWS PrivateLink.
• Implement a hub-and-spoke network architecture using Transit Gateway across multiple accounts.
• Resolve IP address overlap issues using PrivateLink or NAT solutions.
• Utilize AWS Resource Access Manager (RAM) to share networking resources across an organization.
• Evaluate inter-region vs. intra-region connectivity patterns for latency and cost.

Key Terms & Glossary

• VPC Peering: A networking connection between two VPCs that enables routing traffic between them using private IPv4 or IPv6 addresses.
• Transit Gateway (TGW): A network transit hub used to interconnect VPCs and on-premises networks through a central point.
• Transitive Routing: The ability for traffic to pass through one VPC (or hub) to reach another. VPC Peering does not support this; Transit Gateway does.
• AWS PrivateLink: A technology that provides private connectivity between VPCs, AWS services, and on-premises applications without exposing traffic to the public internet.
• AWS RAM (Resource Access Manager): A service that allows you to share AWS resources (like TGWs or Subnets) with any AWS account or within your AWS Organization.
• VPC Sharing: An architecture where multiple AWS accounts create their application resources (EC2, RDS) in shared, centrally managed VPC subnets.

The "Big Idea"

As AWS environments grow from single-account setups to multi-account organizations, networking shifts from simple 1:1 connections to centralized hub-and-spoke models. The core challenge is balancing connectivity (allowing resources to talk) with isolation (security boundaries) while managing complexity (routing tables and IP space). Choosing the wrong pattern leads to "mesh fatigue" (too many peering links) or excessive costs.

Formula / Concept Box

Hierarchical Outline

1. VPC Peering Patterns
   • Intra-Region: Low latency, high performance.
   • Inter-Region: Encrypted at the physical layer; uses AWS backbone.
   • Limitations: No transitive routing (A ↔ B ↔ C does not mean A ↔ C).
2. Hub-and-Spoke (Transit Gateway)
   • Centralized Control: One route table to rule them all (or multiple for isolation).
   • TGW Connect: Integration with SD-WAN via GRE tunnels.
   • Multicast: Supported only within TGW.
3. Service-Oriented (PrivateLink)
   • Interface Endpoints: Exposing a service to a consumer VPC.
   • Security: Minimal attack surface; traffic never leaves the AWS backbone.
4. Multi-Account Strategy
   • VPC Sharing: Owners vs. Participants (using AWS RAM).
   • Resource Access Manager: Sharing TGW Attachments across accounts.

Visual Anchors

Choice Logic for Connectivity

PrivateLink Architecture

Definition-Example Pairs

• Transitive Routing: The ability to hop through a central hub.
  • Example: A Shared Services VPC hosts an Active Directory server. Ten other VPCs connect to the Transit Gateway hub to access that single AD server without needing individual peering links to every VPC.
• Interface VPC Endpoint: A regional endpoint that allows private access to services.
  • Example: Using an Interface Endpoint for S3 so that EC2 instances in a private subnet can upload logs without needing a NAT Gateway or Internet Gateway.
• VPC Sharing: Allowing multiple accounts to provision resources into the same VPC subnets.
  • Example: A central Cloud Platform team manages the VPC/Subnets in a master account, while a DevOps team in a separate account deploys EC2 instances into those subnets using AWS RAM.

Worked Example: Connecting Two Accounts via TGW

Scenario: Connect VPC-A (Account 1, 10.1.0.0/16) and VPC-B (Account 2, 10.2.0.0/16) using a Transit Gateway.

1. Create TGW: In Account 1, create the Transit Gateway.
2. Share TGW: Use AWS RAM in Account 1 to share the TGW resource with Account 2 (or the whole Organization).
3. Accept Share: In Account 2, go to the RAM console and accept the resource share invitation.
4. Create Attachments:
   • In Account 1, create a VPC Attachment for VPC-A.
   • In Account 2, create a VPC Attachment for VPC-B.
5. Configure Routing:
   • In VPC-A's route table, add a route: 10.2.0.0/16 → tgw-xxxxxx.
   • In VPC-B's route table, add a route: 10.1.0.0/16 → tgw-xxxxxx.
6. Verify: Ensure Security Groups on both ends allow traffic from the remote CIDR.

Checkpoint Questions

1. Does VPC Peering support traffic transitive through a third VPC?
2. Which service is specifically designed to handle connectivity between VPCs with overlapping CIDR blocks without complex NAT?
3. What AWS service must be enabled to share a Transit Gateway across different AWS accounts in the same Organization?
4. True or False: Inter-Region VPC Peering traffic stays on the public internet.

[!TIP] Answers: 1. No; 2. AWS PrivateLink; 3. AWS Resource Access Manager (RAM); 4. False (It stays on the AWS Global Backbone).

Muddy Points & Cross-Refs

• Overlapping IPs: If VPC A and VPC B both use 10.0.0.0/16, you cannot use VPC Peering. You must use PrivateLink (to expose specific services) or Transit Gateway with a complex NAT setup.
• MTU Issues: Inter-region peering and TGW peering support a maximum MTU of 1500 bytes (no Jumbo Frames). Intra-region VPC peering supports 9001 bytes.
• Cross-Ref: See Chapter 8 (Hybrid Networking) for how to extend this TGW setup to on-premises via Direct Connect Gateway.

Comparison Tables

VPC Peering vs. Transit Gateway