developersIO
[アップデート] EC2インスタンスのインスタンスタイプベースでEBSボリュームとのIOPSやスループットキャパシティが超過しているかを記すCloudWatchメトリクスが追加されました

[アップデート] EC2インスタンスのインスタンスタイプベースでEBSボリュームとのIOPSやスループットキャパシティが超過しているかを記すCloudWatchメトリクスが追加されました

EC2インスタンスとEBSボリュームのどちらが性能のボトルネックになっているのか判断する際に
Amazon EC2Amazon CloudWatchAWS
FacebookHatena blogX
2025.10.27

EBSボリュームの性能のボトルネックがEC2インスタンスのインスタンスタイプに起因するものか判断したい

こんにちは、のんピ(@non____97)です。

皆さんはEBSボリュームの性能のボトルネックがEC2インスタンスのインスタンスタイプに起因するものか判断したいなと思ったことはありますか? 私はあります。

EBS最適化インスタンスのEC2インスタンスは、通常のネットワークとは別にEBSボリュームへのアクセスするネットワークが用意されています。これによって安定的にEBSボリュームへ読み書きを行うことが可能です。

EBS最適化インスタンスはインスタンスタイプごとにベースライン/バーストの帯域やスループット、IOPSが定義されています。

Instance size Baseline bandwidth (Mbps) Maximum bandwidth (Mbps) Baseline throughput (MB/s, 128 KiB I/O) Maximum throughput (MB/s, 128 KiB I/O) Baseline IOPS (16 KiB I/O) Maximum IOPS (16 KiB I/O)
a1.medium 1 300 3500 37.50 437.50 2500 20000
a1.large 1 525 3500 65.62 437.50 4000 20000
a1.xlarge 1 800 3500 100.00 437.50 6000 20000
a1.2xlarge 1 1750 3500 218.75 437.50 10000 20000

一部抜粋 : Amazon EBS-optimized instance types - Amazon Elastic Compute Cloud

つまりは、EBSボリューム側のスループットやIOPSに余裕があったとしても、インスタンス側がボトルネックになることがあるということです。

今回アップデートにより、EC2インスタンスのインスタンスタイプベースでEBSボリュームとのIOPSやスループットキャパシティが超過しているかを記すCloudWatchメトリクスが追加されました。

https://aws.amazon.com/jp/about-aws/whats-new/2025/10/amazon-cloudwatch-metrics-monitor-ec2-instances-i-o-performance/

具体的なメトリクスはAWS公式ドキュメントで紹介されている以下です。

  • InstanceEBSIOPSExceededCheck
  • InstanceEBSThroughputExceededCheck

以下記事で紹介されているメトリクスのEC2インスタンスに着目したメトリクスものと捉えると良いでしょう。

https://dev.classmethod.jp/articles/amazon-cloudwatch-ebs-volumes-exceeding-performance/

これにより、インスタンスサイズやインスタンスタイプの変更の判断を行いやすくなりました。

実際に試してみたので紹介します。

いきなりまとめ

  • EC2インスタンスのインスタンスタイプベースのEBSボリュームのIOPSやスループットキャパシティが超過しているかを記すCloudWatchメトリクスが追加された
    • InstanceEBSIOPSExceededCheck
    • InstanceEBSThroughputExceededCheck
  • いずれのメトリクスもインスタンスの上限に達した場合は 1 を 達していない場合は 0 を1分間間隔で記す
  • 検証をした限りベースラインのみ超過した場合は 0 であり、バースト上限に達した場合に 1 を返す
  • EC2インスタンスとEBSボリュームのどちらが性能のボトルネックになっているのか判断する際に使おう

やってみた

検証環境

検証は以下のEC2インスタンス、EBSボリュームを用いて行います。

  • AZ : us-east-1d (use1-az4)
  • AMI : al2023-ami-2023.9.20251020.0-kernel-6.1-x86_64 (ami-07860a2d7eb515d9a)
  • インスタンスタイプ : t3.micro
  • EBSボリュームタイプ : gp3
  • EBSボリュームスループット : 300 MBps
  • EBSボリュームIOPS : 12,000 IOPS

