Centralized Egress with Overlapping CIDRs Across Accounts

Transit Gateway routing is destination-CIDR based across all attachments in a route table. Overlapping CIDRs are fundamentally ambiguous.

Why it breaks

1. If three VPCs all use 10.20.0.0/16, the Transit Gateway cannot distinguish which attachment a packet for 10.20.1.5 belongs to. It picks one path, so traffic lands in the wrong business unit.
2. Route propagation conflicts: identical prefixes from multiple attachments produce one winner, and the others are not usable for that prefix.
3. Centralized egress via 0.0.0.0/0 to the inspection VPC works only if the inspection VPC can return traffic to the correct originating VPC. With overlapping source CIDRs, the return path is equally ambiguous, so stateful inspection breaks.
4. Isolation requirements are violated because the same prefix space cannot be cleanly segmented by route tables alone.

Options

• Re-IP the overlapping VPCs. The durable fix. Assign unique CIDRs from an IPAM plan, migrate workloads, and retire the duplicates. Costly but removes all ambiguity.
• Private NAT gateway translation. Place a private NAT gateway in each overlapping VPC (or in a per-business-unit egress VPC) to translate the overlapping source range to a unique range before it reaches the Transit Gateway. This preserves the existing IP plan and gives the inspection VPC unique addresses to route back to. It adds a translation hop and must be designed so return traffic is translated back correctly.
• Separate Transit Gateway route tables per business unit to enforce isolation, combined with private NAT for egress. Route table separation alone does not fix overlapping destinations.
• AWS Cloud WAN or a segment-based design can enforce policy, but overlapping CIDRs still require translation or re-IP.

Recommendation

Use private NAT translation as the near-term compliance path for the three overlapping VPCs, with route table segmentation for isolation, and fund a re-IP program as the long-term fix. Validate with flow logs that no cross-business-unit traffic occurs.

The design must enforce two invariants: every internet-bound packet traverses the inspection VPC, and no packet moves between business units except through approved inspection.

Topology

• Each business unit gets its own Transit Gateway route table (or segment) associated with its VPC attachments. No route exists between business unit route tables by default.
• Overlapping VPCs use a private NAT gateway to translate their source range to a unique range before the Transit Gateway attachment. The translated range is what the inspection VPC and return path use.
• The inspection VPC attaches to the Transit Gateway and to a NAT gateway/internet gateway for egress. Network Firewall policies inspect traffic in both directions.

Routing

• Business unit route tables: default route 0.0.0.0/0 to the inspection VPC attachment; no routes to other business unit attachments.
• Inspection VPC route table: routes back to each business unit's unique (translated) range via that unit's attachment, and default to the internet gateway/NAT.
• On-premises and shared services routes are explicit and only present where approved.

Inspection

• Network Firewall stateful rules allow only approved destinations and log all denies. Egress policy is deny-by-default.
• Enable firewall logging and VPC Flow Logs on the inspection VPC; alert on unexpected cross-unit traffic.

Isolation verification

• Attempt connectivity between business units and confirm it is dropped at the Transit Gateway (no route) and, if routed, at the firewall.
• Confirm that translated addresses are unique and that return traffic reaches the correct unit.
• Document the route table and firewall policy as compliance evidence, and re-test after any change.