AWS Landscape 9: Peering Connections

Secure and scalable VPC-to-VPC communication is essential for multi-account AWS SAP landscapes. Instead of creating multiple VPC peering connections (which can become complex and hard to manage), this design leverages AWS Transit Gateway (TGW) as a centralized hub to simplify routing, control east-west traffic, and enable inter-VPC and inter-region connectivity.

Key benefits:

• Centralized routing: All VPCs communicate via a single TGW.
• Scalable: Supports hundreds of VPCs without mesh complexity.
• Secure: Uses private IPs; Security Groups and NACLs enforce access.
• Disaster Recovery Ready: Inter-region peering can replicate traffic to DR region.

Objective:

Enable secure, scalable inter-VPC communication across multiple AWS accounts and regions using Transit Gateway to:

• Simplify routing and avoid complex peering meshes.
• Allow SAP workloads, shared services, logging, and security accounts to communicate.
• Support DR and backup replication across regions if required.

Design Overview

• Transit Gateway (TGW) deployed in Network Service Account acts as the routing hub.
• All workload and shared services VPCs attach to the TGW.
• Traffic uses private IPs, no direct VPC-to-VPC peering is needed.
• Optional Inter-Region TGW Peering can connect Singapore → Tokyo for DR replication.

Technical Steps for Peering Connections

Step 1: Create Transit Gateway
Log in to Network Service Account.
Navigate to VPC → Transit Gateway → Create Transit Gateway:

• Name: SAP-TGW

• ASN: e.g., 64512

• Enable Default Route Table
• Enable DNS support if cross-VPC name resolution is required

Step 2: Attach VPCs to TGW

For each VPC (Workload, Shared Services, Security, Logging):

• Navigate to VPC → Transit Gateway Attachments → Create Attachment
  
• Select the VPC, subnets (1 per AZ for attachment), and TGW
  
• Wait until attachment status is available

Step 3: Configure Route Tables

In TGW, associate each VPC attachment with the TGW route table.
Update VPC route tables:

• Private subnets → route to other VPCs via TGW (0.0.0.0/0 or relevant CIDRs)
• Enables inter-VPC communication for SAP workloads and shared services

Step 4: Security Groups & NACLs

• Ensure Security Groups allow required intra-VPC communication.
• NACLs can be default or customized per environment for additional security.

Step 5: Optional – Inter-Region Peering

Enable TGW Inter-Region Peering if connecting Singapore → Tokyo region:

• Supports DR workloads and backup replication
  
• Maintains private IP routing between regions

Diagram – VPC-to-VPC Peering via Transit Gateway

Centralized TGW Routing

• All VPCs communicate through Transit Gateway
• Eliminates the need for multiple VPC peering connections

Shared Services, Security, Logging VPCs

• Reachable from all workload VPCs
• Centralized services for CI/CD, monitoring, and audit logging

Private IP Communication

• All traffic between VPCs uses private IPs for security and low latency

Simplified Connectivity

• New VPCs can attach to TGW without creating additional peering
• Reduces management overhead and scaling complexity

Notes and Best Practices

• TGW simplifies routing compared to multiple VPC peering connections.
• Supports east-west traffic for SAP workloads, shared services, logging, and security accounts.
• Highly scalable: Can attach hundreds of VPCs without mesh complexity.
• Inter-region peering supports disaster recovery replication.
• Maintain proper Security Group and NACL policies to enforce least privilege access across VPCs.