RDS storage autoscaling cost: convenient, but it only ratchets up

Quick answer

RDS storage autoscaling has no feature fee; you pay only for the storage it allocates, for example gp3 at about $0.115 per GB-month single-AZ or $0.23 per GB Multi-AZ in us-east-1. The cost trap is that autoscaling only grows and never shrinks: once a temporary spike, a bulk load, or runaway logs push the volume from 100 GB to 500 GB, it stays at 500 GB and keeps billing even after the data is deleted. The controls are a sensible max allocated storage ceiling and periodic review, plus fixing what caused the growth, since reclaiming space means creating a new smaller instance, not shrinking in place.

RDS storage autoscaling is a genuinely useful safety net. When free space drops below a threshold, RDS automatically increases the allocated storage so the database does not run out and go read-only or down. The feature costs nothing extra; you pay only for the storage allocated at the normal rate. The cost problem is not the feature, it is the one-way nature of what it does.

What RDS storage costs

Storage type	Single-AZ /GB-mo	Multi-AZ /GB-mo
General Purpose gp3	~$0.115	~$0.23
Provisioned IOPS io1	~$0.125 + IOPS	~$0.25 + IOPS

Storage is billed per GB of allocated space, not used space, so an instance allocated 500 GB bills for 500 GB even if only 120 GB holds data. On gp3 single-AZ that is about $57.50 per month for the 500 GB, versus $13.80 for the 120 GB you actually use. Multi-AZ doubles it because the standby keeps a full copy. The gap between allocated and used is exactly what autoscaling can silently open up.

The ratchet problem

Autoscaling grows storage but has no mechanism to shrink it. A batch import that temporarily needs 400 GB, a runaway log table, or a one-off data migration can trigger several autoscaling events that push a 100 GB volume to 500 GB. When the temporary data is deleted, the allocated storage stays at 500 GB, billing for the peak forever. The only way to reclaim it is to create a new instance with smaller storage and migrate, usually via a snapshot restore or logical dump, which involves downtime or careful cutover. So a five-minute spike can turn into a permanent cost increase.

Setting the ceiling

The primary control is Max Allocated Storage, the upper bound autoscaling will not exceed. Set it to a realistic maximum for the workload, not an arbitrarily huge number, so a runaway process, an unbounded log, or a bad query writing temp data cannot inflate the volume without limit. A ceiling of, say, 2x the current allocation gives room for genuine growth while capping the damage from an accident. Pair it with a CloudWatch alarm on FreeStorageSpace so growth is noticed and investigated rather than absorbed silently.

Fix the cause, then reclaim

When autoscaling fires, treat it as a signal, not just an event. Find what consumed the space: real data growth that justifies the new size, or transient data, bloat, or logs that should be cleaned up. If the growth was transient and the instance is now oversized, plan a migration to a right-sized instance to recover the cost, since in-place shrink is not supported. See right-sizing RDS for the broader instance and storage review, and remember Multi-AZ doubles every gigabyte, covered in RDS Multi-AZ cost.

Autoscale with a limit, not a blank cheque

Autoscaling is worth enabling for the outage protection alone, but it is not a substitute for capacity planning. Enable it with a deliberate Max Allocated Storage ceiling, alarm on storage growth, and treat every scale event as something to investigate. Price the instance's storage allocation against the resource catalog before deploy so the baseline and the ceiling are chosen on purpose rather than left to grow into a permanent overpay.

FAQ

Does RDS storage autoscaling cost extra?

No, the feature itself is free. You pay only for the storage it allocates at the normal rate, for example gp3 at about $0.115 per GB-month single-AZ or $0.23 per GB Multi-AZ in us-east-1. Storage is billed on allocated space, not used space, so autoscaling's cost impact comes entirely from how much it grows the volume.

Why is RDS autoscaling a cost risk if it is free?

Because it only grows and never shrinks. A temporary spike, bulk load, or runaway log can trigger autoscaling events that push a 100 GB volume to 500 GB, and it stays at 500 GB billing forever even after the data is deleted. Reclaiming the space requires migrating to a new smaller instance, since in-place shrink is not supported.

How do I control RDS storage autoscaling cost?

Set a realistic Max Allocated Storage ceiling so a runaway process cannot inflate the volume without limit, add a CloudWatch alarm on FreeStorageSpace so growth is noticed, and investigate every scale event to see whether the growth is real or transient. If the instance ends up oversized, plan a migration to a right-sized instance to recover the cost.

Can I shrink RDS storage after it autoscales?

Not in place. RDS does not support reducing allocated storage on an existing instance. To reclaim space after autoscaling has grown a volume, you must create a new instance with smaller storage and migrate the data, typically via a snapshot restore or logical dump, which involves downtime or a careful cutover.

How does C3X help with RDS storage cost?

C3X prices RDS instances from Terraform including allocated storage, storage type, Multi-AZ, and the autoscaling ceiling, so the storage cost and its upper bound are visible in the pull request. That lets teams set a deliberate baseline and Max Allocated Storage before deploy, avoiding the permanent overpay a one-time autoscaling spike can otherwise lock in.

What to do next

Set a storage ceiling on purpose, not after a spike. C3X prices RDS storage and autoscaling from Terraform against a live resource catalog. Start with the quickstart.