Service spotlight: AWS Backup replaces per-service snapshot scripts

Every AWS account I’ve inherited that predates AWS Backup has the same shape: a Lambda that snapshots EBS volumes on a cron, a separate RDS automated backup window nobody’s checked in years, and DynamoDB point-in-time recovery toggled on for some tables and not others, with no single place to see whether any of it is actually working. AWS Backup exists to replace that patchwork with one policy.

What it actually is

AWS Backup is a managed service that centralizes backup scheduling, retention, and recovery across most stateful AWS resource types — EBS, RDS/Aurora, DynamoDB, EFS, FSx, Storage Gateway volumes, and EC2 instances as a whole (not just their volumes) — under one backup plan. A plan defines a schedule (cron expression), a retention period, and a lifecycle that can transition backups to cold storage and eventually expire them, then you assign resources to the plan by tag or by explicit resource ID. Everything the plan touches shows up in one backup vault with a consistent job history, so “did last night’s backup actually succeed” is one console view instead of checking five different services’ own backup mechanisms.

Where it earns its keep

• One policy instead of five. Tag every resource that needs a daily backup with backup: daily, assign that tag to a plan, and every new EBS volume or RDS instance with that tag is covered automatically going forward — no per-resource setup step anyone can forget.
• Cross-service consistency. Retention and lifecycle rules are defined once in the plan, not reimplemented per service with each service’s own quirks (RDS automated backups cap at 35 days retention on their own; AWS Backup’s retention isn’t bound by that).
• Backup vault lock. A vault can be locked into compliance mode, which makes backups genuinely immutable and undeletable — including by the account root user — for the configured retention period. That’s the feature that actually matters for ransomware resilience: an attacker with full account access still can’t delete backups a compliance-locked vault is holding.
• Cross-account and cross-region copy. A plan can copy backups to a separate backup account and a separate region in the same job, which is the AWS-native way to satisfy “backups must survive the loss of the source account” without building custom replication.

What it still leaves you to configure

AWS Backup schedules and retains backups; it doesn’t validate that a restore actually works. Restore testing is a separate feature (Restore Testing plans) that you have to opt into explicitly and point at real resources — untested backups are a common source of “we had backups but the restore didn’t work” incidents, and AWS Backup existing doesn’t change that unless you actually run the restore tests.

It also doesn’t replace application-consistent backup logic for databases that need it. RDS/Aurora snapshots through AWS Backup use the same underlying mechanism as native RDS snapshots (so they’re crash-consistent, and for most engines that’s sufficient), but if you’re backing up something like a self-managed database on EC2 that needs quiesce-before-snapshot logic, AWS Backup’s EC2/EBS support won’t give you that for free — you still need your own pre-snapshot hooks.

The pricing model

Costs are backup storage (billed per GB-month, warm vs cold tier priced differently) plus, for some resource types, restore costs. The lifecycle transition to cold storage (available for EBS, RDS, DynamoDB, and a few others) meaningfully cuts long-retention costs, but cold-tier backups typically have a minimum retention period before transition and can carry early-deletion or restore-time costs, so a plan built for “retain 7 years, transition to cold at 90 days” needs those constraints modeled, not just the headline GB-month price.

A practical tip

Turn on AWS Backup Audit Manager (a separate but related feature) once you have plans running — it continuously evaluates whether resources are actually covered by a backup plan matching your organization’s policy and flags drift, which catches the “someone launched a new RDS instance without the required tag” gap that a plan alone won’t.