AWS ソリューションアーキテクト – アソシエイト学習サイト CP 学習サイトへ戻る

コンテナ（ECS / EKS / Fargate / ECR）

コンテナは、アプリケーションと動かすのに必要なライブラリ・設定をひとまとめにして、どこでも同じように動かせるようにする技術です。AWS では、コンテナを管理する Amazon ECS と Amazon EKS、サーバーなしでコンテナを動かす AWS Fargate、コンテナイメージを保管する Amazon ECR を組み合わせて使います。SAA では「コンテナを使う場面」と「要件に合うサービスの選び方」がよく問われます。

ひとことで言うと: ECR はコンテナの「倉庫」、ECS と EKS はコンテナを何個どこで動かすかを決める「指揮者」、Fargate と EC2 はコンテナが実際に動く「舞台」です。

たとえるなら、コンテナは中身を詰めた輸送用コンテナです。中身が何であっても、同じ形の箱ならトラックでも船でも同じ手順で運べます。どの船に何個積むかを決めるのが ECS・EKS、船を自分で持つのが EC2、運送会社に任せるのが Fargate です。

このページで押さえる論点

コンテナの基本と、アプリケーションの移行

コンテナイメージは、アプリのプログラム、ライブラリ、設定をまとめた「ひな形」です。イメージから起動した実行中のものをコンテナと呼びます。イメージはレジストリ（AWS では Amazon ECR）に保管し、動かすサーバーがそこから取り出して（プル）起動します。

項目仮想マシン（EC2 インスタンス）コンテナ
含むものOS 全体とアプリアプリと必要なライブラリだけ（OS のカーネルはホストと共有）
起動の速さOS の起動が必要プロセスを起動するだけなので速い
1 台のサーバーに載る数少ない多い（リソースを効率よく使える）
環境の違い環境ごとに設定がずれやすい同じイメージなら開発でも本番でも同じように動く

試験ガイドでは「アプリケーションをコンテナに移行する方法」「コンテナを使う場面を判断する」ことが求められます。既存のアプリをコンテナに移すときは、アプリをコンテナイメージにまとめて ECR に保存し、ECS や EKS で動かします。機能ごとに小さなサービスに分けて別々のコンテナで動かすマイクロサービスにすると、サービスごとに独立してデプロイ・スケールできます。コンテナは 1 台のサーバーに多く載せられるので、コンピューティングの使用率を上げてコストを下げる手段としても挙げられています。

Amazon ECS

Amazon ECS（Elastic Container Service）は、AWS 独自のコンテナオーケストレーションサービスです。オーケストレーションとは、多数のコンテナを「どのサーバーで何個動かすか」「止まったら起動し直す」「ロードバランサーにつなぐ」といった管理を自動で行うことです。

用語意味
クラスタータスクやサービスをまとめる論理的な単位
タスク定義コンテナの設計図。使うイメージ、CPU とメモリの量、ネットワークの方式、IAM ロール、ログの送り先などを書く
タスクタスク定義から起動した、実行中の 1 組のコンテナ
サービス指定した数（希望数）のタスクを動かし続ける仕組み。タスクが止まると自動で新しいタスクに置き換え、ロードバランサーへの登録も行う
再生型アニメ図解

ECS のサービスがタスクを動かし続ける流れ

ECR 実行ロール ECS サービス（Fargate） タスク1 タスク2 ALB S3 タスクロール

※簡略化しています: タスクは 2 つだけ、1 つの AZ のように描いています。実際には複数の AZ のサブネットにタスクを分けて配置します。ログの送信、ヘルスチェック、サービスの Auto Scaling は図では省略しています。

図で省略したヘルスチェックとスケーリングは、この節の後半で説明します。

タスクを動かす場所（キャパシティ）

動かす場所サーバーの管理向いている場面
AWS Fargate不要（サーバーレス）。タスクが使った分だけ支払うインフラを管理せずアプリに集中したい、負荷が変動する、コンテナを始めたばかり
Amazon EC2 インスタンス自分で EC2 を選び、設定・保守するGPU などの特殊なハードウェア、特定のインスタンスタイプ、キャパシティ予約、特権コンテナ、独自の AMI が必要
ECS Managed InstancesEC2 の用意・パッチ適用・スケーリングを AWS が行うFargate の手軽さと、インフラの細かい制御の両方が欲しい
外部インスタンス（ECS Anywhere）オンプレミスのサーバーや仮想マシンを自分で管理し、ECS クラスターに登録するオンプレミスで動くコンテナも ECS でまとめて管理したい

Fargate のタスクはネットワークモード awsvpc が必須で、タスクごとに専用のネットワークインターフェース（ENI）とプライベート IP アドレスが付き、タスク単位でセキュリティグループを設定できます。Fargate では GPU や特権コンテナ（privileged）は使えません。

2 つの IAM ロール

ロール使うのは誰か必要になる場面
タスクロール（タスク IAM ロール）コンテナの中のアプリケーションアプリが S3 や DynamoDB などの AWS サービスを呼び出す
タスク実行ロールECS（コンテナエージェント・Fargate エージェント）ECR のプライベートリポジトリからイメージを取り出す、ログを CloudWatch Logs に送る（awslogs）、Secrets Manager や Parameter Store の秘密情報をタスクに渡す

「コンテナ内のアプリに S3 へのアクセス権を与える」ならタスクロール、「イメージを取り出せない」「ログが送られない」ならタスク実行ロールの設定を疑います。

ロードバランサーとスケーリング

サービスは ALB などのロードバランサーと連携し、起動したタスクを自動でターゲットに登録します。タスクの数は Application Auto Scaling で自動的に増減できます（サービスの Auto Scaling）。ポリシーはターゲット追跡・ステップ・スケジュール・予測の 4 種類で、指標には CPU の平均使用率、メモリの平均使用率、ALB のターゲットあたりのリクエスト数などを使います。AWS は多くの場合ターゲット追跡を推奨しています。EC2 で動かす場合は、タスクを増やしたときに載せる EC2 も足りるように、キャパシティプロバイダーでインスタンスの台数も合わせて増減させます。

Fargate Spot とキャパシティプロバイダー

Fargate Spot は、中断されてもよいタスクを Fargate より安い料金で動かせる選択肢です。AWS がキャパシティを必要とすると、タスクが止まる 2 分前に警告が送られます。キャパシティプロバイダー戦略で、たとえば「最低 2 タスク（ベース）は通常の Fargate、残りは Fargate と Fargate Spot に 1 対 3 の割合（ウェイト）で配置する」といった組み合わせを指定できます。

Amazon EKS

Amazon EKS（Elastic Kubernetes Service）は、オープンソースのコンテナオーケストレーションツールである Kubernetes のマネージドサービスです。Kubernetes の司令塔にあたるコントロールプレーンを AWS が 3 つの AZ に分散して運用し、障害が起きたインスタンスも自動で置き換えます。クラスターごとに専用のコントロールプレーンが使われます。Kubernetes ではコンテナを動かす単位を Pod、Pod を動かすサーバーをノードと呼びます。

ECS との大きな違いは、Kubernetes の API やツールがそのまま使える点です。「すでに Kubernetes で運用している」「オンプレミスや他のクラウドと同じ Kubernetes の仕組みで管理したい」なら EKS、「AWS の中だけで、できるだけシンプルに運用したい」なら ECS を選ぶのが基本です。

ノード（Pod を動かす場所）の選び方

方式AWS が管理するもの自分で管理するもの
マネージドノードグループノード（EC2）の作成・更新の仕組みEC2 インスタンスと OS（セキュリティ、保守、パッチ適用）
セルフマネージドノードなしすべて（手作業の保守が最も多い）
EKS Auto Modeコントロールプレーンに加え、ノード（EC2）と OS の管理、スケーリングアプリケーション
AWS FargatePod を動かすサーバー。Pod ごとに分離された環境で動くアプリケーション（どの Pod を Fargate で動かすかは Fargate プロファイルで指定）

EKS で Fargate を使う場合、DaemonSet（全ノードで 1 つずつ動かす Pod）、特権コンテナ、GPU、EBS ボリュームは使えません（EFS は使えます）。Pod はプライベートサブネットに置き、外に出るには NAT ゲートウェイが必要です。

オンプレミスで Kubernetes を使う

Amazon ECR

Amazon ECR（Elastic Container Registry）は、AWS が管理するコンテナイメージのレジストリです。Docker イメージや OCI 形式のイメージを保存でき、ECS・EKS・Lambda（コンテナイメージで配布する場合）から取り出して使います。

料金は、保存しているデータ量とデータ転送量にかかります。

コンテナを使う場面と、サービスの選び方

コンテナが向くのは、長時間動き続けるアプリ、マイクロサービス、環境ごとの違いをなくしたいアプリ、1 回の処理が 15 分を超えるバッチなどです。短いイベント処理ならコンテナにせず Lambda のほうが手軽です。

比較・選択フローチャート

質問に答えてコンピューティングサービスを選ぶ

動かしたいアプリを思い浮かべて「はい / いいえ」で答えてください。答えた経路が上から順に表示されます。

    ※簡略化しています: 代表的な選び方だけを分岐にしています。オンプレミスで動かす場合（ECS Anywhere・EKS Anywhere）、バッチ処理を任せる AWS Batch、Fargate Spot の利用、Lambda をコンテナイメージで配布する場合は分岐に含めていません。

    選択肢サーバー管理選ぶ場面
    AWS Lambda不要イベントで動く最大 15 分の短い処理
    ECS ＋ Fargate不要コンテナを最小の運用負荷で動かしたい
    ECS ＋ EC2必要（Managed Instances なら AWS が管理）GPU、特定のインスタンスタイプ、特権コンテナが必要。Savings Plans などで EC2 を安く使いたい
    EKS（ノードまたは Fargate）ノードは必要、Fargate・Auto Mode なら不要Kubernetes を使い続けたい、オンプレミスと同じ仕組みで管理したい
    ECS Anywhere／EKS Anywhereオンプレミスのサーバーを自分で管理オンプレミスのコンテナも AWS の仕組みで管理したい
    AWS Batch不要（計算資源を自動で用意）大量のバッチジョブを、コンテナとして EC2・Fargate・EKS 上で実行したい

    フローチャートで省いたオンプレミスとバッチの選択肢は、上の表のとおりです。Lambda の詳しい制約は「AWS Lambda」、EC2 の購入オプションは「Amazon EC2」のページで扱います。

    問題文のキーワード → 選ぶべき答え

    問題文の言い回し選ぶべき答えと理由
    「コンテナを動かしたいが、サーバーやクラスターの容量を管理したくない」ECS（または EKS）＋ Fargate
    「既存の Kubernetes の設定やツールをそのまま AWS で使いたい」Amazon EKS
    「コンテナで GPU を使いたい」ECS（または EKS）＋ EC2（Fargate は GPU 非対応）
    「コンテナ内のアプリから S3 にアクセスさせたい」タスクロール（EKS では Pod に IAM ロールを割り当てる）
    「タスクが ECR のプライベートリポジトリからイメージを取得できない」「ログが CloudWatch Logs に送られない」タスク実行ロールの権限を確認する
    「中断されてもよいコンテナのタスクを安く動かしたい」Fargate Spot（中断の 2 分前に警告）
    「負荷に応じてタスクの数を自動で増減」ECS サービスの Auto Scaling（ターゲット追跡など）
    「古いコンテナイメージを自動で削除して保存コストを下げる」ECR のライフサイクルポリシー
    「コンテナイメージの脆弱性を自動で検出」ECR のイメージスキャン（拡張スキャンは Amazon Inspector）
    「コンテナイメージを別リージョンにも置きたい」ECR のクロスリージョンレプリケーション
    「オンプレミスのサーバーで動くコンテナも ECS で管理」ECS Anywhere（Kubernetes なら EKS Anywhere）

    引っかけポイント

    まとめ: SAA 試験で押さえるポイント

    確認問題

    参考リンク

    AWS 公式ドキュメント（外部サイトが開きます）。本文の数値はこれらで確認しています。