Three Clouds Can Still Have One Failure Domain

Three cloud logos on an architecture diagram can look like resilience. Sometimes they are. But a logo count is not a dependency map.

NIST’s newly published draft on multi-cloud architecture describes a familiar problem in unusually direct language: when services span providers, it can be hard to identify system boundaries, network architecture, and security processes. Its working group highlights identity and access management, telemetry, configuration and change management, data protection, and authorization as the areas where the seams become most visible.

That does not mean multi-cloud is a mistake. It means “we use more than one cloud” is not an answer to the question a business actually has: what has to keep working for us to serve customers?

The common control plane hiding in plain sight

A practical multi-cloud design often relies on shared things. One identity provider may authenticate users into several services. One network team may manage the paths between them. One managed-service partner may hold the administrative knowledge. One security-monitoring workflow may be expected to see activity everywhere. One recovery plan may assume that the people, credentials, documentation, and vendor contacts needed to restore a service will be available.

Any of those can become a common failure domain. If a centralized identity service is unavailable, the applications may still be running but users cannot reach them. If a change-management process is inconsistent, moving a workload may reproduce the same configuration error in a different provider. If logs are collected unevenly, an organization can end up with two clouds and one blind spot.

NIST’s multi-location zero-trust guidance makes the identity point especially concrete: it shifts attention away from trusting a network location and toward explicit identities and authorization for users, services, and devices. In a multi-cloud setting, that can make the shared identity architecture more important, not less. A stronger front door is valuable; it is also a dependency worth testing.

Resilience is a question of independent recovery

The useful test is not “could this workload move?” It is “could we recover this service if a named dependency failed?” Name the dependencies: identity, DNS, network connectivity, privileged access, encryption keys, monitoring, backup locations, vendor support, runbooks, and the people authorized to make a disruptive decision.

Then ask which of them are truly independent. A backup in another cloud is helpful only if the credentials, keys, network path, restore instructions, and recovery authority do not all depend on the first environment. NIST’s recovery guidance similarly emphasizes understanding interdependencies when establishing recovery objectives; sometimes an identity or authentication service must be restored before the business service that seems more visible.

What to put on the next architecture review

For a 25- to 100-person organization, this does not require building a miniature hyperscaler. It requires an honest map and a small exercise:

• List the shared identity, administration, network, monitoring, and recovery dependencies across each cloud service.
• Assign an owner for each dependency and record who can act when that owner is unavailable.
• Choose one plausible failure—an identity outage, lost privileged access, or a provider-management disruption—and walk through the first hour of recovery.
• Test the assumptions that cross provider boundaries, especially access to backups, keys, runbooks, and vendor escalation paths.

Multi-cloud can create useful options. It does not automatically create independence. The important architecture question is not how many clouds are present. It is how many separate ways the business can still get back to work.