Amazon ECS / EKS
Elastic Container Service / Elastic Kubernetes Service
概要
Amazon ECS と EKS は、Docker コンテナを本番環境で運用するためのフルマネージドなコンテナオーケストレーションサービスです。多数のコンテナをどのホストに配置し、障害時に再起動し、負荷に応じて増減させるか、といった運用を自動化します。ECS は AWS 独自のシンプルなオーケストレーターで AWS との統合が深く、EKS は標準の Kubernetes をマネージドで提供し、Kubernetes エコシステムやマルチクラウドの知見をそのまま活かせます。いずれも EC2 または Fargate を実行基盤として選べます。
主要な概念
ECS の構成要素
ECS では、コンテナの設定（イメージ、CPU/メモリ、ポートなど）をタスク定義に記述し、それを起動した単位がタスクです。サービスは指定した数のタスクを維持し、障害時に再起動し、ロードバランサーと連携して負荷分散します。AWS との統合が深く、IAM ロールや CloudWatch、ALB と素直に連携できるのが特徴です。
EKS と Kubernetes
EKS はアップストリーム互換の Kubernetes コントロールプレーンをマネージドで提供します。Pod、Deployment、Service といった標準の Kubernetes リソースやツール（kubectl、Helm など）をそのまま使え、既存の Kubernetes 資産や運用ノウハウ、サードパーティのエコシステムを活用したい場合に適します。コントロールプレーンの可用性は AWS が管理します。
起動タイプ: EC2 と Fargate
コンテナを動かす基盤として、自分で EC2 インスタンス群（クラスター）を管理する EC2 起動タイプと、サーバー管理が不要なサーバーレスの Fargate を選べます。Fargate はホストのプロビジョニングやパッチが不要で、タスク/Pod 単位のリソースに対して課金されるため運用負荷を大きく下げられます。ECS でも EKS でも Fargate を利用できます。
イメージ管理（ECR）
コンテナイメージは Amazon ECR（Elastic Container Registry）に保存・バージョン管理します。ECS/EKS はデプロイ時に ECR からイメージを取得し、IAM による権限制御や脆弱性スキャンと組み合わせて安全に配布できます。CI/CD パイプラインからビルド済みイメージを push し、サービスを更新する流れが一般的です。
ECS と EKS の選択
AWS 中心でシンプルに素早く始めたい、運用をできるだけ任せたいなら ECS が向きます。一方、Kubernetes の標準API・豊富なエコシステム・マルチクラウドや既存資産の活用が重要なら EKS が適します。どちらも Fargate と組み合わせればホスト管理を不要にでき、要件（運用負荷・移植性・既存スキル）に応じて選択します。
典型的なユースケース
- マイクロサービスをコンテナ化し、ECS/EKSで本番運用とスケーリングを自動化する
- Fargateを使いサーバー管理なしでコンテナワークロードを運用する
- 既存のKubernetes資産やツールを活かしたい場合にEKSへ移行・展開する
- ALBと連携してコンテナサービスへ負荷分散し、ローリング更新でデプロイする
- ECRにイメージを集約し、CI/CDから安全にビルド・配布・更新する
試験での出題観点
ECS / EKS は SAA・DVA・SAP でコンテナ設計として問われます。最頻出の切り分けは「サーバー（ホスト）管理をなくしたい → Fargate」「クラスターの細かな制御やコスト最適化のためインスタンスを自分で管理 → EC2 起動タイプ」です。「AWS中心でシンプルに → ECS」「標準のKubernetesや既存資産・エコシステムを活かす → EKS」という選択の論点も定番です。サーバーレスを徹底するなら Lambda、長時間/常駐や独自ランタイムが必要ならコンテナ、という Lambda との使い分けも問われます。ECR によるイメージ管理、ALB連携、IAMロールによる権限付与（タスクロール）が周辺論点です。
関連サービス
最終更新日: 2026-06-24
本ページの内容は、AWS公式ドキュメントを基に作成し、運営者が編集・監修しています。詳しくは編集・品質管理方針をご覧ください。