The M&A Nightmare
Imagine two companies merge. Company A runs all their workloads in 10.0.0.0/16. Company B — independently, and perfectly reasonably — also chose 10.0.0.0/16. Now the CISO says: "We need Service A in Company A's VPC to call the Inventory API in Company B's VPC by next quarter."
With traditional networking, this is a multi-month project:
- VPC Peering fails immediately. AWS will reject a peering request between two VPCs with overlapping CIDRs. The routing table cannot distinguish between 10.0.1.5 in VPC-A and 10.0.1.5 in VPC-B.
- Transit Gateway also fails for the same reason — overlapping routes cannot coexist in a TGW route table.
- Re-IPing one network (changing all IP assignments, updating every security group, every DNS record, every hardcoded config) is a months-long, high-risk migration.
- NAT-based workarounds exist but require a NAT Gateway per service, custom routing logic, and ongoing operational burden.
How Lattice Solves Overlapping IPs
Lattice sidesteps the entire Layer 3 problem by operating exclusively at Layer 7 (HTTP/HTTPS). Here is the precise mechanism:
When a VPC is associated with a Service Network, AWS injects a link-local endpoint into the VPC using the 169.254.171.0/24 range (link-local addresses are never routed across networks — they are local to a single network segment). This endpoint is the Lattice VPC Lattice Router for that VPC.
When Service A calls https://payment-svc.abc123.vpc-lattice-svcs.us-east-1.on.aws:
1. DNS resolves to a 169.254.x.x link-local address — the local Lattice router endpoint.
2. Service A sends the HTTPS request to that link-local address. The packet never leaves VPC-A's local network segment.
3. The Lattice fleet intercepts the request, reads the HTTP Host header to identify the target service, applies routing rules and IAM auth checks.
4. Lattice forwards the request to the target (e.g., an EC2 instance in VPC-B) from the Lattice fleet's own IP space — not from VPC-A's IP space.
5. The response travels back through the same proxy path.
Because the actual client IP (10.0.1.5 in VPC-A) never appears as a source address in VPC-B, there is no routing conflict. The Layer 3 overlap is completely invisible to the application. The original client IP is preserved in the X-Forwarded-For HTTP header if needed for logging.
This architecture also means Lattice works across AWS accounts without any cross-account VPC peering — the Lattice fleet is the intermediary, not a direct network path.