AWS EBSのIOPSと物理ディスクのIOPSは何が違うのか

この文書の適用条件

そのまま実行できるコマンド

# 対象: Amazon EBS（AWS CLI v2）
# 権限: ec2:DescribeVolumes
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws ec2 describe-volumes \
  --volume-ids vol-0123456789abcdef0 \
  --query "Volumes[].{Id:VolumeId,Type:VolumeType,SizeGiB:Size,Iops:Iops,\
ThroughputMiBs:Throughput,MultiAttach:MultiAttachEnabled,State:State,\
AttachedTo:Attachments[0].InstanceId,Device:Attachments[0].Device}" \
  --output table

# 対象: Amazon CloudWatch（名前空間 AWS/EBS）
# 権限: cloudwatch:GetMetricStatistics
# 変更作業: なし（参照のみ）
# Production 実行: 可能
for M in VolumeReadOps VolumeWriteOps VolumeQueueLength BurstBalance
do
  echo "===== $M ====="
  aws cloudwatch get-metric-statistics \
    --namespace AWS/EBS \
    --metric-name "$M" \
    --dimensions Name=VolumeId,Value=vol-0123456789abcdef0 \
    --start-time 2026-08-12T00:00:00Z \
    --end-time   2026-08-13T00:00:00Z \
    --period 300 \
    --statistics Average Maximum Sum \
    --output text
done

# 対象: EC2 上の Linux
# 権限: 一般ユーザー（nvme list は root 権限が必要な場合がある）
# 変更作業: なし（参照のみ）
# Production 実行: 可能
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL
sudo nvme list
cat /sys/block/nvme1n1/queue/nr_requests
iostat -x 1 5

# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み取り権限（デバイス直接指定なら root）
# 変更作業: なし（読み取りのみ）だが、実行中は他の処理の I/O 性能に影響する
# Production 実行: 非推奨。検証環境、または本番と共有しないボリュームで実行すること
fio --name=randread \
    --filename=/mnt/testdir/fio_testfile \
    --size=64G \
    --rw=randread \
    --bs=4k \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=32 \
    --numjobs=4 \
    --runtime=300 \
    --time_based \
    --group_reporting

結果の読み方

こういう状況で使います

• オンプレミスのSSDで出ていた性能が、EBSに移したら出ない
• ベンチマークツールの数値がEBSのプロビジョニング値と大きく食い違う
• ボリュームのIOPSを増やしたのにスループットが上がらない
• 大きなボリュームを接続したのに、期待した性能が出ない
• gp2ボリュームで、しばらく速いがある時点から急に遅くなる
• CloudWatchのVolumeReadOpsの値とIOPSの単位が合わない

考えられる原因（可能性の高い順）

1. 01

   EBSはネットワーク接続型のブロックストレージである

   EBSはインスタンスに物理的に取り付けられたデバイスではなく、ネットワーク越しに接続されたストレージです。したがってIOPSは「デバイスがどれだけ速いか」ではなく「サービスがどこまで通すか」で決まります。ネットワーク経由であるため、レイテンシの性質も物理ディスクとは異なります。

2. 02

   I/Oサイズによって1回のI/Oが消費するIOPS数が変わる

   EBSはI/Oを固定サイズの単位で数えます。その単位より大きいI/Oは複数IOPSぶんとして計上され、逆に連続したI/Oはまとめて計上されることがあります。つまり「1操作＝1 IOPS」ではありません。単位サイズはボリューム種別（SSD系とHDD系）で異なるため、現行のEBSボリューム種別のドキュメントで対象種別の値を確認してください。この文書では具体的なバイト数を示しません。

3. 03

   IOPSとスループットは別々の上限である

   EBSにはIOPS（回数/秒）とスループット（MiB/秒）の2つの上限があります。小さいI/Oを大量に出すワークロードはIOPS上限に、大きいI/Oを出すワークロードはスループット上限に先に当たります。どちらが律速かは、I/OサイズとIOPSの積がスループット上限に達しているかで判断します。

4. 04

   インスタンス側にもEBS帯域の上限がある

   ボリューム側の上限とは別に、EC2インスタンスクラスごとにEBSへの帯域上限（EBS最適化帯域）が定められています。高性能なボリュームを小さいインスタンスに接続すると、インスタンス側の上限で頭打ちになります。上限値はインスタンスクラスごとに異なるため、現行のAWSドキュメントで対象クラスを確認してください。

5. 05

   gp2はバーストクレジットに依存する

   gp2は容量に応じた基線性能を持ち、それを超えるI/OはI/Oクレジットで賄います。クレジットが枯渇すると基線性能まで落ちます。「最初は速いがある時点から遅くなる」という現象の典型的な原因です。gp3はクレジット方式ではなく、基線に対して追加のIOPSとスループットを設定するモデルです。

6. 06

   インスタンスストア（NVMe）と混同している

   インスタンスストアはホストに物理的に取り付けられたNVMeデバイスで、EBSのようなネットワーク経由の上限は適用されません。ただしインスタンスの停止・終了でデータが消える一時ストレージです。ベンチマークでインスタンスストアの値を測り、それをEBSの値と比較すると必ず食い違います。

7. 07

   ベンチマークがキャッシュを測っている

   `direct=1` を指定していない、あるいはテストデータのサイズがRAM容量より小さい場合、測定しているのはOSのページキャッシュです。この条件で出た数値は、物理ディスクでもEBSでもストレージの性能を表しません。

確認手順

1. 1

   ボリューム側の上限を確認する

   参照のみ

   `aws ec2 describe-volumes` で種別・容量・プロビジョニングIOPS・スループット設定を確認します。

2. 2

   インスタンス側の上限を確認する

   参照のみ

   接続先インスタンスクラスのEBS帯域上限を、現行のAWSドキュメントで確認します。ボリューム側より低ければインスタンスが律速です。

3. 3

   実測をCloudWatchで取る

   参照のみ

   VolumeReadOps・VolumeWriteOpsをSumで取り期間秒数で割ってIOPSに換算します。VolumeQueueLengthとBurstBalanceも併せて見ます。

4. 4

   I/Oサイズを確認する

   参照のみ

   スループット（バイト/秒）をIOPS（回/秒）で割り、平均I/Oサイズを求めます。これがIOPS律速かスループット律速かの判断材料になります。

5. 5

   OS側の見え方を確認する

   参照のみ

   `iostat -x` で `r/s`・`w/s`・`aqu-sz`・`await`・`%util` を確認し、CloudWatchの値と突き合わせます。

6. 6

   必要なら検証環境でfioを実行する

   低

   `--direct=1` とRAMより大きいワーキングセットを必ず指定します。本番と同居するボリュームでは実行しません。

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• ファイルシステムとマウントオプションを確認する

  アライメント、ジャーナル設定、`noatime` の有無などがI/O回数に影響します。ブロックデバイスの上限に当たっていないのに遅い場合の確認先です。

• アプリケーション側の同期I/O設定を確認する

  データベースのログ書き込みは同期I/Oであり、スループットではなくレイテンシが効きます。IOPSに余裕があっても遅い場合はここを見ます。

• RAID構成やLVMの層で待ちが発生していないか確認する

  複数ボリュームをストライプしている場合、1本の遅延が全体を引きずります。デバイス単位で `iostat -x` を確認します。

• インスタンスのネットワーク帯域と競合していないか確認する

  世代・クラスによってはEBS帯域とネットワーク帯域の扱いが異なります。大量のネットワーク通信と同時にI/Oが落ちる場合は要確認です。

• 比較対象の測定条件を入手する

  「物理ディスクではこの値だった」という数値の測定条件（I/Oサイズ、キュー深度、direct指定、ワーキングセット）が不明なら、比較そのものが成立しません。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• HDD RAID 0で高いIOPS値が表示される理由
• EBSのIOPSを上げても速くならないのはなぜか
• オンプレのSSDと同じ性能がEBSで出ない
• CloudWatchのVolumeReadOpsをIOPSに換算する方法

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

EBSの上限がどこに効いているかは、条件を揃えれば1回の調査で分かります。運用で問題になるのはそこではなく、データ量とアクセスパターンが変化して、ある日から上限に当たり始める瞬間に気づけるかどうかです。GIIPではAWSとAzure上の複数データベースおよび約30のWebサービスについて、VolumeQueueLengthやBurstBalanceといったストレージ側の先行指標をAIエージェントが継続的に追い、上限に近づく傾向が出た段階で人間の専門家が構成変更の要否を判断しています。障害になってから測るのではなく、上限に触れる前に検知することを目的にしています。

関連サービス

• データベース性能チューニング
• 性能障害の切り分けを依頼する