Designing a cross-region and cross-account cloud recovery target

Which recovery target fits which incident?

1. Same account, same region. Fits an accidental deletion or a bad change, where the surrounding environment is healthy and trusted.
2. Same account, another region. Fits a regional outage. The account and its credentials are still trusted.
3. Another account or subscription. Fits a compromise. If an attacker holds credentials in the production account, rebuilding inside it restores their access too. A clean account, with credentials the attacker never had, is the safer target.
4. An isolated recovery environment. A clean target cut off from production, used to investigate before anything returns to service. Cohesity calls its version a Minimum Viable Recovery Environment.

What must exist in the target before an incident?

• Capacity and quotas. AWS's guidance on testing recovery tells teams to check service quotas in the recovery region, because a rebuild that hits a quota stops halfway.
• Images. The same guidance says to check that the machine images you need are available in the recovery region.
• Identity. A clean account needs its own roles and access paths for the recovery team, set up and tested in advance.
• A matching configuration. Keep the target free of drift against production, as the lesson on configuration drift explains.

What do vendors state about recovery targets?

Firefly documents cross-region and cross-account rebuild, including into a clean, isolated region or account after ransomware. Arpio states cross-account and cross-region failover on AWS and cross-subscription orchestration on Azure. Commvault Cloud Rewind restores to the production VPC or to isolated recovery environments, without detailing cross-account steps on its product page. Cohesity states cross-region recovery and an isolated recovery environment in AWS. Veeam Backup for Google Cloud states recovery across regions and projects. ControlMonkey lists secondary region replication in its Pro tier. The cross-region and cross-account rebuild criterion on each vendor profile scores these statements.

How do you test a target without touching production?

Recover one application into the target, route test traffic to it, and tear it down. Arpio publishes failover testing that does not disrupt production. Whatever the tool, time each step and keep the record; the briefing on testing cloud disaster recovery lists what to capture.

What should you take from this lesson?

Decide the target per incident type before you choose the tool, then ask each vendor to show a recovery into exactly that target during the trial.