AWS Landing Zone: Network Architecture — Transit Gateway, the Shared Services & Network Account, Centralized Egress/Ingress, Inspection, Direct Connect & IPAM

Where this fits

In an AWS Landing Zone & Control Tower deployment, the first four parts gave you the account structure: AWS Organizations, the OU hierarchy, Control Tower with its mandatory Log Archive and Audit accounts, an SCP guardrail set, and IAM Identity Center for access. Control Tower deliberately stops short of building you an enterprise network — its default is one VPC per provisioned account with no transit, no inspection, and no hybrid links. Network Architecture is where the platform team fills that gap: a dedicated Network account that owns an AWS Transit Gateway hub, shared services every workload depends on, centralized egress and ingress so the internet edge is governed in one place, traffic inspection that no team can bypass, Direct Connect for the data-center backhaul, and an Amazon VPC IPAM plan so no two VPCs ever overlap. It produces the most expensive thing in the whole landing zone to change later — the IP plan and the packet path — so it is built once, centrally, and consumed by every spoke account through sharing.

AWS Transit Gateway

What it is

AWS Transit Gateway (TGW) is a Regional, horizontally-scaled router that replaces the VPC-peering mesh with a hub-and-spoke topology. Each VPC, VPN, or Direct Connect connection becomes an attachment to the TGW; routing between attachments is governed by TGW route tables that you associate with attachments and into which routes are propagated. In a landing zone the TGW lives in the Network account and is shared to every workload account through AWS Resource Access Manager (RAM), so a spoke account creates only a VPC attachment — it never owns the hub. TGWs in different Regions are joined with inter-Region peering over the AWS global backbone (encrypted, no public internet), giving you a global mesh without managing a single tunnel.

Why it matters

VPC peering does not transit: it is strictly point-to-point and non-transitive, so n VPCs that all need to talk require n(n-1)/2 peerings, each with its own route-table entries to maintain. At 40 VPCs that is 780 peerings — operationally unmaintainable and well past several account limits. Transit Gateway collapses that to n attachments and a handful of route tables, and — critically — it is the segmentation primitive for the whole network. By giving production, non-production, and shared-services attachments different TGW route tables, you decide which environments can reach which others at the router, not with hundreds of security-group rules. It is also the single chokepoint through which you steer traffic into a firewall (covered under inspection) and out to on-premises (covered under Direct Connect).

How to do it well

Place exactly one TGW per Region in the Network account and share it org-wide with RAM (enable RAM sharing within AWS Organizations first, so principals resolve without invitations). Design multiple TGW route tables to encode segmentation, not a single default table. A proven pattern is one route table per security domain:

Turn off route propagation where you want isolation and use static routes/blackholes to encode “these never talk.” Enable appliance mode on the inspection VPC attachment so the TGW keeps a flow pinned to the same firewall appliance for both directions (without it, asymmetric routing breaks stateful inspection across AZs). Attach the TGW to one subnet per Availability Zone in each VPC (a small dedicated /28 “TGW subnet” per AZ), and remember the attachment is only present in the AZs whose subnets you list — workloads in an un-attached AZ have no path. Manage the TGW, its route tables, associations, and RAM shares entirely as code (Terraform aws_ec2_transit_gateway* resources or CloudFormation).

Artifacts and decisions: the TGW definition and its ASN; the RAM share to the org; the set of TGW route tables encoding your segmentation matrix; the per-AZ TGW subnet standard; the appliance-mode and DNS-support settings; and an inter-Region peering design if you are multi-Region. The headline decision is your segmentation model — how many security domains (route tables) you operate, and which can reach which.

Shared services VPC

What it is

The shared services VPC is a VPC in the Network account (or a dedicated Shared Services account in larger estates) that hosts the infrastructure every workload account consumes but none should run independently: centralized DNS resolution (Route 53 Resolver inbound/outbound endpoints and Resolver rules), directory services (AWS Managed Microsoft AD), interface VPC endpoints (AWS PrivateLink) for AWS service APIs, package and patch mirrors, golden-image and CI agents, and monitoring/log-forwarding collectors. Spokes reach it over the Transit Gateway; they do not peer to it directly.

