Most multi-cloud architecture diagrams draw each cloud as a tidy box. Inside the boxes there are VPCs, subnets, managed services, and careful labels. Between the boxes there is usually a single line, sometimes labelled just "VPN" or "internet".

That line is where a surprising amount of production pain lives.

As soon as a workload in one cloud genuinely depends on data or services in another — a reporting job reading from a database that stayed behind, an application calling an AI endpoint hosted elsewhere, a failover that suddenly reroutes traffic across providers — the lines between the boxes stop being decoration. They become a network that somebody has to design, secure, document, and debug at 2 a.m.

This is a planning outline for treating inter-cloud connectivity as a designed layer in its own right, before the estate grows enough that retrofitting it becomes expensive.

1. Inventory the flows before choosing any technology

The most common mistake is starting with connection products. Start with flows instead.

For each cross-cloud dependency, write down:

  • Source and destination — which account, VPC/VNet, and region on each side
  • What it carries — application traffic, replication, backups, admin access, inference calls
  • How sensitive it is — does it cross a trust boundary? Does it carry regulated data?
  • What breaks if it stops — a degraded feature, or a full outage?
  • Who owns it — a named team, not "the cloud team" in general

Most estates discover flows nobody remembered creating: a one-off tunnel from a migration two years ago, a peering set up for a demo that quietly became load-bearing. The inventory is unglamorous work, but every later decision — routing, security policy, cost — depends on it being complete.

2. Plan address space and DNS as if there will be a third cloud

Overlapping private address space is the multi-cloud problem that bites earliest and gets discussed least. Two clouds adopted independently often arrive with the same RFC 1918 ranges, because both teams picked 10.0.0.0/16 as the obvious default. The collision only surfaces when a workload in one cloud genuinely needs to reach a service in the other — at which point the fixes are all unpleasant: NAT at the boundary, proxy layers, or renumbering something already running in production.

A few habits prevent most of it:

  • Allocate private ranges centrally, per cloud, per region, per environment — and record the allocations somewhere engineers actually check before creating a new VPC or VNet.
  • Reserve space for future clouds and regions even if there is no current plan for them. Reserving address space costs nothing; renumbering costs weekends.
  • Agree on one DNS resolution convention early. Each cloud resolves names differently, conditional forwarding rules pile up, and an internal service that resolves fine in one environment silently fails in another. Private zones, forwarding rules, and naming conventions should be designed once and applied consistently across AWS, Azure, Google Cloud, and Oracle environments rather than invented per project.

3. Decide deliberately where private paths earn their place

Not every cross-cloud flow needs private connectivity. Public internet routing with TLS and strong authentication is fine for plenty of low-sensitivity, latency-tolerant traffic — and it is simple, cheap, and quick to set up.

Private paths earn their place where one or more of these is true:

  • The traffic carries sensitive or regulated data and the organisation wants it off the public internet entirely.
  • The flow is latency- or jitter-sensitive, such as synchronous replication or real-time inference calls.
  • Predictability matters: internet paths change, and troubleshooting "it was fast yesterday" across two providers and an unknown middle is miserable.
  • An auditor is going to ask, in writing, how traffic between environments is protected — and "the public internet, but encrypted" is not the answer the business wants to give.

Whichever mix an estate ends up with, the decision should be recorded per flow, with the reason. Undocumented exceptions have a way of becoming permanent.

4. Document routing intent, not just the primary path

A link diagram shows the happy path. Operations live on the unhappy ones.

For each important cross-cloud flow, document the intended path for failover as well as for normal operation. Asymmetric routing is a recurring cause of baffling failures: after a failover, return traffic takes a different path than the request, stateful inspection on the new path has no session for it, and packets get dropped in a way that looks — from the application side — like random flakiness.

Writing down "traffic from A to B should return via X, and here is the firewall/NAT behaviour on that path" before the failover happens turns a multi-hour debugging session into a checklist lookup.

5. Treat it as one layer, with one owner

The pattern behind most of the problems above is the same: inter-cloud connections built team by team and project by project, each one reasonable in isolation, adding up to a tangle nobody fully owns or can draw accurately.

The alternative is to treat the network between clouds as its own designed layer — planned address space, consistent DNS, deliberate private paths, documented routing intent, and a single place where those decisions live. That is the layer providers in this space work in: CloudVerg, for example, covers private cloud and multi-cloud networking for US businesses across AWS, Azure, Google Cloud, and Oracle, with platforms such as VergMesh and VergRail for the connectivity side of the estate and zero-trust security and SOC 2 readiness work alongside it: https://cloudverg.com

Whether that layer is built in-house or with outside help, the planning questions are the same.

A short checklist

Before the next cloud, region, or major workload lands:

  • [ ] Every cross-cloud flow inventoried, with an owner and a sensitivity rating
  • [ ] Private address ranges allocated centrally, with space reserved for growth
  • [ ] One DNS naming and resolution convention, applied in every cloud
  • [ ] Per-flow decision on private vs public paths, with the reason recorded
  • [ ] Failover paths documented, including return-path and stateful-inspection behaviour
  • [ ] One team accountable for the inter-cloud layer as a whole

The boxes in the diagram will keep multiplying. The lines between them deserve the same engineering attention as what is inside them — ideally before, not after, the first cross-cloud incident makes the case the hard way.