Securing backup data against modern threats with AWS Backup

Enterprises face an evolving spectrum of threats to their backup data. From ransomware attacks that encrypt production systems and target recovery points, to accidental deletions by well-meaning administrators, to full account compromises that put every resource at risk, organizations can no longer assume that traditional backup approaches will keep their data recoverable. When backup infrastructure shares authentication boundaries, encryption keys, or geographic footprint with the systems it protects, a single incident can eliminate both primary data and the recovery points meant to restore it.

AWS Backup has evolved to address these challenges with advanced security features that create multiple layers of protection. Capabilities including Vault Lock, logically air-gapped vaults, and Multi-party approval workflows work together to keep critical data accessible even during the most severe incidents.

In this post, we examine the modern threat landscape through three categories: non-malicious operational threats, malicious events, and infrastructure and availability threats, and demonstrate how specific AWS Backup features provide targeted protection for each. Whether you need rapid same-account recovery from an accidental deletion or verified clean restore points after a ransomware incident, this framework helps you match the right protection mechanism to your specific risks.

Responding to non-malicious threats

Operational errors remain among the most common causes of data loss. Consider an enterprise running production workloads across multiple AWS accounts with hundreds of automated pipelines managing resource lifecycles. In this environment, a single misconfigured policy or an accidental API call can destroy critical recovery points. These threats come from within your own organization, without malicious intent, but can be equally destructive if backup data is not properly protected.

Accidental resource and backup deletion

Threat: Your application owners or infrastructure automation tools may accidentally delete primary resources, or in some cases, your backup data itself. A misconfigured cleanup script, a mistyped CLI command, or an overly aggressive lifecycle policy can destroy your critical recovery points.

Mitigation: For your primary resources, the backup itself is your protection while having a recoverable copy ensures you can restore after accidental deletion. To protect your backup data from accidental changes, configure your AWS Identity and Access Management (IAM) roles and service control policies (SCPs) to restrict who can modify or delete your backups. Your backup data can only be deleted through AWS Backup APIs, so when primary resources are accidentally deleted, your recovery points remain available for rapid restoration. You should also establish clear separation between application ownership and data protection responsibilities. Your application owners manage the lifecycle of primary resources, while your data protection team controls backup lifecycles through dedicated backup vaults and vault access policies.

For stronger protection against accidental deletion of backup data itself, AWS Backup Vault Lock enforces a Write-Once, Read-Many (WORM) model. In Governance mode, users with sufficient IAM privileges can manage or remove the lock when needed. In Compliance mode, the vault becomes permanently immutable. No user, including the root account, can delete recovery points or modify the lifecycle policy. No single human action, whether accidental or the result of a misconfigured automation, can permanently destroy your backup data.

To provide consistent coverage, AWS Backup tag-based resource selection automatically enrolls new resources into backup plans at creation, avoiding gaps in protection that arise when resources are provisioned but not yet manually added to a backup plan.

Key material expiration and misconfiguration

Threat: Your AWS Key Management Service (KMS) keys protecting backup data can be accidentally scheduled for deletion, have their key policies misconfigured, or expire without renewal, rendering your recovery points permanently inaccessible even when vaults, policies, and credentials remain intact.

Mitigation: Configure logically air-gapped vaults to address this risk directly. When you use AWS-owned encryption keys (the default), these vaults eliminate your dependency on customer-managed KMS keys entirely, ensuring that key deletion or policy changes in your source account cannot render your backup data unrecoverable. If you require customer-managed keys, two additional strategies reduce your risk: first, maintain your KMS keys in a dedicated key vault account with strict access controls and minimal administrative principals, isolating key management from your production operations; second, implement regular key rotation policies to limit your window of exposure if a key is compromised or inadvertently scheduled for deletion.

Regional unavailability

Threat: A regional outage affects your primary operations and any backup infrastructure you have co-located in the same AWS Region.

Mitigation: Adopt a multi-Region disaster recovery strategy. AWS Backup cross-Region copy capabilities automatically replicate your recovery points to a separate AWS Region as part of your scheduled backup plans. Select your geographic resilience approach based on your recovery requirements and budget:

• Cross-Region primary resource replication delivers the fastest recovery and simplest failover during regional incidents
• Cross-Region backup copying provides a cost-effective alternative if you cannot implement full replication, ensuring recovery points exist in an unaffected Region

If you require the strongest geographic resilience against both regional outages and malicious events, logically air-gapped vaults with cross-Region copies provide isolation from both the geographic and identity boundaries of the primary environment.

Malicious threats

Malicious threats require stronger isolation because an attacker actively works to circumvent your protections. Unlike operational errors, these scenarios assume an adversary who has already gained access to your environment and is actively attempting to destroy or exfiltrate data, including targeting your backup infrastructure. AWS Backup addresses these through escalating levels of isolation, matched to the attacker’s privilege level.

Ransomware and malware events

Threat: Ransomware encrypts your production data and increasingly targets your backup infrastructure to prevent recovery. Sophisticated variants search for and destroy your backup files, snapshots, and recovery points before triggering encryption of your production systems.

Mitigation: To protect against ransomware, configure logically air-gapped vaults. These vaults are isolated from your source account’s IAM principals, meaning malware operating within your AWS environment, even with elevated privileges, cannot discover, access, or delete your vault contents. Because logically air-gapped vaults are implicitly locked, your recovery points cannot be deleted or modified regardless of what credentials the malware has obtained.

AWS Backup also supports backing up directly to a logically air-gapped vault, providing flexibility for you to choose direct or a two-step copy process based on recovery point objectives and cost considerations. Combined with cross-Region copy capabilities, this ensures recovery points exist outside both the identity boundary and geographic footprint of the attack.

Logically air-gapped vaults inherently provide account-level isolation without requiring a separate copy operation. Because these vaults have no IAM path from the source account, your production account credentials cannot reach vault contents. To further harden your environment, restrict the vault-owning account to minimal IAM principals and apply strict SCPs that prevent any modification or deletion of vault contents.

Credential compromise: application owner level

Threat: If your application owners’ credentials are compromised, an attacker can use them to intentionally delete resources, replicas, and snapshots within their scope of access.

Mitigation: You should separate application ownership from data protection responsibilities so that compromised application credentials cannot impact your backup retention or accessibility. Apply Service Control Policies (SCPs) at the AWS Organizations level to prevent application owners from calling backup APIs that modify lifecycle policies, shorten retention periods, or alter vault configurations. An attacker with application-level credentials could attempt to reduce recovery point expiry rather than explicitly deleting backups, making retention protection equally important. SCPs should cover both deletion and lifecycle modification to close this gap.

Recovery points copied to a separate backup account add a further layer of defense. Even if application-account credentials are fully compromised, those copies remain out of reach. Vault Lock ensures that even if an attacker reaches the backup vault with valid credentials, recovery points cannot be deleted or their retention shortened.

Credential compromise: backup administrator level

Threat: If your backup administrator’s credentials are compromised, or if a malicious insider holds that role, they can use their elevated privileges to modify backup plans, alter lifecycle and retention policies, or exfiltrate sensitive data by copying it outside your organization. Note that this scenario assumes the attacker has backup-specific permissions but not root or account-level administrative access. The key distinction from full account compromise below is that your IAM boundaries and SCPs still function as expected.

Mitigation: Start by placing your backups in logically air-gapped vaults to make your data immutable. Logically air-gapped vaults have Compliance mode Vault Lock enabled by default. Once the grace period expires, no one, including you or the root account, can remove or alter the lock. Your recovery points cannot be deleted until their retention periods expire, regardless of the credentials used. This immutability protects you even against a compromised backup administrator. To ensure these backups remain available, enable Multi-party approval (MPA), which allows you to recover data even if the owning account of a logically air-gapped vault is compromised by requiring approval from multiple independent parties before critical operations can proceed.

For data exfiltration scenarios, AWS Backup does not allow copies of backups outside of your organization by default. The vault access policy can be used to further restrict where data can be copied. You should combine vault access policies with Vault Lock and separation of duties. Note that your backup administrator can change the vault access policy, so you should combine this with Vault Lock and separation of duties to prevent policy tampering.

Full account compromise

Threat: Your account administrator or root credentials are completely compromised, giving an attacker unrestricted access to every resource in your account including backup vaults. Unlike backup administrator compromise above, this scenario means all your IAM boundaries, SCPs, and organizational controls within the account are ineffective. The attacker can bypass any in-account protection mechanism.

