Three migrating VPCs that all use 10.0.0.0/16, behind one inspected egress
A manufacturer is migrating ERP, MES and a partner-facing dealer portal. Each system is planned into its own VPC, and all three are currently designed with 10.0.0.0/16 because that is what the application teams copied from the on-premises template - the on-premises estate itself uses 10.0.0.0/8 across three sites. Connectivity runs over a shared 200 Mbps Direct Connect. Security mandates that all outbound internet traffic from every VPC exits through one inspected point, and that the dealer portal, which handles partner logins, is protected at layer 7 and cannot be reached directly by IP address. The network team has three weeks and no budget to re-address on-premises.
1. The design fails before any traffic flows. Explain why, and choose between re-addressing and translation.
Read the worked answer
It fails twice, for two different reasons.
First, the three cloud VPCs overlap each other - three 10.0.0.0/16 networks with identical routes cannot be peered, and the Enterprise Router or Direct Connect gateway will see the same prefix from three sources and pick one. Second, they all overlap the on-premises 10.0.0.0/8, so a route to 10.1.x.x is ambiguous between a migrated system and a legacy site.
Choose between:
- Re-address the cloud side (for example distinct 172.16/16, 172.17/16, 172.18/16 ranges) and NAT on the on-premises side if legacy systems have hard-coded cloud IPs. This is the clean answer, and it is available precisely because the workloads have not migrated yet - the cheapest moment to change an IP plan is before cutover, not after.
- Private NAT translation where an application genuinely cannot change address (hard-coded endpoints, vendor appliance). A private NAT gateway translates source addresses so overlapping ranges can coexist, but every translated flow becomes a troubleshooting blind spot and a per-connection cost.
Recommendation: re-address the cloud VPCs by default, and reserve translation only for the specific legacy endpoints that cannot be changed. Doing translation everywhere buys three weeks now and a permanent debugging tax.
2. Design the connectivity and inspection topology, including how the Direct Connect is shared.
Read the worked answer
A hub, not a mesh - because VPC peering is not transitive.
- Attach all VPCs and the Direct Connect virtual gateway to a central Enterprise Router (or Cloud Connect instance). Peering would require a full mesh and still would not let the ERP VPC reach on-premises through the MES VPC; the router gives a single routing domain and one place to apply policies.
- Create a shared-services VPC that hosts a NAT Gateway for centralised internet egress and a Cloud Firewall for both north-south inspection and, if required, east-west inspection between ERP and MES. All VPCs route 0.0.0.0/0 to the router, which routes to the shared-services VPC; return traffic follows the same path.
- Size the Direct Connect for the aggregated 200 Mbps with headroom, and configure a VPN over the internet as a backup path for the router with route preference so a Direct Connect fault does not sever on-premises access. A single 200 Mbps circuit with no backup is a single point of failure for all three systems.
- Watch the asymmetry trap: if a VPC has a public EIP path as well as the central egress route, outbound traffic may leave directly and return through the firewall, which drops it. Remove EIPs from workload VPCs and keep internet access only in shared services.
3. Security insists the dealer portal cannot be reached directly by IP. How do you enforce that, and what usually defeats the control?
Read the worked answer
The control is network path design, not a WAF setting.
- Publish the portal as a domain on WAF, which proxies to the origin and requires the DNS record to point at the WAF CNAME. Attackers cannot address the WAF by IP, so the portal's public surface becomes the domain only.
- Put the portal behind a dedicated load balancer that has no public EIP. If the ELB keeps an EIP, the origin remains directly reachable and the WAF is decorative - this is the usual way the control is defeated, and it is normally done inadvertently when the ELB was created with a public address for testing.
- Restrict the backend security group and subnet ACL to the WAF back-to-source address ranges only, so even a leaked backend address is not reachable from the internet. Health checks must originate from the load balancer, not from the internet.
- Block direct-to-origin by IP at the edge as well: Cloud Firewall rules that permit only WAF sources on 443 to the ELB subnet.
Finally, test the control adversarially - resolve the origin IP from an old DNS record, an email header or a certificate transparency log, then try to connect. If it succeeds, the portal is protected on paper only, which in an audit is worse than not claiming the control at all.