これは何

2026年5月からのAmazon RDS「マグネティックボリューム」廃止に向けた対応事例です。
移行のために本番環境と同スペックの検証環境を構築して移行にかかる時間を計測しましたが、本番環境で実施したところ、検証時に比べ約2倍の時間を要しました。

今回実施したストレージタイプ変更作業の概要と本事象についてのAWSサポートからの回答についてまとめました。

対象RDSの情報

対象となったリソースの基本情報は以下の通りです。検証環境は、本番環境のスナップショットから復元し、インスタンスサイズ、AZ、ストレージ量など同一条件になるよう設定して検証を行いました。

項目  詳細
DBエンジン Amazon RDS (PostgreSQL)
インスタンスクラス db.m5.2xlarge
移行前ストレージ マグネティック
移行後ストレージ gp3
ストレージ容量 500 GiB
AZ マルチAZ

大まかな手順

本番環境への影響を抑えて移行を行うために以下の5ステップで実施しました。

1.本番環境からスナップショットを取得
本番環境のRDSからスナップショットを取得します。

2.本番環境のスナップショットから復元し、本番環境と同様のスペックで検証環境を起動
取得したスナップショットから復元し、インスタンスサイズ、AZ、ストレージ容量など、本番環境と同じ条件で検証環境を起動します。

3.検証環境のストレージタイプを移行、完了までに要する時間を計測
検証環境のストレージタイプの変更（マグネティック → gp3）を行い、完了までの所要時間を計測します。今回の結果は約2時間40分。

4.動作確認問題ないことを確認して、検証環境を削除
その後、アプリケーションからの接続や動作に問題がないことを確認し、不要になった検証環境のRDSは削除します。

5.本番環境に適応する
検証環境での手順と計測時間を踏まえ、本番環境でストレージタイプの変更（マグネティック → gp3）を実施します。ステータスが利用可能になることを確認します。本番環境で変更に要した時間は約5時間でした。

所要時間の比較

検証環境と本番環境では所要時間に約2倍の差がありました。

検証環境 本番環境
約2時間40分 約5時間

なぜ所要時間に差が出たのか

ナレッジを検索しても同様の事象が見受けられず、AWSサポートへ問い合わせをしました。
結論としては「AWS基盤側のリソース状況によるものであり、想定範囲内の正常な挙動」とのことでした。

  • 本番環境の処理時間は正常範囲内

AWS側の内部ログ調査の結果、本番環境で要した約5時間という時間は、エラーや遅延によるものではなく、AWS側が想定している処理時間の範囲内であり、異常はありませんでした。

  • AWS基盤側のリソース状況による影響

ストレージ変更処理に要する時間は、データ量やワークロード特性だけでなく、AWS基盤側の負荷状況の影響を受けます。そのため、全く同じスペックの環境であっても、検証時と同等の時間で完了するとは限りません。

  • 検証環境のログ消失による比較困難

今回は検証環境を削除してから日数が経過しており、AWS側の内部ログ保持期間を過ぎていたため、両環境の比較調査（具体的な原因特定）までは実施できませんでした。

最後に

同じスペックで検証環境を立てたので、本番環境も大体同じ時間で終わると思い込んでいました。
AWSの基盤側でのリソース状況も踏まえた上で、サービス影響が出る環境にはスケジュールを提案する必要があると改めて再認識しました。
特に今回のようなストレージタイプの変更は、一度開始すると完了するまで他の変更操作ができなくなります。一時的に、通常時よりもサイトの表示速度やレスポンスが一時的に低下する可能性もあり、サービスにも影響します。
これからマグネティックボリュームからの移行計画を立てる方は、検証環境での変更完了までの所要時間に対して、十分に余裕を持たせたバッファを確保することを推奨します。

同様の事象に遭遇した方の参考になれば幸いです！