EBSボリューム選定の実務 — IOPS・スループット・コストの決め方

「とりあえずgp2の100GB」で作ったボリュームが、本番稼働後に突然遅くなる——EBSまわりの相談で最も多いパターンです。原因はほぼ毎回同じで、IOPS・スループット・バーストの仕組みを踏まえずにサイズだけで選んでいること。この記事では、SIerの現場でそのまま使える選定の型を、ハマりどころ2つ（バーストクレジットとインスタンス側の帯域上限）と合わせて整理します。

01結論から：新規は「まずgp3」、gp2はもう選ばない

gp3は容量と無関係に3,000 IOPS・125 MB/sがベースラインで保証され、必要なら性能だけを最大80,000 IOPS・2,000 MiB/sまで個別に追加購入できます（160GiB以上で最大IOPS、8,000 IOPS以上かつ16GiB以上で最大スループットに到達します）。しかも単価はgp2より約2割安い。一方gp2は「3 IOPS/GB」の容量連動で、100GBなら300 IOPSしかなく、足りない分をバーストクレジットで凌ぐ設計です。

つまりgp2で性能を確保するには容量を水増しする（1TB積んで3,000 IOPS）しかありませんでしたが、gp3では容量と性能を別々に買えます。新規でgp2を選ぶ理由は、もうありません。

02IOPSとスループットは「両方」見る — ブロックサイズの罠

IOPS（1秒あたりのI/O回数）とスループット（1秒あたりの転送量）は、ブロックサイズで結ばれています。おおまかに「スループット ≒ IOPS × ブロックサイズ」です。

• DBのランダムアクセス（8〜16KiB）：16KiB × 3,000 IOPS ≒ 47 MB/s → IOPSが先に上限に当たる
• バッチのシーケンシャル読み書き（1MiB）：125 MB/s ÷ 1MiB ≒ 125 IOPS → スループットが先に上限に当たる

「IOPSを16,000まで上げたのに速くならない」という相談の正体は、たいていこれです。大きなファイルを流すワークロードで詰まっているのはスループット側なので、gp3ならスループットの方を増やします（IOPSとは独立に設定できます）。

03ボリュームタイプの使い分け早見

• gp3（汎用SSD） — 基本これ。OS領域、アプリ、中規模までのDB。3,000 IOPS/125 MB/sで足りなければ性能だけ追加
• io2（プロビジョンドIOPS SSD） — gp3の上限（80,000 IOPS・2,000 MiB/s）でも足りない大規模DB、またはIOPSあたりの安定したレイテンシがSLA要件になる基幹系。Block Expressなら最大256,000 IOPSまで
• st1（スループット最適化HDD） — ログ集約、大容量のシーケンシャル処理。安いがランダムI/Oは苦手。ブートボリューム不可
• sc1（コールドHDD） — ほぼアーカイブ。アクセス頻度が低い大容量データのみ

迷いどころは「gp3を増強するか、io2にするか」です。目安として、必要IOPSが80,000以内で収まるならgp3の追加購入が圧倒的に安く、超えるか、コンプライアンス上の耐久性要件（io2 Block Expressの年間故障率(0.001%)はgp3(0.2%)より2桁低い）があるならio2です。

04見落とし①：インスタンス側のEBS帯域上限

ボリュームをいくら速くしても、その手前のインスタンス側にEBS帯域の上限があります。ここがこの記事でいちばん伝えたいハマりどころです。

特に注意すべきは、小さめのインスタンスの帯域が「バースト値」で表記されている点です。例えばm5.largeのEBS帯域はスペック表では4,750 Mbpsですが、これは30分程度のバースト値で、ベースラインは650 Mbps（約81 MB/s）です。夜間バッチが30分を超えて走ると、途中から速度がベースラインに落ちる——「最初は速いのに途中から遅くなる」の典型原因です。

05見落とし②：既存gp2のバーストクレジット枯渇

既存環境でgp2が残っている場合、監視すべきはBurstBalanceメトリクスです。100%から減り始めているボリュームは、ピーク時にベースライン（3 IOPS/GB）を超えるI/Oをクレジットで賄っている状態で、枯渇した瞬間に性能がベースラインまで急落します。しかも枯渇は「業務が最も忙しい時間帯」に起きます。クレジットを消費するのがまさにその時間帯だからです。

対処はシンプルで、gp3への変更です。EBSはオンラインでタイプ変更でき（Elastic Volumes）、インスタンスを止めずに移行できます。性能は容量非依存のベースラインになり、料金も下がる。既存環境の棚卸しで最初にやる価値がある改善です。

06測ってから決める：最低限の手順

• 既存環境の実測 — CloudWatchでVolumeReadOps/WriteOps（→IOPS）、VolumeReadBytes/WriteBytes（→スループット）、VolumeQueueLength（滞留）、gp2ならBurstBalanceを2週間分。ピークの数字で設計します
• 新規構築の事前検証 — fio等でアプリのI/Oパターン（ブロックサイズ・ランダム/シーケンシャル比率）を模したベンチマークを検証環境で。カタログ値ではなく自分のワークロードで確認
• QueueLengthの目安 — 恒常的に高い（目安として1ボリュームあたり数以上が張り付く）なら、IOPSかインスタンス帯域のどちらかが足りていません

07コストの目安と削減の定石

• gp2 → gp3 一括移行：単価差でストレージ費用が約2割下がり、性能は容量非依存で安定。リスクの低い削減策の筆頭
• 使っていないボリューム・古いスナップショットの棚卸し：デタッチされたまま課金され続けるボリュームは、どの環境にも必ずあります
• io2は「本当に必要な範囲だけ」：DBのデータ領域はio2、ログ領域はgp3、のようにボリュームを分けると総額が大きく変わります

料金の最新値は公式料金表で確認してください（本記事の数値は2026年7月時点の仕様に基づきます）。

—まとめ：選定の型

①新規はgp3から。②アプリのI/Oパターン（ブロックサイズ）でIOPS型かスループット型かを見極める。③ボリュームだけでなくインスタンス側の帯域ベースラインを必ず確認する。④既存gp2はBurstBalanceを見て、枯渇の気配があれば無停止でgp3へ。⑤カタログ値ではなく、CloudWatchとfioの実測で決める。この5つを押さえれば、EBS起因の「本番で急に遅い」はほぼ防げます。