はじめに
2026 年 6 月 18 日、AWS は Amazon EKS に対して customer-routed control plane egress を発表しました。コントロールプレーンの送信トラフィックをユーザー自身の VPC 経由でルーティングできるようになり、ネットワーク経路を完全にユーザー側でコントロールできることが大きな特徴です。
EKS でクラスターを運用している方の中には、社内ネットワークにしか存在しない OIDC プロバイダーや、プライベートサブネットに配置した admission webhook サーバーに、コントロールプレーンからアクセスできず苦労した経験がある方もいるのではないでしょうか。今回のアップデートは、その課題に直接応えるものです。
本記事では、何が変わったのか、どのような組織にとって意味のあるアップデートなのか、そしてどのようなアーキテクチャでどう有効化すればよいのかを中心に解説します。EKS を運用するインフラ・プラットフォームエンジニアの方や、セキュリティ・コンプライアンス要件の検討に関わる方を想定読者としています。
何が変わったのか
EKS のコントロールプレーンが行う送信トラフィックについて、これまで深く意識したことがない方も多いかもしれません。実は admission webhook の呼び出しや OIDC プロバイダーへの問い合わせは、ユーザーが管理する VPC ではなく、AWS が管理するネットワーク経路を通って行われていました。
| 項目 | AWS_MANAGED(従来) | CUSTOMER_ROUTED(新機能) |
|---|---|---|
| 送信経路の管理者 | AWS | ユーザー自身 |
| プライベートな OIDC プロバイダーや webhook サーバーへの到達性 | パブリックエンドポイントの公開などの回避策が必要 | VPC のルーティングでそのまま到達可能 |
| ルートテーブル・セキュリティグループの設計 | ユーザーは関与不可 | ユーザーが自由に設計可能 |
従来の課題
データ境界要件やコンプライアンス要件の厳しい組織(金融、医療、政府機関など)では、コントロールプレーンの送信トラフィックが自社の管理下にないネットワーク経路を通ることが、監査やガバナンス上の懸念になっていました。また、VPC 内にのみ存在する社内 IdP や webhook サーバーにアクセスさせたい場合も、これまでは到達経路自体が用意されておらず、パブリックエンドポイントとして公開するといった回避策を取らざるを得ませんでした。
customer-routed control plane egress による解決
controlPlaneEgressMode を CUSTOMER_ROUTED に設定することで、以下の 3 種類のトラフィックがユーザーの VPC を経由するようになります。
| 対象トラフィック | 内容 |
|---|---|
| admission webhook コールバック | MutatingAdmissionWebhook、ValidatingAdmissionWebhook への呼び出し |
| OIDC プロバイダールックアップ | OIDC ディスカバリーエンドポイントへの問い合わせ |
| 集約 API サーバーリクエスト | Aggregated API Server への転送リクエスト |
経路上のルートテーブル、セキュリティグループ、NAT ゲートウェイや Transit Gateway の選定まで、すべてユーザー側でコントロールできるようになりました。なお、コントロールプレーンとワーカーノード間の通信(kubelet API、ポート 10250)はこの機能の対象外で、引き続きクラスター ENI を経由します。対象となるのはあくまで外部エンドポイントへの送信トラフィックである点に注意してください。
この機能は追加コストなしで、Amazon EKS が利用可能な全リージョンで利用できます。
この機能が必要なのはどんな組織か
customer-routed control plane egress は、すべての EKS ユーザーに一律で恩恵があるわけではなく、特定のニーズを持つ組織にこそ価値を発揮する機能です。導入を検討する前に、自分たちのケースに当てはまるかどうかを整理しておくと判断がしやすくなります。
この機能が活きるのは、金融、医療、政府機関などデータ境界要件やコンプライアンス要件を持つ組織、社内 IdP や admission webhook サーバーが VPC 内にのみ存在し外部に公開できない組織、あるいは VPC フローログ等でコントロールプレーンの送信トラフィックを監査・可視化したい組織です。逆に、特に規制要件を持たない一般的なワークロードや、利用する OIDC プロバイダーや webhook が既にパブリックに到達可能な環境であれば、無理に導入するメリットは大きくありません。
CUSTOMER_ROUTED モードへの切り替えは、コントロールプレーンの疎通を維持する責任がユーザー側に移る、後戻りのできない変更でもあります。詳しい注意点は次章で扱います。
アーキテクチャ解説
customer-routed control plane egress が「具体的に何を変えているのか」を、もう少し踏み込んで見ていきます。
ポイントは、この機能のために新しいネットワークインターフェースが作られるわけではないという点です。EKS はコントロールプレーンとワーカーノード間の通信のために、もともとユーザーの VPC サブネット内にクロスアカウントネットワークインターフェース(ENI)を作成しています。CUSTOMER_ROUTED モードは、この既存の ENI の使われ方を変えるだけで、Kubernetes API サーバーからの送信トラフィックがこの ENI を経由してユーザーの VPC のルートテーブルに渡され、NAT ゲートウェイや Transit Gateway、ファイアウォールアプライアンスといったエグレスデバイスを通って外部のエンドポイントに到達します。
ルーティングだけでなく、名前解決もユーザーの VPC の DNS 設定に従う点も見逃せません。VPC の DHCP オプションセットに AmazonProvidedDNS が含まれている必要があり、これによって Route 53 のプライベートホストゾーンや、Route 53 Resolver 経由のオンプレミス DNS への到達も可能になります。一方で、webhook や OIDC プロバイダーがパブリックな DNS 名を使っている場合は、パブリック DNS の解決もできる必要がある点に注意してください。
IPv6 クラスターで利用する場合は、IPv4 と IPv6 それぞれにエグレスパスを用意する必要があります。コントロールプレーンの ENI には IPv4 と IPv6 の両方のアドレスが割り当てられるため、IPv4 用に NAT ゲートウェイなどへのデフォルトルート(0.0.0.0/0)を、IPv6 用に egress-only internet gateway などへのデフォルトルート(::/0)を、それぞれ設定する必要があります。
移行前に必ず確認すべきこと
ここまでアーキテクチャを理解したところで、実際に CUSTOMER_ROUTED へ切り替える前に、必ず押さえておきたいポイントを整理します。中でも特に重要なのが、この切り替えが一方向の操作だという点です。
元に戻せない操作であること
CUSTOMER_ROUTED モードへの切り替えは一方向の操作です。一度有効化すると、AWS_MANAGED モードに戻すことはできません。新規クラスター作成時はもちろん、既存クラスターを update-cluster-config コマンドで更新する場合も同様です。本番クラスターに適用する前に、検証環境で十分に動作確認しておくことを強く推奨します。
ネットワーク疎通の責任はユーザー側にある
CUSTOMER_ROUTED モードでは、コントロールプレーンから必要なエンドポイントへの疎通を確保する責任がユーザー側に移ります。エグレスパスの不足、過度に制限されたネットワーク ACL、誤ったセキュリティグループ設定などがあると、admission webhook の呼び出しや OIDC 認証といった、コントロールプレーンの動作そのものが失敗する可能性があります。切り替え前には、以下の観点を満たしているか確認してください。
| 確認項目 | 内容 |
|---|---|
| エグレスパス | webhook サーバーや OIDC プロバイダーへのデフォルトルート(IPv4 は 0.0.0.0/0、IPv6 は ::/0)が、NAT ゲートウェイなどのエグレスデバイスに向いているか |
| セキュリティグループ | クロスアカウント ENI からのアウトバウンド通信(通常はポート 443)が許可されているか |
| ネットワーク ACL | アウトバウンド通信と、戻りトラフィック用のエフェメラルポート(1024〜65535)のインバウンドが許可されているか |
| DNS 解決 | VPC の DHCP オプションセットに AmazonProvidedDNS が含まれており、必要に応じてパブリック DNS の解決もできるか |
この機能の対象外になるもの
CUSTOMER_ROUTED に切り替えても、すべてのコントロールプレーン関連の通信がユーザーの VPC を経由するわけではありません。kubelet API の通信は引き続き対象外であることに加えて、ArgoCD や ACK、KRO といった EKS Capabilities も AWS 管理の別インフラ上で動作しており、これらのコントローラーからのトラフィックは本機能によって VPC 経由になることはありません。なお、Standard クラスターと Auto Mode クラスターのどちらでも、コントロールプレーンのアーキテクチャは同一であるため、この機能の動作に違いはありません。
切り替え後の可視性
VPC フローログをクラスターのサブネットで有効化しておくと、webhook や OIDC エンドポイントへの呼び出しを含む、VPC を経由するエグレストラフィックを観測できるようになります。有効化していない場合、このトラフィックはログに残らないため、切り替えと同時にフローログの有効化もあわせて検討するとよいでしょう。
有効化の手順
前章のチェック項目を満たしていることを確認できたら、実際に有効化していきます。ここでは新規クラスター作成時の設定方法と、既存クラスターを切り替える方法、そして組織全体に強制適用する方法を順に見ていきます。
新規クラスターで有効化する
AWS CLI を使う場合、create-cluster コマンドの resourcesVpcConfig に controlPlaneEgressMode=CUSTOMER_ROUTED を指定します。
aws eks create-cluster \
--name <cluster-name> \
--role-arn arn:aws:iam::<account-id>:role/<role-name> \
--resources-vpc-config "subnetIds=<subnet-id-1>,<subnet-id-2>,securityGroupIds=<security-group-id>,controlPlaneEgressMode=CUSTOMER_ROUTED" \
--kubernetes-network-config "ipFamily=ipv4" \
--region <region-code>
IPv6 クラスターの場合は ipFamily=ipv6 を指定しますが、IPv4 用の NAT ゲートウェイに加えて IPv6 用の egress-only インターネットゲートウェイも併せて用意してください。
AWS Management Console から作成する場合は、ネットワーキングの設定画面で「Control plane egress」を「Customer routed」に切り替えるだけです。AWS CloudFormation でも ResourcesVpcConfig に ControlPlaneEgressMode: CUSTOMER_ROUTED を指定すれば同様に設定できます。
なお、執筆時点(2026 年 6 月)では、Terraform の AWS Provider はこのフィールドにまだ対応していません。Terraform でクラスターを管理している場合は、対応リリースを待つか、AWS CLI やコンソールでの設定変更を検討してください。
既存クラスターを切り替える
既にクラスターを運用している場合は、update-cluster-config コマンドで切り替えられます。
aws eks update-cluster-config \
--name <cluster-name> \
--resources-vpc-config "controlPlaneEgressMode=CUSTOMER_ROUTED" \
--region <region-code>
更新の進捗は describe-update で確認できます。
aws eks describe-update \
--name <cluster-name> \
--update-id <update-id> \
--region <region-code>
更新タイプは ControlPlaneEgressUpdate で、ステータスが Successful になれば完了です。通常 10 分程度で完了します。
IAM 条件キーと SCP で組織に強制適用する
複数アカウントで EKS を運用している場合、eks:controlPlaneEgressMode という IAM 条件キーを使うと、クラスターの作成・更新時に必ず CUSTOMER_ROUTED を指定させることができます。この条件キーは eks:CreateCluster と eks:UpdateClusterConfig の 2 つのアクションに適用できます。以下は、CUSTOMER_ROUTED 以外を拒否する SCP の例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireCustomerRoutedControlPlane",
"Effect": "Deny",
"Action": [
"eks:CreateCluster",
"eks:UpdateClusterConfig"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"eks:controlPlaneEgressMode": "CUSTOMER_ROUTED"
}
}
}
]
}
このポリシーを AWS Organizations の SCP として適用すれば、組織内のすべての新規・更新クラスターに対して CUSTOMER_ROUTED モードを強制できます。
設定後の疎通確認
切り替えが完了したら、コントロールプレーンが想定通りに通信できているかを確認します。
| 確認項目 | コマンド・方法 |
|---|---|
| 現在のエグレスモード | aws eks describe-cluster --name <cluster-name> --query "cluster.resourcesVpcConfig.controlPlaneEgressMode" |
| クラスターの状態 |
aws eks describe-cluster --name <cluster-name> --query "cluster.status"(ACTIVE であること) |
| webhook の疎通 | admission webhook をトリガーするリソースを作成し、正常に処理されるか確認 |
| ノードの登録 |
kubectl get nodes でノードがクラスターに参加しているか確認 |
| IRSA の動作 | IAM ロールを使う Pod が、想定通りロールを引き受けられるか確認 |
これらの確認がすべて問題なければ、移行は完了です。万が一 webhook や OIDC 認証でエラーが出る場合は、前章のチェックリストに立ち返り、ルートテーブルやセキュリティグループの設定を見直してください。
活用シーン
ここまでの内容を踏まえて、実際にどのような場面でこの機能が活きるのか、具体的なシナリオで見ていきます。
プライベートな admission webhook との統合
OPA(Open Policy Agent)や Kyverno といったポリシーエンジンを admission webhook として導入する際、Webhook サーバーをインターネットに公開せず、プライベートサブネットに配置したいケースは少なくありません。これまでは、コントロールプレーンからの呼び出しを受けるために Webhook サーバーを何らかの形で外部公開する必要がありましたが、CUSTOMER_ROUTED モードであれば、コントロールプレーンの送信トラフィックが自社 VPC のルーティングを経由するため、Webhook サーバーをプライベートサブネットに置いたまま、ポート 443 などでコールバックを受け取れます。
社内 IdP との OIDC 連携
Keycloak や Active Directory Federation Services(ADFS)など、社内ネットワーク内にのみ存在する OIDC プロバイダーを使って IAM ロールの認証(IRSA)やクラスター認証を行いたい場合にも有効です。従来はコントロールプレーンが社内 IdP に到達する経路がなく、OIDC エンドポイントを外部公開せざるを得ませんでしたが、本機能を使えば、VPC のルーティングや Transit Gateway を経由して、外部公開なしに OIDC ディスカバリーエンドポイントへアクセスできるようになります。
オンプレミス環境との連携
AWS Direct Connect や VPN でオンプレミスネットワークと接続している環境であれば、オンプレミス側に存在する Webhook サーバーや OIDC プロバイダーへのアクセスも実現できます。VPC のルートテーブルから Transit Gateway、Direct Connect ゲートウェイへと経路を伸ばすことで、コントロールプレーンからオンプレミスのリソースまで、プライベートな経路でアクセスする構成が組めます。認証基盤をオンプレミスで運用し続けている企業にとっては、クラウドとオンプレミスのハイブリッド運用をよりシンプルにする選択肢になります。
まとめ
本記事では、Amazon EKS の customer-routed control plane egress について解説しました。コントロールプレーンの送信トラフィックを自社 VPC でコントロールできるようになったことで、これまでアクセスできなかったプライベートな OIDC プロバイダーや admission webhook サーバーとの統合が可能になり、データ境界やコンプライアンス要件を持つ組織にとっては選択肢が広がるアップデートです。
一方で、この機能はすべての EKS ユーザーに一律で必要というわけではありません。導入する場合は、コントロールプレーンの疎通を維持する責任がユーザー側に移ること、そして CUSTOMER_ROUTED への切り替えが元に戻せない一方向の操作であることを十分に理解した上で、検証環境での確認を経てから本番環境に適用することをおすすめします。なお、本機能は追加コストなしで、Amazon EKS が利用可能な全リージョンで利用できます。
現時点では Terraform の AWS Provider が未対応のため、Terraform でクラスターを管理している場合は、対応リリースまで AWS CLI やコンソールでの設定変更が必要になる点を踏まえて導入を検討してください。