ECSとFargateの使い分け、サーバ管理はどこまでAWSに任せる？

開発・技術2026.10.20更新: 2026.10.20約4分で読めます

この記事のライター・フリーランス佐藤ケイ

“AWSでコンテナを本番運用するとき、ECSとFargateはどう使い分ける？実はFargateはECSの実行先の一つです。EC2との責任範囲の違い、コスト・運用負荷・スケーリングの考え方、構築と運用の流れを、シンプルな判断フローで整理します。”

AWSでコンテナを本番に出すとき、「ECSにするか、Fargateにするか」で手が止まることがありますよね。実はこの2つは、同じ土俵で比べるものではありません。

ECSはコンテナを動かす仕組みで、Fargateはその実行場所の選択肢の一つです。迷ったらまずFargateで始めて、EC2が必要な理由が出たときに切り替えましょう。私ならこの順番で考えます。

🧩 ECSとFargateは「どちらか」ではありません

ECSは、コンテナの数や置き場所を管理するオーケストレーション（コンテナの配置や再起動をまとめて受け持つ仕組み）のサービスです。その実行先として、自分で用意したEC2を使うか、Fargateに任せるかを選びます。

つまり本当の比較は「ECS on EC2」と「ECS on Fargate」です。違いは、どこまでを自分で管理するかという責任範囲にあります。

担当する作業	EC2に直接デプロイ	ECS on EC2	ECS on Fargate
OSのパッチ・更新	自分	自分（AMIの更新）	AWS
サーバ台数の調整	自分	自分	不要
コンテナの配置・再起動	自分	ECS	ECS
アプリとイメージ	自分	自分	自分

EC2に直接アプリを立てていた頃は、OSからアプリまで全部が自分の担当でした。Fargateでは、その下半分をAWSが引き受けてくれるイメージです。

判断はシンプルな質問から始められます。次のどれかに当てはまるなら、EC2を選ぶ理由があります。

どれにも当てはまらなければ、Fargateから始めて困る場面は少ないはずです。「サーバを自分で持つ理由があるか」を先に確かめると、迷う時間がぐっと減ります。

オンプレミスのようにサーバを手元で把握したい、というチームもあります。それも立派な理由ですが、パッチ当てや台数管理を続ける人手があるかも一緒に考えておきたいところです。

エンジビズでは、現在募集中のAWSのフリーランス案件を掲載しています。

コストは、料金表の単価だけで比べると判断を誤りやすいです。Fargateは、タスクに割り当てたvCPU・メモリの量と稼働時間で課金されます。使った分だけ払う形なので、規模が小さいうちは無駄が出にくいです。

EC2はインスタンス単位の課金です。多くのコンテナを常時動かし、隙間なく詰め込めるなら割安になる場合があります。一方で、使っていない空きリソースも料金に含まれます。

見落としやすいのは、運用にかかる人の時間です。AMIの更新や台数調整にかかる手間も、コストの一部として数えてみましょう。

スケーリングの考え方も違います。EC2では、タスク数とインスタンス数という2段階の伸び縮みを設計します。Fargateなら、タスク数だけを考えれば済みます。

共通する部分は多いです。どちらも、だいたい次の流れで組み立てます。

Fargateの場合、ネットワークモードはawsvpcを使います。タスクごとにネットワークの口が付くので、セキュリティグループもタスク単位で考えます。

EC2の場合は、ここに実行サーバの準備が加わります。ECS最適化AMIを使った起動テンプレートとAuto Scalingグループを作ります。それをキャパシティプロバイダー（クラスターに計算資源を供給する設定）としてつなぎます。

運用に入ると、差はさらに広がります。EC2では、AMIの定期更新やディスク容量の監視が続きます。Fargateではそこが不要になり、ログ・メトリクスの監視やIAMの権限設計に集中できます。

ただし、Fargateでもアプリの脆弱性対応やイメージの更新は自分の担当です。任せられるのは「サーバの面倒」までだと覚えておくと安心です。

次の一歩としては、手元の小さなアプリを一つ、Fargateのサービスとして動かしてみるのがおすすめです。タスク定義を書いてALB越しに画面が出るところまでやると、EC2との違いが肌感覚でつかめます。