Why it matters

Without a shared services tier, every workload account re-creates the same expensive plumbing. The clearest example is interface VPC endpoints: each one carries an hourly charge per endpoint per AZ, so standing up endpoints for ssm, ssmmessages, ec2messages, ecr.api, ecr.dkr, logs, sts, kms, and a dozen more in every spoke is both costly and a configuration-drift nightmare. Centralizing them once and sharing access via TGW + centralized Route 53 Resolver turns N copies into one. The same logic applies to DNS: a single, authoritative resolution path (Resolver endpoints plus rules) means on-prem names, AWS private-hosted-zone names, and public names resolve identically from every account — the alternative is per-account DNS that answers differently depending on where you ask.

How to do it well

Make the shared services VPC the DNS hub. Create Route 53 Resolver inbound endpoints (so on-prem can resolve AWS private zones), outbound endpoints with Resolver rules (so AWS forwards on-prem domains to your data-center DNS), and share both the resolver rules and your central private hosted zones to spoke VPCs using RAM. For PrivateLink, decide the topology: either host the interface endpoints centrally and front them with Route 53 private hosted zones that you associate to spoke VPCs (so *.execute-api.<region>.amazonaws.com resolves to the central endpoint ENIs), or — increasingly common — keep latency-sensitive endpoints local and centralize only the long tail. Gateway endpoints for S3/DynamoDB are free and route-table based, so put those in each VPC directly. Run AWS Managed Microsoft AD here and share the directory to spokes. Keep this VPC non-routable to the internet directly — its egress goes through the centralized egress path like any other spoke.

Artifacts and decisions: the shared services VPC CIDR and subnet plan; the Resolver endpoint and rule set; the RAM shares for Resolver rules and private hosted zones; the interface-endpoint inventory and the central-vs-local decision per service; the directory-sharing configuration. The key decision is what is genuinely shared vs. what stays local — over-centralizing latency-sensitive endpoints adds a cross-VPC hop to every API call.

Centralized egress and ingress

What it is

Centralized egress routes all outbound internet traffic from every spoke VPC through a single point — a NAT path and outbound firewall in the Network account — instead of giving each VPC its own NAT gateways and internet gateway. Centralized ingress does the inverse for inbound: public entry points (Application Load Balancers, AWS Global Accelerator, AWS Network Firewall or a third-party appliance) live in a dedicated ingress VPC, and traffic is forwarded inward to workloads in private spokes. Both hang off the Transit Gateway: spokes have no internet gateway of their own, and a default route (0.0.0.0/0) in the spoke points at the TGW, which carries it to the central egress VPC.

Why it matters

Decentralized egress means a NAT gateway in every VPC in every AZ — each one billed hourly and per GB processed — and, worse, an internet edge you cannot govern: outbound filtering, domain allow-listing, and egress logging would have to be re-implemented and audited in dozens of places. Centralizing puts the entire internet boundary in one account where one team owns the NAT gateways, the firewall policy, and the flow logs, and where a single SCP can deny spokes from ever attaching an internet gateway. The cost lever is real but two-sided: you consolidate NAT but you now pay for TGW data processing on every byte that crosses the hub, so the math favors centralization at scale and per-VPC NAT for a handful of chatty, high-throughput VPCs.

How to do it well

Build a central egress VPC in the Network account with public subnets (NAT gateway per AZ + internet gateway) and a TGW attachment; in the egress VPC’s TGW route table, summarize spoke CIDRs back to them, and in each spoke point 0.0.0.0/0 at the TGW. Put AWS Network Firewall (or a gateway-load-balancer-fronted appliance) inline so egress is inspected and domain-filtered, not just NAT’d. For ingress, stand up a dedicated ingress VPC: terminate public ALBs there, optionally front them with AWS Global Accelerator for anycast entry and AWS WAF on the ALB/CloudFront, and forward to workloads over the TGW — or use PrivateLink to publish a workload as an endpoint service that the ingress tier consumes. Keep appliance mode on the inspection/egress attachment so return traffic is symmetric. Always attach a DDoS posture: AWS Shield Advanced on the public ALBs/Global Accelerator and Route 53.

