Work / Backup protection
Backup protection, August 2025
Backups that survive a compromised administrator
A security audit for a financial technology company found that 12 IAM users could delete its RDS snapshots and S3 backups. We added AWS Backup Vault Lock, a separate backup account and a weekly restore test.
The situation
During a security audit for a financial technology company we found that 12 IAM users could delete the RDS snapshots and the S3 backups. One stolen credential, or one employee with a grievance, could delete every copy of the data.
No Vault Lock
Any identity with administrator permissions, including automated scripts, could delete a backup vault.
Backups in the production account
The backups were in the same AWS account as production. A compromised account meant compromised backups.
Restores never tested
The company had kept backups for 3 years and had never restored one. There was no evidence that a restore would work.
Manual snapshots
Developers started database backups by hand. Weeks sometimes passed without a backup.
Step 1: Backup Vault Lock in compliance mode
AWS Backup Vault Lock in compliance mode prevents deletion of a backup until its retention period ends. Once the lock is active, not even the root user of the account can remove it. AWS Backup now takes a backup of the production database every day and writes it to the locked vault.
Production database RDS PostgreSQL
AWS Backup backup plan, every day
Locked vault write once, read many
What the lock changes
An attacker with root access cannot delete a backup. The attacker can only wait for the retention period to end. That gives the client at least 30 days to detect and respond.
Step 2: a separate backup account
Vault Lock prevents deletion, but an attacker who controls the whole account can still cause damage. We created a separate AWS account for backup storage. Backups are copied to it every 4 hours.
RDS PostgreSQL, primary
S3 application data
DynamoDB tables
Local vault Vault Lock
Isolation
Credentials from the production account cannot reach the backup account. If production is fully compromised, the backups remain intact.
Step 3: a restore test every week
A backup that has never been restored is not evidence that the data can be recovered. An automated pipeline restores the latest backup every week and checks it.
Select
A Lambda function selects the most recent RDS snapshot in the backup vault.
Restore
The snapshot is restored to a test RDS instance in an isolated subnet with no route to production.
Validate
Queries check row counts, the schema version, referential integrity and sample records.
Measure
The pipeline records the recovery time from snapshot to a database that answers queries.
Report
Results go to Slack and email. The test instance is deleted and the figures are logged.
What the client receives every week
The figures
| Measure | Before | After |
|---|---|---|
| IAM users who can delete a backup | 12 | 0 |
| Maximum data loss, recovery point objective | unknown | 4 h |
| Recovery time, recovery time objective | never measured | 23 min |
| Restores tested | 0 in 3 years | 1 per week |
What the client's chief technology officer said
"We recognize that data risks come from both external threats and internal factors, whether it is an accidental deletion by a team member or a departing employee. With AWS Vault Lock, our backups are now immutable. No one can delete them, not even administrators. That level of protection gives us complete confidence in our disaster recovery strategy."
What the client received
Locked daily backups
A daily AWS Backup plan with Vault Lock in compliance mode, 30 days minimum and 365 days maximum retention.
Separate backup account
Its own credentials, MFA-only access and a copy every 4 hours.
Weekly restore test
Reports the recovery time and the integrity checks to Slack and email.
Audit evidence
A log of every test as evidence for SOC 2 and ISO 27001 audits.
Backups that an administrator cannot delete
We review your backup configuration first and list every identity that can delete a backup. Then we apply Vault Lock, a separate backup account and a restore test, and hand over the code and the runbook.
Talk to an engineer