ECS/FargateとCloud Run実務で選ぶ判断基準

大手自社開発でDAU30万規模のサービスをECS/Fargateで運用し、フリーランス転向後の副業案件ではCloud Runを使っている。この2つを実務で使い分けてきて感じるのは「どれが優れているかではなく、何のサービスに使うかで選ぶべき」ということだ。

「コンテナに移行したい」「ECSとCloud RunとLambdaどれを選べばいい？」という質問をよく受けるが、答えは規模感・コスト・チームのスキルセットによって変わる。この記事では、実務で3つの環境（EC2、ECS/Fargate、Cloud Run）を使い分けてきた経験をもとに、判断基準を整理する。コンテナが初めてのエンジニアには「なぜ難しいのか」という学習の壁も含めて解説する。

---

まず前提：「コンテナ」とは何かを押さえる

EC2・ECS/Fargate・Cloud Runを比較する前に、「コンテナ」とは何かを整理する。ここを理解していないと、ECS/Fargateを使い始めたときに「なぜこんなに設定が多いのか」という壁にぶつかる。

コンテナとは「アプリとその実行環境をセットにしたもの」

従来の開発では、アプリケーションを動かすためにサーバーに直接ミドルウェアをインストールしていた。Node.jsのバージョン・Nginxの設定・依存ライブラリ……開発環境と本番環境の差異が原因で「ローカルでは動くのに本番で動かない」という問題が頻繁に発生していた。

Dockerに代表されるコンテナ技術は、アプリケーションの実行に必要な環境ごとパッケージングすることで、この問題を解消した。

コンテナ化のメリット3つ

1. ミドルウェアのメンテナンスが不要になる

EC2では、OSのセキュリティパッチ・Nginxのアップデート・Node.jsのバージョン管理などをすべて手動で行う必要がある。コンテナ化すると、これらの管理がDockerfileに集約され、ランタイムのアップデートは新しいイメージをビルドするだけで完結する。

大手自社開発でECS/Fargateに移行したとき、「EC2と比べてミドルウェアのupdateが不要なので楽」と実感したのはまさにこの点だ。

2. 環境の再現性が高い

「自分のMacでは動くがEC2では動かない」という問題がなくなる。開発・ステージング・本番で同じDockerイメージを使うため、環境差異によるバグが大幅に減る。

3. スケールアウトが容易

トラフィックが増えたとき、コンテナは新しいインスタンスを起動するだけでスケールできる。ECS/Fargateであれば、Auto Scalingの設定によってCPU・メモリ使用率に応じて自動でスケールする。

---

EC2の特徴と向いているケース

EC2とは

EC2（Elastic Compute Cloud）はAWSが提供する仮想サーバーサービスだ。Linuxマシンを1台借りてSSHで接続し、自由に設定できるのがEC2の基本的な使い方だ。

RDSと組み合わせた「EC2 + RDS」構成は、Webアプリケーションのもっとも基本的なAWSアーキテクチャとして今でも広く使われている。フリーランス転向後に担当している本業サービスもEC2/RDS構成だ。

EC2の強みと弱み

観点	評価	詳細
セットアップの速さ	◎	SSHで接続してすぐ構築できる
自由度	◎	OSレベルから完全にカスタマイズ可能
学習コスト	○	Linuxコマンドがわかれば始めやすい
ミドルウェアメンテ	△	OS・Nginx等のアップデートを手動管理
スケールアウト	△	AMIからの起動で時間がかかる
コスト	△	インスタンスを起動している間は常に課金

EC2が向いているケース

• プロトタイプや社内ツール：コンテナ化の工数をかけずに素早く立ち上げたい場合
• レガシーシステムの維持：既存のEC2構成をそのまま引き継いで運用している場合
• 小規模・トラフィックが安定している：スケールアウトの必要がなく、安定稼働が前提の場合
• チームにDockerの知識がない：コンテナ技術の学習コストをかけたくない場合

---

ECS/Fargateの特徴と向いているケース

ECS/Fargateとは

ECS（Elastic Container Service）はAWSが提供するコンテナオーケストレーションサービスだ。Dockerコンテナを管理・実行するためのプラットフォームで、Fargateを使うとサーバー（EC2インスタンス）の管理が不要になる。

「EC2起動タイプのECS」と「FargateのECS」の2種類があるが、現在はECS on Fargateがデファクトスタンダードになっている。Fargateではコンテナが動くサーバーの調達・管理をAWSに任せられる。

ECS/Fargateの構成要素

ECS/Fargateを初めて触ると「設定項目が多すぎる」と感じる。コンテナのライフサイクル管理に必要な概念がいくつも存在するためだ。

ECS/Fargateの強みと弱み

