RDS Storage Auto-Scaling

TL;DR: The classic RDS mistake is guessing storage high on day one and paying for empty disk every month after. Auto-scaling (June 2019) lets you start at real size and expands the volume online — no downtime — when free space drops below 10% or 10 GB, adding the greater of 10% or 10 GB, then enforcing a 6-hour cooldown. The single governing fact: storage can never shrink, so the max threshold is a permanent financial guardrail, not a comfort blanket.

The numbers

• Trigger: <10% free or <10 GB free → adds max(10% of current, 10 GB), online, with a 6-hour cooldown between events.
• Waste math: on io2 (~$0.125/GB-mo), every 100 GB of empty disk ≈ $12.50/mo / $150/yr; provisioning 500 GB when you needed 100 ≈ ~$600/yr wasted from day one.
• The gp2 IOPS trap: gp2 gives 3 IOPS/GB, so people buy 1 TB just to reach 3,000 IOPS. gp3 decouples IOPS from size (3,000 baseline, configurable) — "start-real-size on gp3 + auto-scaling" is the cheap-and-elastic pattern.
• Field examples: a SaaS launch started at 100 GB (max 500) instead of provisioning 1 TB "just in case"; an on-prem migration provisioned 250 GB vs a "safe" 500 GB and spent ~40% less on storage for the same workload.

Do this

1. Start at real usage + ~20% headroom, not a rounded-up "safe" number.
2. Enable auto-scaling and set the max to ~2× your honest 12-month growth projection — a circuit breaker, revisited every 6 months.
3. Use gp3 unless you have a specific io1/io2 reason — IOPS independent of size is the biggest "are we doing this right" tell on modern RDS.
4. Alarm on FreeStorageSpace even with auto-scaling on — you want to know each time it fires (alert as free space trends toward ~15%), not just trust it did.
5. For existing over-provisioned instances, enable auto-scaling to stop future waste, and treat current excess as sunk cost (reclaiming it means snapshot → smaller new instance → cutover).

Gotchas

• Storage never shrinks — a nightly job that temporarily fills 500 GB permanently grows the volume by 500 GB even after you delete the data; the only reclaim path is snapshot-and-rebuild.
• Max too low = disk-full errors (same as no auto-scaling, just delayed); max too high (e.g. the 64 TB AWS limit) = no guardrail, and a logging bug can run up a five-figure day you can't claw back.
• Bursty growth outraces the 6-hour cooldown — a bulk import or viral moment writing hundreds of GB in under 6 hours can still hit the ceiling; bump storage manually before known events.
• Auto-scaling ≠ right-sizing — it prevents over-provisioning up front, not a database that's been oversized since day one.

Skip this if

• You have a hard dollar cap per database and prefer a disk-full alert to a budget-blown one — fixed provisioning is more predictable.
• You're in a strict change-control regime where a Saturday-night scaling event can't pass CAB — size manually.
• Your growth routinely outpaces the 6-hour cooldown — match manual sizing to the burst pattern. For the compute side of the same right-sizing pattern, see Compute Optimizer and Rightsizing Recommendations in Cost Explorer.