developersIO
[アップデート]ENA Express がクロス AZ 通信に対応し単一フロー帯域が最大 25Gbps になりました

[アップデート]ENA Express がクロス AZ 通信に対応し単一フロー帯域が最大 25Gbps になりました

Amazon EC2AWS
2026.05.27

はじめに

ENA Express は、AWS の SRD（Scalable Reliable Datagram）プロトコルを使って EC2 インスタンス間の帯域とテールレイテンシを改善する機能です。2026 年 5 月のアップデートまでは、SRD が有効になるのは同一 AZ 内の通信のみでした。AZ をまたぐ通信では通常の ENA にフォールバックするため、マルチ AZ 構成の DB レプリケーションや分散ストレージでは SRD の恩恵を受けられませんでした。この度、同一リージョン内であれば AZ 間でも SRD が使えるようになりました。

ENA Expres.png

https://aws.amazon.com/jp/about-aws/whats-new/2026/05/ena-express-availability-zones/

確認結果

アップデートのおかげで、単一フローの帯域はクロス AZ で 12.6 Gbps と、従来 ENA の上限 5 Gbps を 2 倍以上上回っており、SRD の効果が発揮されています。RTT が同一 AZ よりだいぶ大きいのは AZ 間で物理距離が離れているため、ここは仕方がありません。詳細は「計測結果」セクションを参照してください。

区間 単一フロー帯域 RTT P99
同一AZ 24.3 Gbps 56.7 µs
クロスAZ 12.6 Gbps 677.4 µs

ENA Express と SRD のおさらい

ENA Express は、EC2 インスタンスの ENI アタッチメントごとに有効化できる機能です。SRD プロトコルを使った高スループット・低レイテンシ通信を提供し、追加ソフトウェアは不要です。

SRD（Scalable Reliable Datagram） は AWS が独自開発したネットワークトランスポートプロトコルです。マルチパス転送と SRD により、単一フローで最大 25 Gbps の帯域を引き出せます。また、輻輳を検出したパスを動的に回避してテールレイテンシを削減します。

SRD のマルチパス転送のイメージ（re:Invent 2022 CMP333）

画像引用: AWS re:Invent 2022 - Scaling network performance on next-gen Amazon EC2 instances (CMP333)

詳細は以下の記事を参照ください。

https://dev.classmethod.jp/articles/reinvent2022-cmp333/

従来の仕様と今回のアップデート

アップデート前は、AZ をまたぐ通信で SRD が動作せず、通常の ENA で最大 5 Gbps に制限されていました。今回のアップデートでクロス AZ 通信でも SRD のマルチパス転送が使えます。シングルフロー帯域は 5 Gbps から最大 25 Gbps に引き上げられました。

ENA Express の利用に追加料金はかかりません。ですが、対応しているインスタンスタイプは一部の.8xlargeと、ある程度大きなサイズに限られています。対応可否を含む最新の一覧は公式ドキュメントを参照してください。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ena-express.html

検証環境

同一 AZ とクロス AZ を 1 回の起動でまとめて計測するため、3 台構成にしました。クライアント 1 台から同一 AZ とクロス AZ のサーバーへ順に計測しました。

項目 値
リージョン us-west-2（オレゴン）
クライアント us-west-2a
同一AZサーバー us-west-2a（クライアントと同一AZ）
クロスAZサーバー us-west-2b
インスタンスタイプ c8gn.8xlarge（Graviton4、最大 100Gbps）
OS Amazon Linux 2023（arm64）

c8gn.8xlarge の選定理由は 3 つあります。ENA Express に対応している中で安価であったこと、100 Gbps の帯域で SRD シングルフロー上限の 25 Gbps を余裕でカバーできることです。あとは、Graviton インスタンスを使いたいだけです。

検証手順

検証は次の流れで進めます。インスタンスの起動と SRD 有効化、計測ツールのインストール、サーバー・クライアント間の計測です。

EC2 インスタンスの起動と SRD 有効化

c8gn.8xlarge を 3 台起動します。1 台をクライアント、残り 2 台を同一 AZ・クロス AZ それぞれのサーバーにします。クライアントと同一 AZ サーバーを us-west-2a、クロス AZ サーバーを us-west-2b に配置します。

インスタンス___EC2___us-west-2.png