1.EBSボリューム.png

t3.microのEBS周りのパフォーマンスは以下のとおりです。

Instance size Baseline bandwidth (Mbps) Maximum bandwidth (Mbps) Baseline throughput (MB/s, 128 KiB I/O) Maximum throughput (MB/s, 128 KiB I/O) Baseline IOPS (16 KiB I/O) Maximum IOPS (16 KiB I/O)
t3.micro 87 2085 10.88 260.62 500 11800

EBSボリュームがボトルネックにならないように、IOPSとスループットは調整しています。

スループットがインスタンスの上限に達するように書き込み

まずはスループットがインスタンスの上限に達するように書き込みをします。要するに260.62MBpsを超過するように書き込みます。

EC2インスタンス上で以下のコマンドを実行します。

$ sudo fio \
  --directory=/home/ec2-user \
  --name fio_rw_4MiB_block_4GiB_4jobs \
  --ioengine=psync \
  --direct=1 \
  --rw=randwrite \
  --bs=4M \
  --size=4G \
  --numjobs=4 \
  --runtime=300 \
  --eta-newline=10 \
  --time_based=1 \
  --group_reporting \
  --norandommap
fio_rw_4MiB_block_4GiB_4jobs: (g=0): rw=randwrite, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 4 processes
fio_rw_4MiB_block_4GiB_4jobs: Laying out IO file (1 file / 4096MiB)
fio_rw_4MiB_block_4GiB_4jobs: Laying out IO file (1 file / 4096MiB)
fio_rw_4MiB_block_4GiB_4jobs: Laying out IO file (1 file / 4096MiB)
fio_rw_4MiB_block_4GiB_4jobs: Laying out IO file (1 file / 4096MiB)
Jobs: 4 (f=4): [w(4)][4.0%][w=248MiB/s][w=62 IOPS][eta 04m:48s]
Jobs: 4 (f=4): [w(4)][7.7%][w=252MiB/s][w=63 IOPS][eta 04m:37s]
Jobs: 4 (f=4): [w(4)][11.3%][w=252MiB/s][w=63 IOPS][eta 04m:26s]
Jobs: 4 (f=4): [w(4)][15.0%][w=248MiB/s][w=62 IOPS][eta 04m:15s]
Jobs: 4 (f=4): [w(4)][18.7%][w=244MiB/s][w=61 IOPS][eta 04m:04s]
Jobs: 4 (f=4): [w(4)][22.3%][w=252MiB/s][w=63 IOPS][eta 03m:53s]
Jobs: 4 (f=4): [w(4)][26.0%][w=248MiB/s][w=62 IOPS][eta 03m:42s]
Jobs: 4 (f=4): [w(4)][29.7%][w=248MiB/s][w=62 IOPS][eta 03m:31s]
Jobs: 4 (f=4): [w(4)][33.3%][w=244MiB/s][w=61 IOPS][eta 03m:20s]
Jobs: 4 (f=4): [w(4)][37.0%][w=244MiB/s][w=61 IOPS][eta 03m:09s]
Jobs: 4 (f=4): [w(4)][40.7%][w=248MiB/s][w=62 IOPS][eta 02m:58s]
Jobs: 4 (f=4): [w(4)][44.3%][w=244MiB/s][w=60 IOPS][eta 02m:47s]
Jobs: 4 (f=4): [w(4)][48.0%][w=248MiB/s][w=62 IOPS][eta 02m:36s]
Jobs: 4 (f=4): [w(4)][51.7%][w=252MiB/s][w=63 IOPS][eta 02m:25s]
Jobs: 4 (f=4): [w(4)][55.3%][w=248MiB/s][w=62 IOPS][eta 02m:14s]
Jobs: 4 (f=4): [w(4)][59.0%][w=248MiB/s][w=62 IOPS][eta 02m:03s]
Jobs: 4 (f=4): [w(4)][62.7%][w=248MiB/s][w=62 IOPS][eta 01m:52s]
Jobs: 4 (f=4): [w(4)][66.3%][w=244MiB/s][w=61 IOPS][eta 01m:41s]
Jobs: 4 (f=4): [w(4)][70.0%][w=252MiB/s][w=63 IOPS][eta 01m:30s]
Jobs: 4 (f=4): [w(4)][73.7%][w=248MiB/s][w=62 IOPS][eta 01m:19s]
Jobs: 4 (f=4): [w(4)][77.3%][w=248MiB/s][w=62 IOPS][eta 01m:08s]
Jobs: 4 (f=4): [w(4)][81.0%][w=248MiB/s][w=62 IOPS][eta 00m:57s]
Jobs: 4 (f=4): [w(4)][84.7%][w=248MiB/s][w=62 IOPS][eta 00m:46s]
Jobs: 4 (f=4): [w(4)][88.3%][w=252MiB/s][w=63 IOPS][eta 00m:35s]
Jobs: 4 (f=4): [w(4)][92.0%][w=244MiB/s][w=61 IOPS][eta 00m:24s]
Jobs: 4 (f=4): [w(4)][95.7%][w=252MiB/s][w=63 IOPS][eta 00m:13s]
Jobs: 4 (f=4): [w(4)][99.3%][w=248MiB/s][w=62 IOPS][eta 00m:02s]
Jobs: 4 (f=4): [w(4)][100.0%][w=252MiB/s][w=63 IOPS][eta 00m:00s]
fio_rw_4MiB_block_4GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=25671: Mon Oct 27 05:08:22 2025
  write: IOPS=62, BW=249MiB/s (261MB/s)(73.1GiB/300047msec); 0 zone resets
    clat (msec): min=3, max=122, avg=63.92, stdev=17.54
     lat (msec): min=3, max=122, avg=64.16, stdev=17.54
    clat percentiles (msec):
     |  1.00th=[   31],  5.00th=[   33], 10.00th=[   34], 20.00th=[   51],
     | 30.00th=[   62], 40.00th=[   64], 50.00th=[   64], 60.00th=[   65],
     | 70.00th=[   66], 80.00th=[   81], 90.00th=[   92], 95.00th=[   94],
     | 99.00th=[   96], 99.50th=[   97], 99.90th=[  113], 99.95th=[  116],
     | 99.99th=[  123]
   bw (  KiB/s): min=196608, max=753664, per=100.00%, avg=255486.63, stdev=7126.90, samples=2396
   iops        : min=   48, max=  184, avg=62.37, stdev= 1.74, samples=2396
  lat (msec)   : 4=0.02%, 10=0.35%, 50=17.20%, 100=82.11%, 250=0.33%
  cpu          : usr=0.40%, sys=0.27%, ctx=37301, majf=0, minf=35
  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,18703,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=249MiB/s (261MB/s), 249MiB/s-249MiB/s (261MB/s-261MB/s), io=73.1GiB (78.4GB), run=300047-300047msec

