Growing Pains
Think of a small office building where everyone sits in one room. Communication is easy — you just talk across the desk. Now imagine that company grows to 50 floors, each with its own team, its own locked room, and its own set of rules. Suddenly, you need a real communications infrastructure, not just shouting across the room.
Cloud networking follows the same trajectory. In the previous topic, we learned how to build a single Virtual Private Cloud (VPC) — a logically isolated network inside a cloud provider — and perhaps connect two of them with VPC Peering, which is a direct, private link between exactly two VPCs.
But what happens when your company grows? What if you have:
- 50 different VPCs for different teams (Dev, Test, Prod, Analytics, Security)?
- Multiple on-premises data centers that need to connect to the cloud?
- Remote offices with hundreds of employees who need access to cloud resources?
Trying to connect every single one of these to every other one using individual peering links creates a massive, unmanageable "mesh" of connections. If you have 10 VPCs and want every one to talk to every other, you need 45 peering links. With 50 VPCs, that number explodes to 1,225 links — each requiring its own configuration, route table entries, and ongoing maintenance. Add one new VPC and you might have to create 49 new peering links and update 49 route tables. This is the N² problem, and it is a genuine operational nightmare.
This topic is about the professional-grade tools used to solve connectivity at scale: Transit Gateways, VPNs, Direct Connect, and the security technologies that protect them.