Artifacts and decisions: the egress VPC and ingress VPC designs; the spoke 0.0.0.0/0-to-TGW route standard; the SCP denying AttachInternetGateway/CreateInternetGateway in workload accounts; the Network Firewall / appliance policy; the WAF, Global Accelerator, and Shield Advanced posture for ingress. The decision is centralize-everything vs. allow per-VPC NAT exceptions for a small set of high-volume VPCs where TGW processing cost would dominate.

Traffic inspection

What it is

Traffic inspection is the deep-packet / stateful firewalling and IDS/IPS layer that east-west (VPC-to-VPC), egress (VPC-to-internet), and ingress (internet-to-VPC) traffic passes through so it can be filtered, logged, and alerted on. In an AWS landing zone the inspection point is almost always an inspection VPC attached to the Transit Gateway, containing either AWS Network Firewall (a managed, Suricata-compatible stateful firewall) or a third-party NGFW (Palo Alto, Fortinet, Check Point) deployed behind a Gateway Load Balancer (GWLB) using the GENEVE protocol for transparent insertion. The TGW steers flows into the inspection VPC, the appliance inspects, and the TGW carries the flow onward.

Why it matters

Security groups and NACLs are L3/L4 stateful filters scoped to a VPC; they cannot do domain filtering, TLS-SNI inspection, intrusion detection, or centralized egress allow-listing, and they cannot inspect traffic between VPCs that ride the TGW. Compliance regimes (PCI DSS segmentation, regulated-data boundaries) routinely require an inspection layer that no application team can disable or route around. Putting inspection at the TGW makes it unavoidable: because spokes default-route through the hub and the hub’s route tables force the inspection VPC into the path, there is no spoke-side change that bypasses it.

How to do it well

Decide your inspection patterns explicitly — east-west, egress, and ingress are three different flows and you rarely inspect all three the same way. The cleanest design is a dedicated inspection VPC with the firewall, attached to the TGW, and a TGW routing scheme where the inspection VPC’s TGW route table holds the spoke CIDRs while spokes send everything (including inter-spoke) toward inspection. Enable TGW appliance mode on the inspection attachment — this is non-negotiable for stateful inspection, because it pins both directions of a flow to the same appliance across AZs and prevents the asymmetric routing that silently drops return packets. For Network Firewall, write stateful rule groups (Suricata rules and domain allow/deny lists), enable TLS inspection where policy requires decryption, and ship firewall and flow logs to the Log Archive account. For third-party NGFWs, front them with a GWLB and GWLB endpoints (GWLBe) so insertion is transparent and the appliance fleet auto-scales.

Artifacts and decisions: the inspection VPC design; the choice of AWS Network Firewall vs. third-party NGFW + GWLB; the appliance-mode setting; the stateful rule groups / firewall policy as code; the TLS-inspection scope; the firewall and flow-log destination in Log Archive; the explicit list of which flows (east-west / egress / ingress) are inspected. The major decision is AWS Network Firewall vs. a third-party NGFW — choose Network Firewall for an AWS-native, no-appliance-fleet operating model, and an NGFW + GWLB when you must reuse an incumbent vendor’s signatures, management plane, and SOC tooling.

Hybrid connectivity (Direct Connect)

What it is

AWS Direct Connect (DX) is a dedicated, private physical link between your data center (or colo) and AWS that does not traverse the public internet. You provision a DX connection (a 1/10/100 Gbps dedicated port at a DX location, or a sub-1G hosted connection from a partner), then carve virtual interfaces on it: a private VIF to reach VPCs, a transit VIF to reach a Direct Connect gateway (DXGW) associated with your Transit Gateway, and a public VIF to reach AWS public endpoints over private transport. In a landing zone the DX terminates in the Network account, attaches to the regional TGW via a DXGW + transit VIF, and is shared to spokes the same way every other TGW route is — so on-prem reachability is a hub property, not something each account sets up.

