Amazon EBS gp2からgp3への移行ガイド｜EBSコストを20%削減する実践手順と注意点

「EBSの月額請求書を見たら、gp2ボリュームが積み重なって思った以上のコストになっていた」

オンプレ時代はストレージ＝資産で、一度買えば減価償却が終わるまで追加費用は出ませんでした。ところがクラウドに移行した途端、EBSは毎月きっちり請求されます。なかでも長年EC2のデフォルトだったgp2は、いつの間にか大量にぶら下がっていることが多く、コスト最適化の余地が残っているボリュームタイプの代表格です。

この記事では、Amazon EBSのgp2からgp3への移行について、オンプレ経験者にもわかりやすく解説します。なぜgp3に移行するとコストが下がるのか、性能面で何が変わるのか、実際のCLI手順、移行時にハマりやすい注意点までを一通りカバーします。

なぜgp2からgp3に移行するとコストが下がるのか

gp2とgp3は、どちらもEC2やRDSで標準的に使われるSSDベースの汎用ボリュームです。ただし料金体系と性能モデルに決定的な違いがあります。

1. 容量あたりの単価がgp3の方が安い

東京リージョン（ap-northeast-1）における2026年3月時点のEBS料金は以下のとおりです。

容量単価だけで比較すると、gp3はgp2より20%安くなります。例えば500GBのボリュームを10本運用している場合、gp2なら月額$600、gp3なら月額$480です。年間換算で$1,440の削減になります。

2. 性能と容量が分離している

gp2はIOPSが容量に縛られる設計でした。3,000 IOPSを出したければ1,000GB以上のボリュームを割り当てる必要があり、容量が不要でも性能のために大きくするしかなかったわけです。

gp3は容量と性能が完全に独立しています。100GBのボリュームでもベースで3,000 IOPSと125 MiB/sが保証され、さらに追加料金でIOPSは最大16,000、スループットは最大1,000 MiB/sまで個別に引き上げられます。必要な性能だけを買えるので、オーバープロビジョニングによる無駄が消えます。

3. 多くのワークロードでは追加性能が不要

gp3のベース性能である3,000 IOPS・125 MiB/sは、一般的なWebサーバーやアプリケーションサーバーでは十分なラインです。gp2時代に「性能確保のために容量を盛っていた」ケースでは、gp3に切り替えるだけで容量を縮小できる場合もあります。

移行前に確認すべきチェックポイント

「単価が安いならすぐ切り替えよう」と飛びつく前に、現在のgp2ボリュームの使用状況を把握しておく必要があります。

1. CloudWatchメトリクスで実際のIOPS・スループットを確認する

移行後の性能要件を見積もるため、過去2〜4週間のメトリクスを見ておきます。

・VolumeReadOps / VolumeWriteOps: 読み書きのIOPS（合計してベースラインを超えていないかを確認）
・VolumeReadBytes / VolumeWriteBytes: スループット（MiB/s換算）
・VolumeQueueLength: 慢性的に1を超えているとIO待ちが発生している

ピーク時でも3,000 IOPSと125 MiB/sに収まっていれば、gp3のベース性能のまま移行できます。超えているボリュームは、追加IOPS・追加スループットの料金を見込みます。

2. バーストクレジットに依存しているボリュームを洗い出す

gp2には「バーストクレジット」の仕組みがあり、小容量ボリューム（1,000GB未満）はクレジット消費で一時的に3,000 IOPSまで上げられます。クレジットが枯渇すると性能が一気に落ちるため、このバーストに救われていたワークロードは、gp3移行時にベース性能で安定するので実は改善するケースが多いです。

・BurstBalance: 頻繁に0%近くまで落ちているボリュームは、gp2のままだと不安定
・バースト依存のボリュームはgp3移行の優先候補

3. ルートボリュームとデータボリュームの扱いを分ける

ルートボリュームはOS再起動なしでタイプ変更可能ですが、変更中は一時的にIO性能が低下します。業務時間外に実施するのが無難です。データボリュームはマウント状態のまま変更できますが、念のためアプリケーション側のIO負荷が低いタイミングを選びます。

gp2からgp3への移行手順（AWS CLI）

EBSのボリュームタイプ変更は、無停止で実行できます。EC2インスタンスを止める必要はありません。

1. 対象ボリュームの一覧を取得する

まず現在のアカウント内にあるgp2ボリュームを洗い出します。AWS CLIで以下を実行します。

# AWS CLI: gp2ボリュームを一覧化
aws ec2 describe-volumes \
  --filters "Name=volume-type,Values=gp2" \
  --query 'Volumes[*].[VolumeId,Size,State,Attachments[0].InstanceId]' \
  --output table

2. 単一ボリュームをgp3に変更する

対象のボリュームID（vol-xxxxxxxx）を指定してボリュームタイプを切り替えます。ベース性能のままでよければVolumeTypeだけ指定します。

# AWS CLI: ボリュームタイプをgp3に変更
aws ec2 modify-volume \
  --volume-id vol-xxxxxxxxxxxxxxxxx \
  --volume-type gp3

# 追加IOPSとスループットが必要な場合
aws ec2 modify-volume \
  --volume-id vol-xxxxxxxxxxxxxxxxx \
  --volume-type gp3 \
  --iops 6000 \
  --throughput 250

3. 変更の進捗を監視する

modify-volumeは非同期で実行されます。進捗はdescribe-volumes-modificationsで確認できます。

# AWS CLI: 変更の進捗を確認
aws ec2 describe-volumes-modifications \
  --volume-ids vol-xxxxxxxxxxxxxxxxx \
  --query 'VolumesModifications[*].[VolumeId,ModificationState,Progress,TargetVolumeType]' \
  --output table

