EC2インスタンス上に自前でKubernetesクラスタを構築する（kopsやkubeadmを利用するなど）場合と比較して、Amazon EKS（Elastic Kubernetes Service）を採用するアーキテクチャ上の最大のメリットはどれですか？

解説

正解は「Kubernetesのコントロールプレーン（APIサーバーやetcd）の可用性確保、スケーリング、バックアップをAWSが完全管理してくれる」です。Kubernetes（複数コンテナを自動管理するシステム）の自前運用で最も難しいのは、「コントロールプレーン（システム全体を制御する管理機能）」の維持です。ここには、ユーザーからの操作要求を受け付ける「APIサーバー」や、現在の状態や設定データをすべて保存するデータベース「etcd」が含まれます。EKSを使う最大の利点は、ダウンするとシステム全体が停止してしまうこれら重要機能の保守・監視・バックアップを、すべてAWSに任せられることです。他の選択肢は以下の理由で不正解です。選択肢1: EKSはコンテナの実行環境であり、イメージのビルドや最適化はCI/CDツール等の役割です。選択肢3: セキュリティは依然として重要であり、VPC設計やセキュリティグループによるアクセス制御は必須です。選択肢4: 無限のリソースはなく、Podのrequests/limitsの設計やノードの監視は運用者が引き続き行う必要があります。コントロールプレーンとデータプレーンの責任分界点EKSの仕組みを深く理解するには、クラスタのアーキテクチャを「コントロールプレーン」と「データプレーン（ワーカーノード）」に分けて考えることが不可欠です。自前でEC2上に構築する場合、「etcdのデータバックアップはどうするか」「APIサーバーの負荷が上がったらどうスケールさせるか」をすべて自分たちで設計・運用しなければなりません。しかしEKSでは、これらのコンポーネントはAWSの管理下にある隠蔽されたVPC内で実行され、ユーザーは提供されたエンドポイントを通じて操作するだけで済みます。実務での運用：ワーカーノードの管理はどうなるのかコントロールプレーンが隠蔽されているため、実際に私たちがインフラとして管理するのは、Podが稼働するデータプレーン側のEC2インスタンス（ワーカーノード）です。例えば、コマンドラインからノード一覧を取得してみます。$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-10-12.ec2.internal Ready <none> 10d v1.28.xこのように、表示されるのはワーカーノードのみでマスターノード（コントロールプレーン）は表示されません。「Kubernetesの運用を楽にするには」と考えたとき、まずはマネージドサービス（EKS）を選んでマスターノードの管理を手放し、さらに必要に応じてAWS Fargateを組み合わせてワーカーノードの管理まで手放す、というインフラ設計のステップが存在します。「なぜEKSを使うのか」という問いに対しては、「システムの中核であるコントロールプレーンの泥臭い運用から解放され、アプリケーションのデプロイやビジネスロジックに集中するため」というのがプロの現場での共通認識です。