Amazon EBS gp3 ボリュームの性能上限が大幅に引き上がり、容量 4 倍、IOPS 5 倍、スループット 2 倍になりました
はじめに
2025 年 9 月 26 日 Amazon EBS gp3 ボリュームの性能上限が大幅に引き上げられました。 ボリュームサイズ、IOPS、スループットのすべてが強化されました。追加課金により、より高性能なストレージとしてご利用いただけます。
アップデート内容早見
更新内容
EBS gp3 ボリュームの性能上限が引き上げされた内容は以下のとおりです。
- ボリュームサイズ: 16 TiB → 64 TiB（4 倍）
- IOPS: 16,000 → 80,000（5 倍）
- スループット: 1,000 MiB/s → 2,000 MiB/s（2 倍）
何が嬉しいのか
ボリュームサイズ引き上げにより Oracle や SAP HANA などの大規模データベースや機械学習のワークロードで大量のデータを単一ボリュームで管理可能となりました。IOPS、スループットの上限値が引き上げられたことで、OLTP データベースのトランザクション処理、ETL 処理などの高負荷環境でも対応可能です。ElasticVolumes によりダウンタイムなしで動的変更可能で、既存環境の性能不足時のアップグレードが容易です（※ ディスクサイズの縮小は不可）。
費用感（東京リージョン、2025年9月時点）
追加の IOPS やスループットに対する従量課金は従来通りで変更ありません。
EBS gp3 の最大スペック（64 TiB、80,000 IOPS、2,000 MiB/s）のボリュームが 1 個の月額利用費の試算です。
| 項目 | 計算式 | 月額費用 |
|---|---|---|
| ストレージ料金 | 65,536 GiB × $0.096/GiB | $6,291/月 |
| 追加 IOPS 料金 | (80,000 - 3,000) × $0.006/IOPS | $462/月 |
| 追加スループット料金 | (2,000 - 125) × $0.048/MiB/s | $90/月 |
| 合計 | - | $6,843/月（約10万円/月） |
参考: ハイパフォーマンスブロックストレージの料金 – Amazon EBS の料金 – Amazon Web Services
IOPS とスループットを最大パフォーマンスにするためには
IOPS
最大 IOPS を利用するには、160 GiB 以上のボリュームサイズが必要です。（計算式: 500 IOPS/GiB × 160 GiB = 80,000 IOPS）
- ベースラインパフォーマンス: 3,000 IOPS（無料）
- 追加 IOPS: 最大 80,000 IOPS まで追加可能（有料）
- 補足: 1 GiB あたり 500 IOPS 追加可能
スループット
最大スループットを利用するには、8,000 IOPS 以上かつ 16 GiB 以上のボリュームが必要です。（計算式: 8,000 IOPS × 0.25 MiB/s/IOPS = 2,000 MiB/s）
- ベースライン性能: 125 MiB/s（無料）
- 追加スループット: 最大 2,000 MiB/s まで追加可能（有料）
- 補足: プロビジョニングされた 1 IOPS あたり 0.25 MiB/s 追加可能
インスタンスサイズも重要
インスタンスサイズの性能がボトルネックになる場合、EBS ボリュームのスペックを上げても性能改善が期待できません。例えば m8g.16xlarge の場合、最大スペックの gp3 ボリューム 1 個なら最大限活かせます。インスタンスタイプ、サイズごとの詳細は参考リンクのドキュメントをご確認ください。
| インスタンスタイプ | 最大帯域幅 (Mbps) | 最大スループット (MB/秒) | 最大 IOPS |
|---|---|---|---|
| m8g.16xlarge | 20,000 | 2,500 | 80,000 |
参考: Amazon EBS 最適化インスタンスタイプ - Amazon Elastic Compute Cloud
試してみた
最大スペックの gp3 ボリュームに負荷をかけて、フルパフォーマンスを引き出せるか検証してみます。
検証環境
| 項目 | 設定値 |
|---|---|
| OS | Ubuntu 24.04 LTS |
| インスタンスタイプ | m8g.16xlarge |
| ボリュームサイズ | 160 GiB |
| IOPS | 80,000（上限値） |
| スループット | 2,000 MiB/s（上限値） |
| リージョン | 北米リージョン（us-east-1） |
| 負荷テストツール | fio v3.36 |
最大スペックの gp3 ボリュームを作成し、EC2 にアタッチしました。
追加 EBS のマウント
最高スペックの gp3 は別ボリュームとして EC2 にアタッチしています。そのため手動でマウントします。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 24M 1 loop /snap/amazon-ssm-agent/11798
loop1 7:1 0 68.9M 1 loop /snap/core22/2049
loop2 7:2 0 42.9M 1 loop /snap/snapd/24787
nvme1n1 259:0 0 8G 0 disk
├─nvme1n1p1 259:1 0 7G 0 part /
├─nvme1n1p15 259:2 0 99M 0 part /boot/efi
└─nvme1n1p16 259:3 0 923M 0 part /boot
+ nvme0n1 259:4 0 160G 0 disk
sudo mkfs.ext4 /dev/nvme0n1
sudo mkdir -p /mnt/ebs
sudo mount /dev/nvme0n1 /mnt/ebs
sudo chown ubuntu:ubuntu /mnt/ebs
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 6.8G 1.8G 5.0G 27% /
tmpfs 124G 0 124G 0% /dev/shm
tmpfs 50G 1.5M 50G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
efivarfs 128K 3.1K 125K 3% /sys/firmware/efi/efivars
/dev/nvme1n1p16 891M 59M 770M 8% /boot
/dev/nvme1n1p15 98M 6.4M 92M 7% /boot/efi
tmpfs 25G 12K 25G 1% /run/user/1000
+ /dev/nvme1n1 157G 28K 149G 1% /mnt/ebs
負荷をかけてみる
fio でディスクに負荷をかけて CloudWatch のメトリクスから結果を確認します。
# 準備
sudo apt update
sudo apt install fio -y
# IOPS 負荷テスト（ランダムな書き込み）
fio -name=io_test -filename=/mnt/ebs/testfio.file -direct=1 -ioengine=libaio -rw=randwrite -bs=4k -size=10G -numjobs=64 -runtime=300 -group_reporting
# スループット負荷テスト（シーケンシャルな読み取り）
fio --name=throughput_test -filename=/mnt/ebs/testfio.file -direct=1 -ioengine=libaio -rw=read -bs=1M -size=10G -numjobs=64 -runtime=300 -group_reporting
実行結果
実行結果のサマリです。
| 測定項目 | ボリューム設定値 | 実測値 | 備考 |
|---|---|---|---|
| IOPS | 80,000 | 80,012 | 設定上限値に到達 |
| スループット | 2,000 MiB/s | 2,008 MiB/s | 設定上限値に到達 |
| レイテンシー（IOPS テスト） | - | 0.8ms | 4KB ランダム書き込み |
| レイテンシー（スループットテスト） | - | 14.6ms | 1MB シーケンシャル読み込み |
実行結果折りたたみ
io_test: (groupid=0, jobs=64): err= 0: pid=2097: Sun Sep 28 08:48:40 2025
write: IOPS=80.0k, BW=312MiB/s (328MB/s)(91.5GiB/300002msec); 0 zone resets
slat (nsec): min=1541, max=11437k, avg=3384.04, stdev=39161.96
clat (usec): min=409, max=12753, avg=796.37, stdev=111.26
lat (usec): min=414, max=15445, avg=799.76, stdev=119.34
clat percentiles (usec):
| 1.00th=[ 619], 5.00th=[ 676], 10.00th=[ 725], 20.00th=[ 734],
| 30.00th=[ 742], 40.00th=[ 791], 50.00th=[ 799], 60.00th=[ 807],
| 70.00th=[ 816], 80.00th=[ 865], 90.00th=[ 873], 95.00th=[ 922],
| 99.00th=[ 996], 99.50th=[ 1045], 99.90th=[ 1811], 99.95th=[ 2671],
| 99.99th=[ 4555]
bw ( KiB/s): min=285784, max=371275, per=100.00%, avg=320048.21, stdev=60.92, samples=38336
iops : min=71446, max=92806, avg=80012.03, stdev=15.23, samples=38336
lat (usec) : 500=0.13%, 750=31.73%, 1000=67.32%
lat (msec) : 2=0.74%, 4=0.07%, 10=0.02%, 20=0.01%
cpu : usr=0.25%, sys=0.52%, ctx=24010018, majf=0, minf=917
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,23995834,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=312MiB/s (328MB/s), 312MiB/s-312MiB/s (328MB/s-328MB/s), io=91.5GiB (98.3GB), run=300002-300002msec
Disk stats (read/write):
nvme0n1: ios=0/24006276, sectors=0/193722760, merge=0/209069, ticks=0/18888452, in_queue=18888452, util=99.99%
throughput_test: (groupid=0, jobs=64): err= 0: pid=2322: Sun Sep 28 08:55:59 2025
read: IOPS=2007, BW=2008MiB/s (2105MB/s)(588GiB/300015msec)
slat (usec): min=18, max=341817, avg=15388.34, stdev=20791.93
clat (usec): min=1979, max=50275, avg=14617.58, stdev=3093.31
lat (msec): min=2, max=354, avg=30.01, stdev=21.01
clat percentiles (usec):
| 1.00th=[ 7439], 5.00th=[ 9634], 10.00th=[11207], 20.00th=[13042],
| 30.00th=[13435], 40.00th=[13829], 50.00th=[14091], 60.00th=[14353],
| 70.00th=[14877], 80.00th=[17171], 90.00th=[19792], 95.00th=[20317],
| 99.00th=[21365], 99.50th=[22152], 99.90th=[25035], 99.95th=[26608],
| 99.99th=[32900]
bw ( MiB/s): min= 818, max= 4967, per=100.00%, avg=2156.30, stdev=10.93, samples=36094
iops : min= 818, max= 4966, avg=2156.04, stdev=10.92, samples=36094
lat (msec) : 2=0.01%, 4=0.08%, 10=5.76%, 20=86.58%, 50=7.58%
lat (msec) : 100=0.01%
cpu : usr=0.01%, sys=0.23%, ctx=2866716, majf=0, minf=17100
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=602398,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
READ: bw=2008MiB/s (2105MB/s), 2008MiB/s-2008MiB/s (2105MB/s-2105MB/s), io=588GiB (632GB), run=300015-300015msec
Disk stats (read/write):
nvme0n1: ios=2417361/3, sectors=1233036016/32, merge=0/1, ticks=35162142/29, in_queue=35162172, util=100.00%
CloudWatch のメトリクスから計算して IOPS とスループットを表示させました。どちらも設定した上限値が記録されています。
該当の時間帯にVolumeIOPSExceededCheckとVolumeThroughputExceededCheckがともに1を記録し、性能限界に達していたことが確認できます。
まとめ
Amazon EBS gp3 ボリュームの性能上限が大幅に引き上げられ、ボリュームサイズは 4 倍（64 TiB）、IOPS は 5 倍（80,000）、スループットは 2 倍（2,000 MiB/s）になりました。
おわりに
最大スペックで検証したところ、設定した上限値どおりの性能を発揮することを確認できました。大規模データベースや機械学習ワークロードなど、高いストレージ性能を必要とするシステムでも EBS で運用可能な幅が広がりました。ただし、最大スペックでの月額費用は約 10 万円と高額になるため、実際のワークロードに必要な性能を見極めたサイジングをオススメします。
もう io2 Block Express とそう変わらないのでは？と最初を思って調べたところ、まだ IOPS は 3 倍、スループットは 2 倍の上限の開きがありました。さすが io2 は違うぜ...となりました。
