<初心者向け>AWSのAZ間レイテンシをsockperfでpercentile分布まで測ってみた

はじめに

クラウド事業本部、あきやまです。

今回は「AWS のデータセンター同士の通信って、実際どれくらい速いの?」を実際に測ってみた話です。専門用語はなるべくかみくだいて説明するので、ネットワークにくわしくない方もぜひ読んでみてください。

まず用語を3つだけ

この記事に出てくる大事な言葉を先に説明します。

• AZ（アベイラビリティーゾーン）: AWS のデータセンターのかたまりのことです。たとえば東京リージョンには AZ が3つあり、それぞれ別々の場所にある建物だとイメージしてください。1か所が停電や災害でダウンしても、他の AZ は無事、という仕組みです
• レイテンシ: 通信の「待ち時間」です。「こんにちは」と送って「こんにちは」と返ってくるまでの時間、と思ってください。この記事では μs（マイクロ秒 = 100万分の1秒） という単位を使います。1,000μs = 1ミリ秒 = 0.001秒です
• パーセンタイル（percentile）: 「100人を足の速い順に並べたときの◯番目」です。p50 = ちょうど真ん中の人（中央値）、p99 = 遅い方から数えて2番目（上位99%地点）、p99.9 = 1,000人中999番目です。「遅いケースがどれくらい遅いか」を見るための道具です

注意

本記事の測定結果はあくまで参考値として扱ってください。特定の日時・特定の
アカウント・特定のインスタンスでの一時点の測定であり、AWS 内部のネットワーク構成や経路は日々変わる
可能性があります。実際のシステム設計でレイテンシが重要な場合は、必ずご自身の環境・条件で測定するこ
とをおすすめします。

なぜパーセンタイルで取得するのか

AZ 間のレイテンシは「東京は 1ms くらい」と平均値で語られることが多いです。実際のこのブログを書くにあたり
以下のブログを参照し本検証を行いました。すごく分かりやすかったので、よろしければご参照ください。

AWSのAZ間レイテンシを測定してみた（2026年東京/大阪）
※以降、元記事と表記

ただ、平均値には弱点があります。たとえばテストの平均点が70点でも、「全員が70点」なのか「半分が100点、半分が40点」なのかは区別できません。通信も同じで、「たまに来るすごく遅い通信」がどれくらいあるかは平均値からはわかりません。銀行のシステムやゲームのように速さが命のシステムでは、この「たまに遅い」が事故のもとになります。

そこで本記事では、通信を1回ずつ記録し、レイテンシの「分布」＝ばらつきの形まで見てみました。

環境

測定に使ったツールは2つです。

• netperf: 昔からある定番の測定ツール。元記事と同じ条件で測って「答え合わせ」をするために使います
• sockperf: 今回の主役。「こんにちは」→「こんにちは」の往復（ping-pong）をひたすら繰り返し、1回ずつの時間を全部 CSV に記録できます（--full-log オプション）

仮想サーバー（EC2）の配置はこうしました。

• 東京: 3つの AZ（apne1-az1 / az2 / az4）に1台ずつ + az1 にもう1台（同じ建物内の速さを測る基準用）
• 大阪: 3つの AZ（apne3-az1 / az2 / az3）に1台ずつ + az1 にもう1台（同上）
• 合計8台

※ 補足: 「ap-northeast-1a」のような AZ の名前は、実はアカウントごとに指す場所が違います（Aさんの 1a と Bさんの 1a は別の建物かもしれない）。場所を正確に指す AZ ID（apne1-az1 など）を aws ec2 describe-availability-zones で確認して配置しています。

結論

平均値では元記事とほぼ同じ結果になった一方、分布まで見ると次の2つがわかりました。

1. AZ間レイテンシの「山」は1つではない（速いグループと遅いグループがある）
2. 東京は「遅いけど安定」、大阪は「速いけどばらつく」

sockperf での測定結果です。数字は片道の時間（往復の半分）です。

表の読み方とポイント:

• 「p99/p50 比」は「遅い方から2番目の人が、真ん中の人の何倍遅いか」です。1に近いほど「みんな同じ速さ＝安定」です
• 東京は数字が大きい（遅い）けれど比が 1.1 前後で超安定。大阪は数字が小さい（速い）けれど比が最大 1.85 とばらつく。おそらく東京の方が AZ 同士の距離が離れているのだと思われます
• 同じ AZ 内（同じ建物）なら約25μs。AZ をまたぐと 5〜30 倍かかります。「AZ をまたぐ＝別の建物まで光ファイバーで往復する」ので当然ですね
• 大阪 az1↔az2 の平均は 147.7μs ですが、後で見るようにこの値のあたりに通信はほとんど存在しません。「半分が100点、半分が40点のクラスの平均70点」と同じ現象です

やってみた

Step 1: 測定環境の構築

東京と大阪に VPC（プライベートなネットワーク）とサーバーを各VPCに4台ずつ作ります。ポイントだけ紹介します。

• AZ ごとにサブネット（ネットワークの区画）を作り、AZ ID を指定して確実に狙った場所へ配置
• 測定結果のファイルは S3（ファイル置き場）にアップロードして回収

測定ツールはサーバー起動時に自動でインストール（ソースコードからビルド）します。

dnf install -y gcc gcc-c++ make automake autoconf libtool

# netperf 2.7.0
curl -sSL -o netperf.tar.gz https://github.com/HewlettPackard/netperf/archive/refs/tags/netperf-2.7.0.tar.gz
tar xzf netperf.tar.gz && cd netperf-netperf-2.7.0
CFLAGS="-fcommon -O2" ./configure && make && make install

# sockperf 3.10
curl -sSL -o sockperf.tar.gz https://github.com/Mellanox/sockperf/archive/refs/tags/3.10.tar.gz
tar xzf sockperf.tar.gz && cd sockperf-3.10
./autogen.sh && ./configure && make && make install

※ netperf のビルドは2か所ハマりました。新しめのコンパイラでは CFLAGS="-fcommon" が必須なのと、--enable-demo オプションを付けるとエラーで止まります（詳細は「注意点」参照）。

Step 2: netperf で元記事と同条件の測定

いきなり新しい測り方をする前に、元記事と同じツール・同じ条件で測って「だいたい同じ結果になるか」を確認します。

netperf -H <相手のIP> -t TCP_RR -l 60 -- \
  -o MIN_LATENCY,MEAN_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MAX_LATENCY,TRANSACTION_RATE

実行結果の例（東京 az1 → az2、1回目）。最後の行が結果で、左から2番目の 1152.81 が平均レイテンシ（μs、往復）です:

MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.1.2.120 () port 0 AF_INET : first burst 0
Minimum Latency Microseconds,Mean Latency Microseconds,50th Percentile Latency Microseconds,90th Percentile Latency Microseconds,99th Percentile Latency Microseconds,Maximum Latency Microseconds,Transaction Rate Tran/s
919,1152.81,1143,1250,1327,2251,867.258

元記事との比較（数字は往復の平均、μs）:

東京 az1↔az2 はほぼピッタリ一致（1,150 vs 1,144）。他も傾向が揃っているので、今回の測定環境はおかしくない、と確認できました。測定時期が4ヶ月違うので多少のずれは自然です。

Step 3: sockperf で全部の通信を記録する

sockperf の ping-pong モードに --full-log を付けると、1回1回の通信の時間を全部 CSV に書き出してくれます。

受ける側（サーバー役）:

sockperf server --tcp -p 11111

送る側（60秒 × 2回）:

sockperf ping-pong --tcp -i <相手のIP> -p 11111 -t 60 --full-log /var/tmp/sockperf_az1-az2_run1.csv

実行が終わると、まとめ（サマリ)も表示されます（東京 az1 → az2、1回目の抜粋）:

sockperf: [Valid Duration] RunTime=59.549 sec; SentMessages=49911; ReceivedMessages=49911
sockperf: ====> avg-latency=596.251 (std-dev=33.265, ...)
sockperf: ---> percentile 99.900 =  705.955
sockperf: ---> percentile 99.000 =  670.695
sockperf: ---> percentile 50.000 =  603.890

