Backup and ransomware protection
AWS Backup plans and org backup policies, Vault Lock modes, logically air-gapped vaults, cross-account and cross-Region copies, Data Lifecycle Manager, secure transfer with DataSync, integrity checks and restore testing.
Exam tasks: 5.2.2 (integrity: code signing, file validation), 5.2.3 (retention: FSx for Lustre and other backups), 5.2.4 (secure replication and backup: DLM, AWS Backup, ransomware protection, DataSync)
The decision: if an attacker gets administrator access to a production account (or the whole account is closed), which copy of your data survives, who can restore it, and how do you know the copy is intact?
A ransomware-resistant layout
- Backups that live in the same account as production can be deleted by whoever compromises that account. Copy them to an account the workload administrators can't touch.
- Lock the destination vault so even that account's administrators can't shorten retention.
- Guard the backup account with SCPs that deny
backup:DeleteBackupVault,backup:DeleteRecoveryPoint,backup:PutBackupVaultLockConfigurationchanges andkms:ScheduleKeyDeletionon backup keys, except for a break-glass role.
AWS Backup building blocks
| Piece | What it does |
|---|---|
| Backup plan | Rules with a schedule, backup window, lifecycle (warm to cold storage), retention and copy actions to another Region or account |
| Resource assignment | Selects resources by tag, ARN or type, so new resources tagged backup=gold are covered automatically |
| Backup vault | Container for recovery points, with its own KMS key and an access policy (for example, deny DeleteRecoveryPoint to everyone) |
| Organization backup policy | Defined in the management account or a delegated administrator, attached to OUs; deploys plans to every member account and stops local admins editing them |
| Backup Audit Manager | Frameworks of controls ("resources are in a plan", "backups are copied cross-Region", "vault is locked") with reports |
| Legal hold | Keeps selected recovery points past their retention until the hold is released |
Encryption of backups
- For resource types fully managed by AWS Backup (for example EFS, DynamoDB with advanced features, S3), the recovery point is encrypted with the vault's KMS key.
- For other types (EBS snapshots, RDS snapshots), the backup keeps the source resource's key. That's why an
RDS database encrypted with
aws/rdscan't be copied to another account: its key can't be shared. Use a customer managed key on the source. - Cross-account copies need the destination vault's key policy and the source key policy to allow the other account, and both accounts must be in the same organization.
Vault Lock and air-gapped vaults
| Vault Lock governance | Vault Lock compliance | Logically air-gapped vault | |
|---|---|---|---|
| Who can remove the lock | IAM principals with permission | Nobody after the grace time, not even AWS | Nobody; compliance lock is built in |
| Grace time | None | At least 72 hours | Not applicable |
| Retention bounds | Optional min and max | Optional min (1 day or more) and max | Required: min 7 days or more, and a max |
| Encryption | Vault key | Vault key | AWS owned key by default, or a customer managed key |
| Restore from another account | Copy back first | Copy back first | Yes, share with AWS RAM or recover through multi-party approval |
| Use for | Guardrails while you tune retention | WORM retention for regulators (SEC 17a-4, FINRA) | Fast recovery when the owning account is compromised or closed |
- Backups in a locked vault can't be deleted early by anyone, including the root user.
- Once a compliance lock passes its grace time, the vault can be deleted only when it's empty, so check retention values carefully; a mistake keeps costing money until the recovery points expire.
- Multi-party approval lets a team of approvers authorise restoring from a logically air-gapped vault into another account even when the owning account is inaccessible.
Exam signal
"Protect backups from a compromised administrator" means cross-account copies to a vault with Vault Lock in compliance mode. "Restore quickly into a new account without copying first, even if the source account is gone" means a logically air-gapped vault shared through RAM or unlocked through multi-party approval.
Two different vault locks
AWS Backup Vault Lock protects recovery points in backup vaults. Glacier Vault Lock was a policy lock on the original Glacier vault service, which no longer takes new customers. S3 Object Lock protects object versions in buckets. Match the lock to the storage the question describes.
Amazon Data Lifecycle Manager
- Automates creation, retention (by count or age), cross-Region copy and cross-account sharing of EBS snapshots and EBS-backed AMIs, at no extra charge. Also supports fast snapshot restore and moving snapshots to the archive tier.
- Default policies give every instance or volume in a Region a baseline snapshot schedule without tagging.
- Cross-account copy event policies in a target account automatically copy snapshots shared with it, re-encrypted with the target account's key.
- DLM only manages snapshots it created. For more than EC2 and EBS, central reporting, Vault Lock or org-wide policies, use AWS Backup.
| Need | DLM | AWS Backup |
|---|---|---|
| EBS snapshot and AMI schedules only | Yes | Yes |
| RDS, DynamoDB, EFS, FSx, S3 and more | No | Yes |
| Immutable (locked) retention | No | Yes |
| Organization-wide policies and audit reports | No | Yes |
| Application-consistent pre and post scripts on EC2 | Yes, through SSM documents | Yes (VSS for Windows) |
Retention on file and storage services
- FSx for Lustre backs up only persistent file systems not linked to S3. Automatic daily backups keep 0–90 days (0 turns them off, and it's the default); user-initiated backups never expire. Use AWS Backup for longer retention, hourly schedules and cross-Region copies.
- EFS automatic backups through AWS Backup are on by default for new file systems created in the console.
- RDS automated backups keep up to 35 days; for longer or immutable retention, use AWS Backup.
Secure replication and transfer
- S3 Replication (same- or cross-Region): versioning on both buckets; for SSE-KMS objects, opt in and grant the replication role Decrypt on the source key and Encrypt on the destination key. Use owner override so the destination account owns replicas, and consider not replicating delete markers so a malicious delete in the source doesn't propagate.
- AWS DataSync encrypts in transit with TLS, and can run through an interface VPC endpoint so transfers from on-premises stay on your Direct Connect or VPN. It writes with the destination's default encryption.
- DataSync verifies checksums during every transfer. Choose Verify only transferred data (recommended), Verify all data, or no final check.
Proving integrity
| Need | Control |
|---|---|
| CloudTrail logs weren't altered or deleted | Log file integrity validation: hourly signed digest files with SHA-256 hashes; validate with aws cloudtrail validate-logs |
| Objects weren't corrupted on upload or copy | S3 checksums (CRC64NVME by default, or SHA-256 you supply), checked on upload and stored with the object |
| Transfer copied data faithfully | DataSync verification modes |
| Lambda runs only code your team signed | AWS Signer signing profile plus a Lambda code signing configuration set to Enforce |
| Container images weren't tampered with | Sign images with AWS Signer (Notation) and verify at deploy time |
| Backups can actually be restored | Restore testing in AWS Backup: scheduled restores of selected recovery points, optional validation with Lambda, automatic clean-up |
Scenarios
Cross-account copies put backups outside the compromised account, and a compliance-mode lock stops even that account's administrators from deleting them. MFA helps but doesn't protect against an attacker who already has admin access. More frequent DLM snapshots in the same account can be deleted the same way. Another Region in the same account shares the same administrators.
RDS recovery points keep the source key, and an AWS managed key can't be shared, so the database needs a customer managed key. EFS works because fully managed resources use the vault's key. The aws/rds policy can't be edited, changing the destination vault key doesn't affect RDS snapshots, and the DynamoDB setting is unrelated.
Restore testing proves restorability automatically and records results. A manual runbook works but isn't least effort. Audit Manager proves backups exist, not that they restore. CloudTrail validation proves logs weren't altered, which is unrelated to restores.
Further reading
Storage encryption
Encryption at rest for EBS, snapshots and AMIs, RDS and Aurora, DynamoDB and the AWS Database Encryption SDK, EFS and FSx, and what happens to each when its KMS key is disabled or deleted.
Secrets management
Secrets Manager versus Parameter Store SecureString, rotation with Lambda and managed rotation, single-user and alternating-user strategies, cross-account secrets, caching, and keeping secrets out of code, user data and environment variables.