はじめに
AWSでコンテナ化されたアプリケーションを動かしたいと考えたとき、「ECSとEKS、どっちがいいの？」という疑問を持つ方は多いと思います。しかし実際には、AWSが提供するコンテナの実行環境はECSやEKSだけでなく、Lambda・EC2上での直接実行など、多彩な選択肢があります。それぞれ特性や得意とするユースケースが異なるため、違いを理解せずに選択してしまうと、「運用が思ったより大変だった」「コストが想定外に高くなった」といった問題が発生しやすくなります。
2026年3月31日のAWS Blogで、AppRunnerが2026年4月30日以降新規ユーザーへの公開を終了しメンテナンスモードへ移行することが発表されました。 コンテナ活用パターンの一つの終了が発表されたため、一度このタイミングでAWSのコンテナ関連サービスを整理しておきたいというのが、今回の記事を書くモチベーションとなっています。
本記事では、AWSでコンテナを動かすための主要なパターンを列挙した上で、各パターンがどのような仕組みで動作するのか、メリット・デメリットは何かを整理します。その上で、ユースケースごとにどのパターンが適しているかの選択基準を考えてみます。コンテナ実行基盤の選定に迷っている方のご参考になるような記事になればと思います。
AWSでコンテナを動かす選択肢の全体像
AWSでコンテナを動かす主要なパターンは以下の通りです。大まかに「どれだけAWSに管理を任せるか（マネージドの度合い）」と「スケーリングの単位が何か」という2つの軸で整理できます。
パターン一覧
| # | パターン | コントロールプレーン | データプレーン | スケーリングの単位 |
|---|---|---|---|---|
| ① | ECS on Fargate | ECS（AWS管理） | Fargate（AWS管理） | タスク |
| ② | ECS on EC2 | ECS（AWS管理） | EC2（ユーザー管理） | タスク（+ EC2インスタンス） |
| ③ | EKS on EC2 | EKS（AWS管理） | EC2（ユーザー管理） | Pod（+ EC2インスタンス） |
| ④ | EKS on Fargate | EKS（AWS管理） | Fargate（AWS管理） | Pod |
| ⑤ | Lambda（コンテナイメージ） | Lambda（AWS管理） | Lambda（AWS管理） | 関数の同時実行数 |
| ⑥ | EC2 + Docker（セルフマネージド） | ユーザー管理 | EC2（ユーザー管理） | インスタンス（手動管理） |
| ⑦ | AWS Batch | Batch（AWS管理） | EC2 or Fargate（選択） | ジョブ |
また、マネージドの度合いのイメージを図示すると以下のようになります。右に行くほどユーザーの管理負荷が高く、左に行くほどAWSへの委任が多く（つまりマネージドの度合いが高く）なっています。
各パターンの詳細
① ECS on Fargate
概要
Amazon ECS（Elastic Container Service）は、AWSが独自に提供するコンテナオーケストレーターです。Kubernetesとは異なる独自のAPIを持ちます。データプレーンにFargateを選択した場合、コンテナを動かすための仮想マシン（EC2インスタンス）の管理が一切不要になります。タスク定義（Task Definition）と呼ばれる設定ファイルに、コンテナイメージやリソース設定を記述し、ECSサービスとしてデプロイするのが基本的な使い方です。Fargateはステートフルなアプリ（永続ストレージが必要なアプリ）には不向きでしたが、現在はAmazon EBSの統合がサポートされているため、永続ストレージが必要な場合の選択肢としてEBSをマウントしたFargateについても選択肢となり得ます。
起動の流れ
① ECRにコンテナイメージをPush
② ECSのタスク定義を作成（イメージ、CPU、メモリ、環境変数 等を定義）
③ ECSサービスを作成（タスク定義 + 希望するタスク数 + ネットワーク設定）
④ FargateがAWSの管理するインフラ上でコンテナを起動
⑤ ALB/NLBを経由して外部からトラフィックを受け付け
メリット
- EC2の管理が不要。Kubernetesの知識が不要。サーバーレスでスケールイン/アウトが容易
- ECSとAWS各サービスとの統合が容易（IAM、ALB、CloudWatch、Secrets Manager等）
デメリット
- Fargateは起動が若干遅い（コールドスタートが数十秒かかる場合がある）
- EC2に比べてFargate単価は割高。常時起動系のワークロードでは費用が増えやすい
※ 利用用途（開発環境や中段可能なタスク）によっては、Fargate Spotを組み合わせることでコストを抑えることが可能。 - GPUワークロードや特定のカーネル設定が必要な場合には不向き
② ECS on EC2
概要
コントロールプレーンはECSを使いつつ、コンテナを動かすデータプレーンをEC2インスタンスで構成するパターンです。EC2インスタンス上でECS Agentが動作し、ECSから指示を受けてコンテナを起動します。EC2インスタンスの管理（AMIのアップデート、スケーリング等）はユーザー側で行う必要があります。EC2 Auto Scaling GroupやECS Capacity Providerと組み合わせた構成が一般的です。
起動の流れ
① ECS向けに最適化されたAMI（Amazon ECS-optimized AMI）でEC2インスタンスを起動
② EC2インスタンス上のECS AgentがECSクラスターに自動登録
③ ECSサービスにてタスクをスケジュール
④ ECS AgentがEC2インスタンス上でDockerコンテナとして起動
メリット
- EC2インスタンスを長時間使う場合、Fargateより費用を抑えやすい（Reserved InstanceやSavings Plansが利用可能）
- GPUインスタンスやカスタムカーネル設定など特殊なインスタンスタイプを利用できる
- インスタンスレベルでのチューニング（ストレージ、ネットワーク等）が可能
デメリット
- EC2インスタンスのパッチ適用やAMI更新などのOS管理が必要
- スケーリング時にEC2インスタンスの起動待ちが生じる（インスタンス起動には数分かかる）
③ EKS on EC2
概要
Amazon EKS（Elastic Kubernetes Service）は、AWSが提供するKubernetesのマネージドサービスです。Kubernetesのコントロールプレーン（APIサーバー、etcd等）をAWSが管理し、ユーザーはWorker Node（EC2インスタンス）の管理に集中できる構成です。マネージドノードグループ（Managed Node Group）やKarpenterと組み合わせることで、Nodeのライフサイクル管理を自動化することも可能です。
起動の流れ
① EKSクラスターを作成（コントロールプレーンはAWSが管理）
② EC2のWorker Node（マネージドノードグループ or セルフマネージドノード）を作成
③ Worker NodeがEKSクラスターに登録される
④ Deploymentなどのマニフェストをkubectl apply で適用
⑤ Kubernetes Schedulerがノードを選択してPodを起動
メリット
- Kubernetesのエコシステム（Helm、ArgoCD、Istio等）を最大限活用できる
- マルチクラスター管理、細かいスケジューリング制御など高度なオーケストレーションが可能
- オンプレやマルチクラウドのKubernetes環境との統一的な運用が可能
デメリット
- Kubernetes・EKS・AWS各レイヤーの知識が必要で学習コストが高い
- Worker NodeのEC2管理（AMI更新、パッチ等）が必要
- EKSクラスター自体の料金（$0.10/時間）が発生する
④ EKS on Fargate
概要
EKSのコントロールプレーンはAWSが管理しつつ、Worker NodeにFargateを利用するパターンです。Kubernetes Podが起動するたびに、AWSがFargate上の専用環境でコンテナを動かします。EC2 Nodeの管理が不要になりますが、Fargateの制約（特権コンテナ不可、DaemonSet不可 等）が適用されます。EKSとFargate Profileを組み合わせて、Namespaceやラベルに基づいてどのPodをFargateで動かすかを定義します。また、EKSのノードのオートスケールを行う仕組みとして、Kubernetesの従来の仕組みであるCluster Autoscalerだけでなく、AWSが開発しているKarpenterを利用することも可能です。Karpenterでは高速で柔軟なノードのスケーリングが提供されており、EKSを選択するメリットとなり得ます。
起動の流れ
① EKSクラスターを作成
② Fargate Profileを作成（どのNamespace/ラベルのPodをFargate上で動かすかを定義）
③ Deploymentなどのマニフェストをkubectl applyで適用
④ FargateがマッチするPodを専用環境で起動（EC2 Nodeは不要）
メリット
- KubernetesのエコシステムをEC2 Nodeの管理なしに利用できる
- Pod単位で課金されるためリソースの無駄が少ない
デメリット
- DaemonSet、特権コンテナ、hostNetworkなどFargateの制約により一部のKubernetesアドオンが使えない
- ECS on Fargateと比べKubernetesの知識が追加で必要
- Podの起動に数十秒かかることがあり、レイテンシが求められるワークロードには不向き
⑤ Lambda（コンテナイメージ）
概要
AWS Lambdaは、イベント駆動型のサーバーレスコンピューティングサービスです。従来はZIPアーカイブ形式でコードをデプロイするのが一般的でしたが、現在はコンテナイメージ形式（最大10GB）でのデプロイにも対応しています。コンテナイメージとしてパッケージングしつつも、実行モデルはLambdaのままです（イベント単位の起動、最大実行時間あり）。
また、Lambda Web Adapterを利用すると、Express・FastAPI・Nginxなど一般的なHTTPサーバーとして動作する既存のコンテナをほぼそのままLambda上で動かすことができます。Lambda向けのHandler実装に書き直す必要がなく、既存コンテナのLambda化が比較的容易に実現できます。
※Lambdaの最大実行時間の制限に対応するために、Lambda Durable Functionsの採用が解決策となる可能性はありますが、ユースケース（待機することができる処理）が限られるため今回の記事では考慮していません。
起動の流れ
① コンテナイメージをビルドし、ECRにPush（Lambda対応のベースイメージを使用）
② LambdaファンクションでコンテナイメージのECR URIを指定して関数を作成
③ イベント（API Gateway、SQS、EventBridge等）が発生するとLambdaが起動
④ コンテナイメージのHandler関数が実行される
メリット
- サーバーレスのため、インフラ管理が不要。コードを書いてデプロイするだけ
- リクエスト数に応じた従量課金。リクエストがない場合はコストゼロ
- コンテナイメージ形式により、依存ライブラリが多い場合や既存Dockerワークフローを流用したい場合に便利
デメリット
- コールドスタートが発生する（特にコンテナイメージは起動が遅くなる場合がある）
- 最大実行時間15分、最大メモリ10GBなどLambdaの制約がある
- 長時間稼働するプロセスや、WebSocketなど常時接続が必要なワークロードには不向き
⑥ EC2 + Docker（セルフマネージド）
概要
EC2インスタンスに直接Dockerをインストールし、docker runやdocker-composeでコンテナを起動するパターンです。AWSのオーケストレーションサービスを一切使わず、ユーザーが自前でコンテナのライフサイクルを管理します。最も自由度が高い反面、管理コストも最も高くなります。
起動の流れ
① EC2インスタンスを起動
② EC2インスタンスにDockerをインストール（または Docker入りAMIを使用）
③ ECRからイメージをPull（または直接イメージをビルド）
④ docker run または docker-compose up でコンテナを起動
⑤ nginxやSystemdを用いた再起動設定等を自前で管理
メリット
- オーケストレーション層がないため、構成が最もシンプルで理解しやすい
- どんなコンテナでも動かせる。特殊な要件（privileged、特定カーネルモジュール等）にも対応
- AWSコンテナサービスの追加費用がかからない
デメリット
- 可用性・スケーリング・自己修復などは全て自前で実装が必要
- EC2の管理（パッチ、スケーリング等）が全てユーザー負担
- 本番環境での利用は、障害時の対応・監視コストが非常に高くなる
⑦ AWS Batch
概要
AWS Batchは、バッチ処理専用のフルマネージドサービスです。ジョブキューとコンピューティング環境を定義することで、大量のバッチジョブを効率よく実行できます。コンテナイメージを使って各ジョブを実行する仕組みになっており、データプレーンにはEC2またはFargateを選択できます。機械学習のトレーニングや大規模なデータ加工など、短時間〜長時間のバッチ処理に適しています。
起動の流れ
① コンテナイメージをECRにPush（バッチ処理ロジックが含まれたイメージ）
② コンピューティング環境を定義（EC2 or Fargate、インスタンスタイプ、最大vCPU等）
③ ジョブキューを作成し、コンピューティング環境と紐付け
④ ジョブ定義を作成（コンテナイメージ、コマンド、リソース設定等）
⑤ ジョブをサブミット → Batchが自動でリソースを確保してコンテナを実行
メリット
- 大量ジョブのキューイング・依存関係管理・スケールアウト/インがマネージド
- スポットインスタンスの自動活用によるコスト削減が容易
- 長時間実行バッチ（15分超）でもLambdaの制約を受けない
デメリット
- バッチ処理専用であり、常時稼働のWebアプリなどには不向き
- EC2ベースの場合、インスタンス起動のウォームアップ時間が発生する
パターン比較
各パターンを主要な観点で比較します。
インフラ管理コスト・習得コスト比較
| パターン | サーバー管理 | K8s知識 | AWSサービス固有知識 | 総合的な習得コスト |
|---|---|---|---|---|
| ECS on Fargate | 不要 | 不要 | ECS（比較的シンプル） | ★★☆☆☆ |
| ECS on EC2 | 要 | 不要 | ECS + EC2管理 | ★★★☆☆ |
| EKS on EC2 | 要 | 要 | EKS + K8s + EC2管理 | ★★★★★ |
| EKS on Fargate | 不要 | 要 | EKS + K8s + Fargate制約 | ★★★★☆ |
| Lambda | 不要 | 不要 | Lambda制約の理解 | ★★☆☆☆ |
| EC2 + Docker | 要 | 不要 | EC2 + 自前管理 | ★★★★☆ |
| AWS Batch | 不要 | 不要 | Batchの概念理解 | ★★★☆☆ |
コスト特性比較
| パターン | 課金モデル | コスト最適化のポイント |
|---|---|---|
| ECS on Fargate | タスク起動時間 × vCPU/メモリ | 不要な時間帯のタスク停止、適切なリソース設定 |
| ECS on EC2 | EC2インスタンス費用 | Reserved Instance/Savings Plans、スポットインスタンス活用 |
| EKS on EC2 | EKSクラスター料金 + EC2費用 | Reserved Instance/Savings Plans、Karpenterによる最適スケーリング |
| EKS on Fargate | EKSクラスター料金 + Fargate Pod費用 | 適切なリソース設定 |
| Lambda | リクエスト数 + 実行時間 | コールドスタート対策、適切なメモリ設定 |
| EC2 + Docker | EC2インスタンス費用 | Reserved Instance/Savings Plans |
| AWS Batch | EC2 or Fargate費用 | スポットインスタンス活用が容易 |
ユースケース別選択ガイド
実際の選定では、「どのパターンが理想か」だけでなく「チームのスキルセット」や「既存の技術スタック」も大きな判断材料になります。以下はユースケースごとの推奨パターンをまとめたものです。
ユースケースと推奨パターン
| ユースケース | 推奨パターン | 理由 |
|---|---|---|
| スタートアップ・小規模チームの本番Webアプリ | ECS on Fargate | インフラ管理を最小化し、開発速度を優先できる |
| マイクロサービス（中〜大規模）、K8s不要 | ECS on Fargate | サービス間の独立したスケーリングが可能。ECSのデフォルト選択はFargate（EC2管理不要） |
| マイクロサービス（中〜大規模）、K8sエコシステムを活用したい | EKS on EC2 | IstioやArgoCDなどK8sエコシステムを最大活用。大規模になるほどEKSのデフォルト選択はEC2（Reserved Instance等でコスト最適化） |
| イベント駆動・非同期処理 | Lambda | APIやキューをトリガーとしたスケーラブルな非同期処理に最適 |
| 大規模バッチ処理・機械学習パイプライン | AWS Batch | 大量ジョブの並列実行とスポットインスタンスによるコスト最適化 |
| オンプレからのKubernetesワークロード移行 | EKS on EC2 | マニフェストの再利用性が高く、既存のK8sエコシステムをそのまま活用 |
| GPUが必要なワークロード（推論、学習等） | ECS on EC2 / EKS on EC2 | GPUインスタンスが利用可能。FargateではGPU非対応 |
| 既存のKubernetesチームによる新規AWS構築 | EKS on EC2 or Fargate | Kubernetesの知識とツールチェーンを活かせる |
| 検証・PoC・開発環境 | ECS on Fargate / EC2+Docker | 手軽に始められる。低コストで試せる |
| マルチクラウド・ハイブリッド環境 | EKS on EC2 | KubernetesはAWSに限らない標準APIのため他環境との相互運用性が高い |
| コスト最優先の常時稼働アプリ（中〜大規模） | ECS on EC2 / EKS on EC2 | Reserved InstanceやSavings Plansで単価を下げやすい |
選定フローチャート
※ 今回は、AWS上でワークロードを動かすことのみにフォーカスした形としましたが、将来的にマルチクラウドやオンプレミスへの展開の可能性がある場合、将来的なポータビリティという意味でEKSは大きなメリットを持っていると考えます。
まとめ
本記事では、AWSでコンテナを動かす7つの主要なパターンについて、起動の仕組み・メリット・デメリットを整理し、ユースケース別の選択指針をご紹介しました。
それぞれのパターンの特徴を改めて一言でまとめると以下の通りです。
| パターン | まとめ |
|---|---|
| ECS on Fargate | AWSコンテナの標準解。インフラ管理なしにコンテナを安定運用 |
| ECS on EC2 | コスト最適化や特殊インスタンス要件があるときのECS |
| EKS on EC2 | Kubernetesを本格的に使い倒したいなら。学習コスト覚悟 |
| EKS on Fargate | K8sを使いたいがNode管理は避けたい。制約は許容できる |
| Lambda | イベント駆動・短時間処理のサーバーレス実行環境 |
| EC2 + Docker | 学習・検証や特殊要件向け。本番での本格利用は管理コストが高い |
| AWS Batch | 大規模バッチ処理のためのマネージドジョブスケジューラー |
個人的には、コンテナを考えなくてはいけないユースケースの中では、迷ったときは ECS on Fargate から検討するのが良いのではないかと思います。多くのWebアプリケーションユースケースをカバーでき、AWSとの統合も豊富で、インフラ管理の負担を最小限に抑えることが可能です。ECSでカバーできない要件が出てきた時に、EKSやEC2の採用を検討するという進め方が、現実的でよいと思います。
（Lambdaが向いているパターンについては、そもそもコンテナをどこで動かすかというから議論が始まることが多くないと考えています。Lambdaで動かすことが決まった上で、今後のポータビリティも考えてコンテナとして作ったほうがいいという流れになることが多いのではないでしょうか。）
コンテナ基盤の選定は走り出してしまうとどうしても変更が大変になってしまうので、最初のタイミングでよくよく議論するべきポイントです。本記事が選定の際のご参考になれば幸いです。