Skip to content

AWS Updated 2026-07-04

AWS backup management: do your backups exist, work, and restore fast enough?

AWS backup management is three separate questions: does everything that matters have a backup, do the jobs actually succeed, and can you restore inside the window the business assumes? Here is how to answer all three.

Managing backups on AWS is three separate questions, and most teams can only answer the first one. Does everything that matters have a backup? Do the backup jobs actually succeed, every night, without anyone having to remember to look? And can you restore — a real restore, timed — inside the window the business quietly assumes you can? A backup plan that was configured once in 2023 answers none of these. Backup management is the ongoing work of answering them continuously.

What you are deciding

The real decision is whether backup is a checkbox or an operated system. AWS gives you the parts: AWS Backup for centralized plans and vaults, RDS automated backups with point-in-time recovery, EBS snapshots, S3 versioning. Configuring any of them takes an afternoon. What the parts do not give you is coverage guarantees over time. New resources get created without the tag that assigns them to a plan. A job starts failing because a KMS key policy changed, and the failure email goes to a distribution list nobody reads. Retention gets left at a default that either deletes recovery points you needed or accumulates storage cost forever.

The other half of the decision is recovery objectives. RPO — how much data you can afford to lose — decides backup frequency. RTO — how long you can be down — decides whether snapshot-based restore is even viable, because restoring a large volume or database from a snapshot is not instant. If nobody has written down an RPO and RTO per system, the backup schedule is guessing.

What to check first

  • Coverage against inventory. List what should be backed up (production databases, EBS volumes, EFS, DynamoDB tables) and compare it to what is actually in a backup plan. The gap is usually resources created after the plan was set up.
  • Failed and expired jobs, last 30 days. One failed job is noise; the same resource failing nightly for three weeks is an unprotected system.
  • Where failure notifications go. An SNS topic with no live subscribers means failures are silent.
  • The date of the last restore test. Not the last backup — the last time someone restored something and timed it.
  • Where recovery points live. If every recovery point sits in the same account and region as the workload, one compromised set of credentials or one regional event takes both.

How to verify

Pull the job history and coverage from the CLI:

# Backup jobs that failed recently
aws backup list-backup-jobs --by-state FAILED --max-results 50

# What AWS Backup believes it is protecting
aws backup list-protected-resources --max-results 100

# Recovery points actually sitting in the vault
aws backup list-recovery-points-by-backup-vault \
  --backup-vault-name Default --max-results 20

In the console, AWS Backup > Jobs > Backup jobs filtered to Failed shows the same thing with the failure reason. Then compare protected resources against what exists:

# Everything tagged as production data (adjust tags to your convention)
aws resourcegroupstaggingapi get-resources \
  --resource-type-filters "rds:db" "ec2:volume" "dynamodb:table" \
  --tag-filters Key=env,Values=prod

The most telling command is the restore history:

aws backup list-restore-jobs --max-results 20

If that returns nothing for the last quarter, nobody has tested a restore, and the backups are hope, not recovery.

The runbook

  1. Write the inventory first. List every system whose loss would hurt, with an RPO and RTO per system agreed with whoever owns the business impact. Everything else follows from this document.
  2. Assign by tag, not by hand. Use tag-based resource assignment in the backup plan so new resources are covered the day they are created, provided the provisioning process applies the tag. Enforce the tag at provisioning time, not by quarterly cleanup.
  3. Alarm on job failures. A CloudWatch alarm on NumberOfBackupJobsFailed per vault, routed somewhere a human sees within a day. Failure handling is the difference between backup management and backup configuration.
  4. Copy out of the blast radius. Cross-account and cross-region vault copies protect against credential compromise and regional events. The mechanics — and the restore test that proves the copy works — are in AWS Backup with cross-region and cross-account copy.
  5. Run a timed restore quarterly. Restore one real system to a scratch environment, time it end to end, and compare against the written RTO. The first drill almost always finds a surprise: a missing KMS grant, a security group that does not exist in the target account, an RTO that was fiction.
  6. Set retention deliberately. Recovery-point storage is the main cost driver, and cross-region copies add transfer cost. Warm backup storage costs more than cold; AWS Backup can transition eligible recovery points to cold storage after a minimum warm period. Retention should come from the inventory document, not from the console default.

When this is the wrong move

If your entire data layer is one RDS instance, a full AWS Backup rollout may be more machinery than you need — RDS automated backups with a tested PITR and snapshot strategy covers the database, and you only need AWS Backup when EBS, EFS, or DynamoDB join the picture. If your RPO is minutes rather than hours, no snapshot schedule will get you there — that is replication territory (Multi-AZ, cross-region read replicas), with backups as the second line. And in a multi-account organization, per-account backup plans drift; delegate administration and manage plans centrally instead.

Common mistakes

  • Treating a green job as a tested restore. A completed backup job proves the snapshot was written, not that it restores into something usable.
  • Tag drift. The plan covers env=prod, someone provisions with Environment=Production, and the new database is unprotected for months.
  • Vault in the blast radius. Recovery points in the same account as the workload disappear with the workload if credentials are compromised.
  • Retention by default. Either recovery points expire before the finance team asks for a year-old restore, or storage cost compounds quietly forever.

Keeping it under control

  • Review failed jobs weekly; treat a resource failing repeatedly as an incident, not a log line.
  • Run one timed restore per quarter and record the duration next to the written RTO.
  • Enforce the backup tag in your provisioning path (IaC module defaults, or an SCP/Config rule that flags untagged data stores).
  • Use vault lock or cross-account copy for anything ransomware would target.
  • Re-read the RPO/RTO inventory yearly — systems change importance.

Backups fail quietly and restores fail loudly, and the gap between the two is where businesses get hurt. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.