DACH Architects in Google’s Cache Spotlight
On April 24, Google Cloud unveiled Cross‑Cloud Caching as a new feature during its Cloud Next 2026 recap. The idea is that data from AWS and Azure is replicated into Google Cloud …
On April 24, Google Cloud unveiled Cross‑Cloud Caching as a new feature during its Cloud Next 2026 recap. The idea is that data from AWS and Azure is replicated into Google Cloud Storage on first read, then made locally available for all subsequent requests. This eliminates e‑gress charges for the second, third, and further requests. For DACH multi‑cloud architects, this is a very compelling cost argument on paper. In practice, however, it raises a question rarely addressed head‑on: what level of data sovereignty justifies the e‑gress costs?
Key Takeaways
- What’s new: Google Cloud’s Cross‑Cloud Caching pulls data from AWS S3 and Azure Blob into GCP storage on first read and caches it for later requests.
- Why it matters now: e‑gress from AWS and Azure remains the single most expensive part of multi‑cloud setups. Any repeated read from another cloud still triggers a charge.
- What’s still unclear: the data physically resides in GCP storage. DACH teams bound by strict data‑sovereignty rules need to examine this before rolling the feature out in full.
The announcement was made during the April 24 Cloud Next 2026 recap (cloud.google.com). Cross‑Cloud Caching is part of Google’s push to meet the multi‑cloud reality many DACH firms have lived with for years–yet rarely manage elegantly. We previously laid out the big picture in What DACH Architects Expect from the Cloud Next 2026 Roadmap. Cross‑Cloud Caching is the practical mechanism behind that initiative.
How the feature works
The principle is caching–familiar to front‑end developers via CDNs–pushed one layer deeper and across cloud borders. A BigQuery or Vertex AI job reads a dataset from AWS S3. On the first read, traffic follows the usual path and incurs e‑gress charges. Cross‑Cloud Caching copies the object in parallel into Google Cloud Storage. All later requests for the same dataset hit the local cache. From AWS’s perspective, no further activity is triggered after that first read.
Technically, it’s a blend of storage replication and smart routing: cache lookup before cross‑cloud fetch, TTL‑based invalidation, and a control layer that decides which data deserves caching. Anyone who has worked with edge caches and the “stale‑while‑revalidate” pattern will recognise the pattern. What’s new is Google delivering this at the storage layer and integrating it into its own analytics services.
Why DACH teams are watching it closely
Egress has long been the most dreaded line on cloud bills. AWS and Azure charge roughly €0.08–€0.09 per GB when data leaves their platforms, according to their pricing pages (AWS Data Transfer Pricing, Azure Bandwidth Pricing, as of April 2026). For workloads that frequently transfer several terabytes of data out of third-party clouds, those costs can quickly justify an architectural review. Cross‑Cloud Caching tackles this problem head-on.
For architects in the DACH region, this is especially significant, because many production set-ups follow this read pattern: historical data lives in AWS or Azure, while the analytics team works in BigQuery. Without a cache, the same dataset is pulled from AWS every month. With the cache, traffic is fetched once and then stays local. Once the cost line stabilises, the bill drops fast. Last week we explored a similar principle in CloudFormation vs Terraform for practical Multi‑Cloud verification: tooling choices often hinge on precisely these recurring operational expenses.
What Fails, What Works
What fails
- Data sovereignty issue: data physically ends up in GCP even when the source remains in AWS or Azure.
- Compliance reviews for regulated sectors (finance, healthcare, critical infrastructure) must explicitly assess this functionality.
- Vendor lock-in shifts toward Google as the cache layer resides there.
What works
- Measurable egress savings for read-heavy workloads, especially in analytics and ML training.
- Transparent mechanism that integrates into existing BigQuery and Vertex AI pipelines.
- Architectural question: which datasets justify caching and which do not.
The real debate isn’t whether to use the feature, but where to apply it and under what constraints. Personal data under GDPR, regulated data classes from critical infrastructure environments, or datasets with explicit geographic restrictions aren’t cache candidates. Telemetry streams, clickstreams, or training datasets without personal data are far better fits. Document this decision in your architecture guides–not just during the annual FinOps review.
What Central European Architects Must Tackle in the Next 90 Days
Start with a clear egress report from AWS and Azure, broken down by dataset and target cloud. Without this baseline, you can’t quantify savings. Next, classify datasets by cache feasibility and secure compliance validation. Finally, launch a pilot on a single read-heavy dataset–ideally telemetry or training data. That gives you a concrete metric instead of relying on vendor estimates.
Strategically, the lock-in trade-off deserves an open workshop: multi-cloud caching cuts egress costs but introduces a new dependency on Google’s storage layer. If your multi-cloud exit strategy remains in play, bake this feature into the plan before it quietly becomes a production reality.
Frequently Asked Questions
What is the cost of Cross‑Cloud Caching?
Google Cloud has not published unit prices for the service. Caching costs are expected to be bundled with reduced egress fees. Reliable estimates will only be possible once the official pricing table is available.
Who is the target audience?
Organizations managing multi-cloud environments with productive read pipelines between AWS or Azure and Google Cloud Analytics, particularly users of BigQuery and Vertex AI who frequently pull data from third-party clouds.
What are the implications for data sovereignty?
Data is physically replicated in Google Cloud Storage. Teams subject to geographic restrictions or strict regulatory requirements must verify the GCP region hosting the cache and ensure compliance before enabling the feature.
Photo: Lovelano / Wikimedia Commons (CC BY 4.0)