「60秒間で49,911回やりとりして、平均596μs、真ん中の値は604μs」と読みます。そして CSV にはこの49,911回が1行ずつ全部残っています:

packet, txTime(sec), rxTime(sec), latency(usec)
0, 2.628488533, 2.629583506, 547.487
1, 2.629584211, 2.630822438, 619.113
...

Step 4: グラフにして「分布の形」を見る

回収した CSV を Python（pandas + matplotlib）を使ってヒストグラム（度数分布、山の形がそのまま見えるグラフ）で表示してみました※Claude Code で Python を書いてもらいました。。。いい時代だ。。。

大阪 az2↔az3 には約300μs / 約370μs / 約450μs に3つの山、東京 az1↔az2 にも約540μs と約605μs に2つの山があります。

なぜ山が複数できるのでしょうか。学校から駅まで行くのに近道と大回りの2ルートあると、所要時間も2グループに分かれますよね。それと同じで、AZ 間（建物の間）に複数の通信経路があり、時間帯や機器の状態によって通る道が変わっているのではないかと推測しています（AWS の内部構成は非公開なので、あくまで観測からの推測です）。

そして冒頭の話につながります。大阪 az1↔az2 の平均 147.7μs は、129μs の山と 200μs 前後の山の間の谷にあり、実際にはほとんど存在しない値です。平均値だけを信じて設計すると、25%の通信が想定より1.5倍遅い、という現実を見落とすことになります。

注意点・制約

• netperf と sockperf では数字の意味が違います。netperf は往復の時間、sockperf は片道（往復の半分）を報告します。比べるときは sockperf の値を約2倍してください。実際、東京 az1↔az2 は sockperf 604μs × 2 ≒ 1,208μs で、netperf の 1,141μs とだいたい合います。送るデータの大きさも netperf は 1 バイト、sockperf は 14 バイトと少し違います
• netperf 2.7.0 のビルドでハマりました。Amazon Linux 2023 では CFLAGS=-fcommon を付けないとエラーになります。さらに --enable-demo オプションを付けると demo_interval_display が見つからないというリンクエラーで失敗するため、外しました
• 記録ファイルはかなり大きくなります。同じ AZ 内のような速い環境だと60秒で100万回以上やりとりするので、CSV が数十MBになります。gzip で圧縮してから回収するのがおすすめです
• 今回の結果は2026年7月13日午前のスナップショットです。ネットワークの状態は日々変わりますし、元記事でも年によって傾向が変わることが示されています。設計判断に使う場合はご自身の環境で測り直すことをおすすめします
• AZ の名前と場所の対応はアカウントごとに違います。他の人の測定結果と比べるときは必ず AZ ID で確認してください

まとめ

• 通信を1回ずつ全部記録する方法（sockperf の full-log）で、AZ 間レイテンシ約590万サンプルの「分布の形」まで見えました
• 東京は「遅いけど安定」（p99 は真ん中の値の約1.1倍）、大阪は「速いけどばらつく」（同 約1.3〜1.9倍）でした
• レイテンシの山は1つではありませんでした。平均値は、どの山にも属さない「実在しない値」になることがあります
• 元記事の平均値ともよく一致し（東京 az1↔az2: 1,150 vs 1,144μs）、測定の確からしさも確認できました

「平均◯◯μs」という1つの数字の裏には、様々なデータが隠れています。速さが大事なシステムを設計するときは、平均値だけでなく percentile と分布の形まで見てみてるより要件に沿った準備ができそうですね。

元記事の tsumita さんの年次定点観測に感謝しつつ、本記事が分布視点の補完になれば幸いです。山が複数できる原因（AZ 間の物理経路構成）について詳しい方がいらっしゃいましたら、ぜひ教えてください。

参考

• AWSのAZ間レイテンシを測定してみた（2026年東京/大阪）- Zenn
• sockperf - GitHub (Mellanox)
• netperf - GitHub (HewlettPackard)
• AZ ID とアベイラビリティーゾーン - AWS ドキュメント
• リージョンとアベイラビリティーゾーン - AWS
• Amazon EC2 C7i インスタンス