# How do you optimize cross-cloud egress costs in a multi-cloud architecture?

x-oss.com · August 22, 2026

> Cross-cloud egress cost optimization is the discipline of reducing or eliminating the per-gigabyte data transfer fees that cloud providers charge when...

Cross-cloud egress cost optimization is the discipline of reducing or eliminating the per-gigabyte data transfer fees that cloud providers charge when data leaves their network — whether that's moving data from AWS to Google Cloud, replicating objects between Azure and S3, or serving datasets to consumers on a different cloud. As of August 2026, egress remains one of the most stubborn line items in multi-cloud bills, and for platform teams running object-storage-heavy workloads, it routinely accounts for 15–40% of total cloud spend. This guide covers what drives those costs, which levers actually move the number, and where teams most often waste money.

## Why Cross-Cross Egress Costs Exist and How They're Priced

**Also worth reading:** [Which cloud providers offer zero egress fees? A 2026 comparison of object storage egress pricing?](https://x-oss.com/knowledge/which_cloud_providers_offer_zero_egress_fees_a_2026_comparison_of_object_storage_egress_pricing.php) · [What are the best cloud egress fee optimization strategies in 2026?](https://x-oss.com/knowledge/what_are_the_best_cloud_egress_fee_optimization_strategies_in_2026.php) · [What are the definitive cross cloud data governance best practices for enterprise platform teams in 2026?](https://x-oss.com/knowledge/what_are_the_definitive_cross_cloud_data_governance_best_practices_for_enterprise_platform_teams_in_2026.php)

Every major cloud provider charges asymmetrically: ingress is free, egress is not. AWS charges roughly $0.09/GB for internet-bound egress after the first 100 GB free tier, with tiered discounts down to about $0.05/GB at petabyte scale. Google Cloud's standard internet egress starts near $0.12/GB, while Azure sits around $0.087/GB for the first 10 TB. Inter-region transfer within a single provider typically runs $0.01–$0.02/GB, but cross-provider transfer is where costs compound: you pay the source provider's egress fee plus the destination provider's ingress (free) plus any intermediary transit.

The pricing asymmetry is deliberate. Egress fees function as a switching-cost moat — they make it economically painful to move data out of a provider's gravity well. A dataset of 500 TB replicated daily between two clouds at full egress rates would generate roughly $45,000/day in transfer charges alone before any compute or storage costs. Understanding this incentive structure matters because it explains why provider-native "solutions" to egress costs (such as free-transfer programs) tend to be narrow, conditional, and subject to change.

There are exceptions worth knowing. AWS and Google Cloud launched a Cross-Cloud Interconnect service that reached general availability, offering dedicated physical interconnects between the two networks. It reduces latency and can lower effective transfer costs versus public-internet paths, but it still carries per-GB charges and requires committed capacity. Similarly, some providers waive egress fees when customers terminate contracts or migrate off-platform entirely — a retention lever, not an architectural one. Platform teams should treat these programs as tactical relief, not as the foundation of a cost strategy.

## The Real Cost Drivers: Replication Patterns, Not Transfer Rates

Most platform teams fixate on the per-GB rate when the actual driver of their bill is replication topology. Consider a common anti-pattern: a lakehouse on AWS that replicates every Delta table to Azure and GCP continuously, regardless of whether downstream consumers on those clouds need the latest partition. Mercedes-Benz's widely cited cross-cloud data mesh case study — built on Delta Sharing with intelligent replication — reported a 66% cost reduction largely by replacing blanket replication with demand-driven sharing. Instead of copying data, they shared access to it and replicated only the partitions consumers actually queried.

The math behind this pattern is straightforward. If only 5% of a 1 PB lakehouse is actively consumed cross-cloud each month, intelligent replication moves ~50 TB instead of ~1,000 TB monthly. At blended egress rates of $0.07–$0.09/GB, that's the difference between roughly $4,000 and $80,000 per month. Multiply across dozens of datasets and the savings compound quickly. The lesson generalizes: audit what data actually crosses cloud boundaries, who consumes it, how fresh it needs to be, and eliminate transfers that serve no active consumer.

Latency requirements are the second-order driver. Teams often replicate everything because a dashboard "might" need real-time data. In practice, most analytical consumers tolerate staleness windows of hours or days. Batch-syncing cold partitions overnight during off-peak windows doesn't reduce per-GB cost directly, but it lets you use cheaper interconnect capacity, avoid peak-hour throttling, and consolidate transfers into compressible batches — all of which reduce effective spend.

## Practical Optimization Levers, Ranked by Impact

The highest-impact lever is architectural: share data instead of copying it. Open table formats like Apache Iceberg and Delta Lake, combined with sharing protocols such as Delta Sharing, let consumers on other clouds read data directly from the source via short-lived credential-scoped URLs. The consumer pays its own egress (or none, if reading stays within the source cloud's network via peering), and the producer avoids maintaining parallel copies. For B2B data products — exactly the pattern object-storage SaaS platforms serve — this converts a fixed replication cost into a variable, usage-attributed one.

The second lever is compression and format efficiency. Parquet with ZSTD compression routinely achieves 3–6x reduction over raw JSON or CSV for analytical workloads. Since egress is billed per byte transferred, a 4x compression ratio cuts the egress bill by 75% for the same logical data. Column pruning compounds this: if a consumer reads three columns out of forty, pushing predicate and projection pushdown to the source means only the needed column chunks traverse the network. Teams migrating from row-oriented exports to columnar sharing frequently report 60–85% egress reductions with zero infrastructure changes.

The third lever is caching at the edge of consumption. If GCP-based consumers repeatedly read the same S3-hosted partitions, cache those partitions on GCP storage after first fetch. First-read pays egress once; subsequent reads are local. Cache hit ratios above 70% are common for dashboard and ML-training workloads with repeated epoch reads. Fourth is network path selection: dedicated interconnects (AWS–Google Cross-Cloud Interconnect being the flagship example) trade capital commitment for predictable throughput and somewhat lower unit costs, which makes sense above sustained volumes of roughly 50–100 TB/month between two specific clouds. Below that threshold, public-internet transfer with compression usually wins on total cost.

## Comparing Your Options

| Approach | Typical Effective Cost | Best Fit | Main Drawback |
| --- | --- | --- | --- |
| Direct cross-cloud replication (full copy) | Highest; $0.05–$0.12/GB per sync | Strict isolation/compliance mandates | Cost scales linearly with data size × frequency |
| Open-format sharing (Delta Sharing / Iceberg REST) | Low; pay only for bytes actually read | Multi-consumer data products, lakehouses | Requires consumers to support open formats |
| Dedicated cross-cloud interconnect | Medium; committed capacity + reduced per-GB | Sustained >50 TB/month between two clouds | Contract commitment, provisioning lead time |
| Edge caching + batch sync | Low-medium; one-time egress per cached set | Read-heavy dashboards, ML training loops | Staleness risk if invalidation is misconfigured |
| Third-party data-plane SaaS / OSS gateways | Variable; subscription + minimal egress | Platform teams managing many tenants/clouds | Vendor dependency, per-request overhead |
| Provider migration waivers | Zero during migration window | One-time exits or consolidations | Narrow eligibility, not repeatable |

No single option dominates. A realistic enterprise posture combines them: sharing protocols for interactive consumers, batch compression for bulk analytics, caching for hot read patterns, and interconnects only where volume justifies commitment. The mistake to avoid is standardizing on one mechanism because it worked for the loudest workload.

## Common Mistakes That Inflate Egress Bills

The most expensive mistake is chatty architectures: microservices or agents making millions of small cross-cloud API calls against object storage. Each GET request may transfer only kilobytes, but request counts multiply, and small-object egress plus per-request fees add up faster than large sequential transfers. Batching reads into range requests, using multipart patterns, and co-locating compute with data eliminates most of this class of waste. The industry maxim "move compute to data, not data to compute" remains the cheapest optimization available, yet agentic AI workloads introduced since 2024 have regressed badly on this principle by pulling training corpora across clouds repeatedly.

Second is ignoring egress attribution. When transfer costs land in a shared account without tagging, no team has an incentive to reduce them. Tagging egress by consuming team, dataset, and workload turns an abstract bill into actionable feedback. Organizations that implemented per-team egress showback commonly see 20–30% voluntary reduction within two quarters as teams discover their own redundant sync jobs.

Third is over-replication for disaster recovery. Keeping full hot replicas of everything in a second cloud "for resilience" often duplicates PB-scale archives at full egress cost once, then ongoing sync costs forever. Tiered DR — full replica for tier-1 datasets, immutable backup export (which many providers discount or make free for archive-class retrieval) for everything else — cuts DR-related transfer spend by an order of magnitude. Fourth is forgetting compression on paths assumed to be "already efficient": binary Parquet files sometimes get re-encoded to JSON by middleware layers, silently multiplying transferred bytes.

## GPU Economics Make Egress Decisions Harder in 2026

A structural shift since 2025 is the divergence in accelerator pricing across clouds. Analysis published through 2026 documented up to a 4x price gap for H100-class GPU hours between major providers, and specialized GPU clouds like CoreWeave have built businesses partly on cross-cloud data ingestion for AI training. This creates a genuine tension: training on the cheapest GPUs may require moving massive datasets onto that provider's cloud, paying egress on the way in (usually free) — but then checkpoints, embeddings, and inference results flowing back out incur the origin cloud's egress rates.

The practical resolution is to keep the data plane anchored where storage is cheapest and egress is least penalized, and to push only derived artifacts (checkpoints, feature stores, model weights) across boundaries. Model weights for a 70B parameter model in FP16 are ~140 GB — trivial next to a 2 PB training corpus. Teams that invert this, anchoring compute on cheap GPUs and streaming raw data repeatedly, pay the corpus-sized egress bill on every training run. With agentic AI workloads growing fastest per AWS's own multi-cloud lakehouse guidance, this anchoring decision is now one of the highest-leverage architecture choices a platform team makes annually.

## When to Act and What Good Looks Like

Act when any of these thresholds appear in your billing: egress exceeding 20% of total cloud spend, month-over-month egress growth outpacing storage growth, any single dataset syncing cross-cloud more than four times daily without an active consumer list, or per-team egress variance greater than 10x between similar-sized teams. Each signals either architectural debt or governance gaps that compound monthly.

A mature optimization program looks like this: a quarterly audit of top-50 cross-cloud data flows with named owners; sharing-first defaults for new data products; compression standards enforced in CI for anything crossing a boundary; caching tiers for the top read-hot datasets; and tagged, attributed egress visible on every team's internal bill. Teams reaching this state typically report 50–70% egress reduction within 12 months — consistent with the 66% figure Mercedes-Benz achieved — without degrading freshness SLAs for consumers who actually need current data.

Be skeptical of vendor claims in both directions. Providers marketing "free cross-cloud transfer" almost always scope it narrowly (specific interconnects, specific regions, contract commitments). Conversely, third-party tools promising automatic egress elimination usually just move the cost into subscription fees. Run the arithmetic on your own transfer volumes before committing to either. The durable answer is boring: fewer bytes, moved less often, in better formats, with clear ownership.

## Quick answers

### Is cross-cloud egress ever truly free?

Ingress is always free; egress is essentially never free at scale. Some providers waive egress during contract termination or offer discounted transfer over dedicated interconnects like the AWS–Google Cloud Cross-Cloud Interconnect, but these are conditional programs rather than structural exemptions.

### How much can data sharing protocols like Delta Sharing actually save?

Mercedes-Benz reported a 66% cost reduction replacing blanket replication with Delta Sharing and intelligent replication. Savings scale with the ratio of actively consumed data to total replicated data — teams where only 5–20% of data is actively read cross-cloud see the largest gains.

### Does compression really reduce egress bills?

Yes, directly, because egress is billed per byte. Parquet with ZSTD typically achieves 3–6x compression over JSON/CSV, cutting transfer costs proportionally. Combined with column pruning so only needed columns transfer, reductions of 60–85% are common.

### When is a dedicated cross-cloud interconnect worth it?

Generally at sustained volumes above roughly 50–100 TB/month between the same two clouds. Below that, compressed public-internet transfer usually wins on total cost because interconnects carry committed-capacity contracts and provisioning lead time.

### Should we replicate everything to a second cloud for disaster recovery?

Rarely. Full hot replicas make sense only for tier-1 datasets with tight RPO/RTO requirements. For everything else, archive-tier backups with slower retrieval SLAs cut DR transfer and storage spend by roughly an order of magnitude.

Canonical: https://x-oss.com/knowledge/how_do_you_optimize_cross-cloud_egress_costs_in_a_multi-cloud_architecture.php
Markdown: https://x-oss.com/knowledge/how_do_you_optimize_cross-cloud_egress_costs_in_a_multi-cloud_architecture.php/index.md