ADR-0002: Transit Gateway hub with centralised egress
- Status: Accepted (worked example)
- Date: 2026-10-23
- Deciders: Platform architecture, network engineering, security
Context and Problem Statement
Section titled “Context and Problem Statement”ADR-0001 gives each workload its own account per environment, so we’ll have 100+ accounts. Many workloads need to reach shared services, on-premises systems, and the internet, and security requires inspection of outbound traffic. IP addressing and network topology are among the hardest decisions to reverse.
How should VPCs in many accounts connect to each other, to on-premises, and to the internet?
Decision Drivers
Section titled “Decision Drivers”- Security and auditability: central inspection and logging of internet egress; clear segmentation between prod and non-prod.
- Self-service: a new account gets working connectivity automatically.
- Evolvability: the topology has to grow to 200+ VPCs and a second (EU) region.
- Operational simplicity for a small network team.
- Cost of data processing and NAT.
Considered Options
Section titled “Considered Options”- VPC peering between accounts as needed, each VPC with its own internet access.
- Transit Gateway hub and spoke: one VPC per workload account, attached to a Transit Gateway in the network account, with a central egress/inspection VPC.
- VPC sharing: the network team owns a few large VPCs and shares subnets to workload accounts using AWS RAM.
Decision Outcome
Section titled “Decision Outcome”Chosen option: 2, Transit Gateway hub and spoke with centralised egress, because it scales to hundreds of VPCs, centralises inspection, and keeps each workload’s network in its own account, consistent with ADR-0001.
Supporting choices:
- Amazon VPC IP Address Manager (IPAM) allocates non-overlapping CIDRs from organisation-wide pools, so every new VPC fits the plan.
- Separate Transit Gateway route tables for prod, non-prod, and shared services, so prod and non-prod can’t route to each other.
- An egress VPC in the network account with NAT gateways and AWS Network Firewall; workload VPCs have no internet gateways.
- Account Factory creates the VPC and Transit Gateway attachment as part of the account baseline.
Consequences
Section titled “Consequences”- Good: One place for egress inspection and logging; easier audits.
- Good: New accounts are connected automatically (self-service).
- Good: Segmentation by route table is explicit and reviewable.
- Bad: Transit Gateway charges per attachment and per GB processed; cross-AZ and egress traffic costs need watching.
- Bad: The network account is a critical shared dependency. Its availability matters to everyone (an implicit characteristic).
- Bad: Centralised egress adds a hop and a potential bottleneck.
Confirmation
Section titled “Confirmation”- An SCP denies creating or attaching internet gateways in Workloads OU accounts.
- Every VPC CIDR comes from an IPAM pool (IPAM compliance reports).
- No route exists between prod and non-prod Transit Gateway route tables (automated route table check in the network pipeline).
- VPC Flow Logs are enabled in every VPC (AWS Config rule).
- Monthly Transit Gateway data-processing cost stays under an agreed budget (AWS Budgets alert).
Pros and Cons of the Options
Section titled “Pros and Cons of the Options”1. VPC peering
Section titled “1. VPC peering”- Good: No central component; low latency; no per-GB transit charge for same-AZ traffic.
- Bad: Peering isn’t transitive, so connecting many VPCs becomes a mesh that doesn’t scale.
- Bad: Every VPC has its own internet access, so there’s no central egress inspection.
2. Transit Gateway hub and spoke
Section titled “2. Transit Gateway hub and spoke”- Good: Scales to many VPCs; transitive routing; central egress and on-premises connectivity.
- Good: Each workload keeps its own VPC, so isolation matches the account structure.
- Bad: Per-attachment and data-processing charges; a central dependency.
3. VPC sharing
Section titled “3. VPC sharing”- Good: Fewer VPCs and attachments; the network team controls all routing.
- Bad: Workloads from different accounts share a VPC, which weakens the isolation chosen in ADR-0001.
- Bad: Shared VPC quotas and IP space couple teams together.
- Neutral: Could still be used within a single business unit later, alongside option 2.
More Information
Section titled “More Information”Revisit when:
- the EU region goes live. At that point, multi-region connectivity (Transit Gateway peering, or AWS Cloud WAN for policy-based global networking) needs a new ADR;
- Transit Gateway data-processing costs exceed budget for two months running;
- the egress firewall becomes a measurable latency or throughput bottleneck.
Related: ADR-0001, evolving a cloud platform.
Sources: AWS whitepaper Building a Scalable and Secure Multi-VPC AWS Network Infrastructure (covers Transit Gateway, VPC sharing, and centralised egress); AWS Architecture Blog, The journey to cloud networking.