Oversized RDS Instance Storage

For example, a 2TB volume might contain only 150GB of actual data. Since RDS does not allow reducing allocated storage on existing instances, these volumes continue to incur charges based on total provisioned size - not actual usage. This often goes unnoticed in long-running databases that no longer require their original allocation.

RDS storage is billed per GB-month of provisioned capacity. Charges apply whether or not the database actually uses the full allocated space. Storage type (e.g., gp2, gp3, io1) and optional features like Multi-AZ, backups, and snapshots may further influence the cost.

• Identify RDS instances where provisioned storage significantly exceeds actual usage
• Review storage metrics to validate consistent underutilization (e.g., <25% usage over time)
• Evaluate whether storage needs have declined due to archival, data aging, or workload changes
• Confirm that attached storage is not constrained by IOPS provisioning or replication settings
• Consult with DBAs to determine if data can be migrated to a smaller, more cost-effective volume

Since RDS does not support reducing storage size in-place, the database must move to a new instance with smaller allocated storage. For RDS for PostgreSQL 12+, MySQL 5.7+ and MariaDB 10.4+, a Blue/Green Deployment with smaller allocated storage on the green environment does this with minimal downtime at switchover. For other engines, migrate manually. This can be done using the DB engine's native dump and restore utilities; restoring from a snapshot does not help, because a snapshot restores with the same allocated storage as its source. For minimal downtime, consider using AWS Database Migration Service (DMS) to replicate data to a new instance. After migration, enable storage AutoScaling to allow future growth while minimizing overprovisioning. Ensure proper validation and cutover planning before decommissioning the original instance.

• RDS Pricingaws.amazon.com
• Amazon RDS Storage Typesdocs.aws.amazon.com