Most companies don't choose multi-cloud on purpose. It happens one acquisition, one team preference, or one vendor deal at a time — and the network is usually the last thing anyone designs for it.
Each cloud brought its own networking model
AWS has VPCs and Transit Gateways. Azure has VNets and ExpressRoute. GCP has its own VPC model entirely. None of them were designed with each other in mind, so the connective tissue between them is almost always something a team bolted on after the fact — a VPN here, a peering agreement there.
Point-to-point connections don't scale
Two clouds can get away with a single VPN tunnel. Three clouds and a data center turns into a small mesh of one-off connections, each with its own configuration, its own failure mode, and its own person who understands how it works. By the time a company is running four or five environments, nobody has a complete picture of how traffic actually moves between them.
A network layer is not the same as a VPN
A dedicated network layer gives every environment the same addressing scheme, the same routing policy, and the same observability — regardless of which cloud it happens to run on. That's a fundamentally different design goal than “connect cloud A to cloud B,” and it's why bolting together VPNs eventually stops working no matter how carefully it's done.
The cost shows up as velocity, not just dollars
The clearest symptom of a missing network layer isn't a line item — it's how long it takes to add a new region or onboard a new provider. If that work still requires a networking specialist and a multi-week change window, the network has become the slowest-moving part of the infrastructure, even if everything else ships daily.