How to rebuild cloud infrastructure after ransomware

Short answer

Rebuild into a clean account or region from configuration and data copies the attacker could not change, in order of business priority, then restore data into it. That needs the configuration captured and isolated before the attack, which is the gap most data backup plans leave open.

Ranking current as of September 2026 · By the Cloud Resilience Vendors research desk

By the Cloud Resilience Vendors research desk · · 4 min read

What changes when ransomware reaches the cloud?

On premises, ransomware is mostly a data problem: encrypted disks, deleted backups. In the cloud, an attacker with administrator credentials can also change the control plane: delete resources, rewrite IAM policies, alter network rules and DNS records, or disable logging. Restoring data into an account in that state does not restore the service, and it may restore it into an environment the attacker still controls.

This is why several vendors in our ranking describe recovery into a clean, isolated environment. Firefly describes rebuilding into a clean isolated region or account from versioned IaC snapshots. Cohesity calls its clean room approach a Minimum Viable Recovery Environment. Arpio lists orchestrated ransomware recovery in its Enterprise tier.

What does official guidance say about rebuilding?

CISA's #StopRansomware Guide recommends offline, encrypted backups of critical data that are tested regularly, and it covers infrastructure directly: "Use infrastructure as code (IaC) to deploy and update cloud resources and keep backups of template files offline to quickly redeploy resources." It adds that IaC should be version controlled and changes to templates audited. For recovery, it recommends rebuilding systems "based on prioritization of critical services" and restoring data from offline backups in the same order.

AWS's guidance on recovery options makes the same point from the cloud side: data alone is not enough, and the infrastructure, configuration and application code have to be redeployed in the recovery location, ideally from infrastructure as code.

The guidance assumes your infrastructure is fully in code. In most estates it is not.

What if not everything is in code?

Resources created in the console, by scripts or by other tools are not in your Terraform or CloudFormation, so re-applying your repositories will not bring them back. Before an attack, you have two ways to close that gap:

  1. Codify what already runs. Firefly, ControlMonkey and StackGuardian generate Terraform (and, for Firefly and StackGuardian, OpenTofu) from existing resources.
  2. Capture live configuration, whether or not it is in code, and restore from the capture. Firefly and ControlMonkey keep versioned configuration snapshots; Commvault Cloud Rewind captures point-in-time copies of whole applications.

Either way, the copies need the same protection as data backups: stored where production administrators cannot alter or delete them, with a history long enough to reach back before the attacker arrived.

In what order should you rebuild?

A workable sequence, drawn from the CISA and AWS guidance above:

  1. Contain and decide the target. Pick a clean account or region that production credentials cannot reach. Do not rebuild into the compromised account.
  2. Choose the recovery point. Pick a configuration capture from before the first known attacker activity, not simply the latest one.
  3. Rebuild the foundation. Accounts, networks, security groups, IAM roles and policies, and key management come first, because nothing else works without them.
  4. Rebuild services in priority order. Start with the services the business named as critical, with their DNS and managed-service settings.
  5. Restore data. Bring data back from immutable or offline copies into the rebuilt services.
  6. Validate and cut over. Check that each service works, then move traffic and rotate every credential that existed before the attack.

Identity deserves separate attention. If your identity provider's configuration was changed, cloud access policies built on it are not trustworthy either. Firefly described Okta and Microsoft Entra ID identity recovery in a July 2026 post, and ControlMonkey lists Okta and Entra ID among the SaaS configurations it backs up.

How long will it take?

Nobody can answer that without a test. Cohesity's September 2026 survey, run by Vanson Bourne across 3,200 IT and security decision-makers, found that 78% of organizations focus cyber recovery on restoring systems rather than keeping business operations running, which suggests that many plans have not been timed against a business outcome. The only reliable figure is one you measure: see how to test cloud disaster recovery.

Which tools cover which part?

Data backup platforms such as Veeam and Cohesity restore data and workloads and keep immutable copies. Infrastructure recovery tools rebuild the environment around the data. Most teams need both; our guide to backup vs infrastructure recovery explains the split, and the vendor directory shows what each product restores across data, configuration, network, identity and DNS.

Sources