On this page · 10 sections
- Why cross-cloud egress is the tax nobody budgets for
- How the three engines handle data in another cloud
- Cross-cloud cost at a glance (2026)
- A worked example: 50 TB a month, three clouds
- Which engine fits which situation
- India-specific considerations
- The open table format underneath all of this
- How eCorpIT can help
- FAQ
- References
Summary. Moving a terabyte of data between clouds costs $90 to $155 on Snowflake in 2026, and a straight internet transfer out of AWS runs $0.09 per GB, Azure $0.087, and Google Cloud $0.12 for the first tier. Egress already accounts for 6 to 12 percent of a typical cloud bill. Three query engines now let you read data where it sits instead of paying to copy it out: Google's BigQuery Omni queries AWS S3 and Azure Blob in place at $9.125 per TiB scanned, Snowflake added an Egress Cost Optimizer in April 2025 that caches data after the first read, and Databricks Delta Sharing only charges egress when a recipient actually queries across clouds. This guide compares the real per-TB numbers so a data team can pick the cheapest path for a genuinely multi-cloud estate.
Most data platforms were designed for a single cloud. Real companies are not single-cloud. A marketing team lands events in Amazon S3, finance runs on Microsoft Azure, and the analytics group standardised on Google BigQuery two years ago. The moment a query needs to join those three, someone pays to shuttle bytes across provider boundaries, and that charge shows up on next month's invoice with no line item that explains it.
Corey Quinn, chief cloud economist at The Duckbill Group, has called AWS's data transfer pricing "a sad joke," and the arithmetic backs him up: storing 1 GB in S3 costs about 2.3 cents a month, while sending that same gigabyte to the internet once costs 9 cents, roughly four months of storage in a single read. Cloudflare has estimated that customers in the US, Canada and Europe pay close to 80 times what the bandwidth actually costs to deliver. That gap is why "query in place" has become the design goal for multi-cloud analytics, and why the choice between BigQuery Omni, Snowflake and Databricks is really a choice about who pays the egress and when.
Why cross-cloud egress is the tax nobody budgets for
Egress is the charge to move data out of a cloud region, either to the public internet or to another provider. Ingress is almost always free. That asymmetry is deliberate: it is cheap to get data in and expensive to get it out, which raises the switching cost of ever leaving.
The headline 2026 rates for standard internet egress are close across the three hyperscalers, but the details differ. Amazon Web Services charges $0.09 per GB for the first 10 TB each month after a 100 GB free allowance, dropping to $0.05 per GB above 150 TB. Microsoft Azure starts at $0.087 per GB and matches AWS at higher volumes. Google Cloud lists $0.12 per GB for the first tier. Cross-cloud and cross-region transfers inside a warehouse product run higher still: Snowflake quotes $90 to $155 per TB depending on source and destination, with a transfer out of Google Cloud's US East 4 region reaching $120 to $190 per TB.
Two providers broke the model. Cloudflare R2 and Wasabi both charge zero egress, though Wasabi enforces a 90-day minimum retention. Those zero-egress stores now show up as the shared landing zone in several cross-cloud designs precisely because they remove the transfer penalty from the equation.
The reason this matters for analytics is data gravity. A dashboard that scans 50 TB a month across clouds is not paying for compute alone. If even a fifth of that scan crosses a cloud boundary at $0.09 per GB, that is roughly $920 a month in transfer on top of the query cost, and it scales linearly with usage while your storage bill stays flat.
How the three engines handle data in another cloud
The engines take three different routes to the same goal. One queries the remote data in place, one copies it and then optimises the copy, and one shares it and defers the egress until a read happens.
BigQuery Omni: run the query where the data lives
BigQuery Omni lets BigQuery analyse data in Amazon S3 and Azure Blob Storage without moving it. The compute runs on clusters inside the same region as the data, so the bytes never leave AWS or Azure to be scanned. You see the results in the same BigQuery interface you already use.
The cost structure carries a multi-cloud premium. BigQuery's standard on-demand rate is $6.25 per TiB scanned, with the first 1 TiB each month free per project. Omni queries against AWS or Azure data are billed at $9.125 per TiB on-demand, a 46 percent premium over the in-Google rate, and Omni requires the Enterprise edition, so the Standard tier cannot run it at all. When you do need to bring results back into Google Cloud, cross-cloud transfer fees start at $0.09 per GiB. Omni also offers flat-rate slot pricing on its AWS and Azure warehouses, from around $2,000 per month on an annual commitment to about $4,000 for flex slots per 100 slots.
Google's newer answer is the borderless Lakehouse, in Preview in 2026. It pairs a Lakehouse cross-cloud interconnect with cross-cloud caching: as queries read data from a remote cloud, the Lakehouse temporarily caches those segments on specialised storage inside Google Cloud, so later queries hit the local cache and skip most of the cross-cloud egress. A runtime catalog federation, also in Preview, lets BigQuery and Google-managed Spark discover data across AWS Glue, Databricks Unity Catalog and Snowflake Horizon Catalog. The design targets Apache Iceberg tables in S3 specifically, which matters because Iceberg is becoming the shared table format that makes this federation possible.
Snowflake: replicate, then optimise the copy
Snowflake's model is different. There is no charge to move data within a single region, but cross-region or cross-cloud work means replication, and replication moves bytes. Replicating a database to another cloud for disaster recovery or data sharing generates transfer cost on the initial copy and on every subsequent sync.
The relief valve is the Egress Cost Optimizer, released in April 2025. It caches data in Snowflake-managed storage after the first egress, so replicating to additional regions costs zero extra egress after that first hop. The important limit: the Optimizer applies only to Cross-Cloud Auto-Fulfillment, the managed data-sharing path, and not to manual replication you set up yourself. For a provider distributing a dataset to consumers in several regions, that can turn a per-region transfer bill into a single one. For a team hand-rolling its own cross-cloud replica, the standard $90-to-$155-per-TB rates still apply.
Databricks Delta Sharing: defer egress until someone reads
Databricks Delta Sharing does not duplicate data by default. A provider shares a table in place, and egress is incurred only when a recipient queries across clouds. That makes the cost track actual usage rather than a fixed replication schedule, which is efficient for infrequently read data and expensive for a hot table that thousands of queries hit.
Databricks offers two ways to cut it. A public-preview integration with Cloudflare R2 lets you share from a zero-egress object store, so cross-cloud reads carry no transfer charge from the storage layer. For heavy, repeated access, the Change Data Feed pattern plus Delta Deep Cloning replicates the table into a local regional copy and keeps it fresh, so recipients query locally and egress is limited to the refresh rather than every read.
Cross-cloud cost at a glance (2026)
| Approach | How cross-cloud data is accessed | 2026 cost signal |
|---|---|---|
| BigQuery Omni | Query AWS S3 or Azure Blob in place; compute runs in the data's region | $9.125 per TiB scanned (Enterprise edition), plus cross-cloud transfer from $0.09/GiB |
| Borderless Lakehouse (Preview) | Cross-cloud interconnect with local caching of read segments | Avoids most cross-cloud egress on repeat reads; flat-rate interconnect |
| Snowflake replication | Copy data cross-region or cross-cloud, then query the local copy | $90 to $155 per TB transfer; Egress Cost Optimizer caches after first egress |
| Databricks Delta Sharing | Share in place; egress charged only when queried across clouds | Cost grows with recipient reads; Cloudflare R2 integration removes storage egress |
| Raw cloud egress (reference) | Direct internet or cross-cloud transfer, no query engine | AWS $0.09/GB, Azure $0.087/GB, Google Cloud $0.12/GB (first tier) |
A worked example: 50 TB a month, three clouds
Take a realistic mid-size case. Events land in S3 on AWS, transactions sit in Azure, and the analytics team queries from BigQuery. Analysts scan about 50 TB a month, and roughly 20 percent of that, 10 TB, touches data in another cloud.
Paid as raw egress at the AWS $0.09 per GB first-tier rate, moving 10 TB out costs about $900 a month, or $10,800 a year, before a single query runs. Query the same data in place with BigQuery Omni and you pay the $9.125-per-TiB scan rate on the cross-cloud portion instead of a full copy, plus transfer only on the results you pull back, which for a 10 TB scan that returns a few gigabytes is a rounding error next to the $900. If the workload is a repeated dashboard rather than one-off exploration, the borderless Lakehouse cache or a Snowflake replica with the Egress Cost Optimizer collapses the second-and-later reads to near zero transfer.
The pattern is consistent: the more often you read the same cross-cloud data, the more a cache-or-replicate model wins, and the more one-off the access, the more query-in-place wins. The expensive choice is the default one, paying full egress on every read because nobody modelled the transfer.
Which engine fits which situation
| Situation | Best fit | Why |
|---|---|---|
| Already standardised on BigQuery, data scattered in S3 and Blob | BigQuery Omni or borderless Lakehouse | Query in place; no full copy; caching cuts repeat-read egress |
| Snowflake shop distributing one dataset to many regions | Snowflake with Egress Cost Optimizer | First-egress caching drops per-region replication cost to zero |
| Databricks lakehouse sharing tables with partners | Delta Sharing on Cloudflare R2 | Zero storage egress; cost tracks actual reads |
| Hot table read thousands of times a day cross-cloud | Replicate to a local copy (any engine) | A cached or cloned local copy beats paying egress per read |
| Rare, exploratory cross-cloud joins | Query in place | Avoids paying to copy data you touch once |
None of these removes the underlying transfer physics. They change who pays it and how often. A team that reads a table once a quarter should never replicate it, and a team that reads it 10,000 times a day should almost always keep a local copy. The engineering judgement is matching access frequency to the cost model, not picking a favourite vendor.
India-specific considerations
For teams building in India, two factors sharpen the decision. First, currency: at 2026 exchange rates a $900-a-month cross-cloud egress bill is roughly Rs 75,000, and an unmodelled $10,800 annual transfer line runs close to Rs 9 lakh, real money for a growth-stage company watching burn. Cross-cloud analytics is one of the clearest FinOps wins available to Indian data teams, and it usually needs an architecture change rather than a discount negotiation.
Second, data residency. The Digital Personal Data Protection Act 2023 (DPDP) makes where data physically sits a compliance question, not only a cost one. Query-in-place engines like BigQuery Omni and Delta Sharing help here: because the data is not copied out of its origin region, it is easier to keep personal data inside a required boundary while still analysing it. A replicate-first model needs an explicit check that the destination region is a permitted one before the first sync runs.
The open table format underneath all of this
One thread runs through every option above: they work best when the data is stored in an open table format, usually Apache Iceberg or Delta Lake, rather than a proprietary warehouse format. Google's borderless Lakehouse targets Iceberg tables in S3, Databricks built Delta Sharing on Delta Lake, and catalog federation across AWS Glue, Unity Catalog and Snowflake Horizon only works because the tables underneath speak a common language. Choosing that format is a separate and consequential decision, and it increasingly determines how portable your data is across exactly the cloud boundaries this article is about.
How eCorpIT can help
eCorpIT is a Gurugram-based, ISO 27001:2022-certified engineering organisation that helps teams design multi-cloud data platforms without paying avoidable egress. Our senior engineers audit where your cross-cloud transfer is actually going, model the query-in-place versus replicate trade-off against your real read patterns, and implement the chosen path on BigQuery, Snowflake or Databricks with DPDP data-residency built in. If cross-cloud analytics costs are climbing faster than your data, talk to us at /contact-us/ for a cost review.
FAQ
References
- BigQuery pricing — Google Cloud
- BigQuery pricing guide 2026 — Airbyte
- Introducing the borderless Lakehouse — Google Cloud Blog
- About borderless Lakehouse — Google Cloud Documentation
- Expand to new regions with zero additional egress costs — Snowflake Blog
- Snowflake data transfer costs 101 — Flexera
- Databricks Delta Sharing: cost-efficient cross-cloud data access — Microsoft Community Hub
_Last updated: 3 August 2026._