CONCEPT Cited by 2 sources
Clean-room recovery account¶
Definition¶
A clean-room recovery account is a separate AWS account (or analogous cloud-provider isolation boundary) used as the destination for backup / replication, specifically chosen so that a compromise of the source account cannot reach the recovery account.
The load-bearing properties:
- Distinct credentials. Source-account IAM principals have no path to the recovery account. Long-lived keys, assumed roles, and federated identities are disjoint.
- Distinct attack surface. Recovery account network, access policies, and control plane are managed independently.
- Copy direction is outbound-only. Source account can push backups to the recovery account (via AWS Backup cross-account copy, S3 replication, etc.); the recovery account does not grant the source any read-back / mutate permissions.
Why cross-account is the ransomware / malware isolation axis¶
Cross-Region addresses natural / technical disasters — a region fails, the other region keeps running. Cross-Region inside the same account does not protect against a compromised source account, because a bad actor with source-account credentials can — in a single account — delete/encrypt both the primary and the cross-Region copy.
Cross-account closes that hole:
"Cross-account backup is a critical security measure to enable recovery from malware and ransomware. By storing copies of your data in a separate clean room recovery account with distinct credentials, you create an isolated environment that can't be accessed, even if the source account is compromised." (Source: sources/2026-03-31-aws-streamlining-access-to-dr-capabilities)
Compositional with cross-Region¶
Cross-account and cross-Region are orthogonal axes. The typical high-assurance DR topology combines both:
| Same account | Different account | |
|---|---|---|
| Same region | Native redundancy only | — |
| Different region | Fault isolation | Fault + compromise isolation |
AWS Backup cross-Region cross-account copy writes into the target cell of that matrix in a single operation. Equivalent mechanisms exist for S3 (replication + bucket policy), EBS (cross-account snapshot copy), DRS (cross-account staging VPCs).
Relation to concepts/account-per-tenant-isolation¶
Same structural primitive (AWS account as isolation boundary), used for a different goal:
- Account-per-tenant uses the account boundary for blast-radius containment per tenant (ProGlove's 6,000 tenant accounts).
- Clean-room recovery account uses the account boundary for compromise-recovery isolation per workload.
Both rely on the same AWS property — IAM credentials don't cross the account boundary without explicit cross-account roles — as the load-bearing isolation guarantee.
Agent-access pattern from the source account¶
Vendor DR agents (e.g. Arpio) that operate across source ↔ recovery need a least-privilege IAM role in the source account. Canonical deny-list:
- Explicitly deny write/mutate in the source — the agent can read metadata needed to replicate, not modify source state.
- Explicitly deny read/exfiltrate of data — the agent orchestrates AWS primitives (snapshots, replications) but does not itself hold a copy of customer data.
The 2026-03-31 post's Arpio example: "the IAM role used to access your source AWS account is incapable of changing or mutating your source workload and is explicitly denied from reading or exfiltrating any data."
Seen in¶
- sources/2026-03-31-aws-streamlining-access-to-dr-capabilities — canonical wiki reference. Names the clean-room framing explicitly; frames cross-account copy as "a critical security measure to enable recovery from malware and ransomware"; the composite cross-Region-cross-account axis as the default Arpio recovery topology.
- sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events — extends the clean-room recovery account to a three-account cyber-recovery topology (Production / Recovery / IRE). The Recovery Account = the clean-room recovery account; the IRE adds a third account as the rebuild + validation surface separate from vault governance. The three-account split provides further blast-radius reduction over the original two-account design.
The cyber-resilience extension: three accounts, not two¶
The 2026-05-20 cyber-resilience post adds a third account — the Isolated Recovery Environment (IRE) — to the original two-account clean-room design:
| Account | Role | Why separate |
|---|---|---|
| Production | Where workloads run | Source of compromise; isolated for investigation on confirmed event |
| Recovery (the clean-room recovery account) | Vault governance: owns logically air-gapped vault, MPA configuration, SCP-restricted to backup operations | Vault must survive even if other accounts are compromised |
| Isolated Recovery Environment (IRE) | Execution surface: restores backups, runs validation pipeline, rebuilds infrastructure | Tainted restore stays contained; cannot reach Production or vault |
Why three, not two: if Recovery Account doubled as the rebuild account, a tainted restore could in principle delete or modify the vault. Separating governance (Recovery) from execution (IRE) prevents that — the IRE can be compromised by a tainted restore without losing the vault. See patterns/three-account-cyber-recovery-topology for the full pattern.
Related¶
- concepts/disaster-recovery-tiers — the DR ladder this isolation axis composes with.
- concepts/blast-radius — the containment principle.
- concepts/account-per-tenant-isolation — sibling use of the AWS account boundary as structural isolation.
- concepts/cyber-resilience — the parent posture for the three-account topology extension.
- concepts/isolated-recovery-environment — the IRE = the third account in the cyber-resilience extension.
- systems/aws-backup — the cross-account copy primitive.
- systems/aws-backup-logically-air-gapped-vault — the cyber- resilience-specific storage primitive in the Recovery Account.
- systems/aws-iam, systems/aws-organizations — the cross- account access machinery.
- patterns/three-account-cyber-recovery-topology — the cyber- resilience extension's canonical pattern.