I am looking to increase storage of two RDS instances (just the storage space allocated, not the instance type or other parameters). The documentation at https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting suggests:

You can change from standard storage to Provisioned IOPS storage, or from Provisioned IOPS to standard storage, as well as increase storage, with little to no downtime.

I would definitely schedule a maintenance window before performing the change. But the documentation seems a little vague in this area. For someone who might have done this before, what is "little to no downtime"? Can I expect 5 seconds or is it more like 5 minutes?

Update July, 2019:

I've updated the link to the correct and updated AWS documentation (which was broken). The newer documentation has a blurb that helps answer the original question as well:

In most cases, scaling storage doesn't require any outage and doesn't degrade performance of the server. After you modify the storage size for a DB instance, the status of the DB instance is Storage-optimization. The DB instance is fully operational after a storage modification. However, you can't make further storage modifications either for six hours or while the DB instance status is storage-optimization, whichever is longer.

However, a special case is if you have a SQL Server DB instance and haven't modified the storage configuration since November 2017. In this case, you might experience a short outage of a few minutes when you modify your DB instance to increase the allocated storage. After the outage, the DB instance is online but in the Storage-optimization state. Performance might be degraded during storage optimization.

2 Answers 2


First, note that you may be looking at the incorrect operation -- you describe that you want to change storage size, but have quoted documentation describing storage type. This is an important distinction: RDS advises that you won't experience an outage for changing storage size, but that you will experience an outage for changing storage type.

Expect degraded performance for changing storage size, the duration and impact of which will depend on several factors:

  • Your RDS instance type
  • Configuration
  • Will this occur during maintenance?
  • Will these changes occur first on your Multi-AZ slave, and then failover?
  • Current database size
  • Candidate database size
  • AWS capacity to handle this request at your requested time of day, at your requested availability zone, in your requested region
  • Engine type (for Amazon Aurora users, storage additions are managed by RDS as-needed in 10 GB increments, so this discussion is moot)

With this in mind, you would be better served by testing this yourself, in your environment, and on your terms. Try experimenting with the following:

  • Restoring a new RDS instance from a snapshot of your existing instance, and performing this operation on the new clone.
  • With this clone:
    • Increase the size at different times of day, when you would expect a different load on AWS.
    • Increase to different sizes.
    • Try it with multi-AZ. See if your real downtime changes as compared to not enabling multi-AZ.
    • Try it during a maintenance window, and compare it with applying the change immediately.

This will cost a bit more (it doesn't have to... you could do most of that in 1-3 instance-hours), but you will get a much cleaner answer than peddling for our experiences in a myriad of different RDS environments.

If you're still looking for a "ballpark" answer, I would advise to plan for at least performance degradation in the scope of minutes, not seconds -- again dependent very much on your environment and configuration.

For reference, I most recently applied this exact operation to add 10GB to a 40GB db.m1.small type instance on a Saturday afternoon (in EST). The instance remained in a "modifying" state for approximately 17 minutes. Note that the modifying state does not describe real downtime, but rather the duration that the operation is being applied. You won't be able to apply additional changes to the actual instance (although you can still access the DB itself) and this is also the duration that you can expect any performance degradation to occur.

Note : If you're only planning on changing the storage size an outage is unexpected, but note that it can occur if this change is made in conjunction with other operations like changing the instance identifier/class, or storage type.

  • The last paragraph is pretty much what I was after. That helps a lot. Thanks!
    – Andy Shinn
    Commented Jul 17, 2014 at 14:00
  • 4
    I'm over an hour for adding 10GB to a 10GB m3.xlarge DB at 3AM when there is barely any traffic.
    – Neo
    Commented Apr 1, 2015 at 6:58
  • 2
    One more datapoint, confirming ~linear. It took 2 hours and 50 minutes to add 100G to a 300G DB.
    – Joan Smith
    Commented Feb 6, 2016 at 3:35
  • 3
    Increasing 10G capacity to 100G capacity took only 23 minutes for me, on a db.t2.small with General Purpose (SSD) and MultiAZ. Also note, if you are increasing the size because the DB is already FULL, it will remain non-functional till the operation has finished.
    – davur
    Commented May 8, 2016 at 1:51
  • 2
    Increasing from 100 to 200GB of PIOPS storage under load, ~10am pacific, took about 30 minutes and did not significantly affect throughput/latency. (Read/write IOPS spiked significantly during this time.) Commented Aug 3, 2016 at 19:23

As you are only increasing storage size and not changing the instance type or anything else there shouldn't be any downtime, but there could be 'degraded performance' while the operation is carried out.

The reference you quoted is ambiguous because it's discussing changing the storage type at the same time as it discusses changing storage size. If you instead look at 'Allocated Storage' in the table here:


you'll see that it only says "Performance may be degraded" and nothing about an outage (which it says occurs in some cases when switching storage type).

For reference, when changing a 15GB db.m3.medium MySQL database to be 20GB in eu-west-1 during the working day, my app's connectivity to the database was uninterrupted. However, read/write IOPS both increased to between 400-700/s for just under 20 minutes, hence the references to degraded performance I suppose. This was reported for both single-AZ and multi-AZ database instances. (The instance was reported as 'modifying' for a little longer than this -- about 25 minutes.)

Naturally you can try it out on a db instance identical to your production db before doing it on your production db instance so you can safely see how it behaves in your situation before doing it for real.

  • 1
    Changing the storage type (Magnetic <-> gp2/provisioned IOPS) will result in an outage. Growing a volume, changing gp2 <-> provisioned IOPS, or adjusting provisioned IOPS should not result in an outage. You cannot shrink a volume.
    – notpeter
    Commented Aug 12, 2015 at 23:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .