Networking between cloud providers, and what it costs

Do the two estates need a network path at all?

Often not. If the interaction is one service calling another's API, the public internet with mutual TLS or signed tokens is a legitimate and frequently better answer than a private link. It removes address planning, removes routing, removes a shared failure domain, and removes the temptation to treat the second provider as an extension of the first network.

The situations that genuinely need private connectivity are narrower: database replication, bulk data movement that should not traverse the internet, protocols that predate modern authentication, and compliance positions that require traffic to stay off public networks. Each of those is a specific workload, which means the link can be scoped to that workload rather than joining two estates.

The reason to be strict here is that a private path creates coupling that outlives the reason for it. Once a route exists, teams use it, and within a year the boundary carries traffic nobody designed. Deciding early that the connection serves one named purpose, with routes and firewall rules that permit only that purpose, is much easier than restricting it later.

What are the options for connecting two clouds?

Four, and they differ more in cost shape and operational burden than in capability. All of them can move data between providers; what varies is the fixed monthly commitment, the per-gigabyte rate, the predictability of latency and how much of the arrangement you have to run yourself.

Why does address planning break first?

Because both estates were built assuming they were alone, and both used the same private address ranges. The single most common blocker to connecting two clouds is overlapping network address space, usually because someone chose a friendly range in each. Routing cannot resolve an overlap: the same address exists on both sides and packets go to the wrong one.

The workarounds are all worse than planning. Network address translation on one side hides the overlap but breaks anything that embeds addresses, complicates logging because the source address in one estate's logs no longer means anything in the other's, and makes troubleshooting substantially harder. Renumbering an existing estate is disruptive and usually touches firewall rules, allowlists and hardcoded configuration that nobody knew existed.

The preventable version costs nothing. Maintain one address plan for the whole organisation, covering every provider and every environment, before the second provider is built. Allocate non-overlapping ranges per provider and per region, leave room for growth, and treat the plan as a controlled document. Teams that do this find the connectivity work straightforward; teams that do not spend their first month on renumbering.

How does DNS work across providers?

It does not, until you build it, and it usually half works in a way that is hard to diagnose. Each provider has its own private DNS service that resolves names for resources inside its own networks. Neither knows about the other. A workload on provider A asking for a private name on provider B receives nothing useful, even when the network path between them is working perfectly.

The fix is conditional forwarding in both directions, using each provider's resolver endpoints so that queries for the other estate's zones are forwarded across the link and answered by the authoritative resolver there. The two-directional part is what teams miss. A configuration that forwards A to B but not B to A produces a system where connections initiated from one side work and the other side fails, which presents as an intermittent application problem rather than a DNS one.

Two further details cause outages. Private zones that share a name with a public zone create split-horizon behaviour that differs by provider, so the same lookup can return different answers depending on where it runs. And resolver endpoints are themselves a component with capacity limits and a failure mode: if they are unavailable, every cross-provider name lookup fails at once, which looks like a total outage of the remote estate.

What does cross-cloud traffic actually cost?

Egress is charged by the side sending the data, and inbound traffic is generally not charged, so a request and its response both cost, in opposite directions. That is the mechanism that makes conversational architectures expensive: it is not the volume of any single call, it is the number of calls multiplied by their responses across the boundary, forever.

Private interconnects usually reduce the per-gigabyte rate compared with internet egress, and add fixed charges for ports, virtual circuits and attachment hours. That changes the shape of the bill: below a certain sustained volume the fixed charges exceed the saving, and above it the interconnect is clearly cheaper. Work out your own crossover point from measured traffic rather than assuming the private option is cheaper because it is more serious.

The costs that are missed in planning are structural rather than per-gigabyte. A chatty service that makes several dependent calls per user request pays the boundary charge each time and the round trip latency each time. Replicating a dataset continuously pays for the full change volume rather than the useful volume. And a cache or a queue placed on the wrong side of the boundary can multiply traffic several times over without anyone changing a line of application code.

How should you design the boundary?

Put it in one place, make it asynchronous where possible, and make it one directional where you can. A single defined interface between the estates, carrying events or batches rather than fine-grained requests, is both cheaper and easier to reason about during an incident than a mesh of services that happen to be able to reach each other.

Design for the link being down rather than for it being fast. Cross-provider paths fail more often than paths inside one provider, because they involve more parties, and the failure is frequently partial: high latency, packet loss, or one direction working. Systems that queue and retry survive this; systems that make synchronous calls across the boundary in the request path turn a network event into a customer-visible outage on both sides.

A test you can run this afternoon: enable flow logs on both sides for a day and total the bytes crossing the boundary by service pair. Then ask, for the largest pair, whether that traffic is a dataset that could be replicated once, a conversation that could be batched, or a component that is simply on the wrong side. Most estates find that a small number of pairs account for nearly all the cost, and that at least one of them was never intended to cross at all.