Disk stats (read/write):
  nvme0n1: ios=2/299363, merge=0/9350, ticks=91/15021044, in_queue=15021135, util=97.39%

平均249MiBps(261MBbps)で、平均62.37 IOPSのようです。

CloudWatchメトリクスを見てみましょう。

2.スループット超過時.png

過去1分間にインスタンスの最大EBSスループット制限を超えるスループットを生成しようとしたかどうかのメトリクスであるInstanceEBSThroughputExceededCheckのみが1となっています。このメトリクスは、 0 (スループット超過なし) または1 (スループット超過)のいずれかです。

つまりはEC2インスタンスのEBSスループットの上限に達したということです。VolumeThroughputExceededCheckは0であることから、EBSボリュームのスループット上限には達していないことも分かります。

実際に発生したスループットをCloudWatchから確認します。

3.書き込みスループットの表示.png

最大で250MBpsであることが分かります。

IOPSがインスタンスのベースライン上限を超過するように書き込み

続いて、IOPSがインスタンスのベースライン上限を超過するように書き込みをします。つまりは500 IOPSを超過するような形です。

$ sudo fio \
  --directory=/home/ec2-user \
  --name fio_rw_16KiB_block_4GiB_4jobs \
  --ioengine=psync \
  --direct=1 \
  --rw=randwrite \
  --bs=16K \
  --size=4G \
  --numjobs=4 \
  --runtime=300 \
  --eta-newline=10 \
  --time_based=1 \
  --group_reporting \
  --norandommap