起動後、各インスタンスの ENI に対して ENA Express（SRD）を有効化します。3 台すべての ENI に対して実行します。

aws ec2 modify-network-interface-attribute \
    --network-interface-id eni-xxxxx \
    --ena-srd-specification 'EnaSrdEnabled=true,EnaSrdUdpSpecification={EnaSrdUdpEnabled=true}' \
    --region us-west-2

SRD 有効化の確認

AWS CLI でアタッチメントの設定を確認します。

aws ec2 describe-network-interfaces \
    --network-interface-ids eni-xxxxx \
    --query 'NetworkInterfaces[].Attachment.EnaSrdSpecification' \
    --region us-west-2
実行結果
[
    {
        "EnaSrdEnabled": true,
        "EnaSrdUdpSpecification": {
            "EnaSrdUdpEnabled": true
        }
    }
]

EC2 インスタンスからも ethtool コマンドで確認できます。ENA ドライバの統計情報で、ENA ドライバ 2.8 以降で取得できます。ena_srd_mode が 3（ENA Express on、UDP on）であれば意図した状態です。

# デフォルトインターフェイス名を変数に入れる（環境により eth0 / ens5 / ens34 等）
IF=$(ip route show default | awk '{print $5}')

$ ethtool -S "$IF" | grep ena_srd
+     ena_srd_mode: 3
     ena_srd_tx_pkts: 0
     ena_srd_eligible_tx_pkts: 0
     ena_srd_rx_pkts: 0
     ena_srd_resource_utilization: 0

SRD の動作確認で見るのは次の 2 つのカウンターです。

  • ena_srd_tx_pkts: SRD で送信したパケット数
  • ena_srd_eligible_tx_pkts: SRD の対象条件（両インスタンスで ENA Express 有効など）を満たす送信パケット数

トラフィックを流す前後で ena_srd_tx_pkts が増えれば、SRD が実際に使われた証拠になります。ena_srd_eligible_tx_pkts とほぼ同じ値なら、対象パケットのほぼすべてが SRD 経由です。カウンターはインスタンスの再起動・終了や ENI のデタッチでリセットされます。

計測ツールの導入

3 台それぞれに iperf3 / ethtool / sockperf を導入します。iperf3 と ethtool は Amazon Linux 2023 の標準リポジトリから入ります。

sudo dnf install -y iperf3 ethtool

sockperf は標準リポジトリに無いためソースからビルドします。ビルドには git やコンパイラに加え、autogen.sh が使う libtool が必要でした。（ハマりました）

sudo dnf install -y git automake autoconf libtool gcc gcc-c++ make perl
git clone https://github.com/Mellanox/sockperf.git
cd sockperf
./autogen.sh
./configure --prefix=/usr/local
make -j"$(nproc)"
sudo make install

インストール後、バージョンを確認します。

$ sockperf --version
sockperf, version 3.10-33.git3c65ad99cd38

サーバー側の準備

同一 AZ サーバーとクロス AZ サーバーの両方で、iperf3 と sockperf のサーバーを起動しておきます。

# 帯域計測用サーバー（TCP 5201 で待ち受け）
iperf3 -s

# RTT 計測用サーバー（UDP 11111 で待ち受け）
sockperf server -p 11111

同一AZサーバーへ計測

クライアントから同一 AZ サーバーの private IP に対して計測します。接続先 IP は EC2 コンソール、または aws ec2 describe-instances で確認します。コマンド例の <same_az_server_ip> をその値に置き換えてください。

# 単一フロー帯域（TCP 1 ストリーム、15 秒）※ 今回一番確認したいところ
iperf3 -c <same_az_server_ip> -t 15 -P 1

# 合計帯域（TCP 8 ストリーム、20 秒）
iperf3 -c <same_az_server_ip> -t 20 -P 8

# 往復レイテンシ（UDP ping-pong、15 秒、全 RTT を記録）
sockperf ping-pong -i <same_az_server_ip> -p 11111 -t 15 --full-rtt

# SRD カウンター（計測の前後で実行して増分を見る）
ethtool -S "$IF" | grep ena_srd

同一 AZ の単一フロー帯域の結果です。sockperf を含む全文は計測結果セクションに折りたたみで載せています。

