8 min read

At Cloud Next 2026, Google announced building blocks that turn multi-cloud from an architectural theory into an operational decision. Any DACH CIO who still believes cross-cloud strategies fail due to egress costs and data silos should pay close attention: the leverage is no longer about compute, but where the data resides and what it costs to move it.

Key Takeaways

• Cross-cloud Lakehouse (formerly BigLake) now allows queries across AWS, Azure, and GCP data sources without full replication; the cross-cloud caching layer stores the first read in the home system and slashes egress fees on recurring queries.
• Gemini Enterprise Agent Platform bundles agent registries, skill registries, and governance into a single layer explicitly built for multi-cloud deployments-not a new vendor stack, but a control plane over existing workloads.
• Agentic Data Cloud turns data management into a strategic question: whoever controls the master tables controls the agent stack that uses them.
• AWS and Google have separately announced a multi-cloud deployment partnership, making workloads technically more portable between the hyperscalers, but further intensifying the race for the data layer.
• Operational implication for CIOs: The question is no longer “which cloud,” but “where does the master data stay, where is processing allowed, and who bears the cache risk.”

Egress as a Hidden Tax on Every Multi-Cloud Strategy

Anyone who has seriously tried to spread workloads across two hyperscalers over the past three years knows the CFO’s immediate reflex: egress costs. AWS, Azure, and GCP charge per-gigabyte fees for outbound traffic that can quickly reach five figures a month for an 80-terabyte pipeline. These rates are no accident; they are what vendor lock-in looks like as a line item on a balance sheet. Once data sits in a bucket, it costs a premium to get it out.

The cross-cloud caching feature Google unveiled at Next 2026 tackles this exact problem. It stores data that has been pulled across cloud boundaries locally in the Lakehouse cache, so recurring queries no longer trigger egress every single time. For a reporting setup that consumes the same dataset from an S3 bucket daily, this ideally means an order of magnitude less outbound traffic. The architectural truth behind this: caching is nothing new, but when a hyperscaler offers it as a native service across foreign cloud boundaries, it massively shifts the ROI calculus for cross-cloud deployments.

A DACH Example Makes the Scale Tangible

A mid-sized industrial conglomerate that collects its machine data in AWS S3 and analyzes it via GCP BigQuery reports running about 12 TB of cross-cloud egress monthly. At current AWS rates, that comes to nearly 1,080 euros per month just for data movement. With a 70 percent cache hit rate on recurring analytics queries, outbound traffic drops to about 3.6 TB, and the bill falls to roughly 330 euros. Over a year, that is a 9,000 euro difference on a single data path. Run several pipelines like this, and you are quickly talking about six-figure savings.

From Data Silos to Borderless Lakehouse

The second shift comes from the lakehouse itself. Google calls the new variant “borderless”-the lakehouse layer can reference tables physically located in S3 or Azure Data Lake without requiring data to be replicated into BigQuery. For engineering teams, this means less ETL, fewer sync jobs, and fewer points where schema drift can break a report. For CIOs, it means the question of where data “belongs” can be renegotiated politically and contractually without every answer triggering a migration project.

The flip side: whoever controls the lakehouse layer controls the query logic. Google positions itself here as a neutral mediator-a strategically smart move, as its own compute becomes the default query engine across third-party buckets. AWS and Azure have comparable initiatives, but both are more deeply embedded in their own ecosystems. The choice of which lakehouse layer becomes the de facto standard in a DACH enterprise is therefore a vendor-strategic decision with a long half-life.

“Multi-cloud was once a compliance answer. With the new lakehouse and caching layers, it becomes an architectural option-but the choice of who controls the data layer remains a long-term lock-in decision.”

Agent Stack: Who Controls the Data Controls the Skills

The Gemini Enterprise Agent Platform and Agentic Data Cloud represent the more strategic announcement. Google consolidates agent registry, skill registry, tool registry, and governance into a single layer explicitly designed to manage AWS, Azure, and GCP workloads together. Instead of pushing “migrate your apps to us,” Google’s approach is “we’ll become the control plane over your existing apps.” From a CIO’s perspective, this is appealing because it reshapes the investment equation: rather than funding a workload migration project, you pay for an abstracted control subscription.

However, this merely shifts the risk up one layer. If, in two years, you realize your agent registry and tool inventory reside with Google, swapping out the control plane will feel the same lock-in effect multi-cloud was supposed to avoid. The only sustainable solution: push for open standards for agent definitions, skill schemas, and tool manifests before proprietary formats become entrenched.

Compliance Moves to the Cross-Cloud Layer

What often gets lost in architecture debates: GDPR, NIS2, and the EU AI Act don’t prescribe cloud providers, but they do dictate where data is processed and who can access it. A cross-cloud caching layer holding personal data in a GCP cache while the source table sits in a German AWS data center isn’t a trivial compliance matter. The operational question becomes: which data categories can be cached, and where? And how is the cache lifecycle documented when regulators come knocking?

The vendor response will be “policy-driven caching”-rules defining which data classes can cross cloud boundaries. In practice, this means a data classification schema must exist before the first cross-cloud pipeline goes live. Postpone this, and you’re building an audit-finding generator.

Three Key Questions Before Your Next Multi-Cloud Step

1. Where do the source data reside, and where are copies allowed? Caching may sound like a performance issue, but it’s a compliance one. No data classification, no cross-cloud cache.

2. Which query engine will become the standard? Lakehouse layers have half-lives of five to ten years. Deciding whether BigQuery, Athena, Synapse, or Snowflake becomes the dominant query path is a vendor-strategic call, not just a tooling choice.

3. Who controls the agent control plane? If the agent registry and tool inventory sit with a hyperscaler, multi-cloud works at the compute level-but intelligence becomes centralized again. Start open-standard discussions now, not in two years.

Frequently Asked Questions