fio_rw_16KiB_block_4GiB_4jobs: (g=0): rw=randwrite, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 4 processes
Jobs: 4 (f=4): [w(4)][4.0%][w=62.7MiB/s][w=4013 IOPS][eta 04m:48s]
Jobs: 4 (f=4): [w(4)][7.7%][w=62.6MiB/s][w=4008 IOPS][eta 04m:37s]
Jobs: 4 (f=4): [w(4)][11.3%][w=62.2MiB/s][w=3983 IOPS][eta 04m:26s]
Jobs: 4 (f=4): [w(4)][15.0%][w=62.4MiB/s][w=3994 IOPS][eta 04m:15s]
Jobs: 4 (f=4): [w(4)][18.7%][w=62.7MiB/s][w=4013 IOPS][eta 04m:04s]
Jobs: 4 (f=4): [w(4)][22.3%][w=62.6MiB/s][w=4009 IOPS][eta 03m:53s]
Jobs: 4 (f=4): [w(4)][26.0%][w=62.6MiB/s][w=4004 IOPS][eta 03m:42s]
Jobs: 4 (f=4): [w(4)][29.7%][w=62.6MiB/s][w=4004 IOPS][eta 03m:31s]
Jobs: 4 (f=4): [w(4)][33.3%][w=62.6MiB/s][w=4006 IOPS][eta 03m:20s]
Jobs: 4 (f=4): [w(4)][37.0%][w=62.6MiB/s][w=4009 IOPS][eta 03m:09s]
Jobs: 4 (f=4): [w(4)][40.7%][w=62.8MiB/s][w=4016 IOPS][eta 02m:58s]
Jobs: 4 (f=4): [w(4)][44.3%][w=62.6MiB/s][w=4006 IOPS][eta 02m:47s]
Jobs: 4 (f=4): [w(4)][48.0%][w=62.7MiB/s][w=4012 IOPS][eta 02m:36s]
Jobs: 4 (f=4): [w(4)][51.7%][w=62.4MiB/s][w=3990 IOPS][eta 02m:25s]
Jobs: 4 (f=4): [w(4)][55.3%][w=62.6MiB/s][w=4008 IOPS][eta 02m:14s]
Jobs: 4 (f=4): [w(4)][59.0%][w=62.4MiB/s][w=3996 IOPS][eta 02m:03s]
Jobs: 4 (f=4): [w(4)][62.7%][w=62.6MiB/s][w=4009 IOPS][eta 01m:52s]
Jobs: 4 (f=4): [w(4)][66.3%][w=62.6MiB/s][w=4004 IOPS][eta 01m:41s]
Jobs: 4 (f=4): [w(4)][70.0%][w=60.9MiB/s][w=3900 IOPS][eta 01m:30s]
Jobs: 4 (f=4): [w(4)][73.7%][w=62.5MiB/s][w=4002 IOPS][eta 01m:19s]
Jobs: 4 (f=4): [w(4)][77.3%][w=62.6MiB/s][w=4008 IOPS][eta 01m:08s]
Jobs: 4 (f=4): [w(4)][81.0%][w=62.7MiB/s][w=4010 IOPS][eta 00m:57s]
Jobs: 4 (f=4): [w(4)][84.7%][w=62.5MiB/s][w=4002 IOPS][eta 00m:46s]
Jobs: 4 (f=4): [w(4)][88.3%][w=62.7MiB/s][w=4010 IOPS][eta 00m:35s]
Jobs: 4 (f=4): [w(4)][92.0%][w=62.5MiB/s][w=3999 IOPS][eta 00m:24s]
Jobs: 4 (f=4): [w(4)][95.7%][w=62.6MiB/s][w=4004 IOPS][eta 00m:13s]
Jobs: 4 (f=4): [w(4)][99.3%][w=62.3MiB/s][w=3989 IOPS][eta 00m:02s]
Jobs: 4 (f=4): [w(4)][100.0%][w=62.4MiB/s][w=3991 IOPS][eta 00m:00s]
fio_rw_16KiB_block_4GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=26599: Mon Oct 27 05:35:30 2025
  write: IOPS=3993, BW=62.4MiB/s (65.4MB/s)(18.3GiB/300001msec); 0 zone resets
    clat (usec): min=297, max=21304, avg=999.57, stdev=122.71
     lat (usec): min=297, max=21305, avg=1000.14, stdev=122.75
    clat percentiles (usec):
     |  1.00th=[  914],  5.00th=[  930], 10.00th=[  947], 20.00th=[  963],
     | 30.00th=[  979], 40.00th=[  988], 50.00th=[  996], 60.00th=[ 1004],
     | 70.00th=[ 1012], 80.00th=[ 1029], 90.00th=[ 1057], 95.00th=[ 1074],
     | 99.00th=[ 1123], 99.50th=[ 1188], 99.90th=[ 2376], 99.95th=[ 2966],
     | 99.99th=[ 4555]
   bw (  KiB/s): min=53056, max=69248, per=100.00%, avg=63930.22, stdev=236.47, samples=2396
   iops        : min= 3316, max= 4328, avg=3995.59, stdev=14.79, samples=2396
  lat (usec)   : 500=0.08%, 750=0.11%, 1000=57.88%
  lat (msec)   : 2=41.80%, 4=0.12%, 10=0.01%, 20=0.01%, 50=0.01%
  cpu          : usr=0.52%, sys=1.06%, ctx=1202162, majf=0, minf=38
  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,1198027,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=62.4MiB/s (65.4MB/s), 62.4MiB/s-62.4MiB/s (65.4MB/s-65.4MB/s), io=18.3GiB (19.6GB), run=300001-300001msec

