gp3のIOPS上限は80,000、スループット上限は2,000 MiB/s。AWSが2025年9月に、16,000 IOPS / 1,000 MiB/s から引き上げた値です。ただ、そこまで引き出せるかどうかはボリューム側だけでは決まりません。
gp3はサイズと性能が切り離されている
公式ドキュメントの “gp3 volume performance” 節は、gp3のベースラインをこう定義しています。
gp3 volumes deliver a consistent baseline IOPS performance of 3,000 IOPS, which is included with the price of storage.
1 GiBのgp3でも3,000 IOPSが出る。ここがgp2との決定的な差です。
ベースラインの3,000 IOPSと125 MiB/sは追加課金なし
gp3はストレージ料金の中に3,000 IOPSと125 MiB/sが含まれています。しかもGiBあたりの単価はgp2より20パーセント安い。同じ節のTipが「gp3はバースト性能を使わない」と言い切っているとおり、プロビジョニングした値を無期限で出し続けられます。3,000 IOPSを24時間流しても落ちない。
追加分は500 IOPS/GiBの比率で決まる
3,000を超える分は追加課金でプロビジョニングします。上限は80,000 IOPSですが、サイズとの比率に 500 IOPS per GiB という制約がかかる。つまり80,000 IOPSを取るには160 GiB以上が要ります(500 × 160 = 80,000)。
gp2の3 IOPS/GiBと比べると比率は約167倍になります。gp2で16,000 IOPSを出すには5,334 GiBが必要でしたが、gp3なら32 GiBで届きます。
スループットは1 IOPSあたり0.25 MiB/s
スループットはサイズではなくプロビジョニングIOPSに紐づきます。比率は 0.25 MiB/s per provisioned IOPS、上限2,000 MiB/s。上限に届く条件は8,000 IOPS以上かつ16 GiB以上です。
2,000 MiB/s ÷ 0.25 MiB/s per IOPS = 8,000 IOPS
8,000 IOPS ÷ 500 IOPS per GiB = 16 GiBAWS Outpostsのgp3だけは上限が別で、サイズ16 TiB・16,000 IOPS・1,000 MiB/sに据え置かれています。この条件が載るのはボリュームタイプ一覧の脚注6と、”gp3 volume performance” 節末尾のNoteの2箇所だけ。表を眺めているだけでは拾えません。
gp2はサイズが性能を決める
gp2は3 IOPS/GiBでベースラインが線形に伸びます。33.33 GiB以下は最低値の100 IOPS、5,334 GiBで上限の16,000 IOPSに達します。それを下から支えるのがI/Oクレジットのバケットです。
540万クレジットは3,000 IOPSを約30分
ボリュームはI/O需要がベースライン以下のとき、1 GiBあたり毎秒3クレジットを貯めます。貯められる上限は540万クレジットです。この量が、公式の “gp2 volume performance” 節にある「最大バースト性能の3,000 IOPSを少なくとも30分維持できる」という表現の根拠です。
消費レートはバーストIOPSからベースラインIOPSを引いた値になります。100 GiB(ベースライン300 IOPS)で3,000 IOPSを出し続けると毎秒2,700クレジット減る計算で、公式の表は持続時間を2,000秒としています。
| サイズ(GiB) | ベースライン | 3,000 IOPSの持続 | 空から満タンまで |
|---|---|---|---|
| 1〜33.33 | 100 IOPS | 1,862秒 | 54,000秒(15時間) |
| 100 | 300 IOPS | 2,000秒 | 18,000秒(5時間) |
| 750 | 2,250 IOPS | 7,200秒 | 2,400秒(40分) |
| 1,000 | 3,000 IOPS | 該当なし | 該当なし |
効いてくるのは復帰の遅さ。33 GiBのボリュームでクレジットを使い切ると、満タンに戻るまで15時間かかります。夜間バッチで枯らすと、翌朝の処理は100 IOPSで走る。
1,000 GiBを超えるとバーストは関係なくなる
1,000 GiBでベースラインが3,000 IOPSに達し、バースト上限と並びます。それ以上のサイズではベースラインがバーストを上回るため、クレジットという仕組み自体が効かなくなる。公式の表でも1,000 GiB以降は持続時間が「N/A」です。
ボリュームタイプを数値で並べる
選定で見る数値だけを抜き出します。
| タイプ | 最大IOPS | 最大スループット | サイズ | 耐久性 | ブート |
|---|---|---|---|---|---|
gp3 | 80,000 | 2,000 MiB/s | 1 GiB〜64 TiB | 99.8〜99.9% | 可 |
gp2 | 16,000 | 250 MiB/s | 1 GiB〜16 TiB | 99.8〜99.9% | 可 |
io2 Block Express | 256,000 | 4,000 MiB/s | 4 GiB〜64 TiB | 99.999% | 可 |
io1 | 64,000 | 1,000 MiB/s | 4 GiB〜16 TiB | 99.8〜99.9% | 可 |
st1 | 500 | 500 MiB/s | 125 GiB〜16 TiB | 99.8〜99.9% | 不可 |
sc1 | 250 | 250 MiB/s | 125 GiB〜16 TiB | 99.8〜99.9% | 不可 |
HDD系はブートボリュームに使えない
st1とsc1はブートボリュームに使えません。既存のルートボリュームをこの2つへ変更することもできない。Elastic Volumesの “Limitations” 節は、この禁止に「インスタンスからデタッチしていても」という条件を付け足しています。外してもタイプは変えられない。
io2は2025年4月30日から全てBlock Express
io2とio2 Block Expressは、現在は区別が要りません。公式の “Considerations” 節が、2025年4月30日をもって新規・既存を問わず全てのio2ボリュームがBlock Expressになったと明記しています。耐久性99.999%を年間故障率に直すと、gp3の「1,000ボリュームあたり年2本」に対してio2は「100,000ボリュームあたり年1本」になります。
実効性能はインスタンス側の上限で決まる
gp3に2,000 MiB/sをプロビジョニングしても、m5.largeにアタッチした場合は81.25 MB/sしか出ない時間帯があります。ボリュームの上限とインスタンスのEBS帯域は別物で、AWSは小さい方を適用するためです。
m5.largeのベースラインは650 Mbps
EBS最適化インスタンスの表は、小さいサイズについてベースラインと最大の2段を持ちます。m5.largeの数値を並べます。
| 帯域 | スループット(128 KiB I/O) | IOPS(16 KiB I/O) | |
|---|---|---|---|
| ベースライン | 650 Mbps | 81.25 MB/s | 3,600 |
| 最大 | 4,750 Mbps | 593.75 MB/s | 18,750 |
gp3のベースライン125 MiB/sは、MB/sに直すと131.1 MB/s。m5.largeのベースライン81.25 MB/sの方が小さい。一方でIOPSは3,600対3,000とインスタンス側が上回ります。IOPSは足りているのに、スループットが先に頭打ちになる。
30分のバーストを使い切った後
m5.largeは最大4,750 Mbpsを出せますが、無制限ではありません。EBS最適化インスタンスの表の脚注が持続条件を規定しています。
These instances can sustain the maximum performance for 30 minutes at least once every 24 hours, after which they revert to their baseline performance.
24時間に少なくとも1回、30分。使い切ればベースラインへ戻ります。しかもその最大値ですら593.75 MB/sで、gp3の上限2,000 MiB/s(=2,097 MB/s)の28%にしかなりません。m5.4xlarge以上のサイズには別の脚注が付き、こちらは無期限で維持できる。長時間のI/Oを流すなら、インスタンスサイズの選定がストレージ設計の一部になります。この階層のしくみはEC2インスタンスタイプの命名規則と購入オプションで扱った、t3のCPUクレジットと同じ発想です。
ボリュームとインスタンスのどちらが詰まっているか
切り分けにはCloudWatchのメトリクスを使います。ただし平均値のメトリクスは当てになりません。
VolumeIOPSExceededCheck/VolumeThroughputExceededCheckは、1分の中の1秒でもプロビジョニング値を超えたら1を返すVolumeAvgIOPS/VolumeAvgThroughputは1分平均のため、数秒のマイクロバーストを平準化して見落とすBurstBalanceが対象にするのはgp2・st1・sc1の3つ。バーストを使わないgp3とio2にバケットは無い
gp3で「たまに遅い」が起きるとき、VolumeThroughputExceededCheck が 0 のままならボリュームは上限に触れていない。その場合はインスタンスのEBS帯域か、そもそもI/Oを流し切れていないアプリ側を疑う順番になります。
IOPSの目安はI/Oサイズから逆算する
「3,000 IOPSあれば足りるか」は、I/O 1回のサイズを決めないと答えが出ません。
SSDの1 I/Oは最大256 KiB
公式の “IOPS” 節によると、AWSは1回のI/Oとしてカウントする上限をSSDで256 KiB、HDDで1,024 KiBに定めています。この閾値を境に、小さいI/Oはマージされ、大きいI/Oは分割される。
| アプリ側のI/O | SSDでのカウント | 挙動 |
|---|---|---|
| 1,024 KiB × 1回 | 4 IOPS | 256 KiBずつ4分割 |
| 32 KiB × 8回(連続) | 1 IOPS | 256 KiBに結合 |
| 32 KiB × 8回(ランダム) | 8 IOPS | 結合されない |
連続かランダムかで8倍違う。ベンチマークツールの数字をそのまま見積もりに使うと、この差で外します。
256 KiBのI/Oは1,000 IOPSでスループット上限に当たる
“I/O size and volume throughput limits” 節に、この計算の例が載っています。1,000 GiB未満でクレジットが残っているgp2は3,000 IOPS・250 MiB/sが上限ですが、I/Oサイズが256 KiBの場合、1,000 IOPS(1,000 × 256 KiB = 250 MiB)でスループット側に先に当たります。IOPSは2,000残っているのに使えない。
逆にI/Oサイズが16 KiBなら、3,000 IOPSでもスループットは46.9 MiB/sで余裕があります。
キューの深さは1,000 IOPSにつき1
プロビジョニングした性能を出し切るには、アプリ側が十分なI/Oを投げ続ける必要があります。公式は目安をこう書いています。
For maximum consistency, a volume must maintain an average queue depth (rounded to the nearest whole number) of one for every 1,000 provisioned IOPS in a minute.
3,000 IOPSのボリュームなら平均キュー深度3。シングルスレッドで同期I/Oを回している構成では、キューが1のままでプロビジョニング分を使い切れません。IOPSを上げる前に、アプリの並列度を確認する。
ボリュームタイプ変更にダウンタイムは要らない
Elastic Volumesを使えば、アタッチしたままタイプ・サイズ・IOPS・スループットを変えられます。インスタンスの停止もデタッチも不要。
Process overview でも1番目に置かれている(任意扱い)aws ec2 modify-volume で変更を要求し、describe-volumes-modifications で completed まで追うmodify-volumeと状態遷移
公式ドキュメントは、100 GiBのgp2を200 GiB・10,000 IOPSのio1へ変える例を載せています。
aws ec2 modify-volume \
--volume-id vol-01234567890abcdef \
--volume-type io1 \
--iops 10000 \
--size 200ドキュメントに載っている応答がこれです。
{
"VolumeModification": {
"TargetSize": 200,
"TargetVolumeType": "io1",
"ModificationState": "modifying",
"VolumeId": "vol-01234567890abcdef",
"TargetIops": 10000,
"StartTime": "2022-01-19T22:21:02.959Z",
"Progress": 0,
"OriginalVolumeType": "gp2",
"OriginalIops": 300,
"OriginalSize": 100
}
}ModificationState は modifying → optimizing → completed と遷移します。サイズ増加が効くのは optimizing に入った時点で、ここは数秒で済みます。対して性能変更は数分から数時間かかり、1 TiBのフル使用ボリュームで約6時間が目安と書かれています。optimizing の間、性能は変更前を下回りません。
24時間に4回、サイズは縮小できない
“Considerations” 節と “Limitations” 節に制約がまとまっています。運用で引っかかるのはこのあたり。
- 直前の変更が
completedになるまで次の変更を出せない。加えてローリング24時間で4回まで - サイズは増加のみ。縮小したい場合は小さいボリュームを作って
rsyncやrobocopyでデータを移す - 変更要求は送信後にキャンセルできない
変更間隔にクールダウン時間の規定はありません。条件は completed 待ちと回数制限で、時間は出てこない。1 TiBで約6時間というのは変更処理そのものにかかる所要時間で、次の変更までの待ち時間ではありません。
gp2からgp3へIOPS未指定で変えたとき
タイプだけ指定してIOPSやスループットを省略すると、AWSが自動で値を決めます。判定は「元のgp2相当」と「gp3のベースライン」の高い方を取ります。
公式の例では、250 MiB/s・1,500 IOPSの500 GiB gp2を変換すると、gp3側は3,000 IOPS・250 MiB/sになります。IOPSは元の1,500ではなくベースラインの3,000が採用され、スループットは元の250 MiB/sがgp3ベースライン125 MiB/sを上回るのでそのまま引き継がれる。移行して性能が下がることはない代わりに、スループット125 MiB/s超の分は追加課金の対象になります。
まとめ
- gp3は3,000 IOPS・125 MiB/sがサイズ非依存で付く。追加分は500 IOPS/GiB、0.25 MiB/s per IOPSの比率で、上限は80,000 IOPS・2,000 MiB/s
- gp2はサイズがそのまま性能。33 GiBのボリュームはクレジットを使い切ると回復に15時間かかる
- 実効性能はボリューム上限とインスタンスのEBS帯域の小さい方。m5.largeのベースラインは81.25 MB/sで、gp3の125 MiB/sに届かない
- IOPSの見積もりはI/Oサイズ次第。SSDは256 KiBを1 I/Oとしてカウントし、連続I/Oは結合される
タイプ変更はダウンタイムなしで通りますが、24時間4回の上限とサイズ縮小不可という制約が残ります。移行の前にスナップショットを取っておけば、判断を間違えても戻せる。
