Understanding Aurora MySQL Global Database Storage Metrics (Volume Bytes Used, Volume Bytes Left Total, Free Storage)

Clarifications to fully answer your specific questions regarding internal storage components and DELETE operations:

1. What VolumeBytesUsed Includes vs. Excludes

• Included: Table data, indexes, schema objects, and Undo Logs. Long-running transactions or heavy concurrent write workloads can cause undo logs to grow significantly, directly increasing VolumeBytesUsed.
• Excluded: Snapshots and Temporary Data. Automated or manual snapshots are stored in S3 and billed separately. Most temporary tables and memory-mapped files use the local storage attached to the specific DB instance, which is tracked by FreeStorageSpace, not the shared cluster volume.

2. Storage Reclamation via DELETE

Standard row-level DELETE statements do not automatically shrink the VolumeBytesUsed metric or lower your billing.

While Aurora handles dynamic volume resizing for DROP TABLE or TRUNCATE TABLE, a regular DELETE simply marks the internal InnoDB pages as reusable for future inserts. The underlying storage blocks remain allocated to your cluster. To actually release this space back to AWS, shrink the volume, and lower your bill after large-scale deletes, you must manually defragment and rebuild the table:

OPTIMIZE TABLE table_name;
-- or
ALTER TABLE table_name ENGINE=InnoDB;

Let me help clarify these Aurora MySQL storage metrics and how they work conceptually.

Aurora Volume Bytes Used

This metric represents the amount of storage used by your Aurora DB cluster in the shared cluster volume. It includes your actual database data - tables, indexes, and schema objects. This is the value that directly affects your storage costs.

However, it's important to understand that this metric doesn't reflect some internal storage allocations that don't impact billing. The metric is collected at intervals rather than continuously, so choosing very small monitoring periods isn't particularly useful.

Aurora Volume Bytes Left Total

This metric shows the remaining storage capacity available before reaching Aurora's maximum storage limit (which can be up to 128 TiB depending on your engine version). Even though Aurora auto-scales, there is still a service limit. This metric is actually more accurate than Volume Bytes Used for anticipating out-of-space issues - you should monitor whether this metric is approaching zero rather than comparing Volume Bytes Used against the 128 TiB limit.

Difference Between Volume Bytes Left Total and Free Storage Space

These measure different aspects of storage:

• Aurora Volume Bytes Left Total relates to the shared Aurora cluster volume and how much room you have before hitting the service maximum
• Free Storage Space typically refers to local storage attached to individual DB instances (like temporary storage on the instance itself)

The cluster volume is the distributed, shared storage layer that spans Availability Zones, while local storage is instance-specific.

Storage Auto-Scaling and Reclamation

Aurora cluster volumes automatically grow as data increases, starting from a minimum of 10GB. The key benefit is that when you remove data (such as dropping or truncating tables), Aurora automatically frees that allocated space, which helps minimize storage charges.

For clusters running Aurora MySQL version 2.09 or higher, the space reported by Volume Bytes Used increases when data is added and decreases when data is removed. This dynamic resizing happens automatically without manual intervention.

When to Be Concerned

Even with auto-scaling, you should monitor these metrics because:

1. You're approaching the maximum storage limit (128 TiB) - watch Aurora Volume Bytes Left Total approaching zero
2. Unexpected rapid storage growth could indicate issues like runaway queries, excessive logging, or data bloat
3. Storage costs are increasing unexpectedly

Global Database Considerations

In a Global Database setup, storage metrics apply to each cluster independently. Your primary cluster in one region has its own cluster volume, and each secondary cluster in other regions maintains its own storage volume. The replication between them uses dedicated infrastructure at the storage block level, but each cluster's storage is measured separately.

Practical Example

Imagine your Aurora cluster starts at 10GB. As you insert data, the cluster volume automatically expands to, say, 50GB - Volume Bytes Used shows 50GB. If you then drop a large table that was 20GB, Volume Bytes Used would decrease to approximately 30GB, and that freed space is automatically reclaimed. Meanwhile, Aurora Volume Bytes Left Total would show you still have plenty of room before hitting the 128 TiB maximum.

The beauty of Aurora's architecture is that you only pay for the storage you actually consume, and the system handles both growth and reclamation automatically, eliminating the manual capacity planning required with traditional databases.
Sources
Amazon CloudWatch metrics for Amazon Aurora - Amazon Aurora
Amazon Aurora storage - Amazon Aurora
Managing performance and scaling for Aurora DB clusters - Amazon Aurora
Community | Performance at scale: Amazon Aurora