技術記事 2026/8/2

EKS Auto Mode が EFA・プレイスメントグループに対応 — 分散学習/推論のネットワーク設計はどう変わるか

EKS Auto Mode と OSS版 Karpenter のノードプール設定から、EFA のネットワークデバイス構成と EC2 プレイスメントグループ（cluster/spread/partition）を直接指定できるようになりました。前提となる EFA と配置戦略の整理から、種別の使い分け、EFA-only インターフェースが IP アドレス設計に与える影響までを解説します。

#EKS
#Karpenter
#EFA
#Kubernetes
#分散学習
#生成AI

生成AIモデルの学習や大規模な推論を Kubernetes 上で回す構成では、GPU そのものの性能と同じくらい「ノード同士がどれだけ速く通信できるか」がジョブ全体のスループットを左右します。2026年7月22日、Amazon EKS が EFA（Elastic Fabric Adapter）のネットワークデバイス設定と EC2 プレイスメントグループを、EKS Auto Mode と OSS 版 Karpenter プロジェクトのノードプール設定から直接指定できるようになりました。

本記事では、前提となる EFA とプレイスメントグループの整理から始め、今回の対応で何が変わったのか、分散学習・分散推論のネットワーク設計でどこを判断ポイントにすべきかを順に解説します。対象は EKS 上で GPU ワークロードを設計するプラットフォーム／MLOps 寄りのエンジニアです。

前提①: EFA とは何か

Elastic Fabric Adapter（EFA）は、EC2 インスタンスに取り付けるネットワークインターフェイスの一種で、HPC（高性能計算）や機械学習の集団通信を高速化するために用意されたものです。

通常の ENI（Elastic Network Interface。EC2 の標準的な仮想ネットワークインターフェイス）と決定的に違うのは、OS のネットワークスタックを迂回してハードウェアに直接アクセスする経路（OS バイパス）を持つ点です。レイテンシ（通信の待ち時間）とそのばらつきが抑えられるため、多数のノードが足並みを揃えて通信する処理で効いてきます。分散学習では NCCL などの集団通信ライブラリが Libfabric を介してこの経路を使います。

押さえておくべき制約が2つあります。1つは、EFA は対応したインスタンスタイプでのみ利用できること。もう1つは、OS バイパスによる通信は同一サブネット内に閉じるという点です。後者はプレイスメントグループの選択やサブネット設計と直結します。

前提②: プレイスメントグループの3つの戦略

EC2 プレイスメントグループは、インスタンスが物理的にどう配置されるかを制御する仕組みです。戦略は3種類あり、狙いがはっきり分かれます。

戦略	物理配置	主な狙い	代表的な制約
cluster	単一アベイラビリティゾーン（AZ）内の近接したハードウェアにまとめる	ノード間の低レイテンシ・高帯域	単一 AZ に閉じる。まとまった台数を一度に確保できない場合がある
spread	電源・ネットワークが独立した別々のラックに分散する	同時障害を避ける	1つの AZ あたり実行中インスタンス7台まで
partition	複数のパーティションに分け、パーティション間でハードウェアを共有しない	障害の影響範囲をパーティション単位に限定	1つの AZ あたり最大7パーティション

cluster・spread・partition の3戦略を物理配置で比較した図。cluster は単一 AZ の近接したハードウェアに GPU ノードをまとめて EFA の集団通信を高速化し、単一 AZ に閉じる制約を持つ。spread は電源・ネットワークが独立した別々のラックに1台ずつ分散し、1 AZ あたり実行中インスタンス7台までの上限がある。partition はパーティション間でハードウェアを共有せず障害を1パーティション分に収め、1 AZ あたり最大7パーティションという上限を持つ — 図1: cluster が「速さ」、spread と partition が「壊れ方のコントロール」を担う

何が変わったか

今回のアップデートで追加されたのは、次の内容です。

プレイスメントグループの指定: cluster / spread / partition の3戦略を、EKS Auto Mode または Karpenter のノードプール設定から直接指定して EC2 インスタンスを起動できます。
EFA ネットワークデバイスの構成: EFA 対応インスタンスに対して、ネットワークインターフェイスを「EFA のみ（EFA-only）」または「標準 ENI」として構成できます。
EFA-only は IP アドレスを消費しない: 公式発表では、EFA-only インターフェイスは IP アドレスを消費せず、相互接続の帯域はフルに使えると明記されています。
動的・静的の両方の容量ノードプールに対応: 需要に応じて増減する動的な構成でも、台数を固定する静的な構成でも利用できます。
提供範囲: Amazon EKS が提供されているすべての AWS リージョンで利用できます。

これまでの手動設定との違い

これらは以前から EC2 側の機能としては存在していました。変わったのは「どこで宣言するか」です。

観点	これまで	今回の対応後
配置戦略・EFA の定義場所	起動テンプレートなど EC2 側の設定として個別に用意する	ノードプールの設定に含めて宣言する
オートスケールとの関係	ノード追加の仕組みとは別レイヤーで管理され、追加の作り込みが必要になりやすい	Karpenter がワークロード起因でノードを起動する流れにそのまま乗る
ワークロードごとの出し分け	別系統のノードグループを用意して運用で切り分ける	ノードプールを分けて、それぞれに戦略と EFA 構成を書き分ける

実務上の効き目が大きいのは3行目です。「同期型の分散学習ジョブ用に cluster + EFA-only のノードプール」「本番推論のレプリカ用に spread のノードプール」といった出し分けを、同じ Kubernetes のマニフェスト体系の中で表現できます。公式発表でも、追加の運用上の回避策なしに物理配置を制御できる点が強調されています。

設計判断①: プレイスメントグループ種別の使い分け

選択の分かれ目は「そのノード群が1本の大きなジョブを分担しているのか、それとも独立したレプリカの集まりなのか」です。

ワークロードの性質	向く戦略	理由
1つの学習ジョブを多数の GPU ノードで分担する（同期型の分散学習）	cluster	各ステップで全ノードが集団通信するため、遅い1ノードが全体を待たせる。物理的な近さが学習時間に直結する
少数だが停止が許されない構成要素（スケジューラ、モデルレジストリ、推論のフロント等）	spread	ラック単位で分けて同時障害を避けられる。ただし1 AZ あたり7台の上限があり大規模な GPU 群には使えない
多数のレプリカを抱える分散システムを、障害単位で束ねたい	partition	パーティション単位でハードウェアが分離され、影響範囲を1パーティション分に閉じ込められる

分散学習では cluster がほぼ既定の選択肢になりますが、代償として単一 AZ に閉じる点は設計に織り込む必要があります。AZ 全体に影響する事象が起きればジョブは丸ごと止まるため、チェックポイントの取得間隔と再開手順をセットで決めておきましょう。

また cluster はまとまった台数を同時に確保しようとする性質上、必要な台数を起動できないケースがあります。台数を固定したい学習基盤では静的な容量のノードプールと組み合わせて検討するのが安全です。

設計判断②: EFA-only インターフェースと IP アドレス設計

EKS では VPC CNI が Pod に VPC の IP アドレスを割り当てるため、ノードを増やすほどサブネットの IP アドレスを消費します。GPU ノードを大量に並べる基盤では、この IP 消費がサブネットの CIDR 設計にそのまま跳ね返ってきます。

EFA 対応の大型インスタンスは複数のネットワークカードを備え、カードごとにインターフェイスを構成します。各インターフェイスを標準 ENI として構成すればその分だけ IP アドレスが使われますが、EFA-only として構成したインターフェイスは IP アドレスを消費しません。帯域は確保しつつ IP 消費は抑えるという選び方ができるようになったわけです。

ネットワークカードを4枚持つ EFA 対応 GPU ノードで、インターフェイス構成による IP アドレス消費を比較した図。すべて標準 ENI として構成すると4つとも VPC の IP を消費しノード1台あたり4個ぶんを使う。管理通信・Pod 用の1つだけを標準 ENI にし、残り3つを EFA-only にすると EFA-only 側は IP を消費せず、ノード1台あたり1個ぶんの IP 消費に抑えられる。相互接続の帯域はフルに使えるが、すべてを EFA-only にはできない — 図2: EFA-only インターフェースは IP アドレスを消費しない

設計としては、次の順で考えると整理しやすくなります。

ノードの管理通信と Pod への IP 割り当てには、通常どおり IP アドレスを持つインターフェイスが必要です。「すべて EFA-only」にはできません。
集団通信の帯域を稼ぐために追加するインターフェイスは、EFA-only を選べます。ここが IP 消費を左右する部分です。
EFA の OS バイパス通信は同一サブネットに閉じるため、cluster 戦略で単一 AZ に寄せる設計とサブネットの切り方は連動します。ノードプールが使うサブネットを絞り込む前提で CIDR を確保しておきましょう。

サブネットの IP 枯渇は、GPU ノードを増やそうとした段階で初めて表面化しがちな問題です。ノードプール設計と同時に、そのサブネットの残 IP 数を見積もっておくと後戻りを避けられます。

実務で使うときの注意点

インスタンスタイプの制約: EFA は対応インスタンスタイプでのみ利用できます。ノードプールの要件（requirements）で対象を明示的に絞り込んでおきましょう。
セキュリティグループの設定: EFA を使うノード同士の通信には、同じセキュリティグループを参照する許可ルールが必要です。既存のノード用セキュリティグループをそのまま流用すると通信が成立しないことがあります。
Pod 側の対応も必要: ノードに EFA が構成されても、それだけで Pod が使えるわけではありません。コンテナ側で EFA を要求する設定と、対応する通信ライブラリを含んだイメージが必要です。
リージョンと在庫は別問題: 機能自体は EKS 提供の全リージョンで使えますが、EFA 対応の GPU インスタンスが同じように確保できるとは限りません。使用予定のリージョン・AZ で事前に確認してください。

まとめ

本記事のポイントを3つに整理します。

宣言場所がノードプールに移った: EFA のネットワークデバイス構成と EC2 プレイスメントグループを、EKS Auto Mode と OSS 版 Karpenter のノードプール設定から直接指定できるようになりました。
戦略の選択はワークロードの性質で決まる: 同期型の分散学習は cluster、可用性と影響範囲の限定は spread / partition。cluster は単一 AZ に閉じるため、チェックポイントとキャパシティ確保の設計が前提になります。
EFA-only は IP 設計の選択肢になる: EFA-only インターフェイスは IP アドレスを消費しないため、帯域を確保しながらサブネットの IP 消費を抑えられます。ノードプールとサブネットの CIDR はセットで見積もりましょう。