Skip to content

CONCEPT Cited by 1 source

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

Last updated · 200 distilled / 1,178 read