Pocket Bundle シリーズ : Amazon ECS ~ AWS と深く統合されたフルマネージドなコンテナ基盤

Amazon Elastic Container Service (Amazon ECS) は、コンテナ化されたアプリケーションのデプロイ・管理・スケーリングを担う、フルマネージドなコンテナオーケストレーションサービスです。

コンテナが 1 個なら docker run で足ります。しかし本番環境では、複数ホストへの配置、異常終了したコンテナの自動再起動、負荷に応じた台数の増減、新バージョンへの安全な切り替えが必要です。こうしたコンテナの外側にある仕事を引き受けるのがオーケストレーターです。ECS ではその管理を担うコントロールプレーンを AWS 自身が運用するため、管理すべきオーケストレーターそのものが利用者側に存在しません。

ECS は 3 つのレイヤーで整理できます。コンテナが実際に動く「キャパシティ」、アプリケーションのデプロイと維持を司る「コントローラー (スケジューラ）」、そして操作の入り口となる「プロビジョニング」（AWS マネジメントコンソール・AWS CLI・SDK・AWS CDK）です。

なお、Fargate と EC2 起動タイプでは、オーケストレーション機能自体に追加料金はありません。マネージドインスタンスには別途管理料金があります。詳細は後述の「ECS の料金体系」で扱います。

詳しくは、公式ドキュメントの「Amazon Elastic Container Service とは」をご覧ください。
 

X ポスト » | Facebook シェア » | はてブ »

ECS の特徴は図の 3 点に集約されます。それぞれが実務で何を意味するかを順に説明します。

ECS は 2014 年に発表されました。当時、コンテナを本番で使い始めた企業は、Amazon EC2 の上に自前のオーケストレーション層を組んで運用しており、その維持が大きな負担になっていました。図の言葉は、立ち上げ時の Product Manager である Deepak Singh 氏が 10 周年の公式ブログで振り返ったもので、ECS が何を解決しようとしたかを端的に表しています。

この要望へのアプローチが ECS の設計を方向づけました。汎用のオーケストレーション層を AWS 上に別途構築するのではなく、AWS のサービス群 (IAM・ELB・CloudWatch・VPC) と直結するオーケストレーターを作りました。抽象化のレイヤーが 1 枚少ない分、統合は深く、運用は軽くなります。一方でその設定は AWS 固有のものになるというトレードオフもあります。
この方針はその後も変わっていません。本記事で紹介する新機能も同じ設計思想の延長線上にあります。Amazon ECS マネージドインスタンスは、EC2 の機能を使える状態を保ったまま運用を AWS 側へ移し、Amazon ECS Express Mode は周辺サービスの統合設定そのものを自動化しました。

出典・詳細は、AWS 公式ブログの「Amazon ECS の 10 周年を祝う: 10 年間にわたるコンテナ化イノベーションの推進」をご覧ください。

タスク定義は、アプリケーションの設計図を JSON で宣言したものです。構成要素は図のとおりです。

まず、タスク定義は不変 (イミュータブル) です。内容の変更はできず、更新するたびに新しいリビジョンが同じファミリーの下に登録されます。デプロイはサービスが参照するリビジョンを差し替えることであり、ロールバックは旧リビジョンを指し直すことです。この仕組みが、後述するデプロイ戦略やバージョン整合性の土台になっています。

クラスターはタスクを動かすリージョン内の論理グループです。図の 3 つのキャパシティのうちどれを選び、どう指定するかが設計の中心になります。
指定方法はキャパシティプロバイダー戦略が推奨です。起動タイプの直接指定はタスク定義の互換性の宣言にとどめ、実際の起動はキャパシティプロバイダーに任せる、というのが公式の推奨です。戦略では base (最低確保数) と weight (比率) で複数プロバイダーへの配分を宣言でき、クラスターの自動スケーリングとも連動します。

サービスは desiredCount で指定した数のタスクを維持し続ける仕組みです。

サービススケジューラは、タスクの停止だけでなく異常も検知して置き換えます。判定材料はコンテナのヘルスチェックとロードバランサーのターゲットグループのヘルスチェックで、置き換えの順序は maximumPercent の余裕次第です。余裕があれば代替タスクを先に起動してから異常タスクを止め、余裕がなければ先に 1 つずつ止めて容量を空けます。また、タスクが起動直後に異常終了し続ける場合、スケジューラは再試行の間隔を自動的に広げます。壊れたイメージへのデプロイでリソースが浪費され続けない設計です。

4 種類の戦略の動きは図のとおりです。

デフォルトの ROLLING は、minimumHealthyPercent で維持する下限を、maximumPercent で同時に実行する上限を指定し、一度に入れ替える割合を制御します。追加リソースがほぼ不要な代わりに、新旧が混在する時間が生まれ、トラフィックの向き先は制御できません。失敗検知は 2 系統あります。デプロイサーキットブレーカーはタスクが起動できないという失敗を検知し、CloudWatch アラームは起動はするがアプリの指標が悪化するという失敗を検知します。両者は併用でき、どちらも前のリビジョンへの自動ロールバックに対応します。

BLUE_GREEN・LINEAR・CANARY は、新環境を丸ごと用意してトラフィックを移す系統です。ECS ネイティブのブルー/グリーンデプロイは 2025 年 7 月に追加され、従来必要だった AWS CodeDeploy を挟まずに実現できるようになりました。CodeDeploy 版のドキュメントも、現在は ECS ネイティブの利用を推奨しています。本番切替前にテストトラフィックで検証でき、切替後もベイク時間の間は旧環境が維持されているため、ロールバックはトラフィックを戻すだけで即座に完了します。各ステージにはライフサイクルフック (AWS Lambda 関数または一時停止ポイント) を差し込めるので、スモークテストの自動実行や手動承認をデプロイの一部にできます。

⚠ BLUE_GREEN・LINEAR・CANARY はデプロイ中、新旧のタスクセットが同時に動くため、リソース消費が一時的に最大 2 倍になります。Fargate のアカウント vCPU クォータや EC2 の空き容量が平常時の需要と同じだと、デプロイそのものが失敗します。また Network Load Balancer を使う場合、トラフィック移行の各ステージに 10 分の追加時間がかかります。

詳しくは、公式ドキュメントの「Amazon ECS ブルー/グリーンデプロイ」、ローリング更新については「タスクを置き換えて Amazon ECS サービスをデプロイする」をご覧ください。

Express Mode は 2025 年 11 月に追加された、Web アプリの公開構成を 1 コマンドで組み上げる機能です。必要な入力は 3 つだけ、コンテナイメージ・タスク実行ロール・インフラストラクチャロール (ECS がインフラを代理構築するためのロール) です。

図の 7 つ以上のリソースの内訳は次のとおりです。HTTPS リスナーと証明書 (AWS Certificate Manager) を備えた ALB、最小限の許可に絞ったセキュリティグループ、CPU 使用率 60% を目標とするターゲット追跡スケーリング (1 ~ 20 タスク）、タスク定義 (既定 1 vCPU / 2 GB）、サービス、ロググループ、そして HTTP エラー率を監視してロールバックにつなげるアラームまで作られます。デプロイ戦略はカナリアに固定されており、更新時の安全策が最初から組み込まれています。

Express Mode の設計で重要なのは、リソースがすべて自分のアカウントに通常のリソースとして作られることです。PaaS のように内部リソースへ直接アクセスできない形にはならず、ALB の設定変更もタスク定義の差し替えも後から直接行えます。最初は全自動で作り、必要になったところから個別調整へ移れます。作り直しは不要です。Express Mode 自体は無料で、課金は作られたリソース (Fargate・ALB・CloudWatch Logs 等) の分だけです。ALB は同一 VPC 内の Express サービス最大 25 個で自動共有されるため、サービスを増やすほど 1 アプリあたりのコストは下がります。

⚠ サブネット未指定の場合はデフォルト VPC のパブリックサブネットに、インターネット向け ALB 付きで構築されます。既存の VPC 設計がある本番環境では、最初からサブネットを明示します。プライベートサブネットを渡せば内部 ALB になります。

詳しくは、公式ドキュメントの「Amazon ECS Express Mode」をご覧ください。

図の構成は、ECS がコンテナの実行を担い、それ以外を専門のサービスに任せる役割分担の実例です。この分担には、いくつか前提があります。

大前提は、コンテナを使い捨てにすることです。タスクは障害やデプロイでいつでも入れ替わるため、ローカルに書いたデータは消えます。だからこそ状態は Amazon RDS や Amazon S3 など外部に置き、タスクはステートレスに保ちます。これができていれば、スケールアウトも置き換えも、タスク数の変更だけで済みます。

ネットワーク面では、awsvpc モードの帰結として各タスクが専用の Elastic Network Interface を持ち、そこにセキュリティグループを関連付けます。このため ALB のターゲットグループは instance ではなく ip タイプで作る必要があります。代わりに、RDS へのインバウンドはタスクのセキュリティグループからのみ許可する、というタスク粒度のネットワーク制御をそのまま記述できます。

デプロイの流れは、ECR へイメージを push → タスク定義の新リビジョンを登録 → サービスを更新、の 3 段です。このとき ECS はイメージタグをダイジェスト (内容のハッシュ) に解決してからタスクを起動するため、デプロイ中にタグが動いても、サービス内のタスクは既定で同一のイメージに揃います。図のタスク実行ロールが担っているのは、この ECR からのプルとログ送信です。

詳しくは、公式ドキュメントの「Amazon ECS タスク実行 IAM ロール」をご覧ください。

マイクロサービス化すると、図にあるとおりサービスを個別にデプロイ・スケールできるようになります。ECS ではサービスがそのままデプロイとスケールの単位なので、注文サービスだけをスケールアウトする、決済サービスだけカナリアで慎重に更新する、といった運用ができます。分割の境界は、別々に変更・増減したい単位で引きます。

Service Connect がサービス間通信を担う

分割すると次に問題になるのがサービス間の呼び出しです。Service Connect を有効にすると、各タスクにプロキシコンテナがサイドカーとして自動注入され、アプリは http://payment のような短縮名で相手を呼べるようになります。名前は名前空間 (実体は AWS Cloud Map) で管理され、宛先の選択はプロキシがラウンドロビンと外れ値検出で行い、不調なタスクを避けます。接続のリトライやフェイルオーバーの処理をアプリのコードから分離できることが利点です。

内部 ALB を各サービスの前に並べる構成と比べると、Service Connect は管理するリソースが少なく、全サービスのトラフィックメトリクスが標準化された形で CloudWatch に揃います。サービス間の通信は Service Connect、外部からの入口は ALB、という使い分けが基本形です。

⚠ Service Connect を使うタスク定義では、タスクレベルのメモリ上限の設定が必須です。プロキシコンテナも同じタスクの CPU・メモリを消費するため、アプリ単体のサイジングに少し上乗せが必要です。

詳しくは、公式ドキュメントの「Service Connect を使用して Amazon ECS サービスを短縮名で接続する」をご覧ください。

Web アプリ以外でも、キャパシティを使い分ければ ECS は同じ操作感で応用できます。図の 2 例を設計の観点から補足します。

生成 AI 推論：GPU はどこで手に入るか

タスク定義で GPU 数を指定すると、ECS は GPU 対応インスタンスにタスクを配置し、物理 GPU をコンテナに固定して割り当てます。GPU が使えるのは EC2 (p 系・g 系インスタンス) とマネージドインスタンスで、後者ならアクセラレータを必須とする属性指定だけで、インスタンスの選定・パッチ・入れ替えを AWS に任せられます。Fargate は GPU 非対応なので、推論コンテナは GPU キャパシティへ、その手前の API・前処理は Fargate へ、と 1 つのクラスター内で分けるのが定石です。

バッチ処理：Spot の割引は中断を前提とした設計とセット

Fargate Spot は通常の Fargate 料金から最大 70% 引きで使えますが、AWS が容量を回収する際に 2 分前の警告付きで中断されます。したがって前提はタスク側の中断耐性です。SIGTERM を受けたら途中結果を Amazon S3 に書き出して終了すること、同じ入力で再実行しても結果が壊れないべき等な処理にすること、この 2 点を満たせば、中断はリトライで済むようになります。強制終了までの猶予はタスク定義の stopTimeout で調整でき、既定は 30 秒です。入力も出力も S3 に置き、タスク自身は状態を持たない構成が図の形です。

キャパシティプロバイダー戦略で FARGATE に base を、FARGATE_SPOT に weight を振れば、最低限をオンデマンドで確保して増加分を Spot に流す構成も 1 つのサービスで実現できます。

詳しくは、公式ドキュメントの「GPU ワークロード向けの Amazon ECS タスク定義」をご覧ください。

主要なクォータは図のとおりです。

まず、図にある「数」の上限（1 クラスターあたりサービス 5,000 など）は、通常の設計ではまず到達しません。運用で実際に制約になるのは、速度と同時量の制限です。タスクの起動レートは 1 サービスあたり毎分 500（Fargate では、東京を含む主要リージョン以外は 125）で、大規模なスパイク時のスケールアウトやデプロイの所要時間を規定します。さらに Fargate にはアカウント単位の同時 vCPU 数クォータがあり、新規アカウントでは初期値が低く設定されて使用実績に応じて自動で引き上がります。新しいアカウントで負荷試験を行うと、まずこのクォータに到達するのが典型です。

また、リビジョン数の 1,000,000 は削除しても減らないカウントですし、ブルー/グリーン系のデプロイは一時的にタスク数が倍になるため、クォータや容量は、平常時の需要にデプロイ分を加えて見積もる必要があります。マネージドインスタンスのインスタンス数は ECS ではなく EC2 側のクォータに従います。

図の注記にある Service Connect と AWS Cloud Map の関係も補足します。Service Connect は名前解決のために Cloud Map のサービスを自アカウントに自動作成します。このため Cloud Map 側のクォータが適用されるほか、作られたリソースを手動で変更・削除すると、トラフィックや以降のデプロイが予期しない挙動になります。管理は ECS 側から行い、Cloud Map 側は触らないのが原則です。

詳しくは、公式ドキュメントの「Amazon ECS の Service Quotas」をご覧ください。

比較表と選定フローは図のとおりです。

最大の違いは、運用責任がどちらに寄るかです。Amazon EKS を選ぶと Kubernetes の年数回のバージョンアップへの追随と、アドオン群の維持が自分の仕事として残ります。その対価が K8s 標準 API とエコシステム（Helm・既存マニフェスト資産・マルチクラウド戦略）です。ECS にはオーケストレーターのバージョンという概念自体がなく、この維持コストがゼロになります。AWS Lambda はさらに軽く、実行環境の管理は不要ですが、1 回の実行は最大 15 分、ペイロードやランタイムの制約の中で設計することになります。

「ポータビリティ」の行も誤解されやすい項目です。AWS 依存なのはタスク定義やサービス設定といったオーケストレーション層の記述であって、コンテナイメージそのものはどこでも動きます。移行時に書き直すことになるのは設定であって、アプリケーションそのものではありません。

実際のシステムでは併用が普通です。イベント駆動の非同期処理は Lambda、常駐 API とバッチは ECS、というように図の選定フローをコンポーネント単位で適用してください。1 つのシステムに 1 つの実行基盤、と決める必要はありません。

詳しくは、公式ドキュメントの「AWS コンテナサービスの選択」をご覧ください。

課金の構造は図のとおりです。

Fargate の要点は「リクエスト値」への課金です。タスク定義に書いた vCPU・メモリの分を、実際の使用率が 1 割でも満額支払います。Fargate の節約はタスクサイズの適正化そのものです。エフェメラルストレージは 20 GB まで追加料金なしで、超過分から課金されます。課金は秒単位 (最低 1 分。Windows は OS 料金が加算され、最低 5 分) です。継続利用が見込めるなら Compute Savings Plans で最大 50% の割引が、中断を許容できるなら Fargate Spot で最大 70% の割引が狙えます。また ARM (AWS Graviton) は x86 より単価が低く、イメージが対応していれば乗り換えだけで下がるコストです。

マネージドインスタンスは EC2 インスタンス料金と ECS 管理料金の 2 階建てで、どちらも秒単位・最低 1 分です。注意したいのは割引の適用範囲で、リザーブドインスタンスや Savings Plans、Spot の割引が適用されるのは EC2 部分だけです。管理料金には適用されません。課金はタスクの使用分ではなくインスタンス全体なので、実効単価を下げる鍵はインスタンスの使用率です。マネージドインスタンスが既定で複数タスクを大きめのインスタンスに詰め込むのは、この使用率を上げるためです。

EC2 起動タイプは ECS の追加料金がゼロで、支払いは EC2 インスタンス料金のみです。ただし空いているインスタンスにも満額を支払うため、詰め込み (ビンパッキング) の責任を自分で負うことになります。コスト最適化の中心は、Fargate ではタスクサイズの適正化、マネージドインスタンスと EC2 ではインスタンス使用率の改善になります。

⚠ 単価はリージョン・OS・CPU アーキテクチャで異なり、改定もあります。また、ALB や CloudWatch Logs、データ転送など周辺サービスの料金は別途かかります。見積もりの際は必ず公式料金ページで最新の単価を確認してください。

料金は変更される場合があります。詳しくは、「AWS Fargate の料金」でご確認ください。

ECS についてさらに学ぶための公式リソースです。QR コードから各リソースにアクセスできます。

各リソースの使い分け：

• 公式ドキュメント : 全機能・API・設定値・クォータの正確な確認
  
• ベストプラクティス : ネットワーク・セキュリティ・デプロイ高速化などの設計指針
• AWS Black Belt : 体系的な学習や機能の詳細な理解
• AWS ブログ : Express Mode やマネージドインスタンスなど新機能の最新情報

なお、英語版の公式ドキュメントは日本語版より更新が早い場合があります。本記事で扱った 2025 年以降の新機能は特に、最新の仕様確認には英語版も参照することをおすすめします。

⚠ 本記事は 2026 年 9 月時点の情報です。料金や仕様は変更される場合があるため、最新情報は公式ドキュメントをご確認ください。

米倉 裕基
アマゾン ウェブ サービス ジャパン合同会社
テクニカルライター・イラストレーター

日英テクニカルライター・イラストレーター・ドキュメントエンジニアとして、各種エンジニア向け技術文書の制作を行ってきました。趣味は娘に隠れてホラーゲームをプレイすることと、暗号通貨自動取引ボットの開発です。現在、AWS や機械学習、ブロックチェーン関連の資格取得に向け勉強中です。