[  5]   0.00-15.00  sec  42.5 GBytes  24.3 Gbits/sec    0             sender
[  5]   0.00-15.00  sec  42.5 GBytes  24.3 Gbits/sec                  receiver

クロスAZサーバーへ計測

接続先をクロス AZ サーバーの private IP に変えて同じコマンドを実行します。

iperf3 -c <cross_az_server_ip> -t 15 -P 1
iperf3 -c <cross_az_server_ip> -t 20 -P 8
sockperf ping-pong -i <cross_az_server_ip> -p 11111 -t 15 --full-rtt
ethtool -S "$IF" | grep ena_srd

クロス AZ の単一フロー帯域の結果です。同一 AZ の 24.3 Gbps に対して 12.6 Gbps ですが、従来 ENA の上限 5 Gbps を大きく上回っています。

[  5]   0.00-15.00  sec  22.0 GBytes  12.6 Gbits/sec    0             sender
[  5]   0.00-15.00  sec  22.0 GBytes  12.6 Gbits/sec                  receiver

計測結果

帯域は iperf3 の単一フロー（-P 1）と 8 ストリーム（-P 8）、RTT は sockperf ping-pong の結果です。

区間 単一フロー帯域 8 ストリーム帯域 RTT P50 RTT P99 RTT P99.9
同一AZ 24.3 Gbps 99.8 Gbps 52.2 µs 56.7 µs 59.5 µs
クロスAZ 12.6 Gbps 86.8 Gbps 590.4 µs 677.4 µs 702.0 µs

アップデートによる恩恵は単一フローの帯域です。クロス AZ で 12.6 Gbps を記録し、従来 ENA のシングルフロー上限 5 Gbps を 2 倍以上上回りました。SRD のマルチパス転送がクロス AZ でも機能しています。同一 AZ は 24.3 Gbps で、公式の最大値 25 Gbps に近い値でした。

RTT はクロス AZ が同一 AZ の約 10 倍ですが、これは AZ 間が物理的に離れているため遅くなるのは想定どうりです。SRD が無効なわけではありません。SRD のテールレイテンシ削減は輻輳時に効果を発揮するため、今回は無輻輳状態での計測のため、P99 と P50 の差は小さく出ています。

SRD が実際に使われているかは ena_srd_tx_pkts の増分で確認できます。細かいので計測ログ（全文）をご確認ください。計測中の増分は同一 AZ で約 2,820 万パケット、クロス AZ で約 2,450 万パケットでした。いずれも ena_srd_eligible_tx_pkts（SRD 対象パケット数）とほぼ一致しており、対象パケットのほぼすべてが SRD 経由で送信されています。

実際の計測ログを以下に残します。

同一 AZ の計測ログ（全文）
# 単一フロー（iperf3 -P 1, 15秒。8 ストリームや sockperf とは別に実行。下の SRD カウンター対象外）
[  5]   0.00-15.00  sec  42.5 GBytes  24.3 Gbits/sec    0             sender
[  5]   0.00-15.00  sec  42.5 GBytes  24.3 Gbits/sec                  receiver

# 8 ストリーム（iperf3 -P 8, 20秒）
[SUM]   0.00-20.00  sec   232 GBytes  99.8 Gbits/sec  372             sender
[SUM]   0.00-20.00  sec   232 GBytes  99.8 Gbits/sec                  receiver

# RTT（sockperf ping-pong UDP, 15秒）
sockperf: ====> avg-rtt=52.267 (std-dev=2.088, mean-ad=1.618, median-ad=2.071, siqr=1.390, cv=0.040, std-error=0.004, 99.0% ci=[52.257, 52.277])
sockperf: Summary: Round trip is 52.267 usec
sockperf: Total 278105 observations; each percentile contains 2781.05 observations
sockperf: ---> <MAX> observation =   97.501
sockperf: ---> percentile 99.999 =   94.858
sockperf: ---> percentile 99.990 =   87.156
sockperf: ---> percentile 99.900 =   59.523
sockperf: ---> percentile 99.000 =   56.670
sockperf: ---> percentile 90.000 =   54.811
sockperf: ---> percentile 75.000 =   53.737
sockperf: ---> percentile 50.000 =   52.175
sockperf: ---> percentile 25.000 =   50.954
sockperf: ---> <MIN> observation =   46.155

