Active-Active Multi-Region VPC Topology for a Payments Platform
A payments platform is moving from two on-premises data centers to active-active deployments in AWS us-east-1 and eu-west-1, plus Azure West Europe for analytics. The platform has 42 VPCs across the three clouds, peaks at 14 Gbps inter-region, and must keep checkout p99 latency under 90 ms. Customer records must remain in-region for data residency, but a global read-only catalog is replicated every 30 seconds. The current design peers every VPC to every other VPC, and the route table has grown to 1,900 entries. During a recent failover test, checkout traffic in eu-west-1 took 4 minutes to converge because the on-premises data center advertised a summary route over an IPsec tunnel that remained up. The team wants a simpler topology, deterministic failover, and a way to connect Azure analytics without exposing the entire AWS address space. Budget allows one transit gateway per region and one Azure Virtual WAN hub.
1. Recommend a target topology for the three clouds and explain how it reduces route scale and failover convergence. Include how you would handle the on-premises summary route.
Read the worked answer
Use one AWS Transit Gateway (TGW) per region as the regional hub, attach VPCs to the regional TGW, and peer the two TGWs for inter-region traffic. Replace the full-mesh VPC peering with a small number of TGW route tables, for example prod, nonprod, and shared, so each VPC sees only the routes it needs. Summarize VPC CIDRs per region before advertising to on-premises and Azure; advertise 10.10.0.0/16 for us-east-1 rather than 42 individual VPC prefixes. Connect Azure Virtual WAN to the nearest TGW over a route-based IPsec or ExpressRoute connection. The on-premises 10.0.0.0/8 summary is likely the convergence problem: either remove it and advertise more-specific summaries, or make it less preferred with a route map and local preference. Ensure the IPsec tunnel does not remain preferred when the primary path fails. This design gives deterministic path selection because TGW route tables and BGP attributes decide the path, not a stale summary route.
2. How would you enforce data residency for customer records while allowing the global catalog and Azure analytics to work? Describe routing, DNS, and connectivity controls.
Read the worked answer
Keep customer-record VPCs associated only with regional TGW route tables that do not contain inter-region routes to other customer-record VPCs. Use separate VPCs and KMS keys per region. Replication of the read-only catalog can go to a catalog VPC that is allowed to route inter-region, but the customer-record VPC should not accept routes to catalog replicas in other regions unless the data is non-sensitive. Use Route 53 latency-based records for checkout so users go to the nearest region, with health checks driving failover. For Azure analytics, attach the Azure Virtual WAN hub to the nearest TGW and advertise only the analytics VPC CIDR, such as 10.50.0.0/16, into AWS. On the Azure side, use route filters or prefix lists so only the required AWS endpoints are reachable. Do not advertise the entire AWS address space into Azure. Use private endpoints and service endpoints for analytics access, and log all cross-cloud flows.
3. Propose a failover test plan that proves deterministic convergence under 60 seconds and list the metrics you would capture.
Read the worked answer
Test each failure domain separately: TGW peering failure, on-premises IPsec tunnel failure, and Azure VWAN connection failure. Before each test, capture the baseline route table, BGP table, and active path. Shut down the primary path and measure time to first successful checkout request, not just BGP convergence. Use synthetic transactions every 5 seconds from each region. Capture TGW route table changes, BGP updates, packet loss, p99 latency, and application error rate. Require convergence under 60 seconds and no more than 0.1% failed transactions. Verify that traffic returns to the primary only after the primary is healthy and that no flapping occurs. Add BFD or tuned BGP timers only where both sides support them. Document a rollback and repeat the test during a maintenance window. If the on-premises summary route persists, test with it removed or deprioritized.