AWS RDS Cost Calculator
Estimate RDS-style managed database cost with a simple model: instance hours + storage + backup storage + I/O requests using hours/day x days/month, then compare baseline vs peak I/O.
Maintained by CloudCostKit Editorial Team. Last updated: 2026-02-07. Editorial policy and methodology.
Best next steps
Use this calculator for the first estimate, then validate the answer with the closest guide or companion tool.
Inputs
Instances
Price ($ / hour / instance)
Hours/day
Use 24 for always-on DBs.
Days/month
Use 30.4 for an average month.
Monthly hours: 730
Storage (GB-month)
Approx 0.2 TB-month.
Starting storage (GB)
Monthly growth (%)
Months in period
Est 186 GB-month avg.
Storage price ($ / GB-month)
Backup storage (GB-month)
Backup ratio 100%.
Backup ratio (%)
Current ratio 100% of storage.
Est 200 GB backups.
Backup price ($ / GB-month)
I/O requests (per month)
Avg 1,903.6 IOPS.
Avg IOPS
Use average read + write IOPS.
Est 5,253,120,000 I/O requests/month.
I/O price ($ / 1M requests)
Scenario presets
Results
Estimated monthly total
$1,187.92
Compute
$145.92
DB storage
$23.00
Backups
$19.00
I/O requests
$1,000.00
I/O requests (per month)
5,000,000,000
Billable hours (fleet)
730 hr
RDS cost is a managed database bill with four different growth surfaces
This page works best when you stop treating RDS like one price line. A real month is usually made of compute, primary storage, backup storage, and workload-driven I/O. Different teams overfocus on instance size while backup churn or I/O behavior quietly becomes the real reason the bill grows.
- Compute: the always-on database surface, including primary nodes, read replicas, or serverless runtime.
- Primary storage: the persistent data layer that grows with tables, indexes, and replicas.
- Backup storage: the retention-driven layer that expands with churn, not only with total size.
- I/O behavior: the variable layer that can spike during backfills, batch jobs, or poor query patterns.
Where RDS estimates usually drift
- Instance-hours are modeled carefully, but backup storage is treated like a flat percentage instead of a churn problem.
- I/O spikes are blamed on needing larger instances when the actual issue is workload shape or storage tier choice.
- Allocated storage is treated as static even though growth, replicas, and backup policy change the total month by month.
- One normal month is used even though migrations, reindexing, or backfills create very different database behavior.
What to review before trusting the RDS baseline
- Separate compute, primary storage, backups, and I/O so one noisy line item does not hide the others.
- Check backup retention and daily change rate before assuming backups are a small fixed add-on.
- Model replica or Multi-AZ overhead explicitly if that is part of production architecture.
- Use a batch-heavy or churn-heavy scenario whenever your workload includes imports, backfills, or reporting spikes.
Baseline vs churn-heavy RDS scenarios
| Scenario | Instances | Storage | Backups | I/O |
|---|---|---|---|---|
| Baseline | Expected | Average | Retention plan | Normal workload |
| Peak | Same or +1 | Growth | Higher churn | Batch/backfill |
How to review the first real RDS month
- Compare actual compute, storage, backup, and I/O line items separately so you know which surface missed the estimate.
- Review batch windows and retention-driven backup growth before changing the whole baseline or instance strategy.
Next steps
Example scenario
- 1 instance at $0.20/hour running 24 hours/day for 30 days, 200GB storage, 200GB backups, and 5B I/O requests/month.
- Peak 220% scenario highlights batch workloads and backfills.
Included
- Compute from instances x hours/day x days/month x $/hour.
- Storage from GB-month x $/GB-month.
- Backup storage from GB-month x $/GB-month.
- I/O requests from monthly I/O volume x $ per 1M requests.
- Optional storage growth, backup ratio, and IOPS estimators.
- Baseline vs peak scenario table for I/O spikes.
Not included
- Network/data transfer, monitoring/logs, licensing, taxes, and feature add-ons.
- Free tiers, tiered steps, and per-engine differences unless you reflect them in pricing inputs.
How we calculate
- Compute cost = instances x (hours/day x days/month) x $ per hour.
- Storage cost = GB-month x $ per GB-month.
- Backup cost = backup GB-month x $ per GB-month.
- I/O cost = (I/O requests per month / 1,000,000) x $ per 1M I/O requests.
- Total = compute + storage + backups + I/O (excluding transfer and add-ons).
FAQ
Why do I need to enter pricing?
RDS pricing varies by engine, region, storage type, and discounts. Use your effective rates for accurate estimates.
Does this include Multi-AZ replicas or read replicas?
Not directly. Model additional instances and storage as separate line items (or increase instance count and backup/storage inputs).
What should I use for I/O requests?
Use monitoring/engine metrics or estimate from workload. If you don't have I/O pricing in your plan, set it to $0 to exclude.
Related tools
Related guides
S3 pricing: a practical model for storage, requests, egress, and replication
A practical S3 pricing guide: what to include (GB-month, requests, egress, replication) and how to estimate the key inputs without copying price tables.
Azure SQL Database pricing: a practical estimate (compute, storage, backups, transfer)
Model Azure SQL Database cost without memorizing price tables: compute baseline (vCore/DTU), storage GB-month + growth, backup retention, and network transfer. Includes a validation checklist and common sizing traps.
Bigtable cost estimation: nodes, storage growth, and transfer (practical model)
A driver-based Bigtable estimate: provisioned capacity (node-hours), stored GB-month + growth, and network transfer. Includes validation steps for hotspots, compactions, and peak throughput that force over-provisioning.
CDN Cost Comparison Guide: Compare Pricing, Per-GB Rates, and Provider Trade-Offs
Compare CDN pricing across providers with a practical framework for bandwidth, requests, per-GB rates, regional mix, and origin egress. Built for CDN cost comparison and provider-decision workflows.
Cloud cost estimation checklist: build a model Google (and finance) will trust
A practical checklist to estimate cloud cost without missing major line items: requests, compute, storage, logs/metrics, and network transfer. Includes a worksheet template, validation steps, and the most common double-counting traps.
Cloud SQL pricing: instance-hours, storage, backups, and network (practical estimate)
A driver-based Cloud SQL estimate: instance-hours (HA + replicas), storage GB-month, backups/retention, and data transfer. Includes a worked template, common pitfalls, and validation steps for peak sizing and growth.
Disclaimer
Educational use only. Not legal, financial, or professional advice. Results are estimates based on the inputs and assumptions shown on this page. Verify pricing and limits with your providers and documentation.
Last updated: 2026-02-07. Reviewed against CloudCostKit methodology and current provider documentation. See the Editorial Policy .