A government agency committed to multi-cloud for resilience. The logic was sound in the business case: spread critical services across more than one provider so that no single outage, and no single commercial relationship, could take the whole thing down. Two years later the agency was running three clouds, each with its own team, its own pipelines, and its own way of doing identity, and none of the three could fail over to either of the others because they had never been built to talk. The resilience was theoretical, the cost was real and recurring, and the commitment was politically unbreakable because it had been announced as strategy.
Nobody could say the multi-cloud plan had failed. Nobody could say what it was actually delivering either.
This is the shape the multi-cloud-versus-consolidation debate takes in practice, and both sides of it have been corrupted by procurement narratives. One camp sells multi-cloud as resilience and leverage; the other sells consolidation as simplicity and savings, meanwhile the ground truth is that most enterprises already run several clouds whether they meant to or not, using an average of well over two public providers and, in most cases, private infrastructure alongside them in a hybrid cloud estate (Flexera, 2025). The cloud consolidation instinct is not wrong, but it usually arrives too late to be the real question, because by the time anyone drafts a consolidation slide the cloud strategy has already been settled in a hundred small delivery decisions that nobody went back to revisit.
The real question is how to engineer coherence across what an organisation already has.
This post lays out five things multi-cloud actually demands once it is treated as an architectural fact rather than a strategic choice, and the earlier argument that placement belongs in the data and identity layers rather than at the procurement desk runs straight through all five (see Part 1).
The three-cloud government
Look more closely at how the agency ended up where it did, because the mechanism is general, the resilience mandate was real and reasonable. What turned it into three islands was that it was discharged as a procurement exercise rather than an architectural one. Each cloud was stood up as its own programme, with its own delivery team, its own landing zone, its own identity model, and its own security posture, because that was the fastest way for each team to ship. Standardising inside each cloud was achievable and each estate, taken alone, was competently run. The problem lived entirely in the gaps between them.
Resilience was the first casualty.
You cannot fail a workload onto a platform it has never been integrated with, and three environments that share no identity, no data plane, and no common control cannot actually take over from one another. The failover existed on a diagram and nowhere else. Cost was the second. Three platforms meant roughly three times the engineering surface, triplicated tooling, and three teams solving the same problems in parallel, none of which the original business case had priced. And because the commitment was public, none of it could be unwound; the only way out was forward, through coherence.
That is the useful reframing. Multi-cloud stopped being a decision the moment it became a fact on the ground, and the same is true for most enterprises reading this. Coherence is engineered across clouds, not chosen between them. Government does have working models for this, where shared standards and a common governance layer let independently built systems interoperate, as Singapore’s whole-of-government approach to platform and API governance shows (Singapore Government API Governance case study). The rest of this post is about what that coherence actually requires.
The five things multi-cloud actually demands
Coherence is not a single feature you buy. It is five distinct properties an architecture has to hold at once, and the organisations winning at multi-cloud have engineered all five rather than any one of them in isolation.
1. A control plane that spans clouds
The first demand is the one everything else hangs off: a control plane that spans clouds.
A control plane is the layer that makes decisions about the estate, who is allowed to do what, where a workload may run, which policy applies, and whether an action is permitted, as distinct from the data plane that does the actual work. In a single cloud, the provider gives you one for free. Across three, you either build one that spans them or you have none, and three well-run estates with no common control are still three islands.
This is the move that separates coherent multi-cloud architecture from expensive sprawl. Standardising inside each cloud, making each landing zone tidy, feels like progress but does not close the gaps, because the gaps are between the clouds, not inside them. A spanning control plane authenticates, authorises, places, and governs uniformly regardless of which provider executes the workload: a policy engine, an identity broker, a placement layer, and an evidence aggregator that sit above the providers rather than inside any one of them. That is where cloud governance actually comes to live in a multi-provider estate, and the four demands that follow are the things this layer has to carry. Building that layer, attested and provider-neutral, is the core of what Sakura’s Cloud practice does. The first thing that control plane has to carry, before anything else, is identity.
2. Identity that does not fragment
The second demand is that identity must not fragment along cloud boundaries.
Left to defaults, each provider’s native access management becomes its own identity island: a workload in one cloud and a workload in another authenticate by different mechanisms, hold different credentials, and cannot verify each other without falling back to shared secrets passed across the gap. Every one of those secrets is a liability, and the security posture forks the instant the second cloud appears.
The resolution is portable workload identity, a way of giving every workload, service, and agent an identity that is the same regardless of which cloud it runs in. The open standard here is SPIFFE, implemented by SPIRE, a graduated project of the Cloud Native Computing Foundation whose federation model exists precisely to establish trust across organisational and cloud boundaries (CNCF, 2022). With cross-cloud identity in place, a call from a workload in one provider to a workload in another is authenticated the same way as a local one, short-lived credentials replace the long-lived secrets that used to bridge the gap, and the security model stops forking per environment. Uniform identity is also what makes the next demand safe, because once workloads can reach each other securely across clouds, there is far less reason to copy data into all of them.
3. Data products that do not duplicate
The third demand is that data has to be exposed across clouds as products, not copied into each of them.
The default failure mode is duplication: a dataset that a workload in another cloud needs gets replicated into that cloud, and then into the next, until the same data exists in three places, drifting apart and each carrying its own governance and its own copy of the risk. The cross-cloud data problem is not that data cannot move; it is that duplicating it multiplies cost, staleness, and exposure at once, with egress charges the visible tax and governance drift the hidden one. A dataset copied nightly into two other clouds is three datasets to secure and three to keep current, plus two recurring egress bills, and by the second week the three copies have already begun to disagree.
The alternative is to treat data as a product with a clear owner, contract, and access path, reachable across the cloud boundary rather than replicated across it, which is the same discipline the previous post argued operational telemetry now needs. A well-defined data product exposed through the control plane lets a consumer in one cloud use data that lives in another without a copy landing locally. Duplication becomes the exception you justify, not the default you inherit. That discipline also happens to be where a large share of multi-cloud cost quietly hides, which is the fourth demand.
4. Cost discipline that survives autonomy
The fourth demand is cost discipline that survives team autonomy.
Multi-cloud multiplies spend by construction, and organisations already find single-cloud spend hard to control: a large majority report struggling to manage their cloud costs even before a second and third provider enter the picture (Flexera, 2025). Give three autonomous teams three providers with three billing models and cost visibility fragments completely, which is how multi-cloud cost overruns become invisible until the invoice arrives.
The answer is not to remove the autonomy that lets teams move quickly; it is to make cost a property the control plane enforces rather than a report someone assembles after the fact. Consistent tagging and allocation across providers, budget guardrails expressed as policy that can halt a runaway workload before the month closes, and showback that makes each team see its own spend, turn the practice of cloud financial management, now widely called FinOps, from a monthly reconciliation into a live control. Autonomy without visibility is just untracked spend, and multi-cloud makes the gap between the two expensive fast. The last property the control plane has to carry closes the loop the agency opened, which is proof.
5. Operational evidence that holds up across providers
The fifth demand is operational evidence that holds up across providers.
When a workload fails, or an auditor asks how a decision was reached, an organisation needs one coherent account of what happened, not three partial logs in three formats that no one can reconcile under pressure. Multi-cloud makes this harder because every provider emits its own telemetry, its own audit trail, and its own idea of an event, and left alone they never add up to a single chain.
This is where the argument in the third post of this series, that evidence has to be an engineered property rather than a retrospective reconstruction, meets multi-cloud head on (see Part 3). Coherent evidence across clouds means normalising those disparate signals into one verifiable record at the control-plane level, so a question about any workload resolves against a single account regardless of which provider ran it. Without it, the resilience and compliance claims that justified going multi-cloud in the first place cannot actually be demonstrated across the estate, which returns the agency to exactly where it started: a strategy nobody could fault and nobody could prove.
The organisations that win at multi-cloud stop trying to standardise inside each provider and instead engineer these five properties as one coherent layer across all of them, which is the coherence Sakura’s Managed Services team builds and runs once the architecture is in place.
References
CNCF, 2022. SPIFFE and SPIRE Projects Graduate from Cloud Native Computing Foundation Incubator. Cloud Native Computing Foundation. Available at: https://www.cncf.io/announcements/2022/09/20/spiffe-and-spire-projects-graduate-from-cloud-native-computing-foundation-incubator/ [Accessed 9 July 2026].
Flexera, 2025. Flexera 2025 State of the Cloud Report. Flexera. Available at: https://info.flexera.com/cm-report-state-of-the-cloud [Accessed 9 July 2026].