Disk stats (read/write):
  nvme0n1: ios=3/1198009, merge=0/44, ticks=1/1177060, in_queue=1177062, util=91.54%

平均約4,000 IOPSでした。

CloudWatchメトリクスを確認します。

4.fioで4,000IOPS発生時.png

過去1分間にインスタンスの最大EBSスループット制限を超えるIOPSを発生しようとしたかどうかのメトリクスであるInstanceEBSIOPSExceededCheck含めて全て0となっています。このメトリクスは、 0 (IOPS超過なし) または1 (IOPS超過)のいずれかです。

つまりは超過は発生していません。

CloudWatchから4,000 IOPSが出ているタイミングでいずれのメトリクスが1になっていないことも確認します。

5.fioで4,000IOPS発生時2.png

どうやらベースラインを超過ではなく、バースト上限に達したタイミングでメトリクスが1になりそうですね。

IOPSがインスタンスのバースト上限を超過するように書き込み

ということで、IOPSがインスタンスのバースト上限を超過するように書き込みを行います。今回は11,800 IOPSに達する必要があります。

以下のように、非同期書き込みで多重度とキューの深さを増して書き込みを行います。

$ sudo fio \
  --directory=/home/ec2-user \
  --name fio_rw_16KiB_block_1GiB_16jobs \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=32 \
  --rw=randwrite \
  --bs=16K \
  --size=1G \
  --numjobs=16 \
  --runtime=300 \
  --eta-newline=10 \
  --time_based=1 \
  --group_reporting \
  --norandommap
