Skip to content

CONCEPT Cited by 1 source

Isolated Recovery Environment (IRE)

Definition

An Isolated Recovery Environment (IRE) is a dedicated AWS account (or analogous cloud isolation boundary) used as the rebuild and validation surface for cyber-event recovery. It has:

  • No trust relationship to the Production Account.
  • No VPC peering to the production network.
  • No internet-facing resources.
  • VPC endpoints (PrivateLink) only for AWS service API access — no internet, no peering to production.
  • Access governed by SCPs ( Service Control Policies) at the AWS Organizations level to enforce the isolation properties structurally.

Verbatim from the canonicalising source:

"[The IRE is] where backups are restored, validated, and the new production environment is rebuilt before cutover. The IRE is kept separate from the Production Account so that if a restored backup still contains the threat, it has nowhere to spread. It has no trust relationship to the Production Account, no VPC peering to it, and no internet-facing resources, so a tainted restore discovered during validation stays contained inside the IRE instead of reaching back into production or out to the internet. Infrastructure deployment in the IRE uses VPC endpoints (AWS PrivateLink) to reach AWS service APIs without internet connectivity or VPC peering to production." (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

Why the IRE is structurally distinct from the Recovery Account

The Recovery Account and the IRE serve different functions and are deliberately separate accounts:

Account Owns Receives
Recovery Account Logically air-gapped vault, MPA configuration, SCPs restricting to backup operations Backups (push from Production via AWS Backup cross-account copy)
IRE Rebuild infrastructure, validation pipeline, IaC-driven recreation of production Validated recovery points (shared via AWS RAM from the Recovery Account vault)

The IRE is the execution surface; the Recovery Account is the governance surface. Splitting them ensures that even a compromised identity in the IRE (e.g. a malicious payload exfiltrated from a restored volume) cannot reach the vault to delete or modify backups — the Recovery Account's SCPs prevent it.

The containment property: "tainted restore stays contained"

The load-bearing IRE property is that a restored backup that turns out to still contain the threat has nowhere to spread:

  • Cannot reach back to production (no trust, no peering).
  • Cannot reach the internet (no internet gateway, no NAT gateway).
  • Cannot exfiltrate to attacker-controlled infrastructure (no egress paths beyond the AWS service API endpoints reachable via PrivateLink).

This is what makes the validation pipeline safe to run inside the IRE — even if a malware scanner misses something and the workload- specific check catches it later, the malware has been running only inside an environment that cannot be used as a launch point for further attack.

Pre-configured, not built at incident time

The canonicalising source's checklist explicitly says "Establish an Isolated Recovery Environment in advance, with no trust relationship to production and no network path into the production environment. Pre-configure the networking, monitoring, and access controls required for recovery operations."

This is consequential — at incident time, building a new account from scratch (with the correct SCPs, VPC endpoints, monitoring, and identity setup) takes hours to days. Pre-configured IREs reduce that to minutes.

The third account in the cyber-recovery topology

The IRE is the third account in the cyber-recovery topology described by the canonicalising source's Figure 1:

  1. Production Accounts — workloads run; isolated for investigation when a cyber event is confirmed.
  2. Recovery Account — owns the vault and governance.
  3. IRE — rebuild + validate before cutover.

All three live inside one AWS Organization (so consolidated billing and centralised SCP governance still apply), but with disjoint trust boundaries.

Composition with concepts/clean-room-recovery-account

The IRE composes with the Recovery Account to form the cyber-recovery topology. The Recovery Account is the wiki's existing clean-room recovery account canonicalised in the 2026-03-31 streamlining-DR post; the IRE is the execution counterpart that the 2026-05-20 cyber-resilience post adds:

  • Clean-room recovery account = governance + storage isolation.
  • IRE = execution + validation isolation.
  • Together = full cyber-recovery topology.

Generalisation beyond AWS

The IRE pattern generalises to any cloud or on-prem environment with account/tenant/network-segment isolation primitives:

  • GCP — separate GCP project with no IAM bindings to the production project; VPC Service Controls perimeter.
  • Azure — separate subscription with no RBAC role assignments from the production tenancy; private endpoints.
  • On-prem — separate VLAN / domain forest; no trust relationships; air-gapped or one-way replication.

The structural property is the same: an execution environment that can validate restores without itself becoming a launch point for attack against production or external infrastructure.

Seen in

Last updated · 542 distilled / 1,571 read