backupcost-optimizationawsplaybook

Snapshot and backup cleanup: cutting the line that only grows

Backups are the one cost line with no natural ceiling: a daily schedule with no expiry runs forever. Here is how to audit snapshot spend, set retention that satisfies compliance, and cut 50 to 80 percent without losing recoverability.

The C3X Team··8 min read

Quick answer

Audit first: list every snapshot with age, source, and whether the source still exists. Then apply four cuts. 1) Delete snapshots whose source volume no longer exists and which no recovery plan references. 2) Set explicit retention, a common safe policy is 7 daily, 4 weekly, 12 monthly rather than unlimited. 3) Move long term retention to archive tiers, EBS Snapshot Archive is $0.0125 per GB-month against $0.05 for standard, a 75 percent cut for anything kept over 90 days. 4) Reduce snapshot frequency on non-production from daily to weekly. Expected saving is 50 to 80 percent of snapshot spend, with compliance retention as the binding constraint.

Snapshot cost is structurally different from every other line: it has no ceiling. A daily snapshot schedule with no expiry policy produces 365 snapshots a year, forever, and each incremental snapshot holds the blocks that changed. Nobody notices because the monthly increase is small and the line is never the largest item, right up until it is.

Why the incremental model hides the cost

Snapshots are incremental, which people read as cheap. It is more subtle than that. Each snapshot stores only the blocks changed since the previous one, but deleting a snapshot only reclaims the blocks that no later snapshot still references. On a database volume with high write churn, where 30 percent of blocks change daily, thirty daily snapshots of a 1 TB volume can consume several terabytes of snapshot storage. At $0.05 per GB-month on AWS, $0.026 per GB-month for GCP persistent disk snapshots, and roughly $0.05 per GB-month for Azure snapshot storage, that is real money: 5 TB of snapshot data on AWS is $250 a month, and it grows every day. The mechanics are covered in EBS snapshot cost creep.

Step 1: audit before you touch anything

QuestionWhat the answer tells you
Does the source volume still exist?Orphan candidate
How old is the oldest snapshot?Whether any retention exists
What is the snapshot count per volume?Frequency versus need
Is it production or non-production?Which retention policy applies
Does a compliance policy name it?The hard constraint

Build this table before deleting anything. The compliance question is the one that decides the floor: if a regulation requires seven years of retention on a dataset, no amount of optimisation changes that, but it does change which tier the data should sit in.

Step 2: delete the orphans

Snapshots whose source volume was deleted years ago are the safest cut. They exist because deleting a volume does not delete its snapshots, by design. Cross reference every snapshot against existing volumes, exclude anything an AMI or machine image depends on (deleting those breaks instance launches), exclude anything a recovery runbook names, and delete the rest. On an account with a few years of history this alone is often 30 to 50 percent of snapshot storage.

Step 3: set retention that someone can defend

Unlimited retention is not a policy, it is the absence of one. A defensible default for most workloads is a grandfather scheme: 7 daily, 4 weekly, 12 monthly, and whatever number of yearly copies compliance names. That is 23 snapshots plus yearlies instead of hundreds, and it still gives you point in time recovery for the last week, weekly granularity for a month, and monthly for a year.

For non-production, the honest question is whether you need backups at all. A dev environment rebuilt from Terraform in twenty minutes does not need 30 days of snapshots. Dropping non-production from daily to weekly with 4 weeks retention typically cuts that portion by 85 percent.

Step 4: archive rather than delete for long retention

When compliance requires multi year retention, the lever is tier, not deletion. EBS Snapshot Archive is $0.0125 per GB-month against $0.05 for standard snapshot storage, a 75 percent cut. Azure supports moving snapshots to archive tier, and GCP snapshots can target archive storage locations. The trade offs are strict: archived snapshots take up to 72 hours to restore, there is a minimum 90 day billing period, and there is a per GB restore charge. So archive is correct for a compliance copy you hope never to read and wrong for anything in an active recovery plan with an RTO measured in hours.

On 20 TB of snapshots kept for three years, standard storage is about $1,000 a month and archive is about $250, saving $9,000 a year for data that would only be read during an audit.

Step 5: check cross region copies and managed backup services

Cross region snapshot copies double storage cost and add inter region transfer charges on every copy. Check whether the destination region still matters. Managed backup services add their own charges on top of the underlying storage, and their default plans are usually more conservative than anyone chose deliberately. Also audit database automated backups: retention beyond the free allowance bills at storage rates, and manual database snapshots persist after the instance is deleted, which is a common orphan source.

Expected saving and the one risk that matters

A full pass typically cuts snapshot and backup spend 50 to 80 percent. The single risk is deleting the copy you needed, and it is mitigated by one rule: never change a retention policy without the data owner and the recovery runbook agreeing in writing. Run a restore test against the new policy before deleting the old snapshots, because an untested backup is not a backup regardless of what it costs.

To keep it from regrowing, define retention in the Terraform that creates the backup plan rather than in a console, and price the storage implications of a backup configuration against the resource catalog before it ships. Related reading: EBS snapshot cost and GCP persistent disk snapshot cost.

FAQ

Why do snapshot costs keep growing?

Because a daily schedule with no expiry policy has no ceiling. Snapshots are incremental, but deleting one only reclaims blocks no later snapshot references, so on a high churn database volume where 30 percent of blocks change daily, thirty daily snapshots of a 1 TB volume can consume several terabytes. At $0.05 per GB-month on AWS, 5 TB is $250 a month and it increases every day.

What is a defensible snapshot retention policy?

A grandfather scheme: 7 daily, 4 weekly, 12 monthly, plus whatever yearly copies compliance names. That is 23 snapshots plus yearlies rather than hundreds, and it still gives point in time recovery for the last week, weekly granularity for a month, and monthly for a year. Unlimited retention is not a policy, it is the absence of one.

Can I delete snapshots whose volume no longer exists?

Usually yes, and it is the safest cut, often 30 to 50 percent of snapshot storage on an account with a few years of history. Deleting a volume does not delete its snapshots by design. Before deleting, exclude anything an AMI or machine image depends on since that breaks instance launches, and exclude anything a documented recovery runbook names.

How much does snapshot archive tier save?

About 75 percent. EBS Snapshot Archive is $0.0125 per GB-month against $0.05 for standard snapshot storage, so 20 TB kept for three years drops from roughly $1,000 to about $250 a month. The constraints are strict: up to 72 hours to restore, a minimum 90 day billing period, and a per GB restore charge, so it suits compliance copies rather than active recovery plans.

Do non-production environments need backups?

Often not at the same level. A dev environment that rebuilds from Terraform in twenty minutes does not need 30 days of snapshots. Dropping non-production from daily snapshots with unlimited retention to weekly with 4 weeks retention typically cuts that portion of snapshot spend by around 85 percent, with recovery covered by re-running the infrastructure code instead.

What is the main risk of a backup cleanup?

Deleting the copy you needed. One rule mitigates it: never change a retention policy without the data owner and the recovery runbook agreeing in writing, and run a restore test against the new policy before deleting the old snapshots. An untested backup is not a backup regardless of what it costs, so the restore test is part of the saving, not overhead.

What to do next

Define retention where the backup is created. C3X prices backup and storage config from Terraform against a live resource catalog. Start with the quickstart.

Try C3X on your own Terraform

Free and open source. No API key required. One command to install, one command to estimate.