CONCEPT Cited by 2 sources
Cross-Cloud Architecture¶
Cross-cloud architecture is the (deliberate) choice to run components of one system across more than one hyperscaler (AWS, Azure, GCP, …). Typically motivated by some mix of: best-of-breed per-workload hyperscaler services, regulatory / data-residency requirements, acquisition / org legacy, or strategic vendor-concentration reduction.
It differs meaningfully from multi-region inside one cloud:
- Cost structure. Cross-cloud pays both clouds' egress when data moves; inside-one-cloud cross-region pays one provider.
- Network topology. No "backbone private link" by default — the hop goes over the public internet or a paid inter-cloud connection.
- Identity / IAM. Each cloud has its own identity plane; bridging them is work, not a given.
- Service parity is approximate. Same-abstractions across cloud providers are never pixel-for-pixel equivalent; pick-two-of (capability, cost, lock-in) bites.
Forcing functions it creates¶
- Data-gravity asymmetry. Whichever cloud holds the canonical datasets becomes the expensive side to query from the others. In the Mercedes-Benz case the after-sales canonical store was AWS (Iceberg on Glue), the consumer base was Azure — so egress accumulated asymmetrically. See concepts/egress-cost.
- Identity + catalog federation. A cross-cloud mesh requires a catalog that can hold both clouds' metadata + policy, or the mesh degenerates into two siloed meshes. See concepts/hub-and-spoke-governance.
- Format / protocol openness. If the sharing protocol is vendor-locked, cross-cloud consumers can't participate. Open protocols (systems/delta-sharing in Mercedes-Benz's case) are the exchange-tier answer.
- Replication as an escape hatch. When direct cross-cloud reads are too expensive, the answer is often to land an incremental replica in each consumer cloud and read it locally — patterns/cross-cloud-replica-cache.
The Mercedes-Benz positioning¶
Mercedes-Benz frames the multi-cloud choice as deliberate: "This approach allows them to select the hyperscaler services that best fit specific technical requirements." The mesh architecture on top is then in service of that choice, rather than an attempt to paper over an accidental multi-cloud footprint.
(Source: sources/2026-04-20-databricks-mercedes-benz-cross-cloud-data-mesh)
Seen in¶
- sources/2026-04-20-databricks-mercedes-benz-cross-cloud-data-mesh — AWS ↔ Azure mesh, cross-hyperscaler Delta Sharing, egress-driven replication tier.
- sources/2025-09-25-mongodb-carrying-complexity-delivering-agility
— the "cross-cloud as a managed primary" realisation: a
single MongoDB Atlas replica set spans AWS + GCP + Azure,
standard
mongodb+srvconnection string, intelligent drivers auto-failover primary across providers without app-code changes. MongoDB's explicit framing of DIY multi-cloud as "weeks of networking (VPC/VNet peering, routing, firewall rules) and brittle scripts" that collapse under operational reality; the Atlas alternative is the platform-absorbs- complexity stance. Adjacent Atlas primitive Global Clusters / zone sharding layers declarative data-residency on top. Both ride on logless reconfiguration for cross-cloud membership changes that don't queue behind the oplog. Contrast with Mercedes-Benz's mesh-on-top-of-two-clouds pattern: MongoDB is one logical cluster across three clouds; Mercedes-Benz is one exchange-tier protocol between two clouds' catalogs.