本文へスキップ
BecomeCoder

AWS SAA（ソリューションアーキテクト）コース　·　第4章　コンピューティングの設計　·　レッスン23

コンテナ ― ECS・EKS・Fargate・ECR

導入

「Dockerで作ったコンテナをAWSで動かしたい」というとき、選択肢が複数あって混乱しがちです。ECS/EKS/Fargateの関係を整理すれば、この分野はシンプルに理解できます。

説明

コンテナをAWS上で動かす仕組みは、「オーケストレーター（何で管理するか）」 と 「起動タイプ（どこで動かすか）」 の2軸で整理できます。

オーケストレーター特徴
ECS（Elastic Container Service）AWS独自のコンテナオーケストレーションサービス。シンプルでAWSに統合しやすい
EKS（Elastic Kubernetes Service）マネージドKubernetes。Kubernetesの知見やマルチクラウド前提の構成に向く
flowchart TD
    ORC["オーケストレーター<br/>(ECS または EKS)"] --> T{"起動タイプ"}
    T -->|EC2起動タイプ| EC2["自分でEC2クラスターを管理"]
    T -->|Fargate| FG["サーバーレス、インフラ管理不要"]
    REG["ECR<br/>(コンテナイメージの保管庫)"] -.-> ORC

起動タイプは「コンテナをどこで動かすか」の選択です。

ECR（Elastic Container Registry） は、DockerイメージをAWS内に保管するプライベートリポジトリで、ECS/EKSどちらからも利用します。

具体例

「オーケストレーター」と「起動タイプ」の2軸を、2社の判断で埋めてみましょう。

  • 少人数のスタートアップ → ECS on Fargate … AWSに閉じてシンプルに作りたく（→ ECS）、EC2クラスターの管理までは手が回らない（→ Fargate）。コンテナを渡すだけでインフラ管理ゼロ。
  • Kubernetes経験者が多い大企業 → EKS on Fargate（または EC2） … 既に社内にKubernetesの知見があり、将来マルチクラウドも見据える（→ EKS）。インフラ管理を省きたければ起動タイプはFargate、GPUなど特殊なノードを細かく制御したければEC2起動タイプ。

どちらの場合も、Dockerイメージの保管庫はECRで共通です。「インフラ管理をなくす＝Fargate、Kubernetes資産・マルチクラウド＝EKS、AWSに閉じてシンプル＝ECS」と、2軸を独立に選ぶと混乱しません。

読んでみよう

「コンテナ運用でインフラ管理をなくしたい」→Fargate、「Kubernetesの知見をそのまま使いたい／マルチクラウドを見据える」→EKS、「AWSに閉じてシンプルに構築したい」→ECS、という組み合わせで覚えておくと迷いません。

次のレッスンへ →