fio_rw_16KiB_block_1GiB_16jobs: (g=0): rw=randwrite, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=libaio, iodepth=32
...
fio-3.32
Starting 16 processes
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
fio_rw_16KiB_block_1GiB_16jobs: Laying out IO file (1 file / 1024MiB)
Jobs: 16 (f=16): [w(16)][4.0%][w=183MiB/s][w=11.7k IOPS][eta 04m:48s]
Jobs: 16 (f=16): [w(16)][7.7%][w=184MiB/s][w=11.8k IOPS][eta 04m:37s]
Jobs: 16 (f=16): [w(16)][11.3%][w=185MiB/s][w=11.8k IOPS][eta 04m:26s]
Jobs: 16 (f=16): [w(16)][15.0%][w=174MiB/s][w=11.1k IOPS][eta 04m:16s]
Jobs: 16 (f=16): [w(16)][18.6%][w=173MiB/s][w=11.1k IOPS][eta 04m:05s]
Jobs: 16 (f=16): [w(16)][22.3%][w=177MiB/s][w=11.3k IOPS][eta 03m:54s]
Jobs: 16 (f=16): [w(16)][25.9%][w=184MiB/s][w=11.8k IOPS][eta 03m:43s]
Jobs: 16 (f=16): [w(16)][29.6%][w=184MiB/s][w=11.8k IOPS][eta 03m:32s]
Jobs: 16 (f=16): [w(16)][33.2%][w=178MiB/s][w=11.4k IOPS][eta 03m:21s]
Jobs: 16 (f=16): [w(16)][36.5%][w=185MiB/s][w=11.8k IOPS][eta 03m:11s]
Jobs: 16 (f=16): [w(16)][40.2%][w=184MiB/s][w=11.8k IOPS][eta 03m:00s]
Jobs: 16 (f=16): [w(16)][43.9%][w=185MiB/s][w=11.8k IOPS][eta 02m:49s]
Jobs: 16 (f=16): [w(16)][47.5%][w=185MiB/s][w=11.8k IOPS][eta 02m:38s]
Jobs: 16 (f=16): [w(16)][51.2%][w=185MiB/s][w=11.8k IOPS][eta 02m:27s]
Jobs: 16 (f=16): [w(16)][54.8%][w=184MiB/s][w=11.8k IOPS][eta 02m:16s]
Jobs: 16 (f=16): [w(16)][58.1%][w=185MiB/s][w=11.8k IOPS][eta 02m:06s]
Jobs: 16 (f=16): [w(16)][61.8%][w=185MiB/s][w=11.8k IOPS][eta 01m:55s]
Jobs: 16 (f=16): [w(16)][65.4%][w=184MiB/s][w=11.8k IOPS][eta 01m:44s]
Jobs: 16 (f=16): [w(16)][69.1%][w=185MiB/s][w=11.8k IOPS][eta 01m:33s]
Jobs: 16 (f=16): [w(16)][72.8%][w=185MiB/s][w=11.8k IOPS][eta 01m:22s]
Jobs: 16 (f=16): [w(16)][76.4%][w=184MiB/s][w=11.8k IOPS][eta 01m:11s]
Jobs: 16 (f=16): [w(16)][80.1%][w=184MiB/s][w=11.8k IOPS][eta 01m:00s]
Jobs: 16 (f=16): [w(16)][83.7%][w=185MiB/s][w=11.8k IOPS][eta 00m:49s]
Jobs: 16 (f=16): [w(16)][87.4%][w=184MiB/s][w=11.8k IOPS][eta 00m:38s]
Jobs: 16 (f=16): [w(16)][91.3%][w=185MiB/s][w=11.8k IOPS][eta 00m:26s]
Jobs: 16 (f=16): [w(16)][94.7%][w=184MiB/s][w=11.8k IOPS][eta 00m:16s]
Jobs: 16 (f=16): [w(16)][98.3%][w=185MiB/s][w=11.8k IOPS][eta 00m:05s]
Jobs: 16 (f=16): [w(16)][100.0%][w=185MiB/s][w=11.8k IOPS][eta 00m:00s]
fio_rw_16KiB_block_1GiB_16jobs: (groupid=0, jobs=16): err= 0: pid=26961: Mon Oct 27 05:45:20 2025
  write: IOPS=11.7k, BW=183MiB/s (192MB/s)(53.7GiB/300011msec); 0 zone resets
    slat (usec): min=2, max=193169, avg=1359.08, stdev=4950.69
    clat (usec): min=192, max=313521, avg=42292.54, stdev=23728.07
     lat (usec): min=643, max=313526, avg=43651.63, stdev=24074.67
    clat percentiles (msec):
     |  1.00th=[    8],  5.00th=[   13], 10.00th=[   17], 20.00th=[   23],
     | 30.00th=[   29], 40.00th=[   34], 50.00th=[   39], 60.00th=[   44],
     | 70.00th=[   50], 80.00th=[   59], 90.00th=[   73], 95.00th=[   88],
     | 99.00th=[  121], 99.50th=[  134], 99.90th=[  167], 99.95th=[  182],
     | 99.99th=[  211]
   bw (  KiB/s): min=101762, max=494628, per=100.00%, avg=187762.67, stdev=1696.81, samples=9584
   iops        : min= 6359, max=30908, avg=11734.62, stdev=106.04, samples=9584
  lat (usec)   : 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.15%, 10=2.82%, 20=11.80%, 50=55.48%
  lat (msec)   : 100=27.03%, 250=2.70%, 500=0.01%
  cpu          : usr=0.27%, sys=0.60%, ctx=2583870, majf=0, minf=162
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.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.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,3518668,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=183MiB/s (192MB/s), 183MiB/s-183MiB/s (192MB/s-192MB/s), io=53.7GiB (57.6GB), run=300011-300011msec