Why it matters

VPN over the internet is fine for a backup path but is throughput- and latency-variable and capped (a single IPsec tunnel tops out around 1.25 Gbps; ECMP across tunnels helps but the internet path remains best-effort). Enterprises with steady, high-volume hybrid traffic — data replication, large file transfer, latency-sensitive line-of-business apps, regulated data that must avoid the public internet — need DX’s dedicated bandwidth and consistent latency. The DXGW is what makes DX scale in a landing zone: one DXGW can associate to TGWs in multiple Regions and advertise on-prem prefixes to all of them (and your summarized AWS CIDR back to on-prem), so a single physical link serves a multi-Region, multi-account estate through the hub.

How to do it well

Never rely on a single DX. Provision two DX connections at two different DX locations (ideally on diverse carriers) for resiliency that meets AWS’s SLA tiers, and add a Site-to-Site VPN as a backup path over the TGW so a total DX failure fails over to the internet automatically (BGP prefers DX; VPN takes over when DX BGP drops). Terminate DX on a transit VIF → DXGW → TGW, not a private VIF to a single VPC, so every account benefits. On the DXGW, set allowed prefixes to the summarized AWS supernet you advertise to on-prem, and keep BGP advertisements summarized (this is where the IPAM plan pays off — a clean, contiguous AWS supernet means one or two prefixes to on-prem instead of dozens). Use a MACsec-capable port if data must be encrypted at the physical layer, or run a private-IP VPN over DX for IPsec. Monitor BGP session state and DX link health via CloudWatch and DX’s SLA metrics.

Artifacts and decisions: the DX connection order(s) and location diversity; the transit VIF and DXGW configuration with allowed prefixes; the DXGW-to-TGW association(s); the backup VPN; the BGP/ASN and route-summarization plan; the encryption choice (MACsec or VPN-over-DX); the CloudWatch monitoring. The headline decision is resiliency tier — single DX (don’t), DX + VPN backup (common), or dual-DX at diverse locations + VPN (for SLA-bound, mission-critical hybrid).

IP address management (IPAM)

What it is

Amazon VPC IP Address Manager (IPAM) is the AWS service that plans, allocates, tracks, and audits the IP space for your whole organization. You create an IPAM (delegated to an IPAM admin account — typically the Network account) and build a pool hierarchy: a top-level pool (your private supernet, e.g. 10.0.0.0/8 or a slice of it), regional pools beneath it, and per-environment or per-OU pools beneath those. Accounts and VPCs draw CIDRs from the pools, and IPAM enforces non-overlap, tracks utilization, and flags non-compliant resources — across all accounts and Regions, integrated with AWS Organizations.

Why it matters

Overlapping CIDRs are the single most common, most painful landing-zone failure: the moment two VPCs (or a VPC and an on-prem range) overlap, Transit Gateway cannot route between them, peering breaks, and the only fix is to re-IP a live network — a migration measured in months. In a manual world (spreadsheets, tribal knowledge) overlap is inevitable as soon as account-vending hands CIDRs to dozens of teams. IPAM makes correct allocation the default: an account-vending pipeline calls IPAM, gets a guaranteed-non-overlapping CIDR from the right pool, and the supernet stays contiguous and summarizable — which is exactly what lets you advertise one or two clean prefixes over Direct Connect instead of a sprawling, unsummarizable mess.

How to do it well

Stand up IPAM before you vend the first workload account, delegated to the Network account, scoped to the organization. Design a pool hierarchy that mirrors your OU and Region structure so allocation encodes intent and stays summarizable:

IPAM (org-scoped, admin = Network account)
└─ top-level pool: 10.0.0.0/8           (entire private supernet)
   ├─ regional pool: 10.0.0.0/12  (us-east-1)
   │    ├─ prod pool:     10.0.0.0/14   → prod VPCs draw /20s
   │    ├─ nonprod pool:  10.4.0.0/14   → dev/test VPCs draw /20s
   │    └─ shared pool:   10.8.0.0/16   → shared services VPC
   └─ regional pool: 10.16.0.0/12 (eu-west-1)
        └─ ...

