Two VPCs, overlapping CIDRs, and a latency-sensitive database
A company acquires a partner and must connect two environments. VPC A (10.0.0.0/16) runs the core app in Hangzhou. VPC B (10.0.0.0/16) runs the partner's analytics stack in Shanghai. Both use 10.0.1.0/24 for their application subnets. The app in A must reach a reporting database in B with low, stable latency, and the security team insists traffic never traverse the public internet. A junior engineer proposes peering the two VPCs and adding routes.
1. Why will the proposed VPC peering fail, and what are the realistic options?
Read the worked answer
VPC peering requires non-overlapping CIDR blocks; 10.0.0.0/16 in both VPCs makes the route tables ambiguous and peering cannot be established as proposed. Adding routes does not fix it because the address space itself collides.
Realistic options:
- Re-IP one side. The cleanest long-term fix is to re-address VPC B (or at least its application subnet) into a non-overlapping range, then peer. This is disruptive but removes the collision permanently and is worth doing if the two networks will integrate further.
- Private connectivity with NAT/translation. Use a private network interconnection between the regions and perform address translation at the boundary so each side sees a distinct range. This preserves existing addressing but adds a translation layer to operate and troubleshoot.
- Move the database. If only one service needs the data, replicating or migrating the reporting database into VPC A's address space may be cheaper than re-architecting the network.
Peering plus routes is not an option; the junior engineer has skipped the CIDR prerequisite. The latency requirement also means whichever option is chosen must be validated with real traffic, not assumed from topology diagrams.
2. Assume the collision is resolved and the two VPCs are connected privately. How should the team meet the low-latency requirement and the no-public-internet rule?
Read the worked answer
Private interconnection keeps traffic off the public internet by design, but latency still depends on path and placement. The team should:
- Measure round-trip time between the app subnet and the database under representative query load before committing; regional distance sets a floor they cannot optimize away with configuration.
- If the measured latency is unacceptable, consider placing a read replica or cache in VPC A so hot queries stay local and only bulk/reporting traffic crosses the link.
- Size the interconnection bandwidth for peak reporting jobs so batch runs do not starve interactive queries.
- Enforce the no-internet rule with route tables and security group rules that permit only the specific app-to-database ports across the private path, and verify with flow logs that no traffic egresses via a NAT gateway. The key judgement is that private connectivity satisfies the security constraint but does not by itself satisfy the latency constraint; placement and workload design do.