**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# VPC とサブネットの Amazon EKS ネットワーキング要件を表示する
クラスターを作成する際には、[VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html) と、異なるアベイラビリティーゾーンに存在する 2 つ以上のサブネットを指定します。このトピックでは、クラスターで使用する VPC およびサブネットに関する Amazon EKS 固有の要件と考慮事項の概要について説明します。Amazon EKS で使用する VPC がない場合は、「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。AWS Outposts でローカルクラスターまたは拡張クラスターを作成する場合は、このトピックの代わりに「[AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する](eks-outposts-vpc-subnet-requirements.md)」を参照してください。このトピックのコンテンツは、ハイブリッドノードを持つ Amazon EKS クラスターに適用されます。ハイブリッドノードのその他のネットワーク要件については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。
## VPC の要件と考慮事項
クラスターを作成する際には、指定する VPC が次の要件と考慮事項を満たす必要があります。
+ VPC には、作成するクラスター、ノード、およびその他の Kubernetes リソースで利用できる十分な数の IP アドレスが必要です。使用する VPC に十分な数の IP アドレスがない場合は、使用可能な IP アドレスの数を増やしてみてください。
これを行うには、クラスター設定を更新して、クラスターが使用するサブネットとセキュリティグループを変更します。AWS マネジメントコンソール、AWS CLI の最新バージョン、AWS CloudFormation、および `eksctl` のバージョン `v0.164.0-rc.0` 以降から更新できます。クラスターバージョンを正常にアップグレードするにはこれを実行して、サブネットに利用可能な IP アドレスを増やす必要がある場合があります。
**重要**
追加するサブネットはすべて、クラスターの作成時に最初に提供したのと同じ一連の AZ 内にある必要があります。新しいサブネットは、その他のすべての要件 (例えば、十分な IP アドレスを持っている必要がある) を満たす必要があります。
例えば、1 つのクラスターを作成し、4 つのサブネットを指定したとします。指定した順序では、1 番目のサブネットは `us-west-2a` アベイラビリティーゾーンにあり、2 番目と 3 番目のサブネットは `us-west-2b` アベイラビリティーゾーンにあり、4 番目のサブネットは `us-west-2c` アベイラビリティーゾーンにあります。サブネットを変更する場合は、3 つのアベイラビリティーゾーンのそれぞれに少なくとも 1 つのサブネットを指定する必要があります。また、サブネットは元のサブネットと同じ VPC 内にある必要があります。
VPC 内の CIDR ブロックよりも多くの IP アドレスが必要な場合は、VPC に[追加の Classless Inter-Domain Routing (CIDR) ブロックを関連付ける](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr)ことで CIDR ブロックを追加できます。クラスターの作成前または作成後に、プライベート (RFC 1918) とパブリック (非 RFC 1918) の CIDR ブロックを VPC に関連付けることができます。
新しい CIDR ブロックを追加するとすぐにそのブロックを使用するノードを追加することができます。ただし、コントロールプレーンでは調整が完了した後にのみ新しい CIDR ブロックが認識されるため、VPC に関連付けられた CIDR ブロックがクラスターで認識されるまでに最大で 1 時間かかることがあります。その後、新しい CIDR ブロック内のノードとポッドに対して、`kubectl cp`、`kubectl exec`、`kubectl attach`、`kubectl logs`、および `kubectl port-forward` コマンドを実行できます (これらのコマンドは `kubelet API` を使用します)。また、ウェブフックバックエンドとして機能するポッドがある場合は、コントロールプレーンの調整が完了するまで待機する必要があります。
+ トランジットゲートウェイ、VPC ピアリング、またはその他のネットワーク設定を介して EKS クラスターを他の VPC に接続するときは、IP アドレス範囲が重複しないようにします。CIDR 競合は、EKS クラスターのサービス CIDR が接続された VPC の CIDR と重複するときに発生します。これらのシナリオでは、ServiceIP アドレスは同じ IP アドレスを持つ接続された VPC 内のリソースよりも優先されますが、トラフィックルーティングが予測不能になり、アプリケーションが目的のリソースに接続できなくなる可能性があります。
CIDR の競合を回避するには、EKS サービス CIDR が接続された VPC CIDR と重複しないようにし、すべての CIDR 割り当ての一元化された記録を維持するようにします。CIDR の重複が発生した場合は、共有サービス VPC でトランジットゲートウェイを使用できます。詳細については、「[共有サービスによる分離された VPC](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-isolated-shared.html)」および「[Amazon EKS VPC routable IP address conservation patterns in a hybrid network (ハイブリッドネットワークにおける Amazon EKS VPC ルーティング可能な IP アドレス保全パターン)](https://aws.amazon.com/blogs/containers/eks-vpc-routable-ip-address-conservation)」を参照してください。また、EKS ベストプラクティスガイドの「[VPC とサブネットに関する考慮事項](https://docs.aws.amazon.com/eks/latest/best-practices/subnets.html)」ページの「VPC 間の通信」セクションを参照してください。
+ Kubernetes で `IPv6` アドレスを Pod およびサービスに割り当てる場合は、`IPv6` CIDR ブロックを VPC に関連付けます。詳細については、「Amazon VPC ユーザーガイド」の「[IPv6 CIDR ブロックと VPC の関連付け](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr)」を参照してください。ハイブリッドノードで実行されているポッドやサービスで `IPv6` アドレスを使用することはできません。また、`IPv6` IP アドレスファミリーで設定されたクラスターでハイブリッドノードを使用することはできません。
+ VPC は、`DNS` ホスト名と `DNS` 解決がサポートされている必要があります。そうではない場合、ノードはクラスターに登録されません。詳細については、「Amazon VPC ユーザーガイド」の「[DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)」(VPC の DNS 属性) を参照してください。
+ VPC では、AWS PrivateLink を使用する VPC エンドポイントが必要になる場合があります。詳細については、「[サブネットの要件と考慮事項](#network-requirements-subnets)」を参照してください。
Kubernetes `1.14` 以前でクラスターを作成した場合、Amazon EKS は次のタグを VPC に追加しています。
| キー | 値 |
| --- | --- |
| `kubernetes.io/cluster/my-cluster ` | `owned` |
このタグは Amazon EKS でのみ使用されています。サービスに影響を与えずに、このタグを削除できます。このタグは、バージョン `1.15` 以降のクラスターでは使用されません。
## サブネットの要件と考慮事項
クラスターを作成すると、Amazon EKS は、指定したサブネットに 2～4 つの [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) を作成します。これらのネットワークインターフェイスは、クラスターと VPC 間の通信を可能にします。これらのネットワークインターフェイスでは、`kubelet API` を使用する Kubernetes の機能も有効化されます。`kubelet` API への接続は、`kubectl attach`、`kubectl cp`、`kubectl exec`、`kubectl logs`、`kubectl port-forward` の各コマンドで使用されます。Amazon EKS が作成した各ネットワークインターフェイスの説明には、テキスト `Amazon EKS cluster-name ` が書き込まれます。
Amazon EKS は、クラスターの作成時に指定した任意のサブネットにネットワークインターフェイスを作成することができます。クラスターの作成後に、Amazon EKS がネットワークインターフェイスを作成するサブネットを変更できます。クラスターの Kubernetes バージョンを更新すると、Amazon EKS は作成した元のネットワークインターフェイスを削除し、新しいネットワークインターフェイスを作成します。これらのネットワークインターフェイスは、元のネットワークインターフェイスと同じサブネット内に作成することも、元のネットワークインターフェイスとは異なるサブネット内に作成することもできます。ネットワークインターフェイスを作成するサブネットを制御する場合は、クラスターを作成するとき、またはクラスターの作成後にサブネットを更新するときに、指定するサブネットの数を 2 つだけに制限します。
### クラスターのサブネットの要件
クラスターの作成または更新時に指定する[サブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types)は、次の要件を満たす必要があります。
+ サブネットには、Amazon EKS での使用のために、それぞれ 6 個以上の IP アドレスが必要です。ただし、IP アドレスは 16 個以上を推奨します。
+ サブネットは、少なくとも 2 つの異なるアベイラビリティーゾーンに存在している必要があります。
+ サブネットは AWS Outposts または AWS Wavelength 内に存在できません。ただし、VPC 内にサブネットが存在する場合は、セルフマネージド型ノードおよび Kubernetes のリソースをこれらのタイプのサブネットにデプロイできます。セルフマネージド型ノードの詳細については、「[セルフマネージドノードでノードを自分自身で維持する](worker.md)」を参照してください。
+ サブネットは、パブリックでもプライベートでもかまいません。ただし、可能であれば、プライベートサブネットを指定することをお勧めします。パブリックサブネットは、[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)へのルートが含まれているルートテーブルを含むサブネットです。一方、プライベートサブネットは、インターネットゲートウェイへのルートが含まれていないルートテーブルを含むサブネットです。
+ サブネットは以下のアベイラビリティーゾーンには配置できません。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/network-reqs.html)
### 各コンポーネントの IP アドレスファミリー使用状況
以下の表に、Amazon EKS の各コンポーネントで使用される IP アドレスファミリーを示します。ネットワークアドレス変換 (NAT) またはその他の互換システムを使用すると、表の値が「No」のファミリーに属する送信元 IP アドレスから、これらのコンポーネントに接続できます。
機能は、クラスターの IP ファミリー (`ipFamily`) 設定によって異なる場合があります。この設定は、Kubernetes がサービスに割り当てる CIDR ブロックに使用される IP アドレスのタイプを変更します。設定値が IPv4 のクラスターは *IPv4 クラスター*と呼ばれ、設定値が IPv6 のクラスターは *IPv6 クラスター*と呼ばれます。
| コンポーネント | IPv4 アドレス | IPv6 アドレス | デュアルスタックアドレス |
| --- | --- | --- | --- |
| EKS API パブリックエンドポイント | あり1、3 | あり1、3 | あり1、3 |
| EKS API VPC エンドポイント | はい | なし | 不可 |
| EKS Auth API パブリックエンドポイント (EKS Pod Identity) | はい 1 | はい 1 | はい 1 |
| EKS Auth API VPC エンドポイント (EKS Pod Identity) | はい 1 | はい 1 | はい 1 |
| `IPv4` Kubernetes クラスターパブリックエンドポイント2 | はい | なし | 不可 |
| `IPv4` Kubernetes クラスタープライベートエンドポイント2 | はい | なし | 不可 |
| `IPv6` Kubernetes クラスターパブリックエンドポイント2 | はい 1、4 | はい 1、4 | はい 4 |
| `IPv6` Kubernetes クラスタープライベートエンドポイント2 | はい 1、4 | はい 1、4 | はい 4 |
| Kubernetes クラスターサブネット | あり2 | 不可 | はい 2 |
| ノードのプライマリ IP アドレス | あり2 | 不可 | はい 2 |
| サービス IP アドレスのクラスター CIDR 範囲 | はい 2 | あり2 | 不可 |
| VPC CNI による Pod IP アドレス | はい 2 | あり2 | 不可 |
| IRSA OIDC 発行者 URL | あり1、3 | あり1、3 | あり1、3 |
**注記**
1 エンドポイントは、`IPv4` アドレスと `IPv6` アドレスの両方を持つデュアルスタックです。AWS 外部のアプリケーション、クラスターのノード、およびクラスター内のポッドは、`IPv4` または `IPv6` のいずれかによってこのエンドポイントに到達できます。
2 クラスターの作成時に、クラスターの IP ファミリー (`ipFamily`) 設定で `IPv4` クラスターと `IPv6` クラスターのどちらかを選択します。これは後から変更できません。代わりに、他のクラスターを作成してワークロードを移行する際は、別の設定を選択する必要があります。
3 デュアルスタックエンドポイントは、2024 年 8 月に導入されました。AWS CLI でデュアルスタックエンドポイントを使用するには、「*AWS SDK およびツールリファレンスガイド*」の「[デュアルスタックと FIPS エンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)」の設定を参照してください。新しいエンドポイントを次に示します:
**EKS API パブリックエンドポイント**
`eks.region.api.aws`
**IRSA OIDC 発行者 URL**
`oidc-eks.region.api.aws`
4 デュアルスタッククラスターエンドポイントは、2024 年 10 月に導入されました。EKS は、この日より後に作成され、クラスターの IP ファミリー (ipFamily ) 設定で `IPv6` を選択した新しいクラスターに次のエンドポイントを作成します。
**EKS クラスターパブリック／プライベートエンドポイント**
`eks-cluster.region.api.aws`
### ノードのサブネットの要件
クラスターの作成時に指定するのと同じサブネットに、ノードと Kubernetes リソースをデプロイできます。ただし、これは必須ではありません。これは、クラスターの作成時に指定しなかったサブネットにもノードと Kubernetes リソースをデプロイできるためです。ノードを異なるサブネットにデプロイする場合、Amazon EKS は、それらのサブネットにクラスターネットワークインターフェイスを作成しません。ノードと Kubernetes リソースをデプロイするサブネットは、次の要件を満たす必要があります。
+ サブネットには、すべてのノードと Kubernetes リソースをデプロイするのに十分な数の使用可能な IP アドレスが必要です。
+ Kubernetes で `IPv6` アドレスを Pod およびサービスに割り当てる場合は、サブネットに関連付けられている `IPv6` CIDR ブロックと `IPv4` CIDR ブロックをそれぞれ 1 つずつ指定する必要があります。詳細については、「Amazon VPC ユーザーガイド」の「[IPv6 CIDR ブロックをサブネットに関連付ける](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-associate-ipv6-cidr)」を参照してください。サブネットに関連付けられているルートテーブルには、`IPv4` および `IPv6` のアドレスへのルートを含める必要があります。詳細については、「Amazon VPC ユーザーガイド」の「[Routes](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-table-routes)」(ルート) を参照してください。ポッドに割り当てられるのは `IPv6` アドレスのみです。ただし、Amazon EKS がクラスターとノード用に作成するネットワークインターフェイスには、`IPv4` および `IPv6` のアドレスが割り当てられます。
+ インターネットから Pod へのインバウンドアクセスが必要な場合は、ロードバランサーのデプロイおよびインバウンドトラフィック (イングレス) に十分な数の IP アドレスを利用できるパブリックサブネットが少なくとも 1 つあることを必ず確認してください。パブリックサブネットにロードバランサーをデプロイできます。ロードバランサーは、プライベートサブネットまたはパブリックサブネット内の Pod への負荷分散を行います。可能であれば、プライベートサブネットにノードをデプロイすることをお勧めします。
+ ノードをパブリックサブネットにデプロイする場合は、サブネットが `IPv4` パブリックアドレスまたは `IPv6` アドレスを自動割り当てする必要があります。ノードを `IPv6` CIDR ブロックが関連付けられているプライベートサブネットにデプロイする場合、プライベートサブネットも `IPv6` アドレスを自動割り当てする必要があります。2020 年 3 月 26 日以降に Amazon EKS が提供する AWS CloudFormation テンプレートを使用して VPC をデプロイした場合、この設定は有効になっています。テンプレートを使用してこの日付より前に VPC をデプロイした場合、または独自の VPC を使用した場合は、この設定を手動で有効にする必要があります。テンプレートについては、「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。詳細については、「[Amazon VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/)」の「[サブネットのパブリック IPv4 アドレス指定属性を変更する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-public-ip)」および「[サブネットの IPv6 アドレス指定属性を変更する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-ipv6)」を参照してください。
+ ノードをデプロイするサブネットがプライベートサブネットであり、そのルートテーブルにネットワークアドレス変換 [(NAT) デバイス](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat.html) (`IPv4`) または [Egress-Only ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) (`IPv6`) へのルートが含まれていない場合は、AWS PrivateLink を使用して VPC エンドポイントを VPC に追加します。VPC エンドポイントは、ノードと Pod が通信を行う必要があるすべての AWS サービスで必要になります。例としては、Amazon ECR、Elastic Load Balancing、Amazon CloudWatch、AWS Security Token Service、Amazon Simple Storage Service (Amazon S3) などがあります。エンドポイントには、ノードが存在するサブネットを含める必要があります。すべての AWS で VPC エンドポイントがサポートされているわけではありません。詳細については、「[AWS PrivateLink とは](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)」および「[AWS PrivateLink と統合する AWS サービス](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html)」を参照してください。Amazon EKS のその他の要件のリストについては、「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してください。
+ ロードバランサーをサブネットにデプロイする場合は、サブネットに次のタグが必要です。
+ プライベートサブネット
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/network-reqs.html)
+ パブリックサブネット
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/network-reqs.html)
バージョン `1.18` 以前の Kubernetes クラスターが作成された場合、Amazon EKS は指定したすべてのサブネットに次のタグを追加します。
| キー | 値 |
| --- | --- |
| `kubernetes.io/cluster/my-cluster ` | `shared` |
ここで新しい Kubernetes クラスターを作成した場合、Amazon EKS はサブネットにタグを追加しません。`1.19` より前のバージョンのクラスターが使用していたサブネットにタグがあった場合、クラスターが新しいバージョンに更新されても、タグはサブネットから自動的に削除されませんでした。AWS Load Balancer Controller のバージョン `2.1.1` 以前では、このタグが必要です。新しいバージョンの Load Balancer Controller を使用している場合は、サービスを中断することなくタグを削除できます。コントローラーの詳細については、「[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md)」を参照してください。
`eksctl` または Amazon EKS AWS CloudFormation VPC テンプレートのいずれかを使用して VPC をデプロイした場合、次が適用されます。
+ **2020 年 3 月 26 日以降** - パブリック `IPv4` アドレスは、パブリックサブネットにより、パブリックサブネットにデプロイした新しいノードに自動的に割り当てられます。
+ **2020 年 3 月 26 日より前** - パブリック `IPv4` アドレスは、パブリックサブネットにより、パブリックサブネットにデプロイした新しいノードに自動的に割り当てられません。
この変更は、パブリックサブネットにデプロイされた新しいノードグループに、次のような影響を与えます。
+ **[マネージドノードグループ](create-managed-node-group.md)** - 2020 年 4 月 22 日以降にノードグループをパブリックサブネットにデプロイした場合は、パブリックサブネットでパブリック IP アドレスの自動割り当てを有効にする必要があります。詳細については「[サブネットの IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。
+ **[Linux](launch-workers.md)、[Windows](launch-windows-workers.md)、または [Arm](eks-optimized-ami.md#arm-ami) のセルフマネージドノードグループ** - 2020 年 3 月 26 日以降にノードグループをパブリックサブネットにデプロイした場合は、パブリックサブネットでパブリック IP アドレスの自動割り当てを有効にする必要があります。それ以外の場合は、代わりにパブリック IP アドレスを使用してノードを起動する必要があります。詳細については、「[サブネットのパブリック IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」または「[インスタンス起動時のパブリック IPv4 アドレスの割り当て](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#vpc-public-ip)」を参照してください。
## 共有サブネットの要件と考慮事項
*VPC 共有*を使用して、同じ AWS 組織内でサブネットを他の AWS アカウントと共有できます。共有サブネットに Amazon EKS クラスターを作成できますが、以下の考慮事項に注意してください。
+ VPC サブネットの所有者は、参加者アカウントで Amazon EKS クラスターを作成する前に、そのアカウントとサブネットを共有する必要があります。
+ VPC のデフォルトセキュリティグループは所有者に属しているため、デフォルトのセキュリティグループを使用してリソースを起動することはできません。さらに、参加者は、他の参加者または所有者が所有するセキュリティグループを使用してリソースを起動することはできません。
+ 共有サブネットでは、参加者と所有者がそれぞれのアカウント内のセキュリティグループを個別に管理します。サブネットの所有者は、参加者が作成したセキュリティグループを表示できますが、これらのグループに対してアクションを実行することはできません。サブネットの所有者がこれらのセキュリティグループの削除または変更を希望する場合は、セキュリティグループを作成した参加者がそのアクションを実行する必要があります。
+ 参加者がクラスターを作成する場合、以下の考慮事項が適用されます。
+ クラスター IAM ロールとノード IAM ロールは、そのアカウントで作成する必要があります。詳細については、「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」および「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。
+ 管理対象ノードグループを含め、すべてのノードは同じ参加者が作成する必要があります。
+ 共有 VPC の所有者は、参加者が共有サブネット内に作成したクラスターを表示、更新、削除することはできません。これは、アカウントごとに異なるアクセス権を持つ VPC リソースに加えて適用されます。詳細については、「*Amazon VPC ユーザーガイド*」の「[所有者および参加者の責任と権限](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations)」を参照してください。
+ Amazon VPC CNI plugin for Kubernetes の*カスタムネットワーク*機能を使用する場合、所有者アカウントに記載されているアベイラビリティーゾーン ID マッピングを使用して、それぞれの `ENIConfig` を作成する必要があります。詳細については、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。
VPC サブネット共有の詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC を他のアカウントと共有する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations)」を参照してください。