Set allocation rules on pools (allowed netmask lengths, required tags, locale) so teams can only draw correctly-sized, correctly-tagged CIDRs in the right Region. Wire IPAM into account vending (Account Factory for Terraform / Service Catalog) so a new account’s VPC CIDR comes from IPAM by allocation, never hand-typed. Use monitoring and the utilization dashboard to alert before a pool exhausts, and the compliance view to catch any VPC created with a CIDR outside the plan. Reserve a clean block for the TGW per-AZ /28 subnets and for future growth so summarization to on-prem never fragments.

Artifacts and decisions: the IPAM instance and delegated-admin assignment; the full pool hierarchy with CIDRs; the per-pool allocation rules; the integration into account vending; the reserved blocks (TGW subnets, growth); the utilization alerting. The foundational decision is the supernet and its split — the contiguous private block you own and how it carves by Region and environment, because that single choice determines whether DX advertisements stay summarized for the life of the platform.

Real-world enterprise scenario

Meridian Logistics is a freight and supply-chain company running 9 data centers and a target AWS estate of ~70 accounts across us-east-1 (primary) and eu-west-1 (EU data residency). They have already deployed AWS Control Tower with OUs for Workloads-Prod, Workloads-NonProd, Shared-Services, Infrastructure, and the Control Tower Security OU holding Log Archive and Audit. The platform (network) team owns a dedicated Network account under the Infrastructure OU. They are now executing the Network Architecture phase.

• IPAM first. They delegate IPAM to the Network account and claim 10.32.0.0/11 as Meridian’s AWS supernet (deconflicted with the 9 data centers, which use 10.0.0.0/12 ranges). They split it into a us-east-1 regional pool 10.32.0.0/12 and a eu-west-1 pool 10.48.0.0/12, each carved into prod /14, non-prod /14, and shared /16 pools, with allocation rules forcing /20 VPCs and a mandatory cost-center tag. IPAM is wired into their Account Factory for Terraform pipeline, so every vended account’s VPC CIDR is allocated, not typed.
• Transit Gateway. One TGW per Region in the Network account (ASN 64600/64601), inter-Region peered, RAM-shared to the whole org. They build three TGW route tables per Region — rt-prod, rt-nonprod, rt-shared — so production (47 VPCs) and non-production (18 VPCs) are isolated from each other but both reach shared services and the inspection/egress path. Propagation is off between prod and non-prod; static blackholes document the intent.
• Shared services VPC. A 10.40.0.0/16 shared VPC hosts Route 53 Resolver inbound + outbound endpoints, AWS Managed Microsoft AD, and a consolidated set of interface endpoints (ssm*, ecr.*, logs, sts, kms, secretsmanager). Resolver rules forwarding *.meridian.internal to on-prem DNS, plus the central private hosted zones, are RAM-shared to all spokes. They keep latency-sensitive ecr.dkr endpoints local in the two biggest build accounts after measuring the extra hub hop.
• Centralized egress + inspection. A single egress/inspection VPC per Region runs AWS Network Firewall with a domain allow-list (package mirrors, vendor APIs, AWS endpoints) and Suricata IDS rules; appliance mode is enabled on its TGW attachment. Every spoke default-routes 0.0.0.0/0 to the TGW; an SCP on the Workload OUs denies CreateInternetGateway/AttachInternetGateway so no team can build a side-door egress. Firewall and VPC flow logs ship to the Log Archive account.
• Centralized ingress. A dedicated ingress VPC terminates public ALBs fronted by AWS WAF and AWS Global Accelerator, with Shield Advanced on the accelerator and Route 53. Inbound traffic forwards to private workloads over the TGW.
• Direct Connect. Two 10 Gbps dedicated DX connections at two DX locations on diverse carriers, each with a transit VIF to a Direct Connect gateway associated to both Regional TGWs; allowed prefixes are the single summarized 10.32.0.0/11. A Site-to-Site VPN over the TGW is the automatic BGP failover path. Because IPAM kept the supernet contiguous, on-prem sees exactly one AWS prefix.

