The multi-cloud WAN nobody budgeted for.

Nobody decides to become a multi-cloud enterprise. It happens to you. An acquisition arrives running on Azure. The data science team standardized on GCP two years before anyone asked. A strategic vendor will only deploy into their own cloud. One day an architect draws the environment on a whiteboard and the room goes quiet, because the drawing has three clouds, four data centers, and nobody can explain every line between them.

Here's the part that never makes the roadmap: each of those lines was built as a one-off. An urgent VPN for the acquisition. A peering connection for the data team, approved as an "interim" measure four years ago. A NAT exception for the vendor. None of it was designed. All of it accreted — one urgent ticket at a time — and now it is the most critical, least understood system in the company.

The invisible line item

The accidental WAN bills you three ways. The first is the one finance can see: egress and transit charges that nobody owns, spread across accounts so no single invoice looks alarming. The second is operational: every new connection is a bespoke project, measured in weeks, negotiated across teams, and dependent on the one engineer who remembers why the 2019 tunnel exists. The third is the expensive one: risk. A mesh of point-to-point exceptions has no consistent inspection, no coherent segmentation, and no honest answer to "what can reach what?" Auditors eventually ask that question. So do attackers, more quietly.

What a core network actually changes

The alternative is treating the inter-cloud network as a product with an architecture, not a pile of tickets. In practice that means a policy-driven core — AWS Cloud WAN on the AWS side, its equivalents and interconnects toward Azure and GCP — where the important properties are structural. Routing intent is declared as code and reviewed like code, instead of living in a change ticket from three years ago. Segments replace exceptions: production, non-production, shared services, and partner traffic are isolated by design, so a new workload lands in a segment with known rules instead of negotiating its own path. Inspection and egress are inserted centrally — one governed exit to the internet, one inspection layer — instead of a firewall exception per connection. And multi-Region stops being a diagram in the DR binder, because the core is the failover fabric.

I've built this at Fortune 500 scale, and the before/after is not subtle. The question "can the analytics platform reach the claims data?" goes from a two-week archaeology project to reading a policy file. New-connection lead time goes from weeks to a pull request.

Why this lands on the AI roadmap

The timing matters because AI workloads are the most network-hungry things enterprises have deployed in a decade. Training data lives where it lives; GPUs live where you can get them; agents call APIs across every boundary you have. Every one of those flows rides the inter-cloud network. An accidental WAN turns each AI initiative into a private networking project. A designed core makes the network a solved problem the AI teams never have to think about — which is the entire point of platform engineering.

The whiteboard test

A diagnostic that costs one meeting: ask your network team to draw every inter-cloud and cloud-to-datacenter connection from memory — endpoints, routing, inspection, owner. If the drawing is complete and two people can produce the same one, you have a network. If the drawing trails off into "and there are a few others," you have an accretion, and it's carrying your production traffic right now.

Start with inventory: enumerate every tunnel, peering, and interconnect, with an owner and a reason. Then define the segmentation model you wish you had — usually four or five segments cover a real enterprise. Then migrate connections onto the core deliberately, killing an exception each time. It's unglamorous work with a compounding payoff: every workload that lands after it ships faster, and every audit after it ends sooner.