Amazon EKS

Amazon EKS（Elastic Kubernetes Service）は、アップストリームの Kubernetes を AWS 上でマネージドに動かすためのコンテナオーケストレーションサービスです。コントロールプレーンの可用性確保やバージョンアップといった運用作業を AWS に委ね、利用者はワークロードの設計と運用に注力できます。

解決する課題

Kubernetes はコンテナの宣言的なデプロイ、スケーリング、自己修復を強力に支援しますが、コントロールプレーン（API サーバー、etcd、スケジューラなど）を自前で構築・冗長化・パッチ適用するのは大きな運用負荷になります。特に etcd のバックアップや高可用性、API サーバーの証明書管理、Kubernetes 本体の定期的なアップグレードは専門知識を要し、ミスがクラスタ全体の停止につながります。

EKS はこのコントロールプレーンをマネージドサービスとして提供し、複数のアベイラビリティゾーンにまたがって冗長化された状態で運用します。同時に、IAM による認証、VPC によるネットワーク分離、ロードバランサーやストレージといった AWS の周辺サービスと統合することで、Kubernetes 単体では追加実装が必要だった部分を埋めます。標準準拠のため、オンプレミスや他クラウドの Kubernetes マニフェストやツールチェーンをそのまま持ち込みやすい点も移行のハードルを下げます。

主要概念と用語

• クラスター: Kubernetes の論理的な単位。EKS ではマネージドなコントロールプレーンと、ユーザーが用意するデータプレーン（ノード）で構成される。
• コントロールプレーン: API サーバーや etcd などクラスタの頭脳にあたる部分。EKS が複数アベイラビリティゾーンで冗長化して運用する。
• データプレーン: 実際にコンテナを実行するワーカーノード群。EC2 ベースのノードや Fargate を選べる。
• マネージドノードグループ: EKS が EC2 ワーカーノードのプロビジョニングやライフサイクル、アップグレードを支援する仕組み。
• セルフマネージドノード: ユーザーが Auto Scaling グループなどで自前管理する EC2 ノード。柔軟性が高い反面、運用責任も大きい。
• Fargate: サーバーレスでポッドを実行する方式。ノードの管理が不要になる。
• ポッド: 1 つ以上のコンテナをまとめた Kubernetes の最小デプロイ単位。
• IRSA（IAM Roles for Service Accounts）: Kubernetes のサービスアカウントに IAM ロールを紐づけ、ポッド単位で AWS 権限を付与する仕組み。後継として EKS Pod Identity も提供される。
• アドオン: VPC CNI、CoreDNS、kube-proxy など、EKS がバージョン管理を支援するクラスタ付帯コンポーネント。
• VPC CNI: ポッドに VPC のネットワークアドレスを割り当てるネットワークプラグイン。

仕様・制限・クォータ

EKS のコントロールプレーンは AWS が管理し、アベイラビリティゾーンをまたいで冗長化されます。Kubernetes のバージョンは一定期間ごとに新しいマイナーバージョンがサポートされ、各バージョンには標準サポート期間が設けられているため、利用者は計画的にアップグレードする必要があります。サポート終了後も延長サポートが提供される場合がありますが、追加コストや制約を伴うことがあります。

1 クラスターあたりのノード数やポッド数、リージョンあたりのクラスター数などにはサービスクォータが存在します。これらの上限は変動するため、設計時には必ず最新の公式ドキュメントとサービスクォータの画面で確認してください。VPC CNI を使う場合、各 EC2 インスタンスタイプに割り当てられるネットワークインターフェースとアドレス数によって、1 ノードあたりに配置できるポッド数の上限が実質的に決まる点にも注意が必要です。

内部の仕組み

EKS のコントロールプレーンは、AWS が管理する分離された環境で、複数のアベイラビリティゾーンにわたって API サーバーと etcd を冗長配置します。利用者からはマネージドなエンドポイントとして見え、その内部のスケーリングやパッチ適用は AWS が担います。コントロールプレーンへのアクセスは、パブリックエンドポイント、プライベートエンドポイント、またはその両方として構成でき、プライベート構成では VPC 内からのみ API にアクセスさせることができます。

データプレーンのノードは、ユーザーの VPC 内の EC2 インスタンスとして、または Fargate のサーバーレス基盤上で起動します。ノードは認証情報を用いてコントロールプレーンに登録され、スケジューラがポッドを各ノードに割り当てます。認証は AWS の IAM と Kubernetes の認可（RBAC）を組み合わせて行われ、API 呼び出し元の IAM アイデンティティがクラスタ内のロールにマッピングされます。ネットワーク面では VPC CNI がポッドに VPC のアドレスを直接割り当てるため、ポッドが VPC ネイティブな存在として扱われ、セキュリティグループなど既存のネットワーク制御と親和性が高くなります。

設計パターン / ベストプラクティス

