Estimate RDS backup storage (GB-month) from retention and churn
This page is the backup-storage measurement workflow, not the bill-boundary page: the goal is to turn churn, retention, manual snapshot behavior, copy policies, and long-term retention windows into a defendable backup GB-month model.
If you are still deciding which costs belong inside the RDS bill versus beside it, go back to the pricing guide first.
Evidence pack before you estimate anything
- Churn: daily changed GB from write activity, WAL or binlog behavior, and batch windows.
- Retention: automated backup retention days plus any environment-specific differences.
- Manual snapshot behavior: operational or incident-driven snapshots that persist beyond automated retention.
- Copy policies: cross-region or cross-account snapshot copies that create additional backup footprint.
- Long-term retention windows: monthly or yearly snapshots that should not be mixed with steady-state operational retention.
Method A (best): Start from billing data if you already have usage
- In Cost Explorer, filter Service to Amazon RDS.
- Group by Usage type and identify the backup/snapshot storage line items.
- Take a representative 30-day window and treat the observed backup GB-month as the baseline.
- Use churn × retention only to explain or forecast changes (new retention policy, new workload, migration).
Method B (planning): Estimate daily changed data (churn)
- Use engine metrics, binlog/WAL volume, or write throughput as a proxy.
- Model bursty periods (batch jobs) separately from steady state.
- If unsure, estimate a low and high churn scenario.
What you want is a GB/day changed number. Even a rough range (5–10 GB/day vs 50–100 GB/day) is enough to make retention decisions defensible.
Method B step 2: Multiply by retention (steady-state backup footprint)
First-pass planning model: backup GB is roughly daily changed GB x retention days.
This model estimates the steady-state backup storage footprint after retention “fills up”. It’s a planning approximation, but it’s usually directionally correct for budgeting and for comparing retention policies.
Separate steady-state backup exposure from spike windows
- Steady-state exposure: operational retention under normal daily churn.
- Incident windows: unusual backup growth caused by emergency snapshots, restore drills, or investigation work.
- Migration windows: temporary spikes from snapshot copies, cutovers, or long-lived rollback checkpoints.
- Policy-change windows: months where a new retention setting has not yet reached steady state.
Method B step 3: Add long-term snapshots separately
If you keep weekly/monthly manual snapshots (or use AWS Backup for long-term retention), model them as a separate bucket. In early planning, assume each long-term snapshot is “close to” the DB size at that time and tighten the estimate once you can observe real snapshot growth.
Step 4: Sanity-check with real snapshot sizes
- Look at snapshot sizes and growth over time.
- Confirm whether manual snapshots (long-term) are accumulating.
- Check for retention differences across environments and accounts.
Worked example (make retention trade-offs visible)
If churn is 20 GB/day and operational retention is 14 days, a first-pass estimate is ~280 GB of backup storage at steady state (20 × 14). If you extend retention to 35 days, the same workload becomes ~700 GB. This is why retention changes can move costs even when DB size is stable.
Common mistakes
- Using DB size as the backup estimate (backup is driven by churn and retention).
- Ignoring manual snapshots created during incident response or migrations.
- Assuming dev/staging retention is “cheap” because the instance is small.
- Forgetting cross-region/cross-account snapshot copies in the total footprint.
Turn GB-month into dollars
Use AWS RDS Cost Calculator and set the backup storage input to your estimated backup GB-month. Pair it with DB storage growth for multi-month scenarios.
How to validate (so the estimate holds up)
- Use Cost Explorer to confirm the backup storage line item for Amazon RDS over a representative month.
- Correlate spikes with retention changes, incident windows, backfills, or snapshot copy jobs.
- After policy changes, compare backup GB-month before/after (same workload window) to confirm impact.
When the backup model is ready to hand off
- Go back to RDS pricing if you still are not sure which backup-related costs belong inside the RDS bill versus adjacent workflow budgets.
- Move to RDS cost optimization when you can defend the dominant driver and want to change retention, snapshot policy, or churn-heavy behavior.