The Data Lock-In Problem That Has Quietly Defined Multicloud
Enterprise cloud strategy has converged on multicloud: 87% of enterprises now run workloads across multiple cloud providers, according to Flexera’s 2025 State of the Cloud Report. But multicloud in practice has not delivered the vendor independence and cost control it promised. Organizations using multiple clouds waste an average of 28% more than single-cloud companies, and multicloud total cost of ownership is typically 2x what teams estimate, according to LeanOps Technology.
The primary reason is data gravity. Once large datasets are stored in one cloud — in AWS S3, Google Cloud Storage, or Azure Blob — moving them out carries data egress costs that compound over time. AWS charges $0.09/GB out, and GCP charges $0.08 to $0.12/GB depending on destination. A company syncing 500GB nightly between AWS and GCP incurs approximately $45 daily in egress fees — over $16,000 per year on a single pipeline. Multiply that across a data platform with dozens of pipelines, and the egress bill becomes a structural barrier to multicloud data flexibility. Teams stop moving data not because it is architecturally wrong, but because it is economically prohibitive.
The second reason is format fragmentation. AWS stores data optimized for AWS services, Google’s BigQuery has its own storage format, and each platform’s managed services introduce proprietary table formats and metadata schemas that make cross-cloud queries technically complex and performance-degrading. This format fragmentation means that even organizations willing to pay egress costs often cannot run performant analytical queries across their full dataset without expensive ETL consolidation.
Apache Iceberg — an open table format that stores data in standard Parquet files with an open metadata layer — is the architectural response to both problems simultaneously. And Google Cloud Next 2026 made clear that Iceberg is no longer an aspirational standard: it is the format around which the hyperscalers are converging.
What Google Announced and Why It Matters
Google announced a suite of Iceberg-related capabilities at Cloud Next 2026 that collectively represent the most aggressive industry bet on open data portability yet:
Cross-Cloud Lakehouse (Announcement #57): Google’s Cross-Cloud Lakehouse — formerly BigLake — is now powered by an Iceberg REST Catalog that enables agents and analytics workloads to “seamlessly access data across AWS, Azure, and a vast partner ecosystem.” The REST Catalog standard means any Iceberg-compatible tool can query data across clouds without proprietary connectors.
Managed Iceberg Storage and REST Catalog (Announcement #61): Google is providing automatic management and multi-table transactions on Iceberg tables, with read/write interoperability across BigQuery, Apache Spark, and open-source engines. This eliminates the need for complex ETL pipelines to consolidate data before querying.
Lakehouse Catalog Federation (Announcement #58): Zero-copy sharing of data across AWS Glue, Databricks, and Snowflake — meaning Google can query data directly in those systems’ catalogs without importing or copying it. This is the architectural move that makes Google Cloud a credible participant in data ecosystems that were previously AWS-native.
Cross-Cloud Caching (Announcement #62): An intelligent cache that stores cross-cloud data on first read and slashes egress fees on follow-on queries for AWS and Azure data. This directly attacks the egress fee problem — the first query to cross-cloud data incurs the egress cost; subsequent queries are served from cache.
Lightning Engine for Apache Spark (Announcement #59): Up to 2x price-performance improvement over proprietary market alternatives for agentic data science workloads running on Spark.
Advertisement
What Data Architects and Heads of Data Should Do About It
1. Standardize All New Table Definitions on Apache Iceberg Immediately
The convergence of Google, AWS, and Azure on Iceberg as the de facto open table format creates a clear architectural rule for 2026: any new data table, pipeline, or storage layer should use Iceberg by default. The catalog federation capabilities announced at Cloud Next 2026 — and the parallel investments AWS is making in Iceberg compatibility for its Glue catalog — mean that Iceberg tables can be queried from any major platform without proprietary conversion. Teams that continue creating tables in proprietary formats (Hive metastore without Iceberg, BigQuery native tables without Iceberg export, Delta Lake without Iceberg compatibility) are building lock-in debt that will cost more to remediate in 2027 than the migration effort required to standardize on Iceberg today.
2. Quantify Your Annual Egress Bill Before Designing Any Cross-Cloud Architecture
The $16,000/year figure for a single 500GB nightly pipeline is not a worst case — it is a representative case for a medium-sized data team. Before designing any cross-cloud data architecture — whether for AI training pipelines that span AWS compute and Google Cloud Storage, or for analytics that query data across S3 and BigQuery — calculate the egress cost explicitly. AWS’s cost model ($0.09/GB out), GCP’s ($0.08-0.12/GB), and Azure’s (variable by region) all compound at pipeline scale. Google’s cross-cloud caching is a partial solution; the architectural solution is minimizing unnecessary cross-cloud data movement by placing compute in the same region as data wherever possible, and using Iceberg federation for analytical queries that should never move data at all.
3. Adopt Zero-Copy Federation for Analytical Queries Across Providers
The Lakehouse Catalog Federation capability announced at Google Cloud Next 2026 — enabling zero-copy sharing across AWS Glue, Databricks, and Snowflake — is the most directly actionable capability for eliminating unnecessary data movement in multicloud analytics. Zero-copy federation means querying a table in AWS Glue from BigQuery without moving the underlying Parquet files — only the query result traverses the network, not the dataset. For data teams running analytical workloads that span providers (common in organizations that acquired companies on different clouds, or that use specialized services on different providers), adopting zero-copy federation patterns eliminates the majority of cross-cloud egress costs without requiring data consolidation.
4. Renegotiate Cloud Storage Agreements Using Iceberg Portability as a Negotiating Lever
The commercial implication of Iceberg standardization is that cloud storage agreements are now negotiable in ways they were not before. When data is stored in a proprietary format that only one vendor’s tools can read efficiently, the switching cost is functionally infinite — any renegotiation threat is not credible. When data is stored in Iceberg on standard Parquet files, the switching cost is bounded: it is the cost of migrating catalog metadata and updating connection configurations, not the cost of re-encoding or re-ingesting all data. Use this bounded switching cost as the basis for renegotiating storage pricing, egress fee waivers, and support terms with your primary cloud providers. The argument is simple: Iceberg makes switching credible, and credible switching threats produce better commercial terms.
Where This Fits in 2026’s Data Ecosystem
The Iceberg convergence at Google Cloud Next 2026 is not an isolated announcement — it is the enterprise infrastructure response to a problem that has been accumulating for five years. Organizations adopted multicloud for resilience, regulatory compliance, and capability access. They discovered that multicloud in practice produces data fragmentation, egress costs, and analytical complexity that single-cloud architectures avoid. The hidden cost — 28% more waste, 2x TCO — is the market signal that drove the Iceberg standardization wave.
The practical effect of the Cloud Next 2026 announcements is that the cross-cloud analytical query — running a query that touches data in AWS, Google Cloud, and Databricks simultaneously — is moving from an expensive engineering project to a standard platform capability. The Lightning Engine’s 2x price-performance improvement on Spark workloads reduces the compute cost of running these queries; zero-copy federation eliminates the storage movement cost; and cross-cloud caching reduces the egress cost after the first query.
For data architects in 2026, the strategic posture is clear: standardize on Iceberg, eliminate unnecessary data movement through federation and caching, quantify your egress bill, and use Iceberg portability as commercial leverage with cloud providers. The organizations that execute this strategy in 2026 will have structurally lower multicloud costs and meaningfully more flexibility in how they distribute workloads and negotiate contracts than those that do not.
The competitive dynamics around Iceberg are also worth tracking. Delta Lake — Databricks’ open-source table format — has been the primary competitor to Iceberg in data lakehouse architectures. Databricks announced Delta Universal Format (UniForm) to support reading Delta tables as Iceberg, partially closing the compatibility gap. Snowflake’s Iceberg Tables feature similarly allows Snowflake to read and write external Iceberg tables. The convergence of three major analytics platforms — Google BigQuery, Databricks, and Snowflake — on Iceberg compatibility within a 12-month window is not coincidental; it reflects that enterprises were demanding portability as a condition for large platform commitments, and the vendors had no commercial alternative but to provide it.
The FinOps Foundation’s data indicates that data egress and storage costs are the fastest-growing hidden cost categories in enterprise cloud bills, ahead of compute and support. For data teams that have historically focused optimization efforts on compute (right-sizing instances, reserved pricing, spot instance usage), the 2026 priority shift is toward data movement costs — and Apache Iceberg with zero-copy federation is the primary architectural tool for addressing that category. Teams that treat Iceberg adoption as a format decision are underestimating the commercial leverage it creates; the real value is in the egress cost elimination and the vendor negotiating position that open, portable data enables.
Frequently Asked Questions
What is Apache Iceberg and how does it differ from other data table formats?
Apache Iceberg is an open table format for large analytical datasets that stores data in standard Parquet files with an open metadata layer. Unlike proprietary formats such as BigQuery native tables or Delta Lake (Databricks’ default format), Iceberg tables can be read and written by any compatible engine — Spark, Trino, Flink, DuckDB, and the query engines of AWS, Google Cloud, and Azure — without proprietary connectors. This cross-engine compatibility is what makes Iceberg the foundation for zero-copy cross-cloud data federation, where a query engine can read Iceberg metadata in one cloud and access the underlying Parquet files in another.
What is the actual annual cost of cross-cloud data transfer and how significant is it?
AWS charges $0.09/GB for data transferred out, and Google Cloud charges $0.08-0.12/GB depending on destination. A company syncing 500GB nightly between AWS and GCP incurs approximately $45 per day in egress fees — over $16,000 per year for a single pipeline. For organizations with 10-20 active cross-cloud pipelines, annual egress costs can exceed $100,000-$200,000. These costs are often categorized as “networking” in cloud bills and are systematically underestimated — LeanOps data shows that multicloud TCO is typically 2x what teams estimate before accounting for hidden egress costs.
Does adopting Apache Iceberg require migrating existing data?
Not immediately. Apache Iceberg supports incremental adoption — you can begin creating new tables in Iceberg format while leaving existing tables in their current format. Migration tools (including Iceberg’s built-in table migration utilities and AWS Glue’s Iceberg conversion feature) can convert existing Parquet-based tables to Iceberg format with minimal downtime. The catalog metadata migration is the most complex part; the underlying Parquet data files typically do not need to be re-encoded. The practical recommendation is to standardize all new table definitions on Iceberg immediately and schedule a phased migration for existing high-traffic tables over the next 12 months.
—
