Most organisations running applications or workloads on AWS or Azure assume resilience is built in by design. Distributed regions and availability zones protect you against hardware failure and localised outages. They do nothing to protect you against a compromised cloud account, and that is the threat that ransomware presents. While high availability solves for infrastructure failures, it cannot cover an event where an attacker holds valid credentials inside your environment.
Ransomware now targets your ability to recover
Ransomware has evolved from simply encrypting data to removing all options of recovering it. Backups, recovery vaults, identity systems and privileged accounts are all primary targets, because taking them out is what forces the payment.
The Codefinger attacks are a clear example. Attackers used legitimate AWS keys with read and write access to S3 to re-encrypt objects with their own keys via server-side encryption. Recovery then depended entirely on a key the attacker held. This incident involved no malware as the credentials were already accessed.
Credential theft can be the start of an attack. Attackers can map out the environment and identify the recovery systems first without being discovered. By the time the ransomware is visible, the recovery environment has often already been compromised. As the number of ransomware attacks continues to grow, this is a scenario every organisation must now be prepared to face.
The ability to recover that you need to show regulators, customers, shareholders and the board is precisely what an attacker sets out to destroy. Unless your recovery environment is genuinely isolated, air-gapped and fed by one-way replication, your ability to recover is foundationally weakened.
Immutable data still has limitations
Immutable storage stops data being altered or deleted.
An attacker who cannot touch your immutable data can still stop you recovering it. If they can disable replication, change retention policies, delete recovery workflows, revoke access, corrupt automation or destroy your runbooks, the data survives and the recovery does not. Intact backups are no use if the machinery to restore them has been dismantled.
The recovery environment needs to be separated from production
Historically an air gap meant physical separation. There was no wire between the protected copy and the live environment. In the cloud, the traditional physical separation has to be replaced by trust separation, which involves independent control domains on separate infrastructure, with no path back.
The recovery environment has to operate independently of production, so that anything happening inside the production blast radius, including a fully compromised account, cannot reach it.
Let’s take the example of a customer-facing investment platform running on AWS. Separation and isolation engineered for ransomware recovery could look like this:
| Separation control | How it protects recovery |
| Separate AWS organisation | The recovery copy lives in a destination organisation that is fully isolated from production. Even with complete control of the source organisation, an attacker cannot reach or alter data held in the air-gapped vault. |
| Separate AWS accounts | Data is replicated from production into isolated vault accounts using native cross-account replication, snapshot sharing and independent recovery keys. The recovery copies are owned by the destination account, so they stay protected even if the source account is fully compromised. |
| Separate IAM identities | Identity is separated through dedicated accounts, distinct IAM roles, separate credentials, MFA-protected access and organisation-level service control policies. The vault has no IAM trust relationship with production, so compromised production identities give no route in. |
| Separate MFA and break-glass | All human access to the recovery environment uses independent credentials and mandatory MFA. Break-glass procedures and multi-party approval add a further barrier around the most privileged access. |
| Separate KMS encryption keys | The vault encrypts data with its own customer-managed KMS keys that the source account cannot access. Compromised production credentials, IAM permissions or source keys therefore give no access to the protected copy. |
| No trust path back to production | The vault has no IAM trust, no reverse network connectivity and no API path from production. Replication is strictly one-way. A compromise in production cannot be used to read, change or delete the recovery data. |
| Independent governance and monitoring | A dedicated AWS organisation with 24/7 management, oversight, security and logging, ensuring complete independence. |
Technical separation is not enough without operational separation
The common failure is this: the recovery environment is run by the same people, using the same credentials, under the same change processes as production. The moment a single compromised identity can reach both, the air gap is gone. An attacker only has to compromise one control plane if the same access controls and security tooling govern both sides.
True isolation is therefore operational as well as technical. Independent ownership and a separate governance model are what keep the architecture honest over time.
Recovery environments need to be tested continuously
Recovering a business operation is challenging, and an annual test will not provide adequate assurance, particularly given the pace at which the threat landscape is evolving. Always-on reviews include:
- Replication health that is validated on a regular schedule
- Recovery documentation that is kept current as the technology environment changes
- Infrastructure changes that are captured in the recovery plan
- Application dependencies, recorded continuously to avoid reconstructing them under pressure
Many organisations still experience recovery times running far longer than expected during a live ransomware incident due to inadequate testing of the recovery environment and plan.
Recoverability must be proven through continuous, documented validation. If you are not doing that, you cannot count on your recovery working as intended.
Air Gap Recover: Isolation as a Managed Service
When building Air Gap Recover, Databarracks used the cloud building blocks to design and operate an air-gapped service that is governed and continuously tested.
Air Gap Recover places an immutable, fully isolated copy of every production workload in a separate AWS organisation and region, so your data remains recoverable even if every credential and system in your source account is compromised. It is built on AWS-native services, managed through governance-as-code, and uses intelligent storage tiering to keep long-term retention affordable.
Air Gap Recover provides:
- Continuous monitoring, confirming the protection and isolation controls remain operational rather than assuming they do
- Independent governance, with oversight of recovery controls and security boundaries held separately from your production estate
- Routine recovery testing, validating real recoverability against agreed RPO and RTO targets
- Compliance reporting, providing evidence that controls remain effective and auditable for FCA, PCI DSS, ISO 27001 and NIST 800-53 requirements
- Recovery expertise, giving you access to specialists who have managed real recovery events, not just configured backups
- Incident support, with hands-on guidance when you are executing a real recovery
The only question that matters
Organisations that come through a serious cyber incident tend to have the same things in common: immutable data, a genuinely independent recovery environment, continuous testing, operational governance and managed recovery expertise working together. No single one of these is sufficient on its own.
Strip everything else away and one question remains: can we recover? If you cannot answer that with evidence, you are relying on an assumption.