AWS VPC Setup: Transit Gateway for Multi-Account Networking

Multi-Account AWS VPC Setup with Transit Gateway: A Deep Dive into Scalable Networking

As organizations scale their cloud footprint on AWS, managing network connectivity across numerous Virtual Private Clouds (VPCs) and multiple AWS accounts becomes a formidable challenge. The traditional approach of point-to-point VPC peering quickly devolves into a complex, unmanageable mesh, often dubbed "peering hell." This is where AWS Transit Gateway (TGW) emerges as a game-changer, offering a centralized hub for network connectivity that simplifies routing, enhances security, and provides unparalleled scalability for multi-account architectures.

As Sujay Singh, a senior technology writer at TechNews Venture, I've witnessed firsthand the transformation TGW brings to complex cloud environments. This article will guide you through setting up a robust multi-account networking architecture using AWS Transit Gateway, complete with detailed steps, CLI commands, and best practices.

Overview: The Hub-and-Spoke Revolution

The core concept behind using AWS Transit Gateway for multi-account networking is the hub-and-spoke model. Instead of creating direct peering connections between every VPC (spoke), all VPCs connect to a central Transit Gateway (hub). The TGW then acts as a regional network transit center, facilitating traffic flow between any connected spoke VPCs, VPNs, or AWS Direct Connect connections.

In a multi-account setup, it's a common and highly recommended practice to deploy the Transit Gateway in a dedicated "Network Account." This centralizes network management, simplifies security policy enforcement, and delegates connectivity management to a specialized team, while application teams maintain autonomy over their respective VPCs in their "Spoke Accounts" (e.g., Production, Development, Shared Services accounts).

Key benefits of this architecture include:

• Simplified Routing: Eliminates the need for transitive peering relationships. All spokes route to the TGW, and the TGW handles inter-spoke routing.
• Scalability: Easily add new VPCs or accounts without re-architecting your network. TGW supports thousands of attachments.
• Centralized Network Management: All network policies, routing, and monitoring can be managed from a single point (the Network Account).
• Enhanced Security: Facilitates centralized network inspection, egress filtering, and micro-segmentation capabilities.
• Cost Optimization: Reduces the overhead of managing numerous peering connections and simplifies network troubleshooting.

Prerequisites

Before we dive into the implementation, ensure you have the following:

• Multiple AWS Accounts: For this guide, we'll assume three accounts:
  • Network Account (AWS Account ID: 111122223333) - This account will host the Transit Gateway.
  • Prod Account (AWS Account ID: 444455556666) - This account will host a production application VPC.
  • Dev Account (AWS Account ID: 777788889999) - This account will host a development application VPC.
• AWS CLI Configured: Ensure you have the AWS CLI installed and configured with appropriate credentials for each account. You'll switch between profiles/accounts during the setup.
• IAM Permissions: Users or roles in each account must have permissions to create/manage VPCs, subnets, route tables, Transit Gateway, and AWS Resource Access Manager (RAM).
• VPC Planning: Define non-overlapping CIDR blocks for your VPCs. For our example:
  • prod-vpc-app in Prod Account: 10.10.0.0/16
  • dev-vpc-app in Dev Account: 10.20.0.0/16
• Basic VPC Knowledge: Familiarity with VPCs, subnets, route tables, and security groups is assumed.

Step-by-Step Implementation: Building Your Multi-Account Network

We'll walk through the process step-by-step, providing actual CLI commands for a typical setup in the us-east-1 region.

Step 1: Create VPCs in Spoke Accounts (Prod and Dev)

For brevity, we'll assume the VPCs, subnets, and basic route tables already exist in your respective accounts. We'll focus on the TGW integration. Here's an example of how you would create them, but for this guide, we'll proceed assuming they're ready.

In Prod Account (444455556666):

# Assuming AWS CLI profile 'prod-account' is configured
aws ec2 create-vpc --cidr-block 10.10.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=prod-vpc-app}]' --query Vpc.VpcId --output text --profile prod-account --region us-east-1
# Example Output: vpc-0abcdef1234567890

