How would you design networking for an organisation with dozens of AWS accounts?
Show the answer
Say this first
A dedicated network account owns the transit gateway, the Direct Connect gateway, central egress and inspection, and shared DNS and endpoints. Workload accounts get VPCs from an IPAM pool and attach to the TGW, which is shared through AWS RAM. Segmentation lives in TGW route tables, inspection in a central firewall VPC with appliance mode, and internet egress goes through NAT gateways in one egress VPC per region. GCP does the same with Shared VPC, Azure with a hub VNet or Virtual WAN.
Go deeper
The pieces
- Network account: TGW per region (shared via RAM), TGW peering between regions, Direct Connect gateway with transit VIFs, VPN backup.
- IPAM: pools per region and environment so every VPC gets a unique, summarizable range.
- Inspection VPC: AWS Network Firewall or GWLB with third-party firewalls, for east-west and egress.
- Egress VPC: NAT gateways per AZ. Spokes have no IGW or NAT of their own.
- Shared services VPC: interface endpoints shared through private hosted zones, Route 53 Resolver endpoints and rules shared with RAM, directory services.
- Guard rails: service control policies that stop spoke accounts from creating IGWs or peering on their own.
Alternative: VPC sharing
AWS RAM can share subnets of one VPC with many accounts. Accounts launch resources in shared subnets, the network team owns routing. Fewer VPCs and attachments, but a bigger blast radius per VPC.
Trade-offs to state out loud
- Central egress saves NAT gateway hours across many VPCs but adds TGW processing charges per GB.
- Central inspection adds a hop and cost; inspect what policy requires, not everything by default.
- One TGW per region is a shared dependency; change control on its route tables matters.
Other clouds
- GCP Shared VPC: a host project owns the VPC and subnets; service projects use them. Combine with NCC or VPN and Interconnect in the host project.
- Azure: a hub VNet per region with Azure Firewall, gateways and DNS resolver, spokes per subscription, policy to enforce UDRs. Virtual WAN is the managed version.
They will ask next
How do spokes resolve names for centrally hosted interface endpoints?
Private DNS is turned off on the shared endpoints. The network team creates private hosted zones for the service names, aliases them to the endpoints, and associates the zones with every spoke VPC.
Why stop spoke accounts from creating their own internet gateways?
A stray IGW bypasses the central firewall and egress logging. A service control policy makes the central path the only path.
Traps
- Designing without IPAM and discovering overlap after the first acquisition.
- Forgetting cross-region traffic needs TGW peering with static routes.