Hub-and-Spoke Connectivity with an Overlapping Acquisition Network
A retail group operates 14 cloud accounts and one on-premises data center. The data center connects to the cloud over two 10 Gbps dedicated links that terminate in different physical paths. Three production VPCs use 10.0.0.0/8, while an acquired company uses 10.20.0.0/16, which overlaps a partner network reachable from on-premises. The security team requires all traffic between on-premises and production VPCs to pass through a central inspection layer, but the current full-mesh peering has 38 peerings and no clear owner. During the last incident, a route change in one VPC bypassed inspection for 40 minutes. The network team wants to add two new VPCs per quarter and cannot add another full-mesh peering. A payment application must keep round-trip latency below 8 ms to the data center. The acquired company needs outbound internet access during a 90-day integration and cannot re-IP its servers immediately.
1. Design the connectivity topology. Explain how it scales beyond the current full mesh and keeps inspection mandatory.
Read the worked answer
Reasoning: Full-mesh peering does not scale to 14 accounts plus two VPCs per quarter, and it makes routing policy unenforceable. A single transit hub with a flat route table would still let a VPC bypass inspection. Two dedicated links are enough only if they terminate on diverse paths and are actively tested.
Recommendation: use a hub-and-spoke transit architecture with separate route domains for production, nonproduction, and the acquired company. Attach the inspection VPC to the production domain so on-premises-to-production and production-to-internet traffic is segmented. Use two transit gateways or two route-table domains with BGP metrics preferring the primary link and failing over automatically. Do not peer VPCs directly. Enforce a default route from production spokes to inspection, and block direct routes to on-premises. Keep the payment application in a latency-sensitive route domain that still traverses inspection but uses a local egress point if inspection can be scaled there. Add route-table tests to CI and alert on any route that bypasses inspection.
2. Resolve the 10.20.0.0/16 overlap for the 90-day integration without breaking partner access.
Read the worked answer
Reasoning: 10.20.0.0/16 exists on both the acquired company and the partner network. Merging them into one routing domain creates ambiguous destinations; longest-prefix matching will not save you if the same prefix is advertised twice.
Recommendation: do not connect the acquired company to the partner network until the overlap is resolved. For the 90-day integration, place the acquired company behind a private NAT gateway for outbound-only internet and limited outbound access to approved services. That avoids re-IPing servers and keeps return traffic deterministic. Do not use NAT for inbound partner access or for source-IP-based security policy, because the original addresses are hidden. In parallel, re-IP the acquired company into a non-overlapping /16, update DNS, and migrate in waves. For any temporary exception, use a separate route domain and explicit /32 or /24 routes, not a summary route. Track the exception with an expiry date and remove the NAT path after re-IP.
3. What controls prevent another 40-minute inspection bypass, and how should inspection fail?
Read the worked answer
Reasoning: The bypass happened because a VPC route table could override the central path. Inspection is effective only if it is the only path and if the appliances see both directions of the flow.
Recommendation: make inspection mandatory by policy, not documentation. Use organization-level guardrails that deny route-table changes removing the inspection default route, and alert on drift. Put the inspection appliances in a dedicated VPC with health checks and autoscaling; enable appliance mode on the transit attachment so return traffic follows the same path. Use symmetric routing: spokes send 0.0.0.0/0 to inspection, inspection sends to the hub, and the hub sends back to inspection. Test failure by disabling one link and one appliance during business hours. If inspection fails, fail closed for payment traffic and alert; do not fail open. Keep a break-glass route with an approval ticket and automatic expiry.