ModificationStateは「modifying」→「optimizing」→「completed」の順に遷移します。completedになれば完全に移行済みです。optimizing中でも新しいタイプの料金が適用されはじめるので、急いでいなければ放置でかまいません。

4. 複数ボリュームを一括変更する

アカウント内の全gp2ボリュームを一気に変換する場合は、シェルのループで処理します。

# bash: gp2ボリュームを全てgp3に変換
for vol in $(aws ec2 describe-volumes \
  --filters "Name=volume-type,Values=gp2" \
  --query 'Volumes[*].VolumeId' --output text); do
    echo "Converting $vol..."
    aws ec2 modify-volume --volume-id $vol --volume-type gp3
    sleep 1
done

同じボリュームに対して連続でmodify-volumeを発行するとエラーになるため、本番では1台ずつ完了を待ちながら進める方が安全です。大規模環境ではAWS Systems Manager Automationのランブックで制御する方法もあります。

料金の仕組みとコストシミュレーション

gp3の料金は「容量＋追加IOPS＋追加スループット」の足し算で決まります。東京リージョンの2026年3月時点の単価は以下のとおりです。

ケース1: 500GBの一般的なアプリケーションサーバー

・gp2: 500GB × $0.12 = $60/月
・gp3（ベース性能のまま）: 500GB × $0.096 = $48/月
・削減額: 月額$12（20%削減）

ケース2: 1TBで6,000 IOPSが必要なDBサーバー

・gp2: 1,000GB × $0.12 = $120/月（ベースで3,000 IOPS出るが、バーストに依存）
・gp3: 1,000GB × $0.096 + 3,000 IOPS × $0.006 = $96 + $18 = $114/月
・削減額: 月額$6（5%削減）だが、バースト枯渇の不安定さを回避できる

ケース3: 100GBで高IOPSが必要なワークロード

・gp2: 100GB × $0.12 = $12/月（ただしベースは300 IOPSしか出ない）
・gp3: 100GB × $0.096 = $9.6/月（ベースで3,000 IOPSが確保される）
・性能も上がり、コストも下がる典型的な勝ちパターン

応用・実務Tips

1. AWS Compute OptimizerでEBSの最適化候補を自動抽出する

全ボリュームを手動で分析するのは現実的ではありません。AWS Compute Optimizerを有効化しておくと、過去の使用状況からgp3への変更推奨やダウンサイジング提案を自動で出してくれます。コンソールの「EBSボリュームの推奨事項」から対象を絞り込めます。

2. Infrastructure as Codeで将来のデフォルトをgp3にする

TerraformやCloudFormationでEC2を管理している場合、テンプレート側のvolume_typeをgp3に統一しておきます。新規作成分がgp2に戻らないようにするのが、長期的なコスト管理では重要です。

# Terraform: EBSボリューム定義の例
resource "aws_ebs_volume" "data" {
  availability_zone = "ap-northeast-1a"
  size              = 500
  type              = "gp3"
  iops              = 3000
  throughput        = 125
  encrypted         = true
}

3. 6時間ルールに注意する

modify-volumeを実行したボリュームは、次に変更できるまで6時間のクールダウンがあります。サイズ変更・タイプ変更・IOPS変更すべて同じ制限にかかるので、変更はまとめて一度で実行するのが効率的です。

4. スナップショットからの復元時はgp3を指定する

EBSスナップショットから新しいボリュームを作る際、デフォルトは元のボリュームタイプと同じになります。復元コマンドで明示的にgp3を指定する癖をつけておきます。

よくあるトラブルと対処法

1. 「ModificationState: failed」で変更が失敗する

直前に同じボリュームの変更履歴がある場合、6時間ルールに引っかかって失敗します。describe-volumes-modificationsで最後の変更時刻を確認し、6時間経過してから再試行します。

2. 移行中にアプリケーションの性能が一時的に落ちる

modify-volume中は内部的にデータ再配置が走るため、IO性能が一時的に低下します。本番DBなど性能にシビアなボリュームは、業務時間外やメンテナンスウィンドウで実行します。optimizing状態の間も性能低下が続く可能性があるので、変更後数時間はCloudWatchで監視します。

3. RDSのgp2がgp3に変更できない

RDSのストレージタイプ変更はEC2のEBSとは別の手順です。modify-db-instanceコマンドで–storage-typeをgp3に指定します。ただしRDSは変更中にIOが停止する時間帯（通常数分〜十数分）が発生することがあるため、マルチAZ構成でのメンテナンスウィンドウ活用が推奨されます。

4. 変更してもコストが下がって見えない

AWSの請求は日割りで集計されるため、月途中の変更は翌月の請求書ではじめて効果が反映されます。AWS Cost Explorerで「ボリュームタイプ別」にフィルタリングすれば、gp2とgp3の課金比率の変化が確認できます。

本記事のまとめ

Amazon EBSのgp2からgp3への移行は、無停止で実行でき、単価だけで20%のコスト削減が見込める典型的な「すぐやるべき最適化」です。

・容量単価: gp3はgp2より20%安い（$0.12 → $0.096/GB/月）
・性能モデル: gp3は容量と性能が独立、100GBでも3,000 IOPSが標準
・移行コマンド: aws ec2 modify-volume で無停止変換
・注意点: 6時間のクールダウン、optimizing中の性能低下、RDSは別手順

オンプレ時代のストレージ感覚では「変えるのが怖い」と感じるかもしれませんが、EBSはインフラ側の属性を変えるだけで中身のデータには影響しません。まずは検証環境のgp2ボリュームで1本試してみて、手応えをつかんでから本番に展開するのが安全で確実な進め方です。

EC2上のLinuxサーバーのチューニングやディスクI/Oの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。