+++
title = "Two clouds can share one failure dependency"
description = "Two cloud deployments can fail through one shared dependency. Examine the identity, network and recovery systems behind apparent redundancy."
date = 2026-09-11
draft = false
[taxonomies]
topics = ["hybrid-placement-migration", "backup-disaster-recovery-resilience", "identity-privileged-access-secrets", "encryption-keys-confidential-computing"]
kinds = ["second-order"]
[extra]
tier = "public"
schema_type = "Article"
article_class = "second-order"
related_concepts = ["common-cause failure", "dependency graph", "credential renewal", "recovery independence"]
sources = ["https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html", "https://spiffe.io/docs/latest/spiffe-about/overview/", "https://developer.hashicorp.com/vault/docs/secrets", "https://docs.aws.amazon.com/kms/latest/developerguide/overview.html"]
source_details = [{ title = "Plan for Disaster Recovery", publisher = "Amazon Web Services", url = "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html", checked = "2026-09-09" }, { title = "SPIFFE Overview", publisher = "SPIFFE project", url = "https://spiffe.io/docs/latest/spiffe-about/overview/", checked = "2026-09-09" }, { title = "Secrets engines", publisher = "HashiCorp", url = "https://developer.hashicorp.com/vault/docs/secrets", checked = "2026-09-09" }, { title = "AWS Key Management Service", publisher = "Amazon Web Services", url = "https://docs.aws.amazon.com/kms/latest/developerguide/overview.html", checked = "2026-09-09" }]
faq = [{ question = "Does using two cloud providers make service failures independent?", answer = "No. Required shared components can connect their failure paths." }, { question = "Does an identity-issuer outage stop both sites immediately?", answer = "No. Credential validity, caching, enforcement and alternate authority determine when affected operations fail." }, { question = "Can multi-cloud designs provide independent recovery?", answer = "Yes. The tested service paths must retain their required capabilities under the failures for which independence is claimed." }]
evidence_as_of = "2026-09-09"
related_articles = ["cloud-on-premises-saas", "workload-identity-privileged-access", "recovery-transaction-reconciliation"]
category_slug = "infrastructure"
category_name = "Infrastructure"
+++

A common-cause dependency is a component or condition whose failure can disable otherwise separate service paths. Two cloud deployments can share such a dependency through identity, keys, connectivity or another required service.

## Infrastructure diversity and shared authority

Different infrastructure providers create different compute and storage environments. A business operation still needs every dependency required along its execution path. If both environments rely on one authority, loss of that authority can affect both.

Identity issuance provides a concrete mechanism. A workload can run on either provider while obtaining its credentials from the same issuer. If an operation requires a valid credential and neither deployment can renew it, healthy compute does not complete that operation.

The dependency belongs in the service model even when it is absent from a diagram of virtual machines and storage. A provider count describes infrastructure choices; it does not establish independent authorization or recovery paths.

## Credential lifetime changes the outage timing

Take two healthy cloud deployments whose required credentials expire at 12:30. Their only issuer is unavailable from 12:00 to 13:00. Assume the operation requires renewed credentials after expiration and no alternate authorization path exists.

The issuer outage does not, under these assumptions, stop the operation at 12:00 merely because renewal is unavailable. Existing valid credentials can continue to satisfy the stated check until their expiration. After 12:30, both deployments lack the required renewed authority, despite their healthy infrastructure.

The observed interruption depends on credential validity, caching and the operation’s enforcement behavior. Some established sessions or independently authorized functions can behave differently. The example applies specifically to the operations that require the unavailable renewal.

## Recovery dependencies can be shared too

A recovery path can need a key service, privileged administrator or network route that both deployments share. Restoring encrypted data onto a second provider is insufficient for a function that cannot obtain the required decryption authority.

Likewise, duplicated application instances can share a control configuration or upstream service whose failure prevents both from processing new work. Independence must be assessed for the complete service path and the particular failure being tested.

This does not mean every dependency needs identical duplication. It means the claimed recovery outcome must account for the dependencies it actually requires. A second deployment supplies no evidence about a missing recovery step merely by existing.

## The correlated-failure consequence

If two paths share a required component and lack an alternate path for its failure, loss of that component can disable the same operation on both. Infrastructure diversity reduces only failures for which the complete remaining paths retain the required capabilities.

An availability calculation that treats two deployments as independent needs evidence supporting that assumption. Multiplying nominal provider probabilities while omitting a shared issuer calculates a different model from the deployed service. No outage probability is inferred from this example.

## Conditions that break the common dependency

Independent issuers, valid offline authority or tested alternate authorization can change the result. Cached credentials can defer the effect. A genuinely independent recovery key arrangement can remove a shared key-service dependency for the tested function.

The conclusion is conditional rather than a verdict on multi-cloud designs: two providers can still share one operational failure path. What changes is the dependency graph and the permitted alternatives. Recovery independence is established by the service’s behavior under the specified failure, including the time at which cached authority ceases to suffice.

## Questions about common-cause failure

### Does using two cloud providers make service failures independent?

No. Required shared components can connect their failure paths.

### Does an identity-issuer outage stop both sites immediately?

No. Credential validity, caching, enforcement and alternate authority determine when affected operations fail.

### Can multi-cloud designs provide independent recovery?

Yes. The tested service paths must retain their required capabilities under the failures for which independence is claimed.