Locking Down Production RDS Backups with AWS Backup Vault Lock

#Operational requirement

You are going to get handed a ticket that reads something like: “harden backups

AWS Backup Vault Lock makes recovery points immutable, and in compliance mode it makes them deletion-proof against every principal in the account, including root. Combine it with cross-region copy and you also satisfy the availability requirement: a regional outage, or an attacker who only has access to one region, cannot destroy your only copy of production data. This is a realistic task for a newly hired administrator responsible for RDS resilience. It is also unforgiving. Get the lock mode wrong and there is no undo button.

Do not point this procedure at production on your first attempt. Build it against a throwaway vault first.

#Prerequisites and required permissions

You need an existing production RDS instance, a change management process that will genuinely approve an irreversible action, and the following permissions attached to your working role, ideally through a scoped permission set rather than administrator access: backup:CreateBackupVault, backup:CreateBackupPlan, backup:CreateBackupSelection, backup:StartBackupJob, backup:PutBackupVaultLockConfiguration, backup:DeleteBackupVaultLockConfiguration, kms:CreateKey, kms:CreateGrant, and iam:PassRole scoped to the AWS Backup service role.

You also need a second AWS region already reachable from the account, with no Organizations SCP blocking it, MFA enforced on the identity performing the lock operation, and a Change Advisory Board reference number written into the ticket before you start. Vault Lock in compliance mode is one of the few AWS actions where “we’ll fix it later” simply does not exist as an option. The approval trail matters more here than on almost any other change you will make this year.

#Step 1: Create backup vaults with dedicated KMS keys in both regions

Create a customer-managed KMS key per region rather than accepting the AWS managed backup key. You need explicit key policy control later for the cross-region copy step.

1aws kms create-key --region us-east-1 --description "prod-rds-backup-primary"
2aws backup create-backup-vault 
3  --backup-vault-name prod-rds-vault 
4  --encryption-key-arn arn:aws:kms:us-east-1:111122223333:key/PRIMARY-KEY-ID 
5  --region us-east-1
6
7aws kms create-key --region us-west-2 --description "prod-rds-backup-secondary"
8aws backup create-backup-vault 
9  --backup-vault-name prod-rds-vault-dr 
10  --encryption-key-arn arn:aws:kms:us-west-2:111122223333:key/SECONDARY-KEY-ID 
11  --region us-west-2

Attach resources by tag, not by explicit ARN, so future RDS instances inherit protection automatically without a second change ticket:

1aws backup create-backup-selection 
2  --backup-plan-id <plan-id-from-previous-output> 
3  --backup-selection '{"SelectionName":"prod-rds-tagged","IamRoleArn":"arn:aws:iam::111122223333:role/AWSBackupDefaultServiceRole","ListOfTags":[{"ConditionType":"STRINGEQUALS","ConditionKey":"backup:tier","ConditionValue":"production-rds"}]}' 
4  --region us-east-1

Expect a SelectionId returned with no error. Record the plan ID and selection ID in the ticket. Tag the RDS instance with backup:tier=production-rds before moving on, and give it at least fifteen minutes before the next evaluation window. Miss that window and the first job silently skips the resource, with no error surfaced anywhere.

#Step 3: Validate the service role and run a manual backup job

Confirm the AWS Backup service role carries both managed policies, not just one:

aws iam list-attached-role-policies --role-name AWSBackupDefaultServiceRole

You need AWSBackupServiceRolePolicyForBackup for the backup jobs themselves and AWSBackupServiceRolePolicyForRestores for the restore test in Step 4. Force a manual run instead of waiting on the cron schedule:

1aws backup start-backup-job 
2  --backup-vault-name prod-rds-vault 
3  --resource-arn arn:aws:rds:us-east-1:111122223333:db:prod-orders-db 
4  --iam-role-arn arn:aws:iam::111122223333:role/AWSBackupDefaultServiceRole 
5  --region us-east-1

Run the command, then poll aws backup describe-backup-job --backup-job-id <id> until State reads COMPLETED. Separately confirm a matching copy job with aws backup list-copy-jobs --by-state COMPLETED --region us-east-1, showing a DestinationRecoveryPointArn in us-west-2. If the copy job sits in RUNNING past the completion window, or fails on an access-denied condition, stop. Fix the destination KMS key policy before you go anywhere near Vault Lock.

#Step 4: Apply Vault Lock, governance mode first

Vault Lock uses a single configuration call. During the grace period you set with --changeable-for-days, it behaves like governance mode and an authorised principal can still remove it. Once that grace period elapses, the lock converts automatically and permanently into compliance mode. There is no warning prompt for this transition.

1aws backup put-backup-vault-lock-configuration 
2  --backup-vault-name prod-rds-vault 
3  --min-retention-days 35 
4  --max-retention-days 100 
5  --changeable-for-days 3 
6  --region us-east-1

Expect no error, and a locked configuration block in the next describe-backup-vault call. Capture the full describe output with a timestamp and the calendar date the grace period expires, and put both in the ticket. Do not extend the grace period past your CAB-approved test window. If restore testing is not finished before the grace period ends, delete and reapply the lock rather than letting it convert unreviewed.

#Verification

Before closing the change ticket, run all of the following and attach the outputs:

1aws backup describe-backup-vault --backup-vault-name prod-rds-vault --region us-east-1
2aws backup list-backup-jobs --by-resource-arn arn:aws:rds:us-east-1:111122223333:db:prod-orders-db
3aws backup list-copy-jobs --by-state COMPLETED --region us-east-1

Then perform an actual restore into an isolated non-production VPC. Never into the production subnet. Record the restored instance identifier and the restoration duration. This is the real completion check. If you cannot produce a working restored database from a locked recovery point, the control does not meet the requirement yet, no matter what the console shows.

#Common Traps

#Rollback

If you are still inside the grace period, rollback is straightforward:

1aws backup delete-backup-vault-lock-configuration 
2  --backup-vault-name prod-rds-vault 
3  --region us-east-1

Confirm with describe-backup-vault that the lock configuration block is gone. To remove the cross-region copy action without touching the lock, edit the plan JSON

If the grace period has already expired and the vault has converted to compliance mode, say so plainly to your manager rather than trying to work around it quietly. There is no API rollback at that point. Recovery points can only be deleted once each one individually passes its MinRetentionDays. The remaining avenue is an AWS Support exception request, which is not guaranteed and is reserved for extraordinary documented circumstances, not routine engineering mistakes. This is exactly why the grace period exists, and exactly why you test in governance mode against a disposable vault before ever pointing this procedure at production.

#Operational Summary

The deliverable for this task is a locked, cross-region-replicated backup vault protecting a named production RDS instance, backed by documented evidence: the vault ARNs and encryption key ARNs, the backup plan and selection IDs, at least one completed backup job and one completed cross-region copy job, the lock configuration output with its grace period expiry date, and a successful restore into an isolated non-production environment with a recorded duration. File all of it against the CAB ticket number before you close the change.

Vault Lock is one of the few controls in AWS where the safe default is deliberate slowness. Test in governance mode first. Prove the restore actually works. Get sign-off from your change board. Only then let the grace period run out into compliance mode. Treat the irreversibility as the feature it is meant to be, not as a risk you talked yourself into, and only after you have personally verified the restore path end to end.