はじめに

2026 年 4 月 21 日、AWS は Amazon EKS Hybrid Nodes を使ったハイブリッド Kubernetes 環境向けの新機能「Amazon EKS Hybrid Nodes gateway」の一般提供（GA）を発表しました。

この機能は、EKS クラスターの VPC とオンプレミスで稼働する EKS Hybrid Nodes 上の Pod 間のネットワーキングを自動化するものです。追加料金なし、オープンソースで提供されます。

本記事では「何が変わったのか」「実際にどう設定するのか」「導入前に何を確認すべきか」を中心に解説します。EKS Hybrid Nodes を使っていてネットワーク設定の煩雑さを感じているエンジニアや、これからハイブリッド Kubernetes 環境の導入を検討しているチームはぜひ読んでみてください。

EKS Hybrid Nodes のおさらい

EKS Hybrid Nodes は、2024 年 12 月の AWS re:Invent 2024 で一般提供（GA）が発表された機能です。オンプレミスやエッジ環境のサーバーを EKS クラスターのノードとして登録し、クラウドと同じ EKS の操作感でオンプレミスのワークロードを管理できるようにします。

従来、オンプレミスで Kubernetes を運用するには、コントロールプレーンの構築・運用・アップデートをすべて自前で行う必要がありました。EKS Hybrid Nodes を使うと、コントロールプレーンの管理は AWS に任せつつ、ワークロードはオンプレミスに置いたまま運用できます。低レイテンシ要件やデータ主権・規制対応といった理由でオンプレミスを手放せない環境でも、EKS の機能やツールをそのまま活用できる点が最大のメリットです。

EKS Hybrid Nodes gateway は、この EKS Hybrid Nodes 環境で発生するネットワーク課題を解消する機能として今回発表されました。次のセクションで詳しく見ていきます。

何が変わったのか

EKS Hybrid Nodes でオンプレミスのノードを EKS クラスターに接続した後も、VPC とオンプレミス Pod 間のネットワーク設定は運用者が手動で管理する必要がありました。EKS Hybrid Nodes gateway はこの課題を自動化します。まず変化の全体像を見てみましょう。

項目	Before	After
Pod CIDR のルーティング	オンプレ側ルーターに手動追加	自動管理
VPC ルートテーブルの更新	スケールのたびに手動対応	スケールに追従して自動更新
Webhook への通信	別途ネットワーク設定が必要	自動で有効化
ALB / NLB / Prometheus との接続	個別に設定・調整が必要	自動で接続性を確保
ネットワークチームとの調整	都度必要	最小化

従来の課題

EKS Hybrid Nodes 導入後も、次のような手動作業が継続的に発生していました。

Pod CIDR をオンプレ側のルーターに手動登録
ワークロードのスケールのたびに VPC ルートテーブルを手動更新
Webhook 通信のためにネットワークチームと都度調整
ALB・NLB・Amazon Managed Service for Prometheus との接続を個別に設定

一度設定すれば終わりではなく、構成変更のたびに発生するのがポイントです。

EKS Hybrid Nodes gateway による解決

Helm を使って EC2 インスタンスにデプロイするだけで、以下の 4 つのトラフィックフローが自動的に有効になります。

1. コントロールプレーン → Webhook 通信

オンプレミスのノード上で動作する Admission Webhook へ、Kubernetes コントロールプレーンからの通信が届くようになります。OPA/Gatekeeper などのポリシーエンジンをハイブリッド環境で動かす際に有効です。

2. Pod 間通信（クラウド ↔ オンプレミス）

VPC 上の Pod とオンプレミスの Pod が互いに直接通信できます。クラウド側のフロントエンドとオンプレミス側のバックエンドを同一クラスター内で連携させるような構成が、追加のネットワーク設定なしで実現できます。

3. AWS サービス → オンプレミス Pod

ALB・NLB によるロードバランシングや、Amazon Managed Service for Prometheus によるメトリクス収集が、オンプレミスの Pod に対しても透過的に機能します。

4. VPC ルートテーブルの自動管理

ワークロードのスケールアウト・インに応じて、VPC ルートテーブルが自動的に更新されます。

ゲートウェイの仕組み

EKS Hybrid Nodes gateway が VPC とオンプレミスの通信を自動化する仕組みを整理します。

ゲートウェイの構成

ゲートウェイは EC2 ノード上に 2 つの Pod が Deployment として動作し、Kubernetes の Lease ベースのリーダー選出で Active/Standby を決定します。Active Pod がリーダーとして VPC ルートテーブルの更新と Cilium VTEP の設定を担います。Standby Pod は常に VXLAN インターフェースと CiliumNode の監視を継続しているため、リーダー障害時のフェイルオーバーは約 3〜5 秒で完了します。

VXLAN トンネルによる Pod 間通信

Active Pod は hybrid_vxlan0 という VXLAN インターフェース（VNI 2・UDP 8472）を作成し、Hybrid Node ごとに FDB エントリ・ARP エントリ・ルートを設定してトンネルを確立します。CiliumNode オブジェクトを監視しているため、Hybrid Node の追加・削除に応じてトンネルが自動的に増減します。VPC ルートテーブルにはハイブリッド Pod の CIDR を Active Pod の ENI へ向けるルートが自動登録され、VPC 側からのトラフィックが常に Active Pod 経由で転送されます。

Cilium VTEP との連携

ゲートウェイは CiliumVTEPConfig カスタムリソースを作成し、Hybrid Node 上の Cilium エージェントに対して「VPC 宛のトラフィックをどこへ送るか」を通知します。Hybrid Node 上の Pod が VPC 宛のパケットを送信すると、Cilium がそのパケットを VXLAN でカプセル化して Active Pod へ転送します。

この構造が、後述する「VXLAN トンネルは暗号化を持たない」「Cilium CNI 以外では動作しない」という制約の背景にあります。

デプロイ手順

前提条件

インストール前に以下が満たされていることを確認してください。

Hybrid Node 上の CNI が EKS 版 Cilium（VTEP サポート有効）であること
ゲートウェイノードを含むクラウドノードで AWS VPC CNI が使用されていること
VPC とオンプレミス間に AWS Direct Connect・AWS Site-to-Site VPN いずれかのプライベート接続があること
ゲートウェイ EC2 インスタンスのセキュリティグループおよびオンプレミスのファイアウォールで UDP 8472 の送受信が許可されていること
ゲートウェイが VPC ルートテーブルを管理するための IAM 権限があること（EKS Pod Identity の使用を推奨）
- ec2:DescribeRouteTables
- ec2:CreateRoute
- ec2:ReplaceRoute
- ec2:DescribeInstances

ゲートウェイノードの準備

ゲートウェイは高可用性のため 2 台以上のノードが必要です。ノードのプロビジョニング方法は 2 通りあります。

EKS Auto Mode（推奨）

NodePool と NodeClass を作成することで、ノードのプロビジョニングや Source/Destination Check の無効化が自動で行われます。

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: hybrid-gateway
spec:
  advancedNetworking:
    sourceDestCheck: DisabledPrimaryENI   # トラフィック転送に必要
  role: YOUR_NODE_ROLE
  securityGroupSelectorTerms:
    - tags:
        aws:eks:cluster-name: YOUR_CLUSTER_NAME
  subnetSelectorTerms:
    - id: SUBNET_ID_1   # 異なる AZ を指定して冗長化
    - id: SUBNET_ID_2
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: hybrid-gateway
spec:
  template:
    metadata:
      labels:
        hybrid-gateway-node: "true"
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: hybrid-gateway
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: eks.amazonaws.com/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
      taints:
        - key: hybrid-gateway-node
          effect: NoSchedule

マネージドノードグループ

Auto Mode を使用しない場合は、Source/Destination Check を無効化するユーザーデータを含むカスタム起動テンプレートを作成した上で、マネージドノードグループを作成します。

aws eks create-nodegroup \
  --cluster-name YOUR_CLUSTER_NAME \
  --nodegroup-name YOUR_CLUSTER_NAME-gateway-nodes \
  --subnets SUBNET_ID_1 SUBNET_ID_2 \
  --node-role YOUR_NODE_ROLE_ARN \
  --instance-types INSTANCE_TYPE \
  --scaling-config desiredSize=2,maxSize=2,minSize=2 \
  --labels hybrid-gateway-node=true \
  --taints "key=hybrid-gateway-node,effect=NO_SCHEDULE" \
  --launch-template "name=YOUR_CLUSTER_NAME-gateway-lt,version=1"

起動テンプレートの作成手順など詳細は公式ドキュメントを参照してください。

Helm でインストール

EKS Auto Mode

helm install eks-hybrid-nodes-gateway \
  oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \
  --version 1.0.0 \
  --namespace eks-hybrid-nodes-gateway \
  --create-namespace \
  --set vpcCIDR=VPC_CIDR \
  --set podCIDRs=POD_CIDRS \
  --set routeTableIDs=ROUTE_TABLE_IDS

マネージドノードグループ

autoMode.enabled=false を追加するのみで、その他のパラメーターは共通です。

helm install eks-hybrid-nodes-gateway \
  oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \
  --version 1.0.0 \
  --namespace eks-hybrid-nodes-gateway \
  --create-namespace \
  --set autoMode.enabled=false \
  --set vpcCIDR=VPC_CIDR \
  --set podCIDRs=POD_CIDRS \
  --set routeTableIDs=ROUTE_TABLE_IDS

--version には公開時点のバージョンを記載しています。最新バージョンは ECR Public Gallery で確認してください。

必須パラメーター

パラメーター	説明
`vpcCIDR`	EKS クラスター VPC の CIDR ブロック（例：`10.0.0.0/16`）
`podCIDRs`	Hybrid Node 上の Cilium が使用する Pod CIDR をカンマ区切りで指定（例：`10.100.0.0/16,10.101.0.0/16`）
`routeTableIDs`	ルートを登録する VPC ルートテーブル ID をカンマ区切りで指定（例：`rtb-0abc1234,rtb-0def5678`）

動作確認

Pod の起動確認

2 つの Pod が Running になっていることを確認します。

kubectl get pods -n eks-hybrid-nodes-gateway

リーダー選出の確認

いずれかの Pod がリーダーの Lease を取得していることを確認します。

kubectl get lease -n eks-hybrid-nodes-gateway

HOLDER 列にリーダー Pod 名が表示されていれば正常です。

ヘルスチェック

kubectl port-forward -n eks-hybrid-nodes-gateway LEADER_POD_NAME 8088:8088 &
curl -s http://localhost:8088/healthz

HTTP 200 が返れば正常に稼働しています。

導入前に確認しておきたいこと

制約

トラフィックは暗号化されない

ゲートウェイが作成する VXLAN トンネルはトラフィックを暗号化しません。「ゲートウェイの仕組み」で触れた通り、VXLAN はトンネリングの仕組みであり暗号化の機能は持ちません。転送中の暗号化が必要な場合は、MACsec 対応の AWS Direct Connect または VPN 接続を使用してください。

1 ゲートウェイにつき 1 クラスターのみ対応

各ゲートウェイデプロイメントは単一の EKS クラスターに対してのみ機能します。複数のクラスターで Hybrid Nodes を運用している場合は、クラスターごとに別途ゲートウェイをデプロイする必要があります。

Cilium CNI（VTEP 有効）が必須

ゲートウェイは Hybrid Node 上で VTEP サポートを有効にした EKS 版 Cilium CNI を必要とします。Calico など他の CNI プラグインはサポートされていません。既存環境で Cilium 以外を使用している場合は、CNI の移行が前提となります。

ベストプラクティス

異なる AZ に 2 ノード以上を配置する

高可用性のためゲートウェイノードは 2 台以上が推奨されます。それぞれのノードを異なる AZ のサブネットに配置することで、AZ 障害時にも継続して稼働できます。「デプロイ手順」の NodePool・マネージドノードグループいずれの手順でも、異なる AZ のサブネット ID を指定しているのはこのためです。

インスタンスタイプはネットワーク帯域幅を考慮して選定する

ゲートウェイは VPC とオンプレミス間のすべてのトラフィックを仲介するため、インスタンスのネットワーク帯域幅がスループットの上限になります。想定されるトラフィック量を見積もった上でインスタンスタイプを選定してください。なお、EKS Auto Mode 向けのサンプル NodePool 設定では汎用・コンピューティング最適化・メモリ最適化（c・m・r）の第 5 世代以降が指定されています。

コスト

EKS Hybrid Nodes gateway 自体の追加料金はありませんが、以下のコストが発生します。

コスト項目	概要
EC2 インスタンス費用	ゲートウェイノードとして使用する EC2 インスタンスの費用
データ転送費用	VPC とオンプレミス間のデータ転送に伴う費用
EKS Auto Mode 管理費用	EKS Auto Mode を使用する場合のみ発生

詳細は Amazon EKS 料金ページを参照してください。

まとめ

個人的には、ネットワークチームとの調整コストを削減できる点がこの機能の一番の価値だと感じています。EKS Hybrid Nodes は導入できても、そこから先の Pod ネットワークのルーティング設定で詰まるケースは少なくありません。そこへの直接的な回答がこの機能です。

ただし、Cilium CNI（VTEP 有効）が必須である点と、VXLAN トンネルが暗号化を持たない点は見落としがちな制約です。「導入前に確認しておきたいこと」をひと通り確認した上で検討を進めてください。特に既存環境で Cilium 以外の CNI を使っている場合は、CNI 移行の工数も含めた計画が必要です。

追加料金なし・オープンソース提供という点は、まず試してみるハードルを下げてくれます。EKS Hybrid Nodes をすでに使っているチームであれば、ステージング環境へのデプロイから始めてみるのがよいでしょう。

参考リンク