Amazon RDS の DB インスタンスに対してストレージ関連の変更を行うと、インスタンスのステータスが
optimizing や storage-optimization と表示されることがあります。
どうしてこのステータスになるのか、このステータス中はシステムは何をしているのか、このステータスにならないようにするにはどうしたら良いのか、など、公式サイトから情報を得て整理してみます。
RDS のステータスが optimizing / storage-optimization のまま長時間続くのは何をしているのか？
この状態は、
RDS が内部的にストレージレイアウトの再構成やボリューム最適化をバックグラウンドで実行している状態
を意味します。
重要なのは、
- DB インスタンス自体は Available（利用可能）
- アプリケーションからの接続も 継続可能
- ただし I/O 性能が一時的に低下する可能性あり
という点です。
つまり、
サービス停止はしないが、ストレージ最適化処理とワークロードがディスク帯域を奪い合うためパフォーマンスが落ちる
という「止まらない代わりに遅くなる」フェーズです。
この最適化処理は数時間で終わることが多いですが、ストレージ容量や変更内容によっては 24時間以上継続する場合もある と AWS 公式ドキュメントでも説明されています。
optimizing / storage-optimization はどうして起きるのか？
AWS 公式ドキュメント上、DB インスタンスが storage-optimization ステータスになる典型的なトリガーは以下です。
ストレージ変更系の操作
| 変更内容 | storage-optimization |
|---|---|
| ストレージ容量の変更 | 発生する |
| ストレージタイプ変更（gp2 → gp3 等） | 発生する |
| Provisioned IOPS の変更 | 発生する場合あり |
| Throughput の変更 | 発生する場合あり |
例えば：
- Allocated storage の増加
- gp2 → gp3 への移行
- io1 → gp3 への変更
- IOPS や throughput の調整
などを行った場合、RDS は内部的に
- ボリュームの再配置
- データブロックの最適化
- I/O レイアウトの再構築
を行うため、storage-optimization フェーズに入ります。
さらに厄介なケース：Storage Autoscaling
手動で何も変更していないのに optimizing が始まる というケースの多くはこれです。
Storage Autoscaling が有効になっている場合、FreeStorageSpace が一定条件を下回る（例：空き容量 10% 未満が数分継続）と、RDS が自動的にストレージ拡張を開始します。
この「自動ストレージ変更」も Modify 操作として扱われるため、storage-optimization がバックグラウンドで開始される、という挙動になります。
つまり、
「何も変更してないのに optimizing が数時間続く」
という現象は、autoscaling が裏で走っていた 可能性が高いです。
インスタンスタイプ変更で optimizing は起きるのか？
DB instance class（CPU / メモリ）の変更については、storage-optimization の公式トリガーには含まれていません。
AWS の説明でも、
storage optimization はストレージサイズ変更やボリュームタイプ変更などを行った場合に発生する
と明記されています。
つまり、
- インスタンスタイプ変更 → 再起動（または Multi-AZ フェイルオーバー）による 短時間の停止はあり得る
- しかし、何時間も続く optimizing フェーズは本来発生しない
というのが公式仕様上の整理になります。
optimizing / storage-optimization を避けるには？
本番環境で「数時間の性能劣化」を避けたい場合、実務的に重要なのは以下です。
① ストレージ変更とインスタンス変更を絶対に同時にやらない
Modify DB Instance の操作で、
- DB instance class
- Allocated storage
- Storage type
- IOPS
- Throughput
などを 一度に変更すると、storage-optimization がトリガーされる可能性があります
したがって、
- 今回は instance class のみ変更
- ストレージ系パラメータには一切触れない
という形で変更リクエストを分離するのが安全です。
② Storage Autoscaling の暴発を防ぐ
autoscaling が有効な状態だと、インスタンスタイプ変更の直前・直後に
- 空き容量が閾値を下回る
- 自動ストレージ拡張が発動
という最悪のタイミング事故が起こり得ます。その結果、
インスタンスタイプ変更のつもりが storage-optimization が数時間発生
という事態になります。
対策としては：
- FreeStorageSpace に十分な余裕がある状態で作業する
- もしくは作業ウィンドウ中のみ autoscaling を一時的に無効化する
といった方法が現実的です。
まとめ
optimizing / storage-optimizationはストレージ内部最適化処理- DB は利用可能だが I/O 性能は低下する可能性あり
- 数時間〜24時間以上継続する場合がある
- 原因は基本的にストレージ変更操作（手動 or autoscaling）
- インスタンスタイプ変更のみでは通常発生しない
- 変更操作は「Compute」と「Storage」で分離するのが重要
参考サイト
Viewing instance status - Amazon Relational Database Service
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/accessing-monitoring.html
Amazon RDS now has a progress indicator for the storage optimization process - AWS
https://aws.amazon.com/about-aws/whats-new/2023/07/amazon-rds-progress-indicator-storage-optimization-process/
The database instance goes through a storage optimization state when you modify the instance for requests such as increasing the storage size or changing the storage volume type.
Troubleshoot an RDS DB stuck in storage optimization | AWS re:Post
https://repost.aws/knowledge-center/rds-stuck-in-storage-optimization
When you modify the storage size of your Amazon RDS DB instance, the instance enters the storage-optimization state.
… storage optimization completes in a few hours, but the process can take more than 24 hours.
The instance is operational during storage optimization and your application is still available.