**What If an Attacker Deletes Your Backups? Building Ransomware-Resistant Recovery on AWS**
Discover how to protect critical backups from ransomware and unauthorized deletion using AWS Backup, Vault Lock, IAM least-privilege policies, and encryption. Through a real-world scenario and hands-on implementation, this article demonstrates how to secure recovery points, test deletion protection, and verify data restoration to build a more resilient AWS environment.
What If an Attacker Deletes Your Backups? Building Ransomware-Resistant Recovery on AWS
1. Introduction
Imagine that you are managing the cloud infrastructure of an online shopping company. Your application stores customer information, order histories, and transaction records in AWS. To protect this data, your team regularly creates backups.
One morning, the company discovers that its application has been compromised by ransomware. The production data is encrypted, and the attacker has attempted to delete the available backups using compromised cloud credentials.
Suddenly, the organization faces two problems: its production systems are unavailable, and its recovery strategy may no longer be reliable.
This scenario highlights an important cloud security principle: a backup is not a reliable recovery option unless it is protected, accessible when needed, and regularly tested.
In this article, we will build a practical backup-protection solution using AWS Backup. We will configure a backup vault, apply access controls and encryption, explore AWS Backup Vault Lock, simulate an attempted deletion in a test environment, and verify that protected data can be restored.
The objective is to create multiple layers of protection rather than depend on a single security feature.
2. Understanding the Security Problem
AWS provides several mechanisms for creating and managing backups. However, backup security also depends on how permissions, retention policies, encryption keys, and recovery procedures are configured.
Consider the following risks:
- Compromised credentials: An attacker who obtains sufficiently privileged AWS credentials may attempt to delete backups.
- Excessive permissions: A single administrator role may have permission to modify production resources and delete their backups.
- Insufficient retention: Backups may expire before the organization discovers a security incident.
- Encryption key problems: A backup may exist but remain inaccessible if the required encryption key is unavailable or incorrectly configured.
- Untested recovery: A backup job may complete successfully, but the restored application may fail because of missing configuration or dependencies.
A robust solution should address these risks independently.
For example, encryption helps protect confidentiality, while access controls restrict who can perform sensitive actions. Vault Lock provides additional protection against premature deletion, and restore testing verifies recoverability.
No single control replaces the others.
3. Proposed Architecture
The solution uses AWS Backup as the central backup service and a dedicated backup vault to hold recovery points.
Architecture components
- Protected workload: An Amazon EC2 instance or another AWS resource containing sample application data.
- AWS Backup plan: Defines when backups are created and how long they are retained.
- Backup vault: Stores recovery points created by AWS Backup.
- AWS KMS: Provides encryption key management where the selected resource and backup configuration support it.
- AWS Backup Vault Lock: Helps prevent protected recovery points from being deleted before their retention period ends.
- IAM: Restricts which identities can create, manage, delete, or restore backups.
- AWS CloudTrail: Records supported API activity for investigation and auditing.
- Restore testing: Confirms that the protected data can be recovered.
Workflow
A protected resource is backed up according to a defined schedule. AWS Backup stores the recovery point in the selected vault. Access controls restrict sensitive operations, while Vault Lock adds retention protection. If an incident occurs, an authorized recovery operator can select an appropriate recovery point and restore the resource.
The architecture should also be designed so that compromising an ordinary application role does not automatically grant control over the backup environment.
4. Step One: Prepare a Safe AWS Test Environment
Before configuring security controls, prepare a dedicated lab.
You will need:
- An AWS account with permission to configure the required services.
- A supported AWS resource to protect, such as a test EC2 instance.
- AWS Backup access in a supported AWS Region.
- A sample file or application dataset that can be safely restored.
- An IAM identity with only the permissions required for the lab.
For this demonstration, create a harmless file containing test data. Do not use real customer information, production databases, or confidential business records.
Record the original file contents and the resource configuration. These will become your reference for verifying the restoration.
Important: AWS services can incur charges for backup storage, protected resources, encryption keys, and restore operations. Check the current pricing for your selected resources and Region before starting.
5. Step Two: Create a Dedicated Backup Vault
A backup vault is a logical container used by AWS Backup to organize and protect recovery points.
Follow these steps:
- Sign in to the AWS Management Console.
- Open the AWS Backup console.
- Navigate to the backup vaults section.
- Choose the option to create a backup vault.
- Give the vault a descriptive name, such as
RansomwareProtectedVault.
- Select the appropriate encryption key configuration supported by your intended backup workflow.
- Apply tags to identify the environment and its purpose.
- Create the vault.
For a production environment, consider separating backup administration from the identities used to operate the application.
A dedicated vault makes it easier to apply consistent retention policies and control access to recovery points.
However, creating a separate vault does not, by itself, make the backups immutable. Additional controls are required.
6. Step Three: Configure a Backup Plan
A backup plan defines when backups are created and how their lifecycle is managed.
In the AWS Backup console:
- Open the backup plans section.
- Create a new backup plan.
- Provide a descriptive name, such as
CriticalWorkloadBackupPlan.
- Add a backup rule with an appropriate schedule.
- Set the required retention period based on the recovery and business requirements.
- Select
RansomwareProtectedVaultas the destination vault.
- Assign the test resource to the backup plan.
- Save the configuration.
For a lab, you can use a daily backup schedule and a short, carefully chosen retention period. Select values that fit the service's supported options and your budget.
In a real organization, the schedule should reflect the recovery point objective (RPO): the maximum amount of data the business can afford to lose, measured in time.
For example, if a business can tolerate no more than 24 hours of data loss, its backup strategy must provide suitable recovery points at a frequency that supports that requirement.
After configuring the plan, run or wait for a backup job to complete. Open the backup jobs section and verify that the job succeeded.
Then inspect the backup vault and confirm that the expected recovery point exists.
A successful backup job is the first checkpoint, not the final proof of recoverability.
7. Step Four: Apply AWS Backup Vault Lock
This is the central security control in our demonstration.
AWS Backup Vault Lock helps protect recovery points against accidental or malicious deletion before their retention period ends. It supports two modes: Governance mode and Compliance mode.
Governance mode
Governance mode allows users with sufficient IAM permissions to remove or modify the lock configuration.
It is useful when an organization wants stronger administrative controls but still needs authorized administrators to manage the vault.
Compliance mode
Compliance mode provides stronger immutability guarantees after its configured grace period expires.
Once the grace period has ended, the lock configuration cannot be changed or removed, and protected recovery points cannot be deleted before their applicable lifecycle retention periods end.
This protection also applies against attempts by highly privileged users, including the account root user, to delete protected recovery points through the supported AWS Backup operations.
However, Compliance mode has serious operational implications. It is not an ordinary setting that can simply be switched off when circumstances change.
Configure the lock carefully
For this lab:
- Open AWS Backup and navigate to the vault lock configuration.
- Select the dedicated test vault.
- Review the available lock modes.
- Start with Governance mode if you need to learn the configuration and removal behavior.
- Define suitable minimum and maximum retention limits where appropriate.
- Verify that the backup plan's retention settings comply with the chosen limits.
- Save the configuration and confirm that the lock is active.
If you later want to demonstrate Compliance mode, first review the irreversible implications and test the complete configuration in a disposable environment. Compliance mode requires a grace period of at least 72 hours. During that period, the configuration can still be changed or removed. After the period expires, the lock becomes immutable.
Do not enable a permanent Compliance mode lock on a production vault simply to follow an article.
Before enabling it, verify the retention requirements, lifecycle settings, recovery procedures, expected storage costs, and organizational approval.
Why this matters: Vault Lock adds protection against premature deletion, but it does not guarantee that every component of the production environment is protected. Source resources, encryption keys, permissions, and the ability to restore data must also be secured.
8. Step Five: Apply Least-Privilege Access Controls
Next, separate backup operations from normal application administration.
Imagine that the application role can read and write application data. That role should not automatically have permission to delete recovery points, modify vault locks, or change the backup retention policy.
Use IAM policies and roles to separate responsibilities.
A practical design might include:
- Application role: Accesses only the application resources it needs.
- Backup operations role: Performs approved backup and monitoring tasks.
- Recovery role: Can perform authorized restoration operations.
- Security administration role: Manages sensitive backup security settings under a controlled approval process.
Use the AWS-managed policies and service-specific permissions as a starting point, then narrow permissions to the required resources and actions.
Avoid granting broad permissions such as unrestricted administrative access when a smaller permission set will work.
Also consider permissions that can affect encryption keys. If a recovery point depends on a KMS key, restricting backup deletion alone is insufficient if an attacker can disable or otherwise make that key unavailable.
For a multi-account architecture, consider keeping backup copies in a dedicated backup account with carefully controlled cross-account access. This adds separation from the account that runs the production workload, although it still requires appropriate permissions, encryption configuration, and organizational safeguards.
9. Step Six: Protect Backup Encryption Keys
Encryption helps prevent unauthorized parties from reading backup data, but encryption must be designed with recovery in mind.
AWS Backup supports encryption configurations that depend on the protected resource type and backup workflow. Where supported, a customer managed AWS KMS key can provide additional control over key policies and administrative access.
For this lab:
- Review the encryption configuration of the backup vault and protected resource.
- Identify the key used to protect the backup.
- Verify which IAM identities can use or administer that key.
- Restrict key administration to authorized identities.
- Confirm that the intended recovery role can access the key when performing a legitimate restore.
- Document the key dependencies in the recovery procedure.
Do not remove or disable an encryption key as an attack simulation. That could make your own test backups inaccessible.
Instead, inspect the permissions and demonstrate that an unauthorized identity lacks the required key-management permissions.
For cross-account recovery, verify the relevant KMS key policies and permissions in both accounts before relying on the design.
The key lesson is that encryption protects the data, while proper key management helps ensure that authorized recovery remains possible.
10. Step Seven: Simulate an Attempted Backup Deletion
Now we can test the security controls.
Use only the dedicated lab environment and a recovery point that you are prepared to test.
First, verify that the backup job succeeded and that the recovery point is present in the vault.
Next, use a separate test identity with limited permissions to attempt an operation it should not be allowed to perform.
For example, you can test whether the identity is prevented from deleting a protected recovery point or changing the vault's security configuration.
Record the following:
- The identity used for the test.
- The operation attempted.
- The response returned by AWS.
- Whether the recovery point remains available.
- Any relevant CloudTrail event or error information.
If you are testing Governance mode, remember that users with sufficient IAM permissions can remove the lock. Do not interpret Governance mode as immutable protection against every privileged administrator.
If you are testing Compliance mode after the grace period has expired, the lock provides stronger protection against deletion before the recovery point's retention period ends.
Do not attempt to bypass the controls, delete production backups, or use destructive scripts against a live environment.
The objective is to demonstrate that the intended security policy is enforced, not to endanger the data.
11. Step Eight: Verify That the Backup Can Be Restored
Preventing deletion is only one part of a reliable recovery strategy.
A backup that cannot be restored does not provide the recovery capability the business expects.
For this step, use a supported resource and follow the appropriate restore workflow.
- Open the AWS Backup console.
- Locate the recovery point created during the lab.
- Select the restore operation.
- Review the required restore parameters.
- Restore into a safe test environment.
- Wait for the restore job to finish.
- Inspect the restored resource and its data.
- Compare the restored file or dataset with the original reference.
- Record the recovery job's status and duration.
For the sample file, verify that the restored content matches the original test data.
For an application workload, you may also need to verify network access, application configuration, dependencies, and application-level consistency.
AWS Backup also provides restore testing capabilities that can schedule and evaluate restore jobs for supported resource types. This can help organizations assess whether their recovery procedures work consistently and how long restores take.
Do not claim a successful recovery simply because a restore job was initiated. Verify its final status and the restored data.
12. Step Nine: Monitor and Audit Backup Activity
A resilient backup design should make important changes visible.
AWS CloudTrail records supported AWS API activity, allowing security teams to investigate actions involving backup resources and related services.
Use CloudTrail alongside suitable alerts and monitoring to identify suspicious activity, such as unexpected changes to backup configurations or repeated attempts to perform unauthorized operations.
For a more advanced design, you can use Amazon EventBridge to route relevant supported events to an alerting workflow, such as Amazon SNS.
Consider monitoring:
- Failed backup jobs.
- Unexpected changes to backup plans.
- Attempts to modify sensitive vault configurations.
- Unusual backup deletion activity.
- Failed restore operations.
- Changes to relevant IAM roles or encryption keys.
Event availability depends on the service and event type, so verify the specific event patterns before building automated alerts.
Keep audit logs in a location with appropriate access controls and retention. For stronger separation, consider centralized logging in a dedicated account.
Monitoring is not a substitute for prevention, but it helps a security team investigate incidents and respond before they become larger problems.
13. Step Ten: Review the Results
After completing the lab, summarize what happened and provide evidence.
Use a results table such as the following in your article. Fill in the status and timing columns only after you have actually run the tests.
Test | Expected result | Actual result |
|---|---|---|
Backup job | Backup completes successfully | Record observed result |
Recovery point check | Recovery point exists in the vault | Record observed result |
Unauthorized deletion attempt | Request is denied where the configured controls require it | Record observed result |
Vault Lock verification | Lock configuration matches the intended mode | Record observed result |
Restore test | Test resource and data are recovered correctly | Record observed result |
Audit verification | Relevant activity can be investigated in available logs | Record observed result |
This table provides a clear distinction between the expected behavior and the evidence gathered during testing.
Include genuine screenshots of the backup job, vault configuration, deletion-test response, restore job, and restored sample data. Remove account IDs, resource identifiers, sensitive details, and other information that should not be publicly exposed.
14. Production Considerations and Limitations
Before applying this design to a real organization, consider several operational requirements.
Retention and cost: Locked recovery points remain stored until their applicable retention periods end. Incorrect settings can create unexpected or long-lasting storage costs.
Recovery objectives: Backup frequency and retention should support the organization's recovery point objective and recovery time objective (RTO), which defines how quickly the service must be restored.
Account separation: A dedicated backup account and cross-account copies can improve resilience against compromise of a production account. Their permissions and encryption dependencies must be tested.
Encryption dependencies: A protected backup can still become difficult to restore if its required encryption key is unavailable.
Compliance mode: After its grace period expires, a Compliance mode lock cannot be removed or modified. Confirm all retention and operational requirements before enabling it.
Restore validation: Restoration should be tested regularly, not only when an incident occurs. Successful backup jobs alone do not establish that the entire application can be recovered.
Service limitations: Supported features, resource types, Regions, and configuration options vary. Verify the current AWS documentation for your selected workload before implementing the design.
15. Conclusion
Ransomware resilience requires more than creating periodic copies of production data. Organizations must also prevent unauthorized deletion, restrict access to backup administration, protect encryption keys, monitor suspicious activity, and verify recovery procedures.
AWS Backup provides building blocks for this approach. Backup plans establish a repeatable schedule, backup vaults organize recovery points, Vault Lock adds protection against premature deletion, IAM controls restrict sensitive actions, and restore testing provides evidence that recovery can work.
The most important lesson from this lab is simple: do not measure backup security only by the existence of backups. Measure it by whether the organization can protect those backups and successfully recover when its production environment is compromised.
A tested and carefully controlled recovery strategy can help reduce the impact of ransomware and improve confidence in an organization's ability to resume operations.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article