# Create a private subnet
aws ec2 create-subnet --vpc-id vpc-0abcdef1234567890 --cidr-block 10.10.1.0/24 --availability-zone us-east-1a --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=prod-app-private-a}]' --query Subnet.SubnetId --output text --profile prod-account --region us-east-1
# Example Output: subnet-0123456789abcdef0

# Identify the main route table for this VPC (we'll update it later)
aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-0abcdef1234567890" "Name=association.main,Values=true" --query "RouteTables[0].RouteTableId" --output text --profile prod-account --region us-east-1
# Example Output: rtb-0abcdef1234567890

In Dev Account (777788889999):

# Assuming AWS CLI profile 'dev-account' is configured
aws ec2 create-vpc --cidr-block 10.20.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=dev-vpc-app}]' --query Vpc.VpcId --output text --profile dev-account --region us-east-1
# Example Output: vpc-0fedcba9876543210

# Create a private subnet
aws ec2 create-subnet --vpc-id vpc-0fedcba9876543210 --cidr-block 10.20.1.0/24 --availability-zone us-east-1a --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=dev-app-private-a}]' --query Subnet.SubnetId --output text --profile dev-account --region us-east-1
# Example Output: subnet-0fedcba9876543210

# Identify the main route table for this VPC
aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-0fedcba9876543210" "Name=association.main,Values=true" --query "RouteTables[0].RouteTableId" --output text --profile dev-account --region us-east-1
# Example Output: rtb-0fedcba9876543210

Step 2: Create Transit Gateway in the Network Account

This is the central hub. We'll create it in the Network Account.

# Assuming AWS CLI profile 'network-account' is configured
aws ec2 create-transit-gateway \
    --description "Central Transit Gateway for Multi-Account Network" \
    --options 'AmazonSideAsn=64512,AutoAcceptSharedAttachments=enable,DefaultRouteTableAssociation=enable,DefaultRouteTablePropagation=enable,DnsSupport=enable,VpnEcmpSupport=enable' \
    --tag-specifications 'ResourceType=transit-gateway,Tags=[{Key=Name,Value=TechNews-TGW}]' \
    --query TransitGateway.TransitGatewayId \
    --output text \
    --profile network-account \
    --region us-east-1
# Example Output: tgw-0123456789abcdef0

Explanation of Options:

• AmazonSideAsn=64512: The private Autonomous System Number (ASN) for the TGW. Choose one from the private ASN range (64512 to 65534).
• AutoAcceptSharedAttachments=enable: Automatically accepts VPC attachments shared via RAM. Highly recommended for multi-account.
• DefaultRouteTableAssociation=enable: New attachments are automatically associated with the default TGW route table.
• DefaultRouteTablePropagation=enable: Routes from new attachments are automatically propagated to the default TGW route table.
• DnsSupport=enable: Allows DNS resolution over the TGW.
• VpnEcmpSupport=enable: Enables Equal-Cost Multi-Path (ECMP) for VPN connections.

Step 3: Share the Transit Gateway with Spoke Accounts using AWS RAM

The TGW, being in the Network Account, needs to be shared so other accounts can attach their VPCs to it.

In Network Account (111122223333):

# Create a resource share
aws ram create-resource-share \
    --name "TechNews-TGW-Share" \
    --resource-arns "arn:aws:ec2:us-east-1:111122223333:transit-gateway/tgw-0123456789abcdef0" \
    --principals "444455556666" "777788889999" \
    --permission-arns "arn:aws:ram::aws:permission/EC2TransitGateway" \
    --query resourceShare.resourceShareArn \
    --output text \
    --profile network-account \
    --region us-east-1
# Example Output: arn:aws:ram:us-east-1:111122223333:resource-share/abcdefgh-ijkl-mnop-qrst-uvwxyz123456

This command shares the TGW with the Prod and Dev accounts. They will receive an invitation.

Step 4: Accept the Transit Gateway Share in Spoke Accounts

Each spoke account needs to accept the RAM invitation.

In Prod Account (444455556666):

# List pending invitations
aws ram get-resource-share-invitations --profile prod-account --region us-east-1
# Look for an invitation from the Network Account. Note down the resourceShareInvitationArn.
# Example Output (truncated):
# {
#     "resourceShareInvitations": [
#         {
#             "resourceShareInvitationArn": "arn:aws:ram:us-east-1:444455556666:resource-share-invitation/abcdefgh-ijkl-mnop-qrst-uvwxyz123456",
#             "resourceShareArn": "arn:aws:ram:us-east-1:111122223333:resource-share/abcdefgh-ijkl-mnop-qrst-uvwxyz123456",
#             "senderAccountId": "111122223333",
#             "receiverAccountId": "444455556666",
#             "status": "PENDING"
#         }
#     ]
# }

# Accept the invitation
aws ram accept-resource-share-invitation \
    --resource-share-invitation-arn "arn:aws:ram:us-east-1:444455556666:resource-share-invitation/abcdefgh-ijkl-mnop-qrst-uvwxyz123456" \
    --profile prod-account \
    --region us-east-1

In Dev Account (777788889999):

# List pending invitations
aws ram get-resource-share-invitations --profile dev-account --region us-east-1
# Look for the invitation from the Network Account.

# Accept the invitation
aws ram accept-resource-share-invitation \
    --resource-share-invitation-arn "arn:aws:ram:us-east-1:777788889999:resource-share-invitation/fedcba98-7654-3210-fedc-ba9876543210" \
    --profile dev-account \
    --region us-east-1

Step 5: Create Transit Gateway Attachments from Spoke VPCs

Now that the TGW is shared and accepted, each spoke account can attach its VPC to the TGW.

In Prod Account (444455556666):

# Create TGW attachment for prod-vpc-app
aws ec2 create-transit-gateway-vpc-attachment \
    --transit-gateway-id tgw-0123456789abcdef0 \
    --vpc-id vpc-0abcdef1234567890 \
    --subnet-ids subnet-0123456789abcdef0 \
    --tag-specifications 'ResourceType=transit-gateway-attachment,Tags=[{Key=Name,Value=prod-vpc-app-attachment}]' \
    --query TransitGatewayVpcAttachment.TransitGatewayAttachmentId \
    --output text \
    --profile prod-account \
    --region us-east-1
# Example Output: tgw-attach-0abcdef1234567890

Note: You must specify at least one subnet ID from each Availability Zone that your TGW attachment will span. These subnets are used by the TGW to create network interfaces within your VPC. For high availability, specify subnets in multiple AZs.

In Dev Account (777788889999):

# Create TGW attachment for dev-vpc-app
aws ec2 create-transit-gateway-vpc-attachment \
    --transit-gateway-id tgw-0123456789abcdef0 \
    --vpc-id vpc-0fedcba9876543210 \
    --subnet-ids subnet-0fedcba9876543210 \
    --tag-specifications 'ResourceType=transit-gateway-attachment,Tags=[{Key=Name,Value=dev-vpc-app-attachment}]' \
    --query TransitGatewayVpcAttachment.TransitGatewayAttachmentId \
    --output text \
    --profile dev-account \
    --region us-east-1
# Example Output: tgw-attach-0fedcba9876543210

After creating the attachments, they will move to an "available" state. You can check their status in the Network Account:

aws ec2 describe-transit-gateway-attachments \
    --filters "Name=transit-gateway-id,Values=tgw-0123456789abcdef0" \
    --query "TransitGatewayAttachments[].[ResourceOwnerId,ResourceId,State,TransitGatewayAttachmentId]" \
    --output table \
    --profile network-account \
    --region us-east-1

Step 6: Verify Transit Gateway Route Table

Since we enabled DefaultRouteTableAssociation=enable and DefaultRouteTablePropagation=enable during TGW creation, the VPC CIDRs should automatically propagate to the TGW's default route table.

In Network Account (111122223333):

# Get the default Transit Gateway Route Table ID
aws ec2 describe-transit-gateways \
    --transit-gateway-ids tgw-0123456789abcdef0 \
    --query "TransitGateways[0].Options.AssociationDefaultRouteTableId" \
    --output text \
    --profile network-account \
    --region us-east-1
# Example Output: tgw-rtb-0123456789abcdef0

# Search for routes in the default TGW route table
aws ec2 search-transit-gateway-routes \
    --transit-gateway-route-table-id tgw-rtb-0123456789abcdef0 \
    --filters "Name=state,Values=active" \
    --query "Routes[].[DestinationCidrBlock,TransitGatewayAttachments[0].TransitGatewayAttachmentId,Type]" \
    --output table \
    --profile network-account \
    --region us-east-1

You should see routes for 10.10.0.0/16 and 10.20.0.0/16, with their respective attachment IDs, and type "propagated". This confirms the TGW knows how to reach both VPCs.

Step 7: Update VPC Route Tables

This is a critical step. Each VPC needs to know that to reach CIDR blocks outside its own, it should send traffic to the TGW attachment. For our example, the Prod VPC needs a route to Dev VPC via TGW, and vice-versa.

In Prod Account (444455556666):

# Get the VPC's main route table ID (from Step 1)
# rtb-0abcdef1234567890

# Add a route to the Dev VPC (10.20.0.0/16) via the TGW attachment
aws ec2 create-route \
    --route-table-id rtb-0abcdef1234567890 \
    --destination-cidr-block 10.20.0.0/16 \
    --transit-gateway-id tgw-0123456789abcdef0 \
    --profile prod-account \
    --region us-east-1

In Dev Account (777788889999):

# Get the VPC's main route table ID (from Step 1)
# rtb-0fedcba9876543210

# Add a route to the Prod VPC (10.10.0.0/16) via the TGW attachment
aws ec2 create-route \
    --route-table-id rtb-0fedcba9876543210 \
    --destination-cidr-block 10.10.0.0/16 \
    --transit-gateway-id tgw-0123456789abcdef0 \
    --profile dev-account \
    --region us-east-1

You can also create a default route (0.0.0.0/0) to the TGW in your spoke VPCs if you intend to route all internet-bound or on-premises traffic through a centralized inspection VPC attached to the TGW. This is a common pattern for centralized egress.

Step 8: Testing Connectivity

To test, launch an EC2 instance in a private subnet of prod-vpc-app and another in a private subnet of dev-vpc-app. Ensure their security groups allow ICMP (ping) from the respective CIDR blocks (e.g., Prod SG allows 10.20.0.0/16, Dev SG allows 10.10.0.0/16).

From the Prod EC2 instance, you should be able to ping the Dev EC2 instance's private IP, and vice-versa. Remember to use bastion hosts or Session Manager to connect to your private instances.

Security Considerations

Implementing a multi-account network with Transit Gateway introduces powerful capabilities, but also requires careful attention to security:

• IAM Permissions: Strictly control who can create, modify, and delete TGWs, attachments, and RAM shares. Use least privilege principles for IAM roles/users in both the Network and Spoke accounts.
• Network ACLs (NACLs) and Security Groups: Continue to use NACLs at the subnet level and Security Groups at the instance level within each VPC to control traffic flow. TGW routes traffic between VPCs but does not inspect or filter it.
• Centralized Egress/Ingress VPC: For robust security, consider creating a dedicated "Inspection VPC" in the Network Account. Route all internet-bound traffic from spoke VPCs (using a 0.0.0.0/0 route to TGW) through this inspection VPC, where you can deploy AWS Network Firewall or third-party firewall appliances.
• TGW Route Table Segmentation: For more complex scenarios, use multiple TGW route tables. For example, you might have one route table for production-to-shared-services traffic and another for dev-to-shared-services, with no direct dev-to-prod routing allowed.
• VPC Flow Logs: Enable VPC Flow Logs on all VPCs and TGW attachments to capture network traffic metadata. Centralize these logs in a security logging account for analysis and auditing.
• CloudTrail: Monitor all API calls related to TGW