Optimizing Aurora Storage Costs: Why Costs Stay the Same Even After Deleting Data

In AWS Aurora, logical data was around 310GB, but the billed storage reached as much as 2TB, keeping costs abnormally high. Even after running large-scale DELETEs, VolumeBytesUsed barely decreased, revealing that deleted data didn't immediately translate into cost savings.

The cause was Aurora's storage structure and Fragmentation. Aurora expands storage in 10GB units, and even when data is deleted, space is only returned once the corresponding block is completely emptied. When data is scattered across the disk, only empty gaps form inside blocks, while the actual allocated amount doesn't decrease, so costs kept accruing.

The solution chosen was Snapshot & Restore. By creating a snapshot of the running cluster and then creating a new cluster from it, storage can be reallocated based on the actual current amount of data, without inheriting the fragmentation of the existing physical volume.

The procedure was as follows.

• Stop the related service
• Create a DB snapshot from the current Aurora Cluster
• Create a new cluster from the snapshot
• Configure settings such as parameter groups and security groups, and verify data integrity
• Switch the application's DB Endpoint to the new cluster and restart the service

As a result, VolumeBytesUsed dropped from 2TB → 316GB, and daily cost decreased from $21.4 → $2.99. On a monthly basis, this amounted to savings of roughly over $550, or about 86% cost reduction.

The key point is that Aurora's "pay only for what you use" does not mean "costs drop immediately as soon as you delete." For operations centered on DELETE, it's most reliable to regularly check for storage fragmentation, and when the gap is large, refresh the cluster via Snapshot & Restore as the surest optimization method.