Explanation
Why the waste happens and who it affects.
The default backup policy is generous: snapshots every 6 hours (every 12 on NVMe clusters) kept for 7 days, daily snapshots for 7 days, weekly for 4 weeks, monthly for 12 months and yearly for 1 year. Clusters can also have additional backup copies in other regions; MongoDB notes that copying all backups to one additional region costs approximately twice the storage, plus cross-region data transfer.
The waste comes from applying that default, or a production-grade policy with extra region copies, to every cluster regardless of what it holds. Staging, test and analytics clusters whose data can be rebuilt end up keeping a year of monthly and yearly snapshots, and on-demand snapshots taken before migrations are never deleted. MongoDB's billing optimization guidance lists high backup frequency as a cost driver and recommends lowering it for less critical clusters, and its cost documentation lists deleting unneeded snapshots, reducing frequency and retention, and reducing copies to other regions as the ways to lower backup cost. This entry covers scheduled snapshots; point-in-time Continuous Cloud Backup is a separate add-on.
Billing model
The pricing dimensions that drive this cost.
- Snapshot storage
- Billed per GB per month of retained snapshot data, at rates that vary by cloud provider and region, shown as daily GB-days line items
- Snapshot incrementality
- Atlas snapshots incrementally from one snapshot to the next where possible, so storage grows with how much data changes and how many snapshots are retained
- Additional backup copies
- Snapshots copied to other regions add roughly the same storage again in each copy region, plus cross-region data transfer
- Snapshot export
- Exporting snapshots to cloud object storage is charged per GB exported plus the cloud provider's transfer costs
How to detect
5 checks to find it in your estate.
- Review each project's backup policies in the Backup Policy Editor or the cluster backup schedule in the Administration API, and flag non-production or rebuildable clusters still on the default policy with monthly and yearly retention
- Flag clusters with additional backup copies in other regions where disaster recovery requirements do not call for a second region
- List snapshots per cluster and identify on-demand snapshots and long-retained snapshots that no longer serve a recovery or compliance purpose
- Use Cost Explorer and the invoice to compare backup charges per cluster with the cluster's data size; backup cost growing faster than data points to retention, copies or poor incrementality
- Check whether a Backup Compliance Policy applies to the project, since it sets minimums that cluster policies cannot go below
How to fix
6 ways to remove the waste.
- Define backup tiers by environment and criticality, and reduce snapshot frequency and retention for less critical clusters, for example dropping hourly and yearly items and shortening monthly retention where recovery objectives allow
- When shortening retention, check Update retention time of existing snapshots before saving so existing snapshots created by the edited policy items also expire sooner
- Remove additional backup copies to other regions, or reduce the snapshot types copied, on clusters without a cross-region recovery requirement
- Delete unneeded on-demand and legacy snapshots, keeping those required for audit or rollback
- Improve snapshot incrementality where possible; MongoDB notes that write patterns such as inserting documents rather than repeatedly updating large arrays can make snapshots more efficient
- For projects under a Backup Compliance Policy, move non-production clusters to a project without the policy, since the policy's minimums and snapshot protections cannot be reduced self-service
Documentation
Vendor references for pricing and configuration.