The "Spaghetti" Problem
Think of traditional AWS networking like wiring up phones in an office building. Every time you want two phones to talk, you run a physical cable between them. Add a third phone, and you need two more cables. Add a tenth phone, and you have a rats' nest of cables behind every desk. This is exactly what happens when microservices need to communicate across VPCs in AWS.
In traditional AWS networking, if Service A (in VPC A) wants to talk to Service B (in VPC B), you must build explicit "plumbing" for every connection:
- Set up VPC Peering or a Transit Gateway between the two VPCs.
- Update Route Tables in both VPCs to direct traffic correctly.
- Adjust Security Groups to allow specific IP addresses (e.g., "Allow 10.0.1.5 on port 443").
- Provision and configure a Load Balancer to distribute traffic to the target service.
This approach works for a handful of services, but at scale — dozens of microservices across multiple VPCs, multiple accounts, and multiple teams — it becomes unmanageable. Every new service-to-service connection requires coordination across networking, security, and application teams. A single misconfigured route table can silently black-hole traffic for hours.
AWS VPC Lattice removes the plumbing entirely. It is an Application Layer (Layer 7) network overlay that sits above your VPC infrastructure. Instead of connecting networks (IP address to IP address), you connect services (Service A to Service B by name). Lattice handles routing, load balancing, TLS termination, and authorization automatically — regardless of the underlying network topology, CIDR ranges, or account boundaries.
The mental model shift is significant: you stop thinking about "which VPC is this in and how do I route to it?" and start thinking about "which service do I want to call?" Lattice is the directory that makes this possible.