この記事では、AWSでよく利用されるサービスでありながら少し複雑なECSの概要や実行基盤の選定方針について紹介していきたいと思います。
ECS(Elastic Container Service)とは？
AWS上でコンテナの実行をサポートする、コンテナオーケストレーションサービスです。
コンテナ技術とは、サービスを構成するアプリケーション・ミドルウェアや、それらに関する依存関係をひとまとめにしたものです。
AWSのコンテナの実行用サービスにはECSとEKSの2種類があります。
EKSはKubernetesの実行の為のAWSサービスであり、オンプレミスでKubernetesを活用していた場合の移行の際の検討や、設定を柔軟に細かく行いたい場合等に検討されます。
EKSはKubernetesに関する学習コストが高いため、まずはECSでの運用を検討し、マルチクラウド構成などECSでは実現が難しい場合に、EKSへの移行を検討する形が良いと思います。
ECSは構成や設定等AWSに管理を任せられる範囲が広く、より手軽にコンテナを実行できるサービスとなっています。
ECSを実行することによりAWSのサポート範囲となる部分
ECSを利用することで、コンテナのコントロールプレーンというコンテナの配置、起動順序、更新タイミングなどを制御する機能群の管理をAWSに任せることが可能になります。これをAWSが担うことで、ユーザーはアプリケーション開発により集中できるようになります。
さらに、Fargateというサーバーレスなコンピューティングリソースにも対応しており、これを活用することで、ユーザーの運用負荷をさらに軽減できます。
ECSの実行で必要となるサービス
ECSの運用には、以下のAWSサービスとの連携が必要になります。これらを正しく理解することで、より柔軟な設計が可能になります。
それぞれのサービスについて以下で触れていきます。
・ECSの構成要素
-
タスク定義
タスクで実行するイメージの指定や、確保するリソース、ポートの指定など、コンテナを実行する上での設計図のような役割のサービスです。 -
ECSクラスター
ECS クラスターは、ECS を使う上で必ず必要になる、タスクやサービスの「土台」となるグループです。
すべてのタスクやサービスは、まずこのクラスターに所属させることで実行されます。
同じアプリケーションに関係するコンテナをひとつのクラスターにまとめることで、名前解決やスケジューリングといった機能を効率的に活用できるようになります。
・ECS運用を支えるサービス
-
ECR(Elastic Container Registry)
コンテナイメージの保存を行うサービスです。
同じアプリケーションに関係するコンテナをひとつのクラスターにまとめることで、名前解決やスケジューリングといった機能を効率的に活用できるようになります。 -
EC2 or Fargate
コンテナの実行基盤にあたる部分で、タスク定義を基にタスクを実行します。コンピューティングリソースとしてECSは2種類をサポートしています。選定基準については後述します。
実行基盤の違いによる管理領域の比較
①ECS on EC2と、②ECS on Fargate、この2つはデータプレーンと呼ばれる、コンテナの実行基盤となるサービスですが、 この2つの違いについて見ていきます。
まずはユーザーでの管理領域について見てみます。
ECSの責任共有モデルの文言ベースでみると、Fargateでは管理対象外で、EC2では管理対象となっているのは下記の2点です。
・パッチ適用と強化を含む EC2 インスタンス AMI。
・Amazon ECS エージェント。
それぞれ、どのような内容か確認していきます。
パッチ適用と強化を含む EC2 インスタンス AMI
EC2起動時に使用するAMIの選定に加え、CIS等に準拠したセキュリティ強化、起動後のOSレベルのセキュリティパッチの適用等が管理領域となります。
Amazon ECS エージェント
ECSクラスターとインスタンスを紐づけるためのコンポーネントです。管理領域には、ECSエージェントのインストール（ECSに最適化されていないAMI使用時）、設定ファイル（/etc/ecs/ecs.config）によるクラスター指定、バージョンの管理・アップデート、ログ監視などが含まれます。
実行基盤の料金の違い
EC2とFargateには、利用料金にも違いがあります。
EC2を使用することによってコストを抑えることができますが、管理レイヤーが増加する為天秤に掛けてどちらを優先するか、といった基準で考えることになると思います。
ちなみに、スペックを1vCPU,2GiBメモリと定義した場合の2025/04/04の東京リージョンでの料金は下記になります。
該当スペックのインスタンスをリストアップします。
| インスタンス名 | オンデマンドの時間単価 | vCPU | メモリ | ストレージ | ネットワークパフォーマンス |
|---|---|---|---|---|---|
| c7a.medium | USD 0.0646 | 1 | 2 GiB | EBS のみ | 最大 12.5 Gbps |
| c8g.medium | USD 0.05003 | 1 | 2 GiB | EBS のみ | 最大 12.5 Gbps |
| c7gd.medium | USD 0.0577 | 1 | 2 GiB | 1 × 59 NVMe SSD | 最大 12.5 Gbps |
| c7gn.medium | USD 0.0787 | 1 | 2 GiB | EBS のみ | 最大 25 Gbps |
| c6gn.medium | USD 0.0545 | 1 | 2 GiB | EBS のみ | 最大 25 Gbps |
| c6g.medium | USD 0.0428 | 1 | 2 GiB | EBS のみ | 最大 10 Gbps |
| c7g.medium | USD 0.0455 | 1 | 2 GiB | EBS のみ | 最大 12.5 Gbps |
| t2.small | USD 0.0304 | 1 | 2 GiB | EBS のみ | 低〜中 |
| c6gd.medium | USD 0.049 | 1 | 2 GiB | 1 × 59 NVMe SSD | 最大 10 Gbps |
該当するスペックを持つインスタンスは上記になります。
・Fargateの料金
1 時間あたりの vCPU 単位 USD 0.05056
1 時間あたりの GB 単位 USD 0.00553
上記からでスペックを満たすように計算すると1時間当たりの料金が下記になります。
0.05056+0.00553*2=0.06162
Fargateの料金ページでは、下記の記載の通り1024^3バイト(GiB換算)で計算されているので、そのまま計算しています。
このページでは GB = 1024^3 バイト
EC2はCPUとメモリだけ定義するとインスタンスの幅が広いので、料金の差は変わってしまいますが、要件に合わせたインスタンスを選定したうえでFargateとの料金を比較して検討しましょう。
実行基盤の選択基準
では、EC2とFargateは、どのような基準で選択をすればいのか、一部の例を上げていきます。
・EC2を選択するパターン
- OSの管理など、リソースに対する細かな制御が必要な場合
→ OSのパッチなどの制御が必要となる場合は、FargateだとAWSで管理されるため対応できない範囲となるため、EC2の使用が適しています。
・Fargateを選択するパターン
- サーバーレスサービスの利用によりコンテナの管理負荷を下げたい場合
→ OS管理をAWSに任せることで、OSのセキュリティ等を意識せずに開発に集中することが可能です。 - ワークロードが短期的に変動する場合
→ 自動化されたスケーリング機能によって、急なアクセス数の増加等の予測のできないワークフローに対する強みがあります。
これらの基準をもとに、実行基盤の選定を進めていくことができます。
ただし、ここで挙げた点はあくまで一例であり、EC2とFargateには他にも多くの違いが存在します。
そのため、最終的にはシステム要件や運用方針に応じて、それぞれの特性を比較し、適切な基盤を選定することが重要です。
一方で、運用負荷の軽減という観点からは、まずはFargateを前提に検討を進めることで、構成のシンプル化や効率的な運用につながるケースが多く見られます。
ECS実行時の注意点
Amazon ECSは、AWS上でコンテナを簡単にデプロイ・管理できる非常に便利なサービスですが、運用していく中で注意すべき点もいくつか存在します。
本項目では、ECSを利用する際に特に気を付けるべき項目について解説します。
・エフェメラルストレージ
ECSにはデフォルトで「エフェメラルストレージ」と呼ばれる一時的なストレージがアタッチされます。このストレージは、コンテナのキャッシュやテンポラリファイルなど、一時的なデータの保存には適していますが、揮発性がある為、タスクの終了や再起動を行うとエフェメラルストレージ内に保存されたデータが削除されてしまう点に注意が必要です。
・リソース設定
AWSの自動スケーリングは、スケールアウトというタスクの複製を増やすという形で対応します。
そのため、各タスクに十分なリソース（CPUやメモリ）が割り当てられていない状態では、いくらスケールアウトしても同じタスクが同じリソース不足で落ち続けるという状況になります。
このようなケースでは、「スケールアウト」ではなく「スケールアップ」の観点が必要になります。
・ スケールアウト：同じ構成のタスクを水平方向に増やす（サーバーの台数を増やすスケール方法）
・ スケールアップ：1つのタスクに割り当てるリソース（CPU・メモリ）を増やす（サーバーの処理性能を上げるスケール方法）
ECSにおいてスケールアップは自動では行われないため、明示的にタスク定義を更新し、再デプロイする必要があります。
つまり、コンテナを実行するためのスペックが不足している場合はタスク定義を更新してリソースの再定義をする必要があります。
ECSの採用例
では、実際にECSが採用される構成パターンについて見てみましょう。
例として下記2パターンでの実装を見てみます。
1.Webアプリケーションで使用する際の構成パターン
・ ALB→ECS→RDS
この構成ではhttpやhttpsのリクエストをALBで受け、ALBからリクエストをECSに受け渡します。その後コンテナからRDS等のDBサービスにデータを受け渡す構成です。
また、フロントエンドとバックエンドを分離させてコンテナを作成している場合は、「ALB→ECS(フロントエンド)→ALB→ECS(バックエンド)→RDS」といった構成が一般的になってくると思います。
2.Batch処理向けの構成パターン
・EventBridge→ECS→S3
この構成はイベントドリブンなバッチ処理を行う際に使用される構成です。
S3へのファイルアップロード等をトリガーに、EventBridgeが実行されてECSの実行を行います。ECSでの処理後のデータはS3等のストレージサービスに受け渡すことによってデータを保存する構成です。
まとめ
ECSは、AWSが提供するマネージドなコンテナ実行環境であり、複雑なインフラ管理を最小限にしつつ、柔軟でスケーラブルなアプリケーション運用を実現できます。
実行基盤には、柔軟性の高いEC2と、完全マネージドなFargateの2つの選択肢があり、アプリケーションの要件や運用方針に応じた選定が可能です。
また、ECSを利用する際には、ストレージの特性やリソース設定、スケーリングの仕組みなど、コンテナ特有の設計・運用ポイントを把握することで、より安定した運用につながります。
コンテナ運用において「何を自分たちで管理し、何をAWSに任せるか」は、開発スピードやコストに直結する重要な判断です。
ECSを導入する際は、本記事で紹介したポイントを参考に、要件に合った最適な構成を検討してみてください。