Reducing Backup Costs Without Weakening Recovery

Backup spend grows by accumulation

Backups rarely appear on a cost review because they are boring and small at first. Then retention gets extended once after an incident and never reduced. A second region is added for safety. Developers snapshot a database before a risky change and forget it. Environments are deleted but their snapshots remain. After two years, storage for copies exceeds storage for the live data, and nobody can explain it.

Cost optimisation here is not about weakening protection. It is about making sure every copy exists for a reason you can state. It builds on the backup strategy and fits alongside our broader cloud cost optimisation reviews for managed clients.

What good looks like

• Spend is attributed to workloads through tags.
• Every retention period has a stated purpose.
• Older recovery points are thinned out and, where it makes sense, moved to cheaper storage.
• Orphans and expired copies are removed automatically.
• Cost per protected workload is visible and reviewed.
• Savings never cut below the agreed recovery targets.

Where the money goes

Backup cost has several components, and they behave differently:

We avoid quoting prices because they change by provider, region and service. The method is to read your own bill.

How the analysis works in practice

Step one: attribute

We use cost allocation tags and the cost and usage data to split backup spend by service, environment and region. Untagged spend is its own line, and usually tells a story about where governance is thin. This produces the first honest answer to “what does it cost to protect each system?”

Step two: find the waste

Typical findings:

• Orphaned snapshots whose source volume or database no longer exists.
• Non-production environments kept at production retention.
• Duplicate protection: both a central backup plan and an old per-resource schedule protect the same thing.
• Unneeded second-region copies of rebuildable data.
• Large temporary data such as build artefacts or logs included by accident.

A simple starting point for listing old snapshots on AWS, for review rather than automatic deletion:

aws ec2 describe-snapshots --owner-ids self \
  --query "Snapshots[?StartTime<='2026-01-01'].[SnapshotId,VolumeId,StartTime,VolumeSize]" \
  --output table

We check that each result is not referenced by an image or a retention policy before anything is deleted, and we prefer to delete through the policy engine rather than by hand.

Step three: justify retention

Retention should come from scenarios. A bug introduced by a release is usually noticed within days. Slow data corruption can take weeks. Audit or contractual duties may require months or years. A layered scheme often fits: frequent recovery points kept for a short time, weekly points for a month or two, and monthly points kept longer for the data that needs them. Everything else is trimmed.

Legal rules cut both ways. Some require keeping records, others require erasing personal data on request, which interacts with long-lived backups. We document what you decide and why; your compliance advisers should confirm which rules apply.

Step four: lifecycle and tiering

AWS Backup lifecycle rules can move recovery points to cold storage after a number of days for supported resource types, with minimum retention periods in cold storage, so verify the details for your service. S3 lifecycle configuration transitions objects between storage classes. Azure Backup policies and archive tiers offer similar options for supported workloads. Cold tiers save money for data you rarely read and charge for access, so we model your actual restore patterns first.

In Terraform, lifecycle settings sit with the plan:

lifecycle {
  cold_storage_after = 30
  delete_after       = 365
}

Cold storage has a minimum duration, and delete_after generally has to exceed it by the required margin. We check current service rules when we set values.

Decisions and trade-offs

Cost versus restore speed. Cheaper tiers restore more slowly. That is fine for year-old audit copies, not for last night’s database.

Fewer copies versus resilience. Removing the cross-region copy of a critical store saves money and removes protection. Spend should follow tier. Our cross-region replication work states which stores deserve it.

Automation of deletion. Automatic cleanup is efficient but dangerous. We start with reports, then enable deletion with guardrails such as tags that exempt a resource.

When not to optimise. On a small estate the effort may exceed the saving. A one-off tidy of orphans and a sensible retention default may be all that is worth doing. For wider spend, see our EKS cost optimisation guide and the EKS cost calculator.

Common failure modes

• Cutting retention to save money, then needing the old copy.
• Cleanup scripts that delete shared snapshots.
• Ignoring transfer costs when adding a second region.
• Cold storage minimums that make early deletion more expensive than keeping.
• No ownership, so nobody feels responsible for the line item.

Delivery and handover

You receive a cost breakdown by workload, a list of changes with estimated effect and risk, updated policies as code, and a dashboard or report for ongoing review. We agree a review rhythm with your team, typically quarterly, so growth is caught early.

How to tell it is working

Spend per protected workload is stable or falling relative to data growth, every retention period has a stated reason, orphan counts trend toward zero, and recovery tests still meet their targets after the changes. To review your backup bill, book a consultation.

References

• Backup plans, AWS Backup
• Azure Backup archive tier overview, Microsoft Learn