Backup storage cost is mostly over-retention and wrong-tier placement, not the data you genuinely need to recover. Cut it without weakening recovery by mapping every dataset to its real recovery point objective and recovery time objective, right-sizing retention to what compliance and operations actually require, using incremental backups and deduplication so each recovery point stores only changes, and tiering cold recovery points into cheap archive classes whose restore time still meets the RTO. The recovery guarantee is preserved because you keep the points the business needs and only remove redundancy and over-retention. In the 500+ environments we have optimized, backup bloat is one of the quietest line items, and clearing it is part of the work behind our 31% average reduction.
Last updated: June 2026 · Written by Fredrik Filipsson and reviewed by Morten Andersen · See, Cut, Lock, Run method
Backups grow forever unless something stops them. A protection policy gets set once, usually with a generous default retention, and then nobody revisits it because reducing a backup feels like reducing safety. Meanwhile full copies pile up where incrementals would do, recovery points that should have aged into archive sit on the hottest tier, and backups of long-deleted resources keep billing. None of that buys more recovery. The discipline is to separate the recovery you actually need, defined by RPO and RTO, from the storage habits that have accreted around it. This guide is part of our complete guide to cloud storage and data cost optimization, the cluster pillar it links up to.
Why are my backup storage costs so high?
Backup costs are usually high because of over-retention and wrong-tier placement, not because the protected data is large. Default policies retain recovery points far longer than compliance or operations require, full backups duplicate unchanged data that incrementals would skip, and aging recovery points stay on premium storage instead of moving to archive. Backups of deleted resources and abandoned snapshots keep billing because nothing cleans them up. With AWS Backup you pay for the backup storage consumed as a GB-month figure, plus restore and cross-Region transfer, per the AWS Backup pricing page, and the gap between premium and archive storage is wide: S3 Glacier Deep Archive starts around $0.00099 per gigabyte-month, per the Amazon S3 pricing page, against roughly $0.023 for S3 Standard. The bill is high because nothing is thinning retention and nothing is moving cold recovery points down. Both are fixable with policy changes rather than weaker protection.
How do I reduce backup costs without losing recovery, step by step?
Reduce backup cost by anchoring every decision to the recovery objective the data actually has, then cutting everything that exceeds it. Work through these steps:
- Map each dataset to its real RPO and RTO. Classify data by how much loss and how long a restore the business can tolerate. A reporting database and a production transaction store do not need the same backup frequency or retention.
- Right-size retention to the policy actually required. Replace indefinite or default retention with a tiered schedule: frequent recent recovery points, thinned to weekly then monthly, with only the legally required points held long term.
- Deduplicate and use incremental backups. Use incremental or change-block backups and deduplication so each recovery point stores only what changed, not a full copy every cycle. This is often the single largest saving.
- Tier cold backups to cheaper classes. Move recovery points past the hot-recovery window into low-cost warm or cold archive tiers, respecting each tier's minimum retention and retrieval time so restores still meet RTO. AWS Backup, for example, requires backups to sit in warm storage for a minimum period before transition.
- Delete orphaned and superseded backups. Find and remove backups of deleted resources, abandoned snapshots, and recovery points beyond their retention policy so they stop accruing storage forever.
This is the same waste-elimination work in our rightsizing and waste elimination service. When constant backup writes are also driving up per-operation charges, the sibling guide on how to reduce object storage API and request costs covers that line directly.
Never cut a backup whose recovery point the business actually needs. The savings come from redundancy and over-retention: full copies that should be incremental, premium-tier storage that should be archive, and retention beyond the compliance window. Set RPO and RTO first, then optimize storage underneath those fixed targets. Order matters, just as it does across our whole method.
What is the difference between RPO and RTO for backup cost?
RPO and RTO are the two recovery objectives that should drive every backup cost decision. The recovery point objective is how much data loss is tolerable, measured as a time window, and it drives backup frequency: a one-hour RPO means hourly recovery points, which costs more in storage than a daily RPO. The recovery time objective is how fast a restore must complete, and it drives which storage tier a backup can live on: a tight RTO forces recovery points onto fast-restore storage, while a loose RTO lets older points sit in cheap archive classes that take hours to retrieve. Most environments apply one blanket policy to everything, which means tier-one protection cost on tier-three data. Setting RPO and RTO per dataset is what lets you cut storage cost without touching the recovery the business depends on, because you only ever reduce protection that exceeds the stated objective.
When should I tier backups to cold or archive storage?
Tier a recovery point to cold or archive storage once it ages past the window where a fast restore is realistic, and only where the RTO tolerates the retrieval delay. Backup access is steeply recency-biased: the newest recovery points are the ones restored in an incident, and points older than a few weeks are kept mainly for compliance or worst-case rollback. That makes age the natural transition trigger. Keep recent recovery points on a fast tier for operational restores, move points past the hot window into a low-cost warm tier, and send long-term compliance copies to deep archive classes such as S3 Glacier Deep Archive, where storage is roughly a tenth of a cent per gigabyte-month but retrieval takes hours and carries a fee. The judgment is identical to the access-frequency call covered in the sibling guidance on reducing object storage API and request costs: tier by the recovery the data actually needs, not by optimism, because a misjudged RTO turns retrieval fees and restore delay into a real incident.
Are your backups protecting recovery or just billing?
Our cost audit maps every protected dataset to its RPO and RTO, finds over-retention, redundant full copies, and orphaned recovery points, and proves the saving against a clean baseline before anything changes. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →The Cloud Storage and Egress Cost Playbook includes the backup retention and tiering checklist we run, so recovery points are matched to RPO and RTO before storage is ever cut.
Frequently asked questions
How can I reduce backup costs without losing recovery?
Reduce backup cost without weakening recovery by matching retention and frequency to each dataset's real RPO and RTO, using incremental backups and deduplication so each recovery point stores only changes, and tiering cold recovery points to cheaper classes that still meet restore time. The recovery guarantee is preserved because you keep the recovery points the business actually needs and only remove redundancy and over-retention.
What is the difference between RPO and RTO in backup cost?
RPO, the recovery point objective, is how much data loss is tolerable and it drives backup frequency. RTO, the recovery time objective, is how fast a restore must complete and it drives which storage tier a backup can live on. A tight RPO means more frequent backups and more storage, while a loose RTO lets cold backups sit in cheap archive classes. Setting both per dataset is how you cut cost without hurting recovery.
Does tiering backups to cold storage hurt recovery?
Tiering only hurts recovery if you ignore retrieval time. Archive classes such as S3 Glacier Deep Archive cost far less per gigabyte but can take hours to restore and add retrieval fees, so they suit long-term recovery points with a loose RTO. Keep recent recovery points on a fast tier for quick restores and archive only the older points whose RTO allows the retrieval delay.
How long should I retain cloud backups?
Retain cloud backups for as long as compliance and the business recovery need require, and no longer. A common pattern is frequent recent recovery points for operational restores, thinned to weekly then monthly for the medium term, with a small set of long-term points held in archive for legal or regulatory retention. Indefinite default retention is the most common source of backup waste.
The short version
Backup storage cost is over-retention and wrong-tier placement, not the recovery you genuinely need. Map every dataset to its RPO and RTO, right-size retention to what compliance and operations require, use incremental backups and deduplication so each recovery point stores only changes, and tier cold points into cheap archive whose restore time still meets the RTO. Recovery stays intact because you only cut what exceeds the objective. When you want every protection policy audited and the saving proven down, that is the work our rightsizing and waste elimination service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.