Why Does AWS Backup Cost More Than the Data It Protects?

Nobody provisions a backup. You provision a volume, a database, a file system — the backup is a side effect, something AWS or a policy takes on your behalf without asking you to size it, price it, or ever look at it again. Then a year passes, the volume gets deleted, the database gets torn down, the migration finishes — and the backup does not get the memo. It is still there, still billing, for a resource that no longer exists anywhere in your account. Multiply that by every EBS volume and RDS instance your team has ever retired, and "backup" quietly becomes one of the least examined line items on the bill.

Why does a backup bill keep growing after the thing it protects is gone?

Three separate things go by "backup" on an AWS bill, and each is billed on its own terms:

• EBS snapshots — point-in-time copies of a volume's blocks, billed per GB-month for as long as they exist, independent of whether the source volume still does.
• RDS manual snapshots — full backups of a database instance, billed per GB-month, with no expiry field and no link to the instance's lifecycle once it is deleted.
• AWS Backup — the managed service that wraps both of the above (plus DynamoDB, EFS, and more) in a policy: a backup plan, a vault to hold recovery points, and rules for how long each copy lives.

The common thread is that none of the three treat "the source resource is gone" as a reason to stop billing. A snapshot or recovery point is a standalone object the moment it is created — it has its own storage footprint, its own retention (or lack of one), and its own bill, and it keeps all three long after the volume or instance it came from has been deleted.

What does backup and snapshot storage actually cost per GB?

At standard us-east-1 rates:

Two things stand out. RDS backup storage costs almost double EBS snapshot storage per GB — $0.095 against $0.05 — because an RDS manual snapshot is a full copy of the instance's allocated storage rather than an incremental chain that shares blocks the way EBS snapshots do. And AWS Backup's own per-resource rates are not uniform — the console shows the exact figure for each service you protect, and it is worth checking per resource type rather than assuming EBS's rate applies to a DynamoDB or RDS backup plan too.

Why doesn't deleting the resource stop the meter?

Because the free allowance and the retention policy both belong to the instance, not to the backup.

RDS gives every database instance free backup storage up to 100% of its own provisioned size — a 200 GB database gets 200 GB-month of automated-backup-and-snapshot storage at no charge. That allowance is real, and it is why RDS backup storage looks free for as long as the instance is running. Delete the instance, and the allowance disappears with it. Automated backups are deleted along with the instance that owned them, but manual snapshots are not — they persist, and from the moment the instance is gone, every gigabyte of them bills at $0.095/GB-month with no free tier behind it anymore. A pile of manual snapshots that cost nothing while the database was alive becomes a real line item the moment it is torn down.

EBS snapshots never had a free allowance to begin with, so there is no cliff — just an object with no expiry that bills at the standard rate for as long as it exists. A snapshot taken before a migration in 2023, of a volume deleted the same week, has been billing every month since, and nothing in the console will ever flag it as stale.

How do I find the backups and snapshots nobody is watching?

Start with EBS. This lists every snapshot you own; cross-reference VolumeId against your live volumes to find ones whose source is gone:

aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[].[SnapshotId,VolumeId,VolumeSize,StartTime,Description]' \
  --output table

Then RDS. List manual snapshots, then list live instances, and anything in the first set with no match in the second is an orphan:

aws rds describe-db-snapshots --snapshot-type manual \
  --query 'DBSnapshots[].[DBSnapshotIdentifier,DBInstanceIdentifier,AllocatedStorage,SnapshotCreateTime,Status]' \
  --output table

aws rds describe-db-instances \
  --query 'DBInstances[].DBInstanceIdentifier' --output text

If you run AWS Backup, the vault view tells a different story — not orphaned resources, but what a backup plan has been quietly accumulating:

aws backup list-recovery-points-by-backup-vault --backup-vault-name Default \
  --query 'RecoveryPoints[].[RecoveryPointArn,ResourceType,BackupSizeInBytes,Status]' \
  --output table

A vault holding years of daily recovery points for a resource that was deleted last quarter is the AWS Backup version of the same problem, one layer up.

How do I fix this manually?

Once you have confirmed a snapshot is genuinely dead, delete the whole chain rather than sampling it — EBS snapshots share blocks within a chain, so removing one from the middle frees almost nothing. For RDS, delete-db-snapshot removes it outright; there is no cheaper tier to move it to instead.

Where retention is real but restores are unlikely, move the data rather than deleting it. EBS Snapshot Archive cuts the rate by 75% (to $0.0125/GB-month) in exchange for a restore that takes up to 72 hours and a 90-day minimum commitment — a good trade for a compliance archive, a bad one for anything you might need mid-incident. RDS has no equivalent archive tier, so the closer option is exporting the snapshot to S3, which writes the database contents as Parquet into a bucket under your own lifecycle rules, still queryable through Athena, at a fraction of $0.095/GB-month — the trade is that the export is no longer a restorable database.

Going forward, put a Data Lifecycle Manager policy on EBS volumes so their snapshots age out on a schedule, and tag every manual RDS snapshot with an owner and a review date at the moment it is taken — RDS gives snapshots no expiry of their own, so a tag is the only thing that makes the decision cheap six months later.

What else should I check while you are in here?

Backup pricing is one slice of a bigger picture for each service. If EBS is where most of your orphaned snapshots live, how EBS pricing actually works breaks down the other two meters — provisioned capacity and performance — that usually dwarf the snapshot line once gp2 volumes and idle IOPS are added in. If RDS is the bigger pile, how RDS pricing works, and where it leaks covers the same free-allowance mechanic for the live side of a database, plus the Multi-AZ multiplier that doubles two of its four meters.

More broadly, backups outliving their resource is one instance of a pattern that shows up everywhere AWS lets you create something without an obvious way to see everything you have created — everything else an AWS account usually leaks money on works through the account in order of savings per minute, and orphaned storage of every kind tends to sit near the top.

How do I keep this from building back up?

Checking one account for orphaned snapshots and stale backup vaults is half an hour. Doing it every month, across every region, for every EBS volume and RDS instance your team retires — and catching the ones that turn into full-priced storage the moment their source is deleted — is the part that stops happening after the first pass. That is what a scan is for. Parsivex checks each region for orphaned EBS snapshots and RDS manual snapshots with no live source, and then keeps watching, so the backup created after your cleanup does not quietly start the same annuity over again.

For what these findings mean once they appear in your report, see Orphaned RDS manual snapshot and Orphaned EBS snapshot.