A platform team spins up a new GPU cluster and points it at a data lake in another cloud. Nobody provisions a line item for that connection, and the bill still arrives.
A platform team spins up a new GPU cluster on CoreWeave and points it at a data lake sitting in Amazon S3. Nobody provisions a line item for that connection. It does not appear as its own charge anywhere. It shows up split across three invoices instead: a few cents per gigabyte of S3 egress, an hourly charge for a transit gateway attachment someone configured eighteen months ago, and a Direct Connect port fee that renews automatically every month regardless of how much traffic actually crosses it.
This is the connectivity layer, and it is the part of multi-cloud architecture that budgeting spreadsheets consistently miss. Compute costs get a line. Storage costs get a line. The pipes between them, the thing that makes multi-cloud actually functional rather than three isolated silos, gets absorbed into whatever category happens to be nearby. By the time someone notices, it has usually grown into a five or six figure annual cost that nobody remembers approving.
Inside a single cloud, networking is close to free. AWS does not charge for traffic between two EC2 instances in the same availability zone, and VPC peering within a region is cheap enough that most teams never think about it. That experience trains engineers to treat internal networking as a solved problem, something the platform handles.
Multi-cloud removes that assumption entirely. The moment traffic leaves a provider's network boundary, whether that is a GPU cluster on Lambda Labs calling back to an object store on AWS, or a Kubernetes control plane on Azure talking to a database on Google Cloud, it stops being internal traffic and becomes a billable, latency-sensitive, security-relevant event. Every cloud's network fabric is built to keep customers inside it, not to make it convenient to leave. That is not a conspiracy, it is the natural result of infrastructure economics: the provider bears the cost of building a global backbone and recovers it, in part, by metering what leaves.
Teams that get surprised by connectivity costs are almost always missing one of four categories.
The most visible cost and still the most underestimated. Moving a single terabyte out of AWS to a destination outside the AWS network commonly runs in the range of 80 to 90 dollars at standard tiers, before volume discounts. Multiply that by the terabytes a training run checkpoints, or the volume a backup job replicates nightly across providers, and the number stops being trivial.
AWS Transit Gateway, Azure Virtual WAN, and Google Cloud Network Connectivity Center all charge an hourly per-attachment fee on top of a per-gigabyte data processing fee. These are designed for intra-cloud hub and spoke topologies, and teams that extend them into multi-cloud designs often pay both the gateway's processing fee and the underlying egress fee on the same byte.
Direct Connect, ExpressRoute, and Cloud Interconnect all charge a fixed port fee for the physical or virtual circuit itself, independent of how much data actually crosses it. A team that provisions a 10 Gbps port for a migration and then leaves it running afterward is paying for capacity it is not using.
Cross-cloud service meshes add health checks, retries, and cross-region DNS resolution that generate their own, smaller but constant, traffic volume. Latency between providers is typically higher than intra-cloud latency, which increases retry rates under load, which quietly increases the egress volume tied to the retries themselves.
Dedicated interconnects solve throughput, latency consistency, and security posture. They do not eliminate metering, and teams that adopt them expecting a flat fee to replace egress charges are usually disappointed. What they buy is a private, predictable path instead of the public internet, with lower jitter and the ability to negotiate committed use discounts on the data that moves across it. For a workload where consistency matters more than raw cost, such as replicating a production database across providers for disaster recovery, that trade is often worth it. For a workload where the goal is simply to move GPU output into cheaper long-term storage, it frequently is not, because the fixed port fee adds cost without addressing the underlying egress rate.
This is also why GPU providers themselves are worth vetting carefully before an architecture gets built around them. On the DataStorage.com Podcast, Massed Compute founder Sunny Smith described storage as needing to sit adjacent to the GPU with high east-west bandwidth, because moving a petabyte between data centers after the fact is prohibitively expensive. He also pointed to network fabric partnerships as a practical way some teams avoid egress charges entirely rather than absorbing them. That episode does not yet have an approved link on the site, so treat the reference as directional until it is published.
A third option sits between paying public internet egress and provisioning a dedicated cloud interconnect: network fabric providers such as Megaport, PacketFabric, and Console Connect. These companies maintain private, pre-built connections into the major cloud on ramps and let customers provision cross-cloud circuits on demand, often billed by the hour or by committed bandwidth rather than by the gigabyte. For a team moving large, predictable volumes between two or three specific providers, a fabric partner can flatten a variable egress bill into a fixed monthly cost, which is a meaningfully easier number to forecast.
This connects directly to a pattern this site returns to often: GPU capacity is scarce and shifting, so a team may run training on AWS today and inference on CoreWeave next quarter depending on availability and price. Every one of those provider switches drags data along with it, and the egress fee on that data can erase the savings that motivated the move in the first place. Keeping the data layer on zero-egress or low-egress storage such as Backblaze B2 or Wasabi, and treating compute as the portable layer instead, removes the connectivity tax from the equation almost entirely. It is architecture advice as much as a cost optimization, because it decouples the decision of where to compute from the decision of where to store.
Most FinOps practices tag spend by service and by team. Few tag it by traffic direction. That is the gap to close first.
Start with an inventory: list every cross-cloud data flow currently in production, not the ones documented in an architecture diagram from a year ago, but the ones actually moving bytes today. For each flow, capture the source, the destination, the average monthly volume, and which of the four hidden categories above it is paying into. Most teams find this exercise alone surfaces at least one transit gateway attachment or interconnect port that nobody is using anymore.
From there, price out the three paths for each flow: standard egress, a dedicated interconnect with its port fee, and a network fabric partner's committed rate. The right answer is rarely the same for every flow. A nightly backup job with a predictable volume often fits a fabric partner's flat rate well. A bursty, unpredictable analytics query pattern often does not justify a fixed port fee at all and is cheaper left on standard egress with volume discounts applied. Running these three numbers side by side against current spend is exactly the kind of comparison the Cloud Cost Calculator is built for, and it is worth doing before signing a new interconnect contract, not after.
Finally, put an owner on the number. Connectivity spend tends to drift because it sits between teams: the network team provisions the pipe, the application team generates the traffic, and neither one sees the combined bill. Assigning a single named owner to cross-cloud connectivity spend, with a recurring review cadence, is the single change that most reliably keeps this line item from disappearing back into the noise.
| Path | Best for | Billing model | Watch out for |
|---|---|---|---|
| Standard public egress | Bursty, unpredictable traffic | Per gigabyte | |
| Cost scales directly with volume, no ceiling | |||
| Dedicated interconnect | Consistent, latency-sensitive traffic | Fixed port fee plus data processing | |
| Pays for provisioned capacity even when idle | |||
| Network fabric partner | Predictable, recurring volume between specific providers | Flat or committed bandwidth rate | |
| Requires a multi-month or multi-year commitment for the best rate | |||
The pipes between your clouds are not free just because nobody sent you a bill that says so.
Compare AWS, Google Cloud, Azure, and alternatives like Backblaze B2 Discover how much you could save in seconds