Mitigation: Your logically air-gapped vaults provide the critical isolation boundary for ensuring data restorability. These vaults have no IAM path from your source account, so compromised account credentials, including root, cannot delete your vault contents. It is important to understand that the attacker can still own and operate within the compromised account, performing any other actions to disrupt your environment. The purpose of the logically air-gapped vault is not to prevent all attacker activity, but to guarantee that your backup data remains recoverable when you are locked out of your primary environment. Multi-party approval (MPA) is the critical control for this scenario. MPA requires independent authorization from a quorum of pre-defined approvers before recovery operations can proceed, ensuring no single compromised identity can prevent your data recovery. You can share logically air-gapped vaults across accounts and outside your AWS Organization, enabling recovery from a clean account with no dependency on the compromised environment.

To guarantee that vault contents remain accessible for recovery, logically air-gapped vaults should be combined with Multi-party approval. For AWS Backup, Multi-party approval enables you to create a recovery path that uses a quorum of pre-defined approvers, authenticated through an independent identity path (such as AWS IAM Identity Center), to federate authorization for sharing vault contents to a recovery account. Once authorized, this sharing cannot be revoked from the source account. Even if an attacker has root access to the compromised account, they cannot bypass the approval team or revoke access that has already been granted to the recovery organization.

For step-by-step configuration guidance, see Implementing Multi-party approval workflows for AWS Backup logically air-gapped vaults.

Identity provider compromise

Threat: Your organization’s identity provider (IdP) is compromised, or a critical mass of your administrators collude, potentially blocking legitimate access to your recovery infrastructure during an active incident.

Mitigation: Enable Multi-party approval to establish a separate authentication path for your recovery authorization. Your approvers authenticate through a distinct identity provider from the one you use for day-to-day operations. This means a compromised primary IdP cannot be used to authorize, or block, vault sharing for your recovery.

Combined with a logically air-gapped vault in a recovery organization outside your primary failure domain, this creates a complete recovery path: the vault data is isolated (inaccessible from the compromised environment), and the authorization to share it for recovery operates through an independent identity boundary. The result is a clean place to recover to, with a guaranteed mechanism to access your backup data.

Validating your recovery capability

Restore testing validates the integrity of your recovery chain, the third pillar alongside immutability and isolation. While immutability ensures your data cannot be deleted or modified, and isolation protects it from compromised environments, integrity confirms that protected recovery points are genuinely recoverable and capable of returning your applications to a functional state when you need them. AWS Backup restore testing enables you to validate that recovery points are genuinely recoverable and capable of returning your applications to a functional state. You should run restore tests on a regular schedule, treating them with the same rigor as disaster recovery drills. Specific use cases for restore testing include: validating cross-account restore from a logically air-gapped vault (including the vault sharing and Multi-party approval workflow) to confirm the full recovery path works before an actual incident; testing restore of encrypted resources to verify KMS key accessibility and proper decryption across account boundaries; confirming application-level integrity after restore, ensuring databases are consistent and applications start correctly from recovery points; and verifying that compliance-mode locked vaults with long retention periods still produce usable restores as underlying service APIs evolve.

Regular restore testing validates the entire recovery chain: that backup jobs complete successfully, that recovery points are not corrupted, and that restored resources function as expected. This is particularly important for logically air-gapped vaults, where the recovery process involves vault sharing and cross-account restoration steps that should be practiced before an actual incident. By testing your recovery procedures proactively, you confirm that your protection strategy delivers actual recoverability, not just theoretical coverage.

Conclusion

Modern data protection requires matching your defense mechanisms to specific threats. Non-malicious threats like accidental deletion are addressed through Vault Lock and role separation. Malicious threats require escalating isolation: from SCPs and cross-account copies for credential compromise, to logically air-gapped vaults for full account compromise, to Multi-party approval for guaranteeing accessibility when your primary identity boundary is breached.

The key architectural principle is defense in depth with independent boundaries: logically air-gapped vaults ensure your backup data cannot be reached from a compromised environment, and Multi-party approval ensures you can always access that data for recovery through an independent authorization path. Together, they provide a complete cyber recovery capability that operates independently of any single point of compromise.

To implement this pattern, start by enabling Vault Lock on your existing backup vaults to protect against accidental and unauthorized deletion. Then evaluate logically air-gapped vaults for your most critical workloads where account-level isolation is required. For organizations with the highest recovery assurance requirements, add Multi-party approval to guarantee accessibility independent of any single identity boundary.

For detailed implementation guidance, see the AWS Backup documentation and Improve recovery resilience with AWS Backup support for Multi-party approval.