AWS が、Amazon EKS(AWSのKubernetes のサービス)のネットワーク ポリシーを広げ、クラスター全体に効く決まりと、ドメイン名で外向きの通信を許す決まりを使えるようにしました。もとは2025年12月に英語で発表した機能で、AWSは2026年10月19日に日本語のブログで紹介し、既存のクラスターにも対応したと書き添えています。日本語のブログとEKSのユーザーガイドから整理します。
何が変わったか
Kubernetesの標準のネットワークポリシー(NetworkPolicy)は、名前空間(Namespace)ごとの決まりです。ブログは、その限界として、クラスター全体にまたがる制御ができないこと、明示的な「拒否」の決まりが無いこと、決まりどうしに優先の順がないことを挙げています。アプリの担当者がそれぞれ守るには向いていますが、会社のセキュリティ の基準を、クラスター全体に一律でかけるには向きません。
今回、次の2つが加わりました。
決まり
使えるクラスター
できること
ClusterNetworkPolicy(Admin層・Baseline層)
標準のEKS(Amazon VPC CNIを使う)と、EKS Auto Mode
名前空間にかかわらず、クラスター全体に通信の決まりをかける。「拒否」も書ける
ApplicationNetworkPolicy
EKS Auto Modeだけ
Podからクラスターの外への通信を、IPアドレスではなくドメイン名(FQDNや、*.example.comのような形)で許す
決まりの評価の順番
ClusterNetworkPolicyには、Admin層とBaseline層があります。評価の順は、Admin層 → 標準のNetworkPolicy → Baseline層です。
Admin層は最初に評価され、上書きできない(AWSの日本語のブログ) 出典: Amazon Web Services ブログ「Amazon EKS のネットワークポリシー機能を強化」 (引用)
Admin層 : 最初に評価され、アプリの担当者のNetworkPolicyで上書きできません。たとえば「外のインターネットへの通信を禁止」とすれば、開発者 がNetworkPolicyで許しても通りません。Baseline層 : 最後に評価される、クラスターの初期の決まりです。NetworkPolicyで上書きできます。
ブログは使い方の例として、機密の高い仕事を置く名前空間に、ほかの名前空間からの通信を一律で拒否する決まりや、監視の仕組みからの通信と、DNS(kube-dns)への通信を、全名前空間で必ず許す決まりを挙げています。決まりは、networking.k8s.aws/v1alpha1という、まだ試験段階(alpha)の版の書式で書きます。
ドメイン名での許可(Auto Modeだけ)
ApplicationNetworkPolicyは、OSIの第7層でも動き、通信の行き先をドメイン名で絞れます。ブログは、IPアドレスが頻繁に変わるSaaS(例として「.salesforce.com」「 .slack.com」)や、社内のデータセンターのシステムへの通信で、IPアドレスの一覧を持たずに済むとしています。
ユーザーガイドによると、Auto Modeでは、まずネットワークポリシーの制御を有効にするConfigMapをクラスターに入れます。DNSの問い合わせは、許可したドメインの一覧で絞り込むしくみを通ってから答えが返ります。ノードの設定(Node Class)で、ネットワークポリシーの出来事の記録も有効にできます。
使うための条件
使うための要件。既存のクラスターにも対応したと訳注で補っている 出典: Amazon Web Services ブログ「Amazon EKS のネットワークポリシー機能を強化」 (引用)
Kubernetesは1.29以降
新しいクラスターと既存のクラスターの両方で使える(日本語のブログの訳注)
標準のクラスターでClusterNetworkPolicyを使うには、Amazon VPC CNIのv1.21.1以降(ブログ)。ユーザーガイドは、標準とAdminのネットワークポリシーに1.21.0以降としている
決まりが効くのは、EC2のLinuxのノードだけ。FargateやWindowsのノードには効かない(ユーザーガイド)
IPv4のクラスターではIPv4の決まりだけ、IPv6のクラスターではIPv6の決まりだけが効く(ユーザーガイド)
ドメイン名での許可は、Auto Modeが起動したEC2のインスタンスだけ
料金の扱いは、ブログとユーザーガイドには書かれていません。
影響する会社・しない会社
影響する: Amazon EKSで、複数のチームや複数のアプリを同じクラスターに載せている会社です。会社の基準(外への通信の禁止、機密の名前空間の分離など)を、チームごとのNetworkPolicyに頼らず、上から一律にかけられます。
影響する: EKS Auto Modeで、外のSaaSや社内のシステムへの通信を、IPアドレスの一覧で絞っている会社です。ドメイン名に置き換えると、相手のIPアドレスが変わるたびに決まりを直す手間が減ります。
影響しない(効かない): FargateやWindowsのノードで動かしている仕事です。今回の決まりは、EC2のLinuxのノードにしか効きません。
影響しない: EKSを使っていない会社です。
情シスが今日やること
前提をそろえる 。クラスターのKubernetesの版(1.29以降か)と、Amazon VPC CNIの版(1.21.1以降か)を確かめます。FargateやWindowsのノードがあるなら、そこには効かないことを、決まりを作る人と共有します。会社の基準をAdmin層に移す候補を決める 。外への通信の禁止、機密の名前空間の分離、監視とDNSへの通信の許可など、どのチームにも守ってほしい決まりを、Admin層の候補として書き出します。今のNetworkPolicyと突き合わせる 。Admin層で禁止する通信を、いまアプリが使っていないかを確かめます。いきなり本番に入れず、試験のクラスターで、止まる通信が無いかを見ます。外向きの許可の一覧を作る 。Auto Modeを使っているなら、PodがつなぐSaaSや社内のシステムのドメイン名を一覧にし、IPアドレスで書いている決まりを置き換えられるか検討します。書式が試験段階であることを覚えておく 。決まりの書式はv1alpha1です。今後の版で書き方が変わることがあるため、更新の知らせを追います。 