• ワークロードの性質でデータプレーンを使い分ける。運用の手間を最小化したい、または断続的なワークロードには Fargate、GPU や特殊なインスタンスタイプ、デーモンセットが必要な場合は EC2 ノードを選ぶ。
• ノードは複数のアベイラビリティゾーンに分散し、ポッドのアンチアフィニティやトポロジー分散制約を使って単一ゾーン障害の影響を抑える。
• IRSA または EKS Pod Identity を使い、ポッド単位で最小権限の IAM ロールを割り当てる。ノードのインスタンスロールに広い権限を持たせる設計は避ける。
• マネージドノードグループやアドオンの仕組みを活用し、ノードと付帯コンポーネントのアップグレードを段階的かつ計画的に実施する。
• クラスタオートスケーラや Karpenter のようなノードプロビジョナを導入し、需要に応じてノードを自動で増減させる。

運用・監視

クラスタの可観測性は、コントロールプレーンのログ（API サーバー、監査、オーセンティケータなど）を有効化してログ集約サービスに送り、ノードやポッドのメトリクスはモニタリングサービスやオープンソースのモニタリングスタックで収集するのが基本です。EKS はコントロールプレーンのログ出力を任意で有効化でき、監査ログはセキュリティ調査やコンプライアンスに役立ちます。

アップグレード運用では、コントロールプレーンを先に新バージョンへ更新し、その後データプレーンのノードを順次入れ替える流れが一般的です。ノードの入れ替え時はポッドの退避（ドレイン）と再スケジュールが発生するため、ポッドのレプリカ数や PodDisruptionBudget を適切に設定して可用性を保ちます。アドオンのバージョン整合性もアップグレード時に確認すべき重要なポイントです。

コスト

EKS のコストは大きく分けて、クラスターのコントロールプレーンに対する時間課金と、データプレーンの実行コストで構成されます。コントロールプレーンはクラスター単位で時間あたりの料金が発生し、これはノード数に関係なく一定です。データプレーン側は、EC2 ノードであれば通常の EC2 と関連リソース（EBS など）の料金、Fargate であれば割り当てた仮想 CPU とメモリに応じた料金がかかります。

コスト最適化の観点では、開発環境では小規模なクラスターに統合する、EC2 ノードにスポットインスタンスを活用する、Fargate と EC2 を適材適所で使い分ける、オートスケーリングで余剰ノードを減らす、といった工夫が有効です。具体的な料金は変動するため、最新の料金ページとコスト試算ツールで確認してください。

セキュリティ

EKS では責任共有モデルに従い、コントロールプレーンの基盤は AWS が保護し、ワークロード、ノードの構成、Kubernetes の認可設定は利用者が責任を持ちます。認証は IAM と連携し、認可は Kubernetes の RBAC で制御するため、両者を整合させた最小権限設計が重要です。アクセスエントリの仕組みを使うと、IAM プリンシパルとクラスタ権限のマッピングをより管理しやすくなります。

ネットワークでは、API エンドポイントをプライベート化して VPC 内からのみアクセスさせる、ポッドにセキュリティグループを適用する、NetworkPolicy で東西通信を制限するといった多層防御を組み合わせます。シークレットはエンベロープ暗号化により保管時の保護を強化でき、コンテナイメージは信頼できるレジストリから取得し脆弱性スキャンを通すべきです。ノードやアドオンを最新に保つこともセキュリティ維持の基本です。

Well-Architected の観点

信頼性の観点では、コントロールプレーンが複数アベイラビリティゾーンで冗長化され、ノードを複数ゾーンに分散することでゾーン障害に耐える構成が取れます。運用上の優秀性の観点では、コントロールプレーンの運用を AWS に委ねつつ、アドオンやマネージドノードグループでアップグレードを体系化できます。パフォーマンス効率の観点では、ワークロードに応じて EC2 と Fargate、インスタンスタイプ、オートスケーリングを選択し、需要に追従できます。これらに加え、セキュリティとコスト最適化の柱も IAM 連携や課金モデルの選択を通じて支援されます。

試験で問われるポイント

関連サービス・比較

同じコンテナオーケストレーションの選択肢である Amazon ECS とよく比較されます。ECS は AWS 独自のシンプルなオーケストレータで学習コストが低い一方、EKS は標準 Kubernetes 準拠でエコシステムの資産を活かせます。

ハンズオン / CLI例

以下は AWS CLI で EKS クラスターの一覧と詳細を確認し、kubectl 用の接続情報を設定する例です。

# クラスターの一覧を取得
aws eks list-clusters --region ap-northeast-1

# 特定クラスターの詳細を確認
aws eks describe-cluster --name my-cluster --region ap-northeast-1

# kubectl からアクセスするための kubeconfig を更新
aws eks update-kubeconfig --name my-cluster --region ap-northeast-1

# 接続確認（ノード一覧の表示）
kubectl get nodes