# SRD カウンター（ethtool -S ens34）
計測前        : ena_srd_tx_pkts=0          ena_srd_eligible_tx_pkts=0
8ストリーム後 : ena_srd_tx_pkts=28195047   ena_srd_eligible_tx_pkts=28195063
sockperf後    : ena_srd_tx_pkts=28480994   ena_srd_eligible_tx_pkts=28481011
クロス AZ の計測ログ（全文）
# 単一フロー（iperf3 -P 1, 15秒。8 ストリームや sockperf とは別に実行。下の SRD カウンター対象外）
[  5]   0.00-15.00  sec  22.0 GBytes  12.6 Gbits/sec    0             sender
[  5]   0.00-15.00  sec  22.0 GBytes  12.6 Gbits/sec                  receiver

# 8 ストリーム（iperf3 -P 8, 20秒）
[SUM]   0.00-20.00  sec   202 GBytes  86.8 Gbits/sec    4             sender
[SUM]   0.00-20.00  sec   202 GBytes  86.8 Gbits/sec                  receiver

# RTT（sockperf ping-pong UDP, 15秒）
sockperf: ====> avg-rtt=592.805 (std-dev=35.226, mean-ad=26.481, median-ad=31.041, siqr=21.016, cv=0.059, std-error=0.225, 99.0% ci=[592.226, 593.384])
sockperf: Summary: Round trip is 592.805 usec
sockperf: Total 24542 observations; each percentile contains 245.42 observations
sockperf: ---> <MAX> observation =  704.778
sockperf: ---> percentile 99.999 =  704.778
sockperf: ---> percentile 99.990 =  704.408
sockperf: ---> percentile 99.900 =  702.036
sockperf: ---> percentile 99.000 =  677.422
sockperf: ---> percentile 90.000 =  645.293
sockperf: ---> percentile 75.000 =  612.676
sockperf: ---> percentile 50.000 =  590.375
sockperf: ---> percentile 25.000 =  570.643
sockperf: ---> <MIN> observation =  485.889

# SRD カウンター（ethtool -S ens34）
計測前        : ena_srd_tx_pkts=28480994   ena_srd_eligible_tx_pkts=28481011
8ストリーム後 : ena_srd_tx_pkts=53015315   ena_srd_eligible_tx_pkts=53015350
sockperf後    : ena_srd_tx_pkts=53040614   ena_srd_eligible_tx_pkts=53040649

まとめ

クロス AZ 通信でも ena_srd_tx_pkts が増加し、SRD 通信を確認できました。単一フロー帯域は従来 ENA の 5 Gbps から 12.6 Gbps へ伸び、効果が数値で見えました。RTT が同一 AZ より大きいのは AZ 間の物理距離によるもので SRD は問題なく動いています。

恩恵が大きいのは、AZ をまたぐ単一フローの帯域が 5 Gbps で頭打ちになっていたワークロードです。

  • マルチ AZ DB レプリケーション
    • マネージメントサービスの RDS は AWS 側で SRD 通信をサポート済み
  • AZ 間に分散したストレージのレプリカ通信

設定は対応インスタンスの ENI で EnaSrdEnabled=true に切り替えるだけで、追加料金もかかりません。混雑時の P99 が読めなかったケースにも効きます。一方で AZ 間のレイテンシそのものは縮まらないため、距離由来の遅延を減らしたい用途には向きません。

おわりに

当初 RDS の裏側で使わている技術がユーザー側に解放されたのかなと思っていました。後日、RDS で利用可能になったアナウンスがでたので先行して公開されただけでした。RDS の方も検証したいので時間見つけて試してみます。

https://aws.amazon.com/jp/about-aws/whats-new/2026/05/amazon-rds-ena-express-multiAZ/

参考

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

[アップデート]EC2 が特定の宛先への帯域幅の拡大とジャンボフレームをサポートするようになりました
あかいけ
2025.04.04
Amazon Aurora Global Database のリージョン切り替え（スイッチオーバー）が速くなったらしいので実際に確認してみた
Guri / Hajime Oguri
2025.05.27
[アップデート]AWS EC2インスタンスでENAキューの柔軟な割り当てが可能になりました
みなみ
2025.05.31
[アップデート]ENA Express 対象インスタンスが58サイズ追加されました！無料でENAのレイテンシ削減！ #AWSreinvent
千葉淳
2023.11.28