RDS storage autoscaling doesn’t actually grow your disk; it tells the database instance to request more storage from the underlying EBS volume.
Here’s how it all works, from the moment your database starts nudging the autoscaler:
Let’s say you have an RDS instance, maybe a PostgreSQL one, and it’s happily chugging along. You’ve provisioned it with 100 GiB of storage. Over time, your data grows. Your tables get bigger, indexes expand, and temporary files get churned out. RDS, being a managed service, is designed to handle this gracefully.
When your RDS instance’s storage utilization hits 85%, it triggers the autoscaling mechanism. It doesn’t immediately expand the EBS volume. Instead, it initiates a process that will eventually lead to that expansion.
First, RDS sends an event notification. You’ll see something like RDS-EVENT-0005 (Storage is full) in your CloudWatch logs or via SNS if you’ve configured it. This is your first heads-up.
Concurrently, RDS makes a call to the AWS API to modify the underlying EBS volume associated with your RDS instance. This modification request is for an increased size. The new size is calculated based on a few factors, primarily your current utilization and a pre-defined threshold. AWS generally aims to increase the volume by a percentage that ensures you have enough headroom for a sustained period, often around 15-20% of the current provisioned size, or enough to reach a target utilization like 70%.
The modification request goes into a pending state. You can see this in the RDS console under your instance’s "Maintenance & backups" tab, or via the AWS CLI:
aws rds describe-db-instances --db-instance-identifier your-db-instance-id --query "DBInstances[0].StorageOptions[0].StorageType"
This command will show you details about the storage, and if a modification is pending, you’ll see it reflected in the status.
Now, here’s the critical part that trips people up: the EBS volume modification is not instantaneous, and it’s often a rolling operation. For most general-purpose SSD (gp2 and gp3) volumes, EBS can modify the size and IOPS/throughput settings while the volume is in use, and the changes are applied almost immediately. However, the operating system within the RDS instance needs to recognize this new space.
For RDS, this means the underlying Linux kernel needs to perform a resize operation on the filesystem. This is usually handled automatically by RDS’s management layer. The process involves:
- EBS Volume Resize: AWS resizes the EBS volume.
- Filesystem Resize: The RDS instance’s operating system detects the new volume size and resizes the mounted filesystem (e.g.,
ext4orxfs) to encompass the expanded storage.
This entire process can take anywhere from a few minutes to an hour, depending on the size of the volume, the current load on the instance, and the EBS volume type. During this time, your instance remains available, but there might be a slight performance dip as the filesystem is being expanded.
The most surprising thing about RDS storage autoscaling is that it’s not a "set it and forget it" feature if you’re not paying attention to your growth rate. While it will grow your disk, it’s a reactive process. If your data grows faster than the autoscaling can keep up, you’ll eventually hit a "storage full" state, leading to write errors and potential application downtime. RDS will stop accepting writes to prevent data corruption when the disk is truly full.
The actual levers you control are:
- Storage Type:
gp2,gp3,io1,io2, etc.gp3is generally the most cost-effective and flexible, allowing independent scaling of IOPS and throughput without needing to provision more storage. - Provisioned Storage: The initial size you set. Autoscaling adds to this.
- Storage Autoscaling Toggle: You can enable or disable this feature. It’s enabled by default for most new RDS instances.
- Max Storage Threshold: You can set a maximum storage threshold (e.g., 90% of provisioned storage) that, if reached, will trigger an alert but not automatically scale. This is a safety mechanism to prevent runaway scaling or to force manual intervention.
The one thing most people don’t realize is that while RDS automatically requests the increase, the actual filesystem resize within the instance can sometimes lag slightly behind the EBS volume modification, especially on older instance types or under heavy I/O. This is why you might see metrics showing the EBS volume is larger, but df -h on the instance still reports the old size for a short period. RDS’s internal orchestration layer manages this, but it’s a point of potential confusion if you’re expecting immediate, synchronous changes.
The next problem you’ll likely encounter is understanding how to optimize your storage costs by choosing the right storage type and performance characteristics (IOPS/throughput) for your workload, especially with gp3 volumes.