観点	評価	詳細
ミドルウェアメンテ	◎	コンテナ管理のみ、OSレベル不要
スケールアウト	◎	Auto Scalingで自動対応
大規模運用	◎	マイクロサービス構成にも対応
セットアップの複雑さ	△	タスク定義・IAM・ALB連携など設定項目多数
コンテナ知識の必要性	△	Dockerの仕組みの理解が前提
コスト（小規模）	△	Fargateは常時稼働でコストがかかりやすい

ECS/Fargateが向いているケース

• 中〜大規模・高トラフィックサービス：DAU数万〜数十万規模でスケールアウトが必要な場合
• マイクロサービス構成：複数サービスをコンテナで分離管理したい場合
• ミドルウェア管理の工数を削減したい：チームのインフラ運用負荷を下げたい場合
• CI/CDパイプラインと連携したい：GitHub Actionsなどと組み合わせた自動デプロイを構築したい場合

---

ECS/Fargateで詰まりやすいポイント（実体験）

大手自社開発でECS/Fargateを運用していて「EC2より構築が難しい」と感じた主な理由は、コンテナの仕組みそのものの理解が必要だからだ。EC2はLinuxの知識があれば何とかなるが、ECS/FargateはDockerの概念理解が前提になる。

詰まりポイント1：コンテナの仕組みの理解

まずDockerの基本概念（イメージ・コンテナ・Dockerfile・レイヤー構造）を理解していないと、タスク定義の設定が何を意味するかわからない状態になる。

「コンテナが起動しない」というトラブルの多くは、Dockerfileの記述ミス・ポートのマッピング設定ミス・環境変数の未設定などが原因だ。これらを素早く診断するにはDockerの仕組みを理解していることが前提になる。

詰まりポイント2：IAMロールの設定

ECS/FargateはIAMロールの設定が複雑だ。「タスク実行ロール」と「タスクロール」の2種類があり、それぞれ役割が異なる。

• タスク実行ロール：ECRからコンテナイメージを取得したり、CloudWatchにログを送信するためのロール
• タスクロール：コンテナ内のアプリケーションがS3やRDSなどのAWSリソースにアクセスするためのロール

この2つの違いを理解していないと「コンテナが起動しない」「ログが出ない」というトラブルで詰まることになる。

詰まりポイント3：ネットワーク設定（ALBとの連携）

本番環境でECS/FargateをALB（Application Load Balancer）と連携させるとき、ターゲットグループの設定・セキュリティグループのポート許可・ヘルスチェックのパス設定など、確認すべき箇所が多い。

ECS/Fargateの学習方法

自分はUdemyのハンズオンコースと実務の組み合わせで習得した。Udemyのコースは手を動かしながらECS/Fargateの構成を一通り体験できるため、ドキュメントを読むだけよりもはるかに理解が早い。

ECSを学ぶうえでUdemyが有効な理由は、ECR・ALB・CloudWatch・IAMがどう連携するかを一つのハンズオンで確認できることだ。AWSの資格取得も視野に入れているなら、AWSコースのラインナップが充実しているUdemyで学ぶのが効率的だ。

---

Cloud Runの特徴と向いているケース

Cloud RunとはGCPのサーバーレスコンテナ

Cloud RunはGoogle Cloud（GCP）が提供するサーバーレスコンテナサービスだ。Dockerコンテナをデプロイするだけで自動的にHTTPリクエストを受け付けられる状態になり、リクエストがないときはインスタンス数がゼロまで縮退する（スケールトゥゼロ）。

現在の副業案件では Cloud Run + Cloud SQL 構成を使っている。ユーザー数が多くないサービスでコスト最適化を優先したため、クライアントからの提案でGCPを採用した。

Cloud Runの強みと弱み

観点	評価	詳細
コスト（小規模）	◎	リクエストがない間は課金ゼロ（スケールトゥゼロ）
デプロイの手軽さ	◎	gcloud run deploy 一発でデプロイ可能
設定項目の少なさ	◎	ECS/Fargateより設定がシンプル
スケールアウト	○	自動スケール対応
メモリ上限	△	デフォルトが小さく、超えるとコンテナが落ちる
大規模サービス	△	コールドスタートの遅延・メモリ制限が課題になる
日本語情報量	△	AWSと比べてネット上の情報が少ない

Cloud Runの注意点：メモリ上限でコンテナが落ちる

Cloud Runを使っていて実際にハマったのがメモリ上限によるコンテナの強制終了だ。

新規機能を追加してデプロイしたとき、処理の重さによってメモリ使用量が増え、設定した上限を超えてコンテナが落ちることが複数回あった。Cloud Runはデフォルトのメモリが小さめに設定されているため、アプリケーションの規模が大きくなるにつれてメモリ設定の見直しが必要になる。

上限は設定で変更できるが、メモリを増やすとコストも上がるため、スケールトゥゼロの恩恵が薄れてくる。「ある程度の規模になるとECS/FargateやEC2の方が向いている」という感覚は、この経験からきている。

Cloud Runが向いているケース

• 小規模サービスやAPIサーバー：リクエスト数が少なくコストを抑えたい場合
• 社内ツール・プロトタイプ：デプロイ手順をシンプルに保ちたい場合
• クライアントがGCPを使っている：既存インフラに合わせる場合
• 開発スピード優先：設定項目を最小化して素早くリリースしたい場合

---

ECS/Fargate vs Cloud Run：使い分けの比較

ECS FargateとCloud Runを両方試したとき、最初はCloud Runの方が設定がシンプルで「なんでみんなECSを使うんだ」と思っていた。実際に本番規模で動かしてみて、VPCとの統合やIAMの細かい制御が必要になったとき、ECSの柔軟性に助けられた。単純に比較できないという当たり前の結論に至るまで、かなり遠回りした。

機能比較表

観点	ECS/Fargate	Cloud Run
クラウド	AWS	GCP
向いている規模	中〜大規模	小〜中規模
スケールトゥゼロ	✕（常時課金）	✓（無料枠内に収まることも）
コールドスタート	なし	あり（初回リクエストが遅い）
メモリ上限の扱い	柔軟に設定可能	デフォルト小さめ・要注意
設定の複雑さ	高い	低い
日本語情報量	多い	少ない
AWSサービスとの連携	◎	△

選定フロー

---

Lambdaも加えた4択の整理

AWSにはEC2・ECS/Fargateに加えてLambdaという選択肢もある。Cloud Runと同様にサーバーレスで、リクエストがないときは課金されない。

「小規模で最速なら、Cloud RunかAWSならLambda」というのが自分の判断基準だ。イベント駆動か常時起動かで使い分けるイメージになる。

4択の使い分けまとめ

サービス	向いているケース	構築難度
EC2	速攻で立ち上げたい・レガシー維持・複雑なOS設定が必要	★★☆
ECS/Fargate	中〜大規模・マイクロサービス・ミドルウェア管理を減らしたい	★★★
Cloud Run（GCP）	小規模・コスト最小・GCPを使う必要がある	★★☆
Lambda	イベント駆動・定期処理・APIの一部機能を切り出したい	★★☆

---

AWSとGCPどちらを学ぶべきか

両方を実務で使ってきた立場から言うと、AWSを先に学ぶのが正解だ。

AWSが優位な理由

マネージドサービスの充実度：RDS・ElastiCache・SQS・SNS・Cognitoなど、AWSはサービスの種類と成熟度でGCPを上回る。

学習リソースの豊富さ：日本語の技術ブログ・UdemyのAWSコース・AWS認定試験と、学習コンテンツがGCPより圧倒的に多い。「詰まったときに検索すれば答えが見つかる」という安心感が実務では非常に大きい。

ドキュメントの品質：AWSのドキュメントは詳細かつ更新頻度が高い。GCPのドキュメントもよくなってきているが、エッジケースの情報量ではAWSが上だと感じる。

求人・案件数：AWSエンジニアの求人数はGCP・Azureと比べて圧倒的に多い。フリーランスとして案件を取りに行く際も、AWSスキルは強みになる。

GCPを学ぶ意味

GCPはBigQueryやVertex AIなどデータ・AI分野に強みを持つ。データエンジニアやMLOpsに興味があるならGCPを学ぶ価値は高い。Cloud Runはデプロイの手軽さから小規模プロダクトでは有力な選択肢になっている。

ただしバックエンドエンジニアとしてのキャリアを作るなら、まずAWSを習得してからGCPを補完的に学ぶのが効率的だ。

AWSを体系的に学ぶには

AWSの全体像をつかむにはUdemyのハンズオンコースが最も効率的だ。ECS/Fargateのような複数サービスが絡む構成は、ドキュメントを読むだけでは全体像がつかみにくい。

クラウドエンジニア学習ロードマップ2026でも学習の順序について詳しく解説しているので合わせて参考にしてほしい。

---

まとめ：実務での選び方

EC2・ECS/Fargate・Cloud Run・Lambdaをどれ選ぶかは「どのサービスが優れているか」ではなく「何のために使うか」で決まる。

選び方の原則

• スピード重視・シンプル構成 → EC2
• 中〜大規模・ミドルウェア管理を減らしたい → ECS/Fargate
• 小規模・コスト最小・GCP環境 → Cloud Run
• イベント駆動・定期処理 → Lambda

ECS/FargateとCloud Runのどちらが優れているかという話ではない。規模感・コスト・チームのDockerスキルを考慮した上で、そのサービスに最適な選択をするだけだ。

コンテナ技術を使いこなすには、まずDockerの仕組みの理解が前提になる。「コンテナが難しい」と感じるエンジニアのほとんどは、コンテナの概念そのものの理解が不足しているケースが多い。

AWSの体系的な学習についてはAWS認定ソリューションアーキテクト合格ガイドも参考にしてほしい。インフラをコードで管理したい場合はTerraform×AWS インフラ構築ガイドも合わせて読んでほしい。