VPC Peering, Overlapping CIDRs, and a Shared Database
A company has three VPCs: prod (10.0.0.0/16), staging (10.0.0.0/16), and shared-services (172.16.0.0/16) that hosts a central ApsaraDB for RDS instance and a monitoring collector. Prod and staging were created independently and both use 10.0.0.0/16, which was not noticed until peering was attempted. Prod must reach the RDS instance in shared-services. Staging must also reach the same RDS instance but must never reach prod. All three VPCs are in the same region.
1. Explain why a VPC peering connection between prod and shared-services is possible but a peering between prod and staging is not, and why this blocks a naive hub-and-spoke design.
Read the worked answer
VPC peering requires that the CIDR blocks of the two VPCs do not overlap. Prod (10.0.0.0/16) and shared-services (172.16.0.0/16) do not overlap, so a peering connection between them can be created. Prod and staging both use 10.0.0.0/16, so a peering connection between them cannot be established at all - the route tables would be ambiguous about which 10.x address belongs to which VPC.
This breaks a naive hub-and-spoke where shared-services is the hub and both prod and staging are spokes, because the hub would need routes to two different VPCs that claim the same address space. Peering is also non-transitive: even if prod peered with shared-services and staging peered with shared-services, prod and staging would not be able to reach each other through the hub. That non-transitivity is actually helpful here - it satisfies the isolation requirement - but the overlapping CIDRs still prevent the spokes from being addressed distinctly.
2. Propose a design that lets prod and staging each reach the shared RDS instance while keeping them isolated, without recreating the prod VPC.
Read the worked answer
Because prod cannot be renumbered, the workable options are:
PrivateLink / endpoint-based access (preferred). Expose the RDS instance (or a proxy in front of it) through a VPC endpoint service in shared-services, and have prod and staging each create an endpoint in their own VPC. Each consumer VPC gets a distinct local endpoint address, so the overlapping 10.0.0.0/16 ranges never need to be routed to each other. Isolation is preserved because there is no route between prod and staging.
Re-IP staging. If staging can be rebuilt, give it a non-overlapping CIDR (for example 10.1.0.0/16) and peer it to shared-services. This is the cleanest long-term fix but requires recreating staging resources.
Transit-based hub. A transit VPC or Cloud Enterprise Network can centralize connectivity, but overlapping CIDRs still require NAT or re-IP on one side; it does not by itself solve the overlap.
Recommendation: use PrivateLink endpoints for both consumers now, and schedule a re-IP of staging to remove the overlap permanently. Document CIDR allocation for future VPCs to prevent recurrence.
3. After connectivity is working, prod reports intermittent timeouts to RDS while staging is fine. What would you check first?
Read the worked answer
Check in this order:
- Security group and whitelist rules. RDS access is typically controlled by a whitelist of source CIDRs. Confirm prod's endpoint or NAT source addresses are whitelisted, and that any security group referencing is correct. Intermittent failures often mean only some source addresses are allowed.
- Route symmetry. If prod reaches RDS through an endpoint or NAT while return traffic takes a different path, connections can establish but stall. Verify both directions use the same path.
- Connection pool and limits. Prod likely has far higher concurrency than staging. Check RDS max connections, wait timeouts, and whether the prod application is exhausting the pool during peaks.
- MTU and path. Endpoint and peering paths can have different MTU behavior; large queries may time out while small ones succeed.
The asymmetry between prod and staging points at volume or whitelist differences rather than a broken route, since staging works over the same shared service.