Outcome. Meridian onboards a new workload account end-to-end (account vended, VPC CIDR allocated from IPAM, TGW-attached to the right route table, egress + DNS + on-prem reachability inherited) in under 30 minutes, down from a multi-day networking ticket. Interface-endpoint consolidation removed ~60 duplicate endpoint-AZ charges per environment. A PCI segmentation audit passed on the strength of the unavoidable inspection path and the prod/non-prod TGW isolation. And in 18 months of growth across 70 accounts, they have logged zero CIDR-overlap incidents and zero re-IP projects — the metric that, more than any other, proves the network foundation was right.

Deliverables & checklist

• Network account provisioned under the Infrastructure OU as the home for all shared networking.
• Amazon VPC IPAM delegated to the Network account, org-scoped, with the supernet and full pool hierarchy (Region → environment) and allocation rules.
• IPAM wired into account vending (AFT / Service Catalog) so VPC CIDRs are allocated, never hand-typed.
• Transit Gateway per Region in the Network account, RAM-shared to the org, with route tables encoding the prod/non-prod/shared segmentation matrix and inter-Region peering if multi-Region.
• Per-AZ TGW attachment subnets (/28) standardized in every VPC; appliance mode enabled on the inspection attachment.
• Shared services VPC with Route 53 Resolver endpoints + rules, central private hosted zones, consolidated interface endpoints, and AWS Managed Microsoft AD — shared via RAM.
• Centralized egress VPC (NAT + IGW) with spokes default-routing to the TGW; SCP denying spoke internet gateways.
• Traffic inspection (AWS Network Firewall or NGFW + GWLB) inline at the hub, with rule groups as code and logs to Log Archive.
• Centralized ingress VPC (ALB + WAF + Global Accelerator + Shield Advanced) forwarding to spokes over TGW / PrivateLink.
• Direct Connect (resilient: dual-DX or DX + VPN backup) via transit VIF → DXGW → TGW, with summarized allowed prefixes.
• All of the above as IaC (Terraform/CloudFormation/CDK) in the platform repository, with VPC flow logs and firewall logs centralized.

Common pitfalls

• No appliance mode on the inspection attachment. Stateful inspection silently breaks across AZs because return traffic takes a different appliance, dropping connections intermittently. Enable TGW appliance mode on the inspection (and centralized-egress) VPC attachment from day one.
• Hand-allocating CIDRs. Spreadsheets guarantee an eventual overlap, and the fix is a months-long re-IP that TGW routing makes mandatory. Deploy IPAM before the first account is vended and allocate every CIDR from a pool.
• Treating Transit Gateway as a flat router. A single default TGW route table lets every VPC reach every other VPC, collapsing your segmentation. Use multiple TGW route tables (per security domain) and turn off propagation where isolation is required.
• Forgetting TGW data-processing cost. Centralized egress is cheaper than per-VPC NAT up to a point, but every byte crossing the hub incurs TGW data processing; a few ultra-high-throughput VPCs can cost more centralized. Model the traffic and allow per-VPC NAT exceptions for those, governed by exception.
• Leaving side-door internet egress open. If workload accounts can still create an internet gateway, centralized inspection and filtering are theatre. Back the design with an SCP denying CreateInternetGateway/AttachInternetGateway in the Workload OUs.
• A single, un-summarizable hybrid link. One Direct Connect with no backup is a single point of failure, and fragmented CIDRs flood on-prem with dozens of routes. Provision DX + VPN backup (or dual-DX) and keep IPAM’s supernet contiguous so you advertise one or two summarized prefixes.

What’s next

Part 6 of AWS Landing Zone & Control Tower moves from the network to Security & Logging Architecture — centralized CloudTrail and Config in the Log Archive account, GuardDuty, Security Hub, and Macie delegated to the Audit account, and the detective controls that watch everything the network now carries.