Disk stats (read/write):
  nvme0n1: ios=0/3549449, merge=0/132, ticks=0/17029025, in_queue=17029025, util=85.39%

平均約11,800 IOPSであることが分かります。

CloudWatchメトリクスを確認します。

6.fioで11800IOPS発生時.png

InstanceEBSIOPSExceededCheckが1になっており、他のメトリクスは0であることからEC2インスタンスのEBSボリュームへのIOPSのみ上限に達したことが分かります。

念の為、CloudWatchから書き込みIOPSを確認しましたが、確かに11,827 IOPSが発生していました。

7.fioで11800IOPS発生時2.png

EC2インスタンスとEBSボリュームのどちらが性能のボトルネックになっているのか判断する際に

EC2インスタンスのインスタンスタイプベースでEBSボリュームとのIOPSやスループットキャパシティが超過しているかを記すCloudWatchメトリクスが追加されたアップデートを紹介しました。

EC2インスタンスとEBSボリュームのどちらが性能のボトルネックになっているのか判断する際に活躍しますね。

逆にEC2インスタンスとEBSボリュームのいずれのメトリクスも1になっていない場合は、インフラがボトルネックなのではなく、アプリケーション側の設定や前後処理などがボトルネックになっていると言えます。そのようなトラブルシューティングにも役立ちそうですね。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!

この記事をシェアする

FacebookHatena blogX

関連記事

本番 EC2 サーバーがダウン！その時にまず確認するポイントと復旧手順
M.Shimizu
2025.10.26
バッチ処理のコスト削減に EC2 インスタンスプール方式を実装してみた
miyan
2025.10.22
Amazon EC2 の各インスタンスの物理コア数と 1 コアあたりの単価を一覧で確認する方法
大村 保貴
2025.10.22
SIMD と AVX を EC2 上の Python + NumPy で試してみた
大村 保貴
2025.10.21