Building a solid network foundation in AWS

Building Scalable AWS Multi-Account Networking: From Peering Chaos to Transit Gateway Harmony

Building a robust multi-account AWS network architecture is one of the foundational decisions that will either enable or constrain your organization’s cloud journey. Like many infrastructure choices, what works perfectly with 2-3 accounts can become an operational nightmare at 10+ accounts.

I want to walk you through three approaches to AWS multi-account networking, showing you what actually happens when you implement each one at scale, and why getting your network foundation right enables everything else.

What Makes a Great Multi-Account Network?

Before diving into specific approaches, let’s establish what we’re trying to achieve. A scalable multi-account network needs to support several core requirements:

Traffic Inspection

You need visibility and control over what flows between your accounts. This isn’t just about security; it’s about compliance, troubleshooting, and understanding your application dependencies. When you have multiple accounts, you need a central point where you can inspect east-west traffic and apply consistent security policies.

Horizontal Scaling

Adding new AWS accounts should be simple and repeatable, not an exponential complexity nightmare that requires updating dozens of existing configurations. Your network architecture should scale linearly, not exponentially.

Standardized Onboarding

Every new account should follow consistent networking patterns. Manual, snowflake configurations don’t scale and create operational debt. You need Infrastructure as Code approaches that ensure consistency across all accounts.

Hybrid Connectivity

Your AWS accounts need reliable, standardized connectivity to on-premises systems, and this connectivity should be easy to extend to new accounts without creating separate VPN connections for each workload.

Let’s see how different networking approaches handle these requirements.

VPC Peering: The Direct Connection Trap

VPC peering is usually where everyone starts, and for good reason. With your first few accounts, it feels elegant and straightforward.

The Simple Beginning

You have two AWS accounts that need to communicate. Create a VPC peering connection, update a few route tables, and you’re done. The connection is direct, the latency is minimal, and security groups can reference each other across the peering connection. It’s clean, simple, and works perfectly.

What works well with VPC peering:

• Point-to-point connections between VPCs
• Route tables pointing to peered CIDR ranges
• Security groups can reference peered VPC security groups
• No additional AWS services required

Platform Expansion Reality

Success brings growth. You add a third account for shared services. Now you need three peering connections to ensure everything can communicate. Still manageable.

Add a fourth account. Now you have six peering connections. Add a fifth account, and you’re managing ten connections. By the time you reach six accounts, you’re looking at up to fifteen potential peering connections.

Here’s where the math becomes your enemy. With 6 accounts, you potentially need 15 peering connections. With 10 accounts? 45 connections.

The Scaling Reality Check

The problems aren’t just about connection count:

Route Table Explosion: Each VPC needs routes to every other VPC it communicates with. Adding a new account means updating route tables across multiple existing VPCs.

No Transitive Routing: VPC peering connections don’t support transitive routing. If Account X peers with Account Y, and Account Y peers with Account A, Account X cannot reach Account A through Account Y. Every connection must be direct.

Operational Overhead: Each new account requires multiple manual peering setups, route table management becomes exponentially complex, and there’s no standardization. Every connection becomes a bespoke configuration.

Where Peering Breaks Down

Traffic Inspection Challenge: Want to inspect traffic between Account A and Account C? With peering, that traffic flows directly between VPCs. There’s no central point to insert inspection. You have multiple connections, and security groups and NACLs only get you so far. There’s no logical place to put your Network Firewall.

Hybrid Connectivity Nightmare: When looking at hybrid connectivity for the mesh network, every VPC that needs to connect to the on-premises datacenter needs its own VPN connection. This is because VPC peering does not support transitive routing. You cannot route traffic from Workload X through the peering with Workload Y to the on-premises datacenter.

You have to create a new VPN connection terminating in each workload account.

Let’s say you need to add a monitoring account to ensure you have full platform observability. Adding this monitoring account that needs access to all others requires five new peering connections and route table updates in every existing VPC. One new account creates massive operational overhead.

VPC Sharing: Everything Through Central Infrastructure

Looking at the peering chaos, there’s an obvious solution that seems to address every single pain point: VPC sharing.

The Logical Solution

Why not share one well-designed VPC across all accounts?

This is why VPC sharing looks so attractive:

• Single VPC to manage, no more juggling route tables across multiple VPCs
• Perfect spot for centralized traffic inspection, everything flows through one network
• One place for hybrid connectivity: terminate your VPN once, serve everyone
• Simplified routing, it’s just normal VPC routing, no complex peering mesh

On paper, this solves every single problem we had with peering. Your security team gets visibility, your operations team gets control.

Implementation Reality

We start back in the same place with two AWS accounts. Instead of peering the VPCs, we share one VPC between accounts. We create the Network account, this account creates the shared VPC and workload account subnets.

With just two accounts, Workload X gets some subnets, Workload Y gets others, but they’re all in the same VPC owned by a central network account. No peering connections to manage, no route tables pointing everywhere. Everything can talk to everything through normal VPC routing.

Adding a new account is simple: create a new subnet and the necessary IAM roles. Then use AWS Resource Access Manager (RAM) to share it to the new account.

Growth and Benefits

Now we add hybrid connectivity, and look how elegant this is. One VPN Gateway, one connection to on-premises, and all workload accounts get access through the shared VPC. No multiple VPN connections, no complex routing, just clean, centralized connectivity. Your network team sets it up once, and every account benefits.

Add AWS Network Firewall for traffic inspection. We can inspect all traffic flowing between accounts, all VPN traffic from on-premises, everything in one place. Your security team finally has the visibility they’ve been asking for. One firewall, one set of rules, complete traffic inspection.

At this point, VPC sharing looks like the perfect solution. This is when most organizations think they’ve solved multi-account networking.

Technical Problems vs People Problems

Here’s what actually happens:

Participant accounts can’t create subnets, can’t modify route tables, can’t manage NACLs, can’t create NAT gateways. Every infrastructure request goes through the VPC owner. Your platform team becomes the bottleneck for every single network change.

Development teams can’t even create their own subnets; that’s an owner-only operation. Need a route table change? Owner only. Want a NAT gateway? Owner only. The cloud promise of self-service just died.

And the blast radius is real: A network ACL change can affect all participant accounts. One team’s network mistake has the potential to impact everyone in the shared VPC.

Your platform team went from managing simple VPCs to managing one incredibly complex shared environment serving multiple business units.

So we’ve gone from technical complexity with VPC peering to organizational complexity with VPC sharing. We solved the networking problems but created people problems.

Your platform team has become the bottleneck instead of an enabler. You’re paying senior engineers to manually manage network changes instead of building business value.

Transit Gateway: The Scalable Solution

There has to be a better way. We need something that gives us the technical benefits of centralization without turning our platform team into a ticket-processing factory. We need an approach that scales technically AND organizationally.

What Transit Gateway Provides

AWS Transit Gateway connects your VPCs and on-premises networks through a central hub. This connection simplifies your network and puts an end to complex peering relationships. Transit Gateway acts as a highly scalable cloud router—each new connection is made only once.

Key concepts:

• Transit Gateway is your network hub
• Your account VPCs attach as spokes
• Your routing policies are controlled centrally, making it easier to manage
• Developer teams maintain autonomy over their own VPCs

Building Transit Gateway Step-by-Step

We start in the same place: two AWS accounts with their respective VPCs. Two independent accounts connected through a central coordination system. Clean, elegant, and each account manages its own infrastructure.

Add two more accounts: look how easy this is. Each new account simply connects to the central hub.

Traffic Inspection

Now we need traffic inspection: We deploy AWS Network Firewall in the Transit Gateway network account. All inter-account (east-west) traffic can be inspected without affecting individual account operations.

The traffic flow becomes:

Workload-X → Transit Gateway → Network Firewall → Transit Gateway → Workload-Y

Hybrid Connectivity

Add hybrid connectivity: VPN terminates in the coordination account, giving all connected accounts access to on-premises systems. Unlike VPC peering where every VPC needs its own VPN connection, Transit Gateway allows one VPN connection to serve all attached VPCs.

What Did We Just Build?

An architecture that solves all our original requirements:

• Traffic Inspection: Network Firewall sees all inter-VPC traffic
• Horizontal Scaling: Adding accounts is simple and repeatable
• Standardized Onboarding: Terraform modules enable consistent automation
• Hybrid Connectivity: Single VPN connection serves all VPCs

Infrastructure as Code Implementation

The key is Terraform module approach with a hub-and-spoke architecture:

terraform-vpc-hub: Manages Transit Gateway, Network Firewall, VPN connections

terraform-vpc-spoke: Deploys standard workload VPC + attachment to hub

Account Onboarding Process

1. Deploy Spoke Module: terraform-vpc-spoke creates VPC with standard configuration
2. Automatic Attachment: Spoke automatically connects to Transit Gateway in hub
3. Route Association: Terraform assigns spoke to appropriate route table in the Transitive Network account
4. Security Policies: Standard Network Firewall rules applied via hub module

Why This Architecture Works

Separation of Concerns: Hub team manages shared infrastructure, workload teams deploy spokes

Consistency: Every workload follows the same network patterns

Self-Service: Teams can deploy new workloads without network team involvement

Scalability: Adding workloads doesn’t increase hub complexity

Terraform modules enable standardized networking without manual processes.

Scaling Beyond

For organizations that outgrow Transit Gateway’s regional bandwidth limits or need to manage complex multi-region topologies, AWS CloudWAN provides the next evolution. CloudWAN creates a global network fabric that spans regions and accounts, offering higher aggregate bandwidth and unified policy management across your entire network infrastructure. While TGW excels for regional connectivity, CloudWAN becomes essential when your network demands truly global scale.

The Bottom Line

Transit Gateway solves the fundamental problem: your network should enable teams, not constrain them.

Instead of choosing between technical complexity (VPC peering) and organizational complexity (VPC sharing), Transit Gateway gives you the technical benefits of centralized networking with the organizational benefits of team autonomy.

Getting infrastructure fundamentals right enables everything else.

When your network architecture becomes invisible to your development teams—when they get secure, compliant connectivity without thinking about it—that’s when you know you’ve built the right foundation. Your platform team can focus on building value instead of processing tickets, and your development teams can focus on shipping features instead of fighting infrastructure.

The goal isn’t just to connect your AWS accounts. The goal is to create a network foundation that scales with your organization and enables your teams to move at the speed of business, not the speed of infrastructure tickets.