翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# VPC とサブネットに関する考慮事項
**ヒント**
Amazon EKS [https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)ワークショップを通じてベストプラクティスをご覧ください。
EKS クラスターを操作するには、Kubernetes ネットワークに加えて、AWS VPC ネットワークに関する知識が必要です。
VPC の設計または既存の VPC へのクラスターのデプロイを開始する前に、EKS コントロールプレーンVPCs通信メカニズムを理解しておくことをお勧めします。
EKS で使用する [VPC とサブネットを設計する場合は、クラスター VPC に関する考慮事項](https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html)と Amazon EKS セキュリティグループの考慮事項を参照してください。 [https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html](https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html)
## 概要:
### EKS クラスターアーキテクチャ
EKS クラスターは 2 つの VPCsで構成されます。
+ Kubernetes コントロールプレーンをホストする AWS マネージド VPC。この VPC はお客様のアカウントに表示されません。
+ Kubernetes ノードをホストするカスタマーマネージド VPC。これは、コンテナだけでなく、クラスターで使用されるロードバランサーなどのカスタマー管理の AWS インフラストラクチャも実行される場所です。この VPC は顧客アカウントに表示されます。クラスターを作成する前に、カスタマーマネージド VPC を作成する必要があります。eksctl は、指定しない場合に VPC を作成します。
カスタマー VPC のノードには、AWS VPC のマネージド API サーバーエンドポイントに接続する機能が必要です。これにより、ノードは Kubernetes コントロールプレーンに登録され、アプリケーションポッドを実行するリクエストを受信できます。
ノードは、(a) EKS パブリックエンドポイント、または (b) EKS によって管理されるクロスアカウント [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (X-ENI) を介して EKS コントロールプレーンに接続します。クラスターを作成するときは、少なくとも 2 つの VPC サブネットを指定する必要があります。EKS は、クラスターの作成時に指定された各サブネット (クラスターサブネットとも呼ばれます) に X-ENI を配置します。Kubernetes API サーバーは、これらのクロスアカウント ENIs を使用して、カスタマーマネージドクラスター VPC サブネットにデプロイされたノードと通信します。
![\[クラスターネットワークの一般的な図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/subnet_image.png)
ノードが起動すると、EKS ブートストラップスクリプトが実行され、Kubernetes ノード設定ファイルがインストールされます。各インスタンスの起動プロセスの一環として、コンテナランタイムエージェント、kubelet、Kubernetes ノードエージェントを起動します。
ノードを登録するため、Kubelet は Kubernetes クラスターエンドポイントに連絡します。VPC の外部にあるパブリックエンドポイントまたは VPC 内のプライベートエンドポイントとの接続を確立します。Kubelet は API 指示を受け取り、ステータスの更新とハートビートを定期的にエンドポイントに提供します。
### EKS コントロールプレーン通信
EKS には、[クラスターエンドポイント](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html)へのアクセスを制御する 2 つの方法があります。エンドポイントアクセスコントロールを使用すると、パブリックインターネットからエンドポイントにアクセスできるか、VPC 経由でのみエンドポイントにアクセスできるかを選択できます。パブリックエンドポイント (デフォルト）、プライベートエンドポイント、またはその両方を一度にオンにできます。
クラスター API エンドポイントの設定によって、ノードがコントロールプレーンと通信するためのパスが決まります。これらのエンドポイント設定は、EKS コンソールまたは API を使用していつでも変更できます。
#### パブリックエンドポイント
これは新しい Amazon EKS クラスターのデフォルトの動作です。クラスターのパブリックエンドポイントのみが有効になっている場合、クラスターの VPC 内 (ワーカーノードからコントロールプレーンへの通信など) から発生する Kubernetes API リクエストは VPC を離れますが、Amazon のネットワークは離れません。ノードをコントロールプレーンに接続するには、パブリック IP アドレスとインターネットゲートウェイへのルート、または NAT ゲートウェイのパブリック IP アドレスを使用できる NAT ゲートウェイへのルートが必要です。
#### パブリックエンドポイントとプライベートエンドポイント
パブリックエンドポイントとプライベートエンドポイントの両方が有効になっている場合、VPC 内からの Kubernetes API リクエストは、VPC 内の X-ENIs を介してコントロールプレーンと通信します。クラスター API サーバーにはインターネットからアクセスできます。
#### プライベートエンドポイント
プライベートエンドポイントのみが有効になっている場合、インターネットから API サーバーへのパブリックアクセスはありません。クラスター API サーバーへのすべてのトラフィックはクラスターの VPC または接続されたネットワーク内から送信する必要があります。ノードは、VPC 内の X-ENIs を介して API サーバーと通信します。クラスター管理ツールには、プライベートエンドポイントへのアクセス権が必要です。[Amazon VPC の外部からプライベート Amazon EKS クラスターエンドポイントに接続する方法について説明します。](https://aws.amazon.com/premiumsupport/knowledge-center/eks-private-cluster-endpoint-vpc/)
クラスターの API サーバーエンドポイントは、パブリック DNS サーバーによって VPC のプライベート IP アドレスに解決されることに注意してください。これまではエンドポイントは VPC 内からしか解決できませんでした。
### VPC 設定
Amazon VPC では、IPv4 と IPv6 アドレス設定がサポートされています。Amazon EKS はデフォルトで IPv4 をサポートしています。VPC には、それに関連付けられた IPv4 CIDR ブロックがある必要があります。オプションで、複数の IPv4 [クラスレスドメイン間ルーティング](http://en.wikipedia.org/wiki/CIDR_notation) (CIDR) ブロックと複数の IPv6 CIDR ブロックを VPC に関連付けることができます。VPC を作成するときは、RFC 1918 で指定されているように、プライベート IPv4 アドレス範囲から VPC の IPv4 CIDR ブロックを指定する必要があります。 [http://www.faqs.org/rfcs/rfc1918.html](http://www.faqs.org/rfcs/rfc1918.html)許可されるブロックサイズは、`/16`プレフィックス (65,536 IP アドレス) と`/28`プレフィックス (16 IP アドレス) の間です。
新しい VPC を作成するときは、単一の IPv6 CIDR ブロックをアタッチし、既存の VPC を変更するときは最大 5 つまでアタッチできます。IPv6 CIDR ブロックサイズのプレフィックスの長さは /44 ～ /60 で、IPv6 サブネットの場合は /44/ ～ /64 にすることができます。Amazon が管理する IPv6 アドレスのプールから IPv6 CIDR ブロックをリクエストできます。詳細については、[「VPC ユーザーガイド」の「VPC CIDR ブロック](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)」セクションを参照してください。
Amazon EKS クラスターは、IPv4 と IPv6 の両方をサポートします。デフォルトでは、EKS クラスターは IPv4 IP を使用します。クラスターの作成時に IPv6 を指定すると、IPv6 クラスターの使用が有効になります。IPv6 クラスターには、デュアルスタック VPCs とサブネットが必要です。
Amazon EKS では、クラスターの作成時に異なるアベイラビリティーゾーンにある少なくとも 2 つのサブネットを使用することをお勧めします。クラスターの作成時に渡すサブネットは、クラスターサブネットと呼ばれます。クラスターを作成すると、Amazon EKS は指定したサブネットに最大 4 つのクロスアカウント (x アカウントまたは x ENIs) ENIs を作成します。x-ENIs は常にデプロイされ、ログ配信、exec、プロキシなどのクラスター管理トラフィックに使用されます。[VPC とサブネットの要件](https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html#network-requirements-subnets)の詳細については、「EKS ユーザーガイド」を参照してください。
Kubernetes ワーカーノードはクラスターサブネットで実行できますが、推奨されません。[クラスターのアップグレード](cluster-upgrades.md#upgrades-ips)中、Amazon EKS はクラスターサブネットに追加の ENIs をプロビジョニングします。クラスターがスケールアウトすると、ワーカーノードとポッドがクラスターサブネットで使用可能な IPs を消費する可能性があります。したがって、使用可能な IPs が十分あることを確認するために、/28 ネットマスクで専用クラスターサブネットを使用することを検討してください。
Kubernetes ワーカーノードは、パブリックサブネットまたはプライベートサブネットで実行できます。サブネットがパブリックかプライベートかとは、サブネット内のトラフィックが[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)を介してルーティングされるかどうかを指します。パブリックサブネットには、インターネットゲートウェイを介してインターネットへのルートテーブルエントリがありますが、プライベートサブネットにはありません。
別の場所から発信され、ノードに到達するトラフィックは*、イングレス*と呼ばれます。ノードから発信され、ネットワークを離れるトラフィックは*、エグレス*と呼ばれます。インターネットゲートウェイで設定されたサブネット内のパブリック IP アドレスまたは Elastic IP アドレス (EIPs) を持つノードは、VPC の外部からの進入を許可します。プライベートサブネットには通常、[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)へのルーティングがあります。これにより、VPC の外部からのサブネット内のノードへの進入トラフィックは許可されませんが、ノード*からの*トラフィックが VPC (*進入*) から出ることは許可されます。
IPv6 の世界では、すべてのアドレスがインターネットでルーティング可能です。ノードとポッドに関連付けられた IPv6 アドレスはパブリックです。プライベートサブネットは、VPC [に Egress-Only インターネットゲートウェイ (EIGW)](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) を実装することでサポートされ、すべての着信トラフィックをブロックしながらアウトバウンドトラフィックを許可します。IPv6 サブネットを実装するためのベストプラクティスについては、VPC [ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html)を参照してください。
### VPC とサブネットは 3 つの異なる方法で設定できます。
#### パブリックサブネットのみを使用する
同じパブリックサブネットに、ノードとイングレスリソース (ロードバランサーなど) の両方が作成されます。パブリックサブネットに をタグ付け[http://kubernetes.io/role/elb](http://kubernetes.io/role/elb)して、インターネットに面するロードバランサーを構築します。この設定では、クラスターエンドポイントをパブリック、プライベート、またはその両方 (パブリックとプライベート) に設定できます。
#### プライベートサブネットとパブリックサブネットの使用
ノードはプライベートサブネットに作成されますが、イングレスリソースはパブリックサブネットにインスタンス化されます。クラスターエンドポイントへのパブリックアクセス、プライベートアクセス、またはその両方 (パブリックとプライベート) アクセスを有効にできます。クラスターエンドポイントの設定に応じて、ノードトラフィックは NAT ゲートウェイまたは ENI を介して入ります。
#### プライベートサブネットのみを使用する
ノードと進入の両方がプライベートサブネットに作成されます。[http://kubernetes.io/role/internal-elb:1](http://kubernetes.io/role/internal-elb:1) サブネットタグを使用して内部ロードバランサーを作成します。クラスターのエンドポイントにアクセスするには、VPN 接続が必要です。EC2 およびすべての Amazon ECR および S3 リポジトリに対して [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) を有効にする必要があります。クラスターのプライベートエンドポイントのみを有効にする必要があります。[プライベートクラスターをプロビジョニングする前に、EKS プライベートクラスターの要件](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html)を確認することをお勧めします。
### VPCs間の通信
複数の VPCs と、これらの VPCs にデプロイされた個別の EKS クラスターを必要とするシナリオは多数あります。
[Amazon VPC Lattice を使用すると](https://aws.amazon.com/vpc/lattice/)、複数の VPCs とアカウント間でサービスを一貫して安全に接続できます (VPC ピアリング、AWS PrivateLink、AWS Transit Gateway などのサービスによって追加の接続が提供される必要はありません）。詳細については、[こちら](https://aws.amazon.com/blogs/networking-and-content-delivery/build-secure-multi-account-multi-vpc-connectivity-for-your-applications-with-amazon-vpc-lattice/)を参照してください。
![\[Amazon VPC Lattice\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/subnet_vpc-lattice.gif)
Amazon VPC Lattice は IPv4 と IPv6 のリンクローカルアドレス空間で動作し、IPv4 アドレスが重複している可能性のあるサービス間の接続を提供します。運用効率を高めるために、EKS クラスターとノードを重複しない IP 範囲にデプロイすることを強くお勧めします。インフラストラクチャに重複する IP 範囲を持つ VPCs が含まれている場合は、それに応じてネットワークを設計する必要があります。[プライベート NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-basics)、または[カスタムネットワーキング](custom-networking.md)モードの VPC CNI を[トランジットゲートウェイ](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-transit-gateway.html)と組み合わせて EKS 上のワークロードを統合し、ルーティング可能な RFC1918 IP アドレスを維持しながら、重複する CIDR の課題を解決することをお勧めします。
![\[カスタムネットワーキングを使用したプライベート Nat ゲートウェイ\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/subnet_private-nat-gw.gif)
お客様がサービスプロバイダーであり、Kubernetes サービスと進入 (ALB または NLB) を個別のアカウントの顧客 VPC と共有する場合は、エンドポイントサービスとも呼ばれる [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html) の使用を検討してください。
### 複数のアカウント間で VPC を共有する
多くの企業は、ネットワーク管理を合理化し、コストを削減し、AWS Organization 内の複数の AWS アカウントでセキュリティを向上させる手段として、共有 Amazon VPCs を採用しました。AWS Resource Access Manager (RAM) を使用して、サポートされている [AWS リソース](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html)を個々の AWS アカウント、組織単位 (OUs)、または AWS Organization 全体と安全に共有します。
AWS RAM を使用して、別の AWS アカウントの共有 VPC サブネットに Amazon EKS クラスター、マネージド型ノードグループ、その他のサポート対象の AWS リソース (LoadBalancers、セキュリティグループ、エンドポイントなど) をデプロイできます。以下の図は、高レベルアーキテクチャの例を示しています。これにより、中央ネットワークチームは VPCs、サブネットなどのネットワーク構造を制御し、アプリケーションまたはプラットフォームチームはそれぞれの AWS アカウントに Amazon EKS クラスターをデプロイできます。このシナリオの完全なチュートリアルは、この [github リポジトリ](https://github.com/aws-samples/eks-shared-subnets)で入手できます。
![\[AWS アカウント間で VPC 共有サブネットに Amazon EKS をデプロイする。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/networking/subnet_eks-shared-subnets.png)
#### 共有サブネットを使用する場合の考慮事項
+ Amazon EKS クラスターとワーカーノードは、すべて同じ VPC の一部である共有サブネット内に作成できます。Amazon EKS は、複数の VPCs にまたがるクラスターの作成をサポートしていません。
+ Amazon EKS は AWS VPC セキュリティグループ (SGs) を使用して、Kubernetes コントロールプレーンとクラスターのワーカーノード間のトラフィックを制御します。セキュリティグループは、ワーカーノード、他の VPC リソース、および外部 IP アドレス間のトラフィックを制御するためにも使用されます。これらのセキュリティグループは、アプリケーション/参加者アカウントで作成する必要があります。ポッドに使用するセキュリティグループも参加者アカウントにあることを確認します。セキュリティグループ内のインバウンドルールとアウトバウンドルールを設定して、中央 VPC アカウントにあるセキュリティグループとの間で必要なトラフィックを許可できます。
+ Amazon EKS クラスターが存在する参加者アカウント内に IAM ロールと関連するポリシーを作成します。これらの IAM ロールとポリシーは、Amazon EKS によって管理される Kubernetes クラスター、および Fargate で実行されているノードとポッドに必要なアクセス許可を付与するために不可欠です。アクセス許可により、Amazon EKS はユーザーに代わって他の AWS サービスを呼び出すことができます。
+ 次のアプローチに従って、k8s ポッドから Amazon S3 バケット、Dynamodb テーブルなどの AWS リソースへのクロスアカウントアクセスを許可できます。
+ **リソースベースのポリシーアプローチ**: AWS サービスがリソースポリシーをサポートしている場合は、適切なリソースベースのポリシーを追加して、kubernetes ポッドに割り当てられた IAM ロールへのクロスアカウントアクセスを許可できます。このシナリオでは、OIDC プロバイダー、IAM ロール、およびアクセス許可ポリシーがアプリケーションアカウントに存在します。リソースベースのポリシーをサポートする AWS サービスを検索するには、[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)を参照し、リソースベースの列に「はい」があるサービスを探します。
+ **OIDC プロバイダーアプローチ**: OIDC プロバイダー、IAM ロール、アクセス許可、信頼ポリシーなどの IAM リソースは、リソースが存在する他の参加者の AWS アカウントに作成されます。これらのロールは、クロスアカウントリソースにアクセスできるように、アプリケーションアカウントの Kubernetes ポッドに割り当てられます。このアプローチの完全なウォークスルーについては、[Kubernetes サービスアカウントのクロスアカウント IAM ロール](https://aws.amazon.com/blogs/containers/cross-account-iam-roles-for-kubernetes-service-accounts/)のブログを参照してください。
+ Amazon Elastic Loadbalancer (ELB) リソース (ALB または NLB) をデプロイして、アプリケーションまたは中央ネットワークアカウントの k8s ポッドにトラフィックをルーティングできます。中央ネットワークアカウントに ELB リソースをデプロイする詳細な手順については、[「クロスアカウントLoad Balancerによる Amazon EKS ポッドの公開](https://aws.amazon.com/blogs/containers/expose-amazon-eks-pods-through-cross-account-load-balancer/)」のチュートリアルを参照してください。このオプションは、Load Balancerリソースのセキュリティ設定に対する完全な制御をセントラルネットワーキングアカウントに付与するため、柔軟性が向上します。
+ `custom networking feature` Amazon VPC CNI を使用する場合は、中央ネットワークアカウントに記載されているアベイラビリティーゾーン (AZ) ID マッピングを使用して、各 を作成する必要があります`ENIConfig`。これは、物理 AZs を各 AWS アカウントの AZ 名にランダムにマッピングするためです。
### セキュリティグループ
[https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)は、関連付けられたリソースに到達できるトラフィックおよびリソースから発信できるトラフィックを制御します。Amazon EKS はセキュリティグループを使用して、[コントロールプレーンとノード](https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html)間の通信を管理します。クラスターを作成すると、Amazon EKS により `eks-cluster-sg-my-cluster-uniqueID` という名前のセキュリティグループが作成されます。EKS は、これらのセキュリティグループをマネージド ENIsとノードに関連付けます。デフォルトのルールでは、すべてのトラフィックがクラスターとノード間で自由に行き来することができます。また、任意の送信先へのすべてのアウトバウンドトラフィックが許可されています。
クラスターを作成するときに、独自のセキュリティグループを指定できます。独自の[セキュリティグループを指定する場合は、セキュリティグループの推奨事項](https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html)を参照してください。
## 推奨事項
### マルチ AZ 配置を検討する
AWS リージョンは、複数の物理的に分離および分離されたアベイラビリティーゾーン (AZ) を提供します。AZ は、低レイテンシー、高スループット、および高度に冗長なネットワークで接続されます。アベイラビリティーゾーンを使用すると、中断することなくアベイラビリティーゾーン間で自動的にフェイルオーバーするアプリケーションを設計および運用できます。Amazon EKS では、EKS クラスターを複数のアベイラビリティーゾーンにデプロイすることを強くお勧めします。クラスターを作成するときは、少なくとも 2 つのアベイラビリティーゾーンにサブネットを指定することを検討してください。
ノードで実行されている Kubelet は、 などのノードオブジェクトにラベルを自動的に追加します[http://topology.kubernetes.io/region=us-west-2,topology.kubernetes.io/zone=us-west-2d](http://topology.kubernetes.io/region=us-west-2,topology.kubernetes.io/zone=us-west-2d)。ノードラベルを [Pod トポロジーの分散制約](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)と組み合わせて使用して、ゾーン間で Pod がどのように分散されるかを制御することをお勧めします。これらのヒントにより、Kubernetes ス[ケジューラ](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)は Pod を配置して可用性を期待し、相関障害がワークロード全体に影響を与えるリスクを軽減できます。ノードセレクタと AZ スプレッド制約の例については、[「ポッドへのノードの割り当て](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)」を参照してください。
ノードを作成するときに、サブネットまたはアベイラビリティーゾーンを定義できます。サブネットが設定されていない場合、ノードはクラスターサブネットに配置されます。マネージド型ノードグループの EKS サポートは、利用可能な容量で複数のアベイラビリティーゾーンにノードを自動的に分散します。[Karpenter](https://karpenter.sh/) は、ワークロードがトポロジーのスプレッド制限を定義する場合、ノードを指定された AZ にスケーリングすることで AZs スプレッドプレイスメントを尊重します。
AWS Elastic Load Balancer は、Kubernetes クラスターの AWS Load Balancer Controller によって管理されます。Kubernetes Ingress リソース用の Application Load Balancer (ALB) と Load Balancer タイプの Kubernetes サービス用の Network Load Balancer (NLB) をプロビジョニングします。Elastic Load Balancer コントローラーは[タグ](https://aws.amazon.com/premiumsupport/knowledge-center/eks-vpc-subnet-discovery/)を使用してサブネットを検出します。ELB コントローラーでは、進入リソースを正常にプロビジョニングするために、最低 2 つのアベイラビリティーゾーン (AZs) が必要です。地理的冗長性の安全性と信頼性を活用するには、少なくとも 2 つの AZs にサブネットを設定することを検討してください。
### プライベートサブネットにノードをデプロイする
プライベートサブネットとパブリックサブネットの両方を含む VPC は、Kubernetes ワークロードを EKS にデプロイするのに最適な方法です。2 つの異なるアベイラビリティーゾーンに 2 つ以上のパブリックサブネットと 2 つのプライベートサブネットを設定することを検討してください。パブリックサブネットの関連ルートテーブルには、インターネットゲートウェイ へのルートが含まれています。ポッドは NAT ゲートウェイを介してインターネットとやり取りできます。プライベートサブネットは、IPv6 環境 (EIGW) の [Egress-Only インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html)でサポートされています。
プライベートサブネット内のノードをインスタンス化することで、ノードへのトラフィックを最大限制御でき、ほとんどの Kubernetes アプリケーションに効果的です。イングレスリソース (ロードバランサーなど) はパブリックサブネットでインスタンス化され、プライベートサブネットで動作する Pod にトラフィックをルーティングします。
厳格なセキュリティとネットワークの分離が必要な場合は、プライベート専用モードを検討してください。この設定では、AWS リージョンの VPC 内の個別のアベイラビリティーゾーンに 3 つのプライベートサブネットがデプロイされます。サブネットにデプロイされたリソースは、インターネットにアクセスすることも、サブネット内のリソースにもアクセスすることもできません。Kubernetes アプリケーションが他の AWS のサービスにアクセスするには、PrivateLink インターフェイスやゲートウェイエンドポイントを設定する必要があります。AWS Load Balancer Controller を使用してトラフィックを Pod にリダイレクトするように内部Load Balancerを設定できます。コントローラーがロードバランサーをプロビジョニングするには、プライベートサブネットにタグ ([http://kubernetes.io/role/internal-elb](http://kubernetes.io/role/internal-elb)) を付ける必要があります。ノードをクラスターに登録するには、クラスターエンドポイントをプライベートモードに設定する必要があります。要件と考慮事項の詳細については、[プライベートクラスターガイド](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html)を参照してください。
### クラスターエンドポイントのパブリックモードとプライベートモードを検討する
Amazon EKS には、パブリック専用、public-and-privateのクラスターエンドポイントモードが用意されています。デフォルトモードはパブリック専用ですが、クラスターエンドポイントをパブリックモードとプライベートモードで設定することをお勧めします。このオプションを使用すると、クラスターの VPC 内の Kubernetes API コール (node-to-control-plane通信など) がプライベート VPC エンドポイントとトラフィックを利用してクラスターの VPC 内に留まることができます。一方、クラスター API サーバーにはインターネットからアクセスできます。ただし、パブリックエンドポイントを使用できる CIDR ブロックを制限することを強くお勧めします。[CIDR ブロックの制限など、パブリックエンドポイントとプライベートエンドポイントのアクセスを設定する方法について説明します。](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#modify-endpoint-access)
セキュリティとネットワークの分離が必要な場合は、プライベート専用のエンドポイントをお勧めします。[EKS ユーザーガイド](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#private-access)に記載されているオプションのいずれかを使用して、API サーバーにプライベートに接続することをお勧めします。
### セキュリティグループを慎重に設定する
Amazon EKS は、カスタムセキュリティグループの使用をサポートしています。カスタムセキュリティグループでは、ノードと Kubernetes コントロールプレーン間の通信を許可する必要があります。組織がオープンな通信を許可していない場合は、[ポートの要件](https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html)を確認し、ルールを手動で設定してください。
EKS は、クラスターの作成時に指定したカスタムセキュリティグループをマネージドインターフェイス (X-ENIs。ただし、ノードにすぐに関連付けられるわけではありません。ノードグループを作成するときは、[カスタムセキュリティグループを手動で関連付け](https://eksctl.io/usage/schema/#nodeGroups-securityGroups)ることを強くお勧めします。[securityGroupSelectorTerms](https://karpenter.sh/docs/concepts/nodeclasses/#specsecuritygroupselectorterms) を有効にして、ノードの自動スケーリング中にカスタムセキュリティグループの Karpenter ノードテンプレート検出を有効にすることを検討してください。
すべてのノード間通信トラフィックを許可するセキュリティグループを作成することを強くお勧めします。ブートストラッププロセス中、ノードはクラスターエンドポイントにアクセスするためにアウトバウンドインターネット接続を必要とします。オンプレミス接続やコンテナレジストリアクセスなどの外部アクセス要件を評価し、ルールを適切に設定します。本番環境に変更を加える前に、開発環境で接続を慎重に確認することを強くお勧めします。
### 各アベイラビリティーゾーンに NAT ゲートウェイをデプロイする
プライベートサブネット (IPv4 および IPv6) にノードをデプロイする場合は、各アベイラビリティーゾーン (AZ) に NAT ゲートウェイを作成して、ゾーンに依存しないアーキテクチャを確保し、AZ 間の支出を削減することを検討してください。AZ 内の各 NAT ゲートウェイは冗長性を持って実装されます。