AWS Organizations and multi-account architectures have become the standard for teams beyond a certain size — and for good reason. Separate accounts provide hard blast-radius boundaries, clean billing separation, and independent IAM domains. But once you're running workloads across multiple accounts, you need a deliberate strategy for how those VPCs connect to each other.
There are three primary topology patterns, each with different scaling characteristics, costs, and operational tradeoffs. Choosing the wrong one early is expensive to reverse. This post breaks down each pattern, when it fits, and what it actually costs at different scales.
Why Multi-Account Topology Matters
In a single-account setup, the worst-case blast radius of a misconfigured IAM role or a compromised workload is the entire account. In a multi-account setup, each account is a hard isolation boundary — a compromised role in the dev account can't read production S3 buckets because they're in a different account with different IAM policies.
But network isolation is separate from account isolation. VPCs in different accounts can be connected if you choose to connect them. The topology you design determines what can talk to what — and getting that wrong is how you end up with a dev workload that has a network path to a production database.
Multi-account topology decisions also affect cost, operational complexity, and how easy it is to enforce isolation. All three patterns below make different tradeoffs across these dimensions.
Pattern 1: Hub-and-Spoke with Transit Gateway
The hub-and-spoke pattern uses a single Transit Gateway (TGW) — typically deployed in a dedicated network services account — as the central routing hub. All spoke VPCs (in dev, staging, production, and shared-services accounts) attach to this TGW via Transit Gateway attachments. Traffic between any two spokes flows through the TGW.
# Share a TGW from the network account to other accounts via RAM
aws ram create-resource-share \
--name "central-tgw-share" \
--resource-arns arn:aws:ec2:us-east-1:111122223333:transit-gateway/tgw-0abc12345 \
--principals 444455556666 777788889999 \
--region us-east-1
# Attach a spoke VPC to the shared TGW (run in spoke account)
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-0abc12345 \
--vpc-id vpc-0spoke12345 \
--subnet-ids subnet-0a1b2c3d subnet-0e4f5a6bThe attachment must then be accepted in the network account (or auto-accepted if the TGW has auto-accept enabled for RAM shares):
# Accept the attachment in the TGW owner account
aws ec2 accept-transit-gateway-vpc-attachment \
--transit-gateway-attachment-id tgw-attach-0abc12345Pros
- Centralized routing — adding a new spoke requires one attachment and a route table update, not N new peering connections
- Supports transitive routing — spokes can reach each other without direct peering
- Centralized egress — route all internet-bound traffic through an inspection or NAT VPC in the hub
- TGW route tables support traffic segmentation — you can prevent dev spokes from reaching prod spokes at the routing layer
- Scales to thousands of attachments per TGW
Cons
- Cost: $0.05/hr per attachment (~$36/month per VPC) plus $0.02/GB of data processed through the TGW
- The TGW is a routing dependency — a TGW route table misconfiguration can affect all spokes simultaneously
- Cross-region TGW peering adds additional latency and cost ($0.02/GB for inter-region TGW traffic)
Pattern 2: Full-Mesh VPC Peering
In a full-mesh topology, every VPC that needs to communicate with every other VPC has a direct peering connection between them. There is no central hub — each pair communicates directly.
The number of peering connections required for N VPCs to be fully connected is N × (N−1) / 2. For 5 VPCs: 10 connections. For 10 VPCs: 45 connections. For 20 VPCs: 190 connections. At each VPC, you also need route table entries for every peer — and those entries must be maintained in every route table in the VPC.
# Create a peering connection between two VPCs in different accounts
aws ec2 create-vpc-peering-connection \
--vpc-id vpc-0abc12345 \
--peer-vpc-id vpc-0def67890 \
--peer-owner-id 444455556666 \
--peer-region us-east-1
# Accept the peering connection in the peer account
aws ec2 accept-vpc-peering-connection \
--vpc-peering-connection-id pcx-0abc12345
# Add routes in both VPCs
aws ec2 create-route \
--route-table-id rtb-0abc12345 \
--destination-cidr-block 10.2.0.0/16 \
--vpc-peering-connection-id pcx-0abc12345Pros
- No per-attachment or data-processing fee — VPC peering charges only the standard inter-AZ or inter-region data transfer rate
- Traffic takes the most direct path — no routing through a hub
- No single point of routing failure
Cons
- Does not scale: The n(n−1)/2 relationship means 10 VPCs = 45 connections, each needing routes on both ends
- Hard limit of 125 active peering connections per VPC (soft default; can be increased via quota request)
- No transitive routing: If A peers with B, and B peers with C, A cannot reach C via B — a direct A–C peering is required
- Route table management becomes a significant operational burden past 8–10 VPCs
Pattern 3: Hybrid — TGW Within Accounts, Peering Between
The hybrid pattern uses Transit Gateway to connect VPCs within each account (or within a group of related accounts), and VPC peering for specific point-to-point connections between account groups. This is common in organizations that have a mix of team-owned accounts and a central platform account.
For example: the platform team runs a TGW in their network account, connecting their shared-services VPCs. The product team runs a TGW in their account connecting their dev/staging/prod VPCs. A single peering connection links the platform TGW attachment VPC to the product team's hub VPC, giving product teams access to shared services without exposing the full platform TGW to every account.
When the Hybrid Pattern Makes Sense
- You have distinct organizational boundaries (platform team, product teams) that should be partially isolated from each other at the network layer
- The number of cross-boundary connections is small and stable — a few peering connections between hubs, not a mesh
- You want TGW cost savings at the account level without paying for TGW attachments for every single spoke across all accounts
Cost Comparison
| Scale | Full Mesh (Peering) | Hub-and-Spoke (TGW) | Notes |
|---|---|---|---|
| 5 VPCs | 10 peering connections ~$0/mo fixed |
5 TGW attachments ~$180/mo fixed |
Peering wins on fixed cost; TGW wins on operational simplicity if you're growing |
| 10 VPCs | 45 peering connections ~$0/mo fixed |
10 TGW attachments ~$360/mo fixed |
Peering route management becomes painful; TGW operational advantage grows |
| 25 VPCs | 300 connections — impractical | 25 TGW attachments ~$900/mo fixed |
Full mesh is not viable; TGW is the only scalable option |
| Data transfer (1 TB/mo) | $0.01/GB cross-AZ $10/TB intra-region |
$0.02/GB TGW processing + $0.01/GB cross-AZ $30/TB intra-region |
TGW adds ~$20/TB processing overhead on top of standard data transfer rates |
Data transfer costs dominate at high-throughput. If you're moving terabytes per month between VPCs, the $0.02/GB TGW processing fee adds up quickly. At 10 TB/month, that's $200/month just in TGW processing — before the standard cross-AZ data transfer charges. For latency-sensitive, high-bandwidth inter-VPC paths (e.g., a microservices mesh), peering between specific VPC pairs may be worth the extra connection management.
When to Use Each Pattern
- Small team, fewer than 8 VPCs, stable topology: Full-mesh peering. The fixed costs are zero, the route management is tractable, and you avoid TGW attachment fees.
- Growing organization, 8+ VPCs, or need for transitive routing: Hub-and-spoke with TGW. The operational simplicity is worth the attachment cost as you scale.
- Multiple distinct org units with different trust levels: Hybrid. Use TGW internally within each unit, peering for controlled cross-unit paths.
- High-throughput internal traffic between specific VPC pairs: Add direct peering alongside TGW for those paths — the $0.02/GB TGW processing fee can be avoided for high-volume, predictable flows.
Visibility Is the Hard Part
Designing a topology is the easy part. Maintaining visibility into what's actually connected — across accounts, across regions, with all the route tables and security group rules that govern reachability — is where most organizations fall down. It's common for multi-account environments to drift from the intended design: a new TGW attachment added for a temporary project that never gets removed, a peering connection that creates an unintended path between environments, a route that was added for debugging and never cleaned up.
Without a topology map that reflects the current state of your network — not the diagram you drew when you designed it — you're operating blind. Audits, incident response, and compliance reviews all require knowing what paths actually exist, not what should exist according to documentation.