What's the Difference Between EBS IOPS and Physical Disk 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

結果の読み方

こういう状況で使います

• Performance that was achieved on on-premises SSD is not reproduced after moving to EBS
• A benchmark tool's numbers diverge significantly from EBS's provisioned values
• Increasing a volume's IOPS doesn't raise throughput
• A large volume was attached, but the expected performance is not achieved
• A gp2 volume is fast for a while, then suddenly slows down at some point
• CloudWatch's VolumeReadOps value doesn't line up with IOPS units

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

1. 01

   EBS is network-attached block storage

   EBS is not a device physically attached to the instance — it is storage connected over the network. IOPS is therefore determined not by "how fast the device is" but by "how much the service lets through." Because it goes over the network, latency characteristics also differ from a physical disk.

2. 02

   I/O size changes how many IOPS a single operation consumes

   EBS counts I/O in fixed-size units. An I/O larger than that unit is counted as multiple IOPS, while consecutive I/O can sometimes be counted together. In other words, "one operation" does not equal "one IOPS." The unit size differs by volume type (SSD-based vs. HDD-based), so check the current EBS volume type documentation for the value for your type — this article does not give specific byte figures.

3. 03

   IOPS and throughput are separate ceilings

   EBS has two ceilings: IOPS (operations/sec) and throughput (MiB/sec). A workload issuing many small I/Os hits the IOPS ceiling first, while one issuing large I/Os hits the throughput ceiling first. Judge which is the limiting factor by whether I/O size times IOPS has reached the throughput ceiling.

4. 04

   The instance side also has an EBS bandwidth ceiling

   In addition to the volume-side ceiling, each EC2 instance class has a defined bandwidth ceiling to EBS (EBS-optimized bandwidth). Attaching a high-performance volume to a small instance means the instance-side ceiling becomes the bottleneck. Since the ceiling differs by instance class, check the target class in current AWS documentation.

5. 05

   gp2 depends on burst credits

   gp2 has a baseline performance tied to capacity, with I/O beyond that drawn from I/O credits. Once credits run out, performance falls to baseline. This is the classic cause of "fast at first, then slows down at some point." gp3 is not credit-based — it is a model where additional IOPS and throughput are configured on top of a baseline.

6. 06

   Confusion with instance store (NVMe)

   Instance store is an NVMe device physically attached to the host, and it is not subject to a network-based ceiling like EBS. However, it is temporary storage that loses data on instance stop or termination. Benchmarking instance store and comparing the result against EBS numbers will always produce a mismatch.

7. 07

   The benchmark is measuring the cache

   If `direct=1` is not specified, or the test data size is smaller than RAM, what's being measured is the OS page cache. A figure obtained under these conditions does not represent storage performance, on a physical disk or on EBS.

確認手順

1. 1

   Check the volume-side ceiling

   参照のみ

   Use `aws ec2 describe-volumes` to check the type, capacity, provisioned IOPS, and throughput setting.

2. 2

   Check the instance-side ceiling

   参照のみ

   Check the attached instance class's EBS bandwidth ceiling in current AWS documentation. If lower than the volume side, the instance is the limiting factor.

3. 3

   Pull measured values from CloudWatch

   参照のみ

   Get the Sum of VolumeReadOps/VolumeWriteOps and divide by the number of seconds in the period to convert to IOPS. Also check VolumeQueueLength and BurstBalance.

4. 4

   Check the I/O size

   参照のみ

   Divide throughput (bytes/sec) by IOPS (ops/sec) to get the average I/O size. This is a basis for judging whether the limit is IOPS or throughput.

5. 5

   Check the OS-side view

   参照のみ

   Use `iostat -x` to check `r/s`, `w/s`, `aqu-sz`, `await`, and `%util`, and cross-check against the CloudWatch values.

6. 6

   Run fio in a test environment if needed

   低

   Always specify `--direct=1` and a working set larger than RAM. Do not run this against a volume shared with production.

対応方法

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

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

• Check the filesystem and mount options

  Alignment, journaling settings, and whether `noatime` is set affect I/O count. Check this when things are slow without hitting a block-device ceiling.

• Check the application's synchronous I/O settings

  A database log write is synchronous I/O, where latency matters more than throughput. Check this if things are slow despite headroom in IOPS.

• Check for waiting at the RAID or LVM layer

  When striping multiple volumes, a single slow one drags down the whole array. Check `iostat -x` per device.

• Check for contention with the instance's network bandwidth

  How EBS bandwidth and network bandwidth are handled differs by generation and class. Worth checking if I/O drops during heavy network traffic.

• Obtain the measurement conditions for anything being compared

  If the measurement conditions (I/O size, queue depth, direct flag, working set) behind a claim like "on physical disk it was this value" are unknown, the comparison itself does not hold.

この文書の根拠と限界

よくある質問

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

• Why does HDD RAID 0 show a high IOPS value
• Why doesn't raising EBS IOPS make things faster
• Can't get the same performance on EBS as on-premises SSD
• How to convert CloudWatch's VolumeReadOps to IOPS

リスク表示の意味

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

GIIPの対応範囲

Where an EBS ceiling applies can be figured out in a single investigation once conditions are matched. What matters operationally isn't that — it's whether you notice the moment data volume and access patterns shift enough to start hitting the ceiling. At GIIP, an AI agent continuously tracks storage-side leading indicators such as VolumeQueueLength and BurstBalance across several databases on AWS and Azure and roughly 30 web services, and a human specialist judges whether a configuration change is needed once a trend approaches the ceiling. The goal is to detect this before it becomes an incident, not to measure it afterward.

関連サービス

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