AWS Fargate完全ガイド：Cloud Run・Azure Container Apps比較でわかる「サーバーレスコンテナ基盤」の選び方
はじめに
AWS Fargate は、サーバーやノードを自分で管理せずにコンテナを実行できる、AWS のサーバーレスコンテナ実行基盤です。AWS 公式では、Fargate を Amazon ECS と Amazon EKS の両方で使えるサーバーレス・従量課金のコンピュートエンジンと説明しており、サーバー管理、リソース割り当て、スケーリングの負担を AWS 側へ移せる点を強みとして挙げています。さらに、ECS/EKS で Fargate を使うと、仮想マシン群のプロビジョニング、設定、スケールやクラスターパッキングを自分で考えなくてよくなります。:contentReference[oaicite:0]{index=0}
比較相手としてよく挙がるのが、Google Cloud の Cloud Run と Azure の Azure Container Apps です。Cloud Run は、Google のスケーラブルなインフラ上でコードやコンテナをフルマネージドに実行できるサービスで、リクエストがなければインスタンスがゼロになる、いわゆる scale to zero を標準で備えています。Cloud Run の料金も、使ったリソースに対して 100 ミリ秒単位で課金される設計です。Azure Container Apps は、オーケストレーションや基盤管理を強く意識せずにコンテナアプリを実行できる Azure のサービスで、KEDA ベースのオートスケール、リビジョン管理、トラフィック分割、そして多くのアプリで scale to zero を利用できます。:contentReference[oaicite:1]{index=1}
この記事は、次のような方に向いています。まず、ECS や EKS を使いたいけれど、EC2 ノード運用はできるだけ避けたいインフラ担当の方。次に、Cloud Run や Azure Container Apps と比べて、Fargate が本当に自社向きかどうかを知りたいアーキテクトの方。さらに、マイクロサービス、バッチ、イベント駆動ジョブ、内部 API などをコンテナ化したいが、「Kubernetes を丸ごと抱えるほどではない」と感じている開発チームにも役立ちます。Fargate は、“コンテナは使いたい、でもノード運用はやりたくない” という悩みに対する、非常に現実的な落としどころだからです。:contentReference[oaicite:2]{index=2}
結論から申し上げると、AWS 上で ECS または EKS を前提にコンテナを動かし、ノード管理を消したいなら Fargate はとても自然です。一方で、HTTP リクエスト中心のアプリを素早く公開し、scale to zero やリクエスト駆動課金を強く活かしたいなら Cloud Run や Azure Container Apps のほうが直感的です。つまり、Fargate は「サーバーレスなコンテナコンピュート」、Cloud Run と Container Apps は「サーバーレスなアプリ実行基盤」と見ると、かなり整理しやすくなります。:contentReference[oaicite:3]{index=3}
1. AWS Fargateとは何か
AWS Fargate は、Amazon ECS または Amazon EKS の上でコンテナを実行するための、サーバーレスなコンピュート基盤です。AWS の公式ドキュメントでは、Fargate を使うことでサーバーや EC2 インスタンスのクラスタを管理せずにコンテナを実行できると明記されており、サーバータイプ選定、クラスタのスケーリング、クラスターパッキングの最適化を自前で行う必要がなくなると説明されています。さらに AWS のドキュメント概要ページでは、Fargate が ECS タスクや EKS Pod を専用のランタイム環境で動かし、ワークロード分離にも寄与すると案内されています。:contentReference[oaicite:4]{index=4}
ここで大切なのは、Fargate は ECS や EKS の代わりではなく、その下でコンテナを動かす“実行レイヤー” だという点です。つまり、Fargate 単体で「アプリを 1 コマンドで Web 公開する」サービスではありません。ECS サービスや EKS Pod の実行先を EC2 ではなく Fargate にすることで、ノード運用を AWS に委ねる、という役割です。この違いを理解すると、Cloud Run や Azure Container Apps と Fargate の“似ているようで違う感じ”がかなり明確になります。:contentReference[oaicite:5]{index=5}
実務上の感覚で言えば、Fargate は「ECS/EKS の体験を保ったまま、EC2 ノード管理だけ消したい」ときに強いです。ですので、すでに ECS や EKS の世界観に乗っているチームほど、Fargate のメリットを感じやすいです。逆に、コンテナレジストリから即座にアプリ公開し、HTTP リクエストに応じて自動起動・自動停止させたいだけなら、Cloud Run や Container Apps のほうが初学者にも分かりやすいことが多いです。:contentReference[oaicite:6]{index=6}
2. Fargateの本当の価値は「ノード運用を消す」ことです
Fargate の価値を一言で表すなら、「コンテナはほしい、でもノードは持ちたくない」を実現することです。AWS 公式は、Fargate によってスケーリング、パッチ適用、サーバーの管理・保護といった運用オーバーヘッドを減らせると説明しています。特に、ECS タスクや EKS Pod が専用のランタイム環境で動く点は、セキュリティやマルチテナント運用を気にするチームにとって安心材料になります。:contentReference[oaicite:7]{index=7}
これは、Kubernetes や ECS を導入するときに最も重くなりやすい責任、つまり 「ワーカーノードをどう管理するか」 をかなり軽くしてくれます。実際、EC2 ベースでコンテナ基盤を運用する場合は、インスタンスサイズ、オートスケーリング、OS パッチ、余剰キャパシティ、障害時のノード入れ替えまで考える必要があります。Fargate はそこを抽象化することで、チームが「コンテナ定義」と「スケーリングルール」へ集中しやすくしてくれます。:contentReference[oaicite:8]{index=8}
ただし、ここで誤解してはいけないのは、Fargate が “全部を隠してくれる PaaS” ではない ということです。ECS サービスや EKS のオブジェクト設計、ネットワーク、サービスディスカバリ、ロードバランサー、ログ設計などは、依然として利用者側の責任です。Fargate が消してくれるのは、あくまでノードレイヤーの面倒です。この境界がわかっているチームほど、Fargate をうまく活かしやすいです。:contentReference[oaicite:9]{index=9}
3. Cloud Runとの比較：Fargateは「基盤寄り」、Cloud Runは「アプリ寄り」
Google Cloud Run は、Google のスケーラブルなインフラ上でコンテナをフルマネージドに実行するサービスです。Cloud Run の公式概要では、インフラ管理を意識せずにコンテナを実行できること、リクエストがなくなると最後のインスタンスも削除される scale to zero を備えることが明記されています。さらに、Cloud Run ではインスタンスごとの最大同時リクエスト数を設定でき、デフォルト concurrency は 80、最大 1000 まで設定可能です。料金も、利用した CPU・メモリなどに対して 100 ミリ秒単位で課金されます。:contentReference[oaicite:10]{index=10}
この特徴から、Cloud Run は HTTP リクエストやイベントを起点に動くアプリケーション と非常に相性が良いです。具体的には、社内 API、Webhook 受信、軽量なバックエンド、プロトタイプ、AI エージェントの実行基盤などが典型です。Google も、Cloud Run が AI ワークロードや大規模アプリにも広がっていることを最近の公式ブログで強調しています。:contentReference[oaicite:11]{index=11}
一方、Fargate は Cloud Run のように「リクエストがないとゼロになる」ことを前提とした設計ではありません。Fargate は ECS サービスや EKS 上の Pod を実行するコンピュートであり、コンテナ数の調整は ECS/EKS 側のオートスケーリング設計に依存します。つまり、Cloud Run は“リクエスト駆動のアプリ実行基盤”、Fargate は“コンテナオーケストレーション基盤のサーバーレス実行層” と見ると、かなり違いが見えてきます。:contentReference[oaicite:12]{index=12}
現場向けに簡単に言い換えるなら、
- Cloud Run は「コンテナをすぐ Web アプリとして出したい」
- Fargate は「ECS/EKS でコンテナ運用したいが、ノード管理は消したい」
ときに強いです。Cloud Run は単体で完結する場面が多く、Fargate は ECS/EKS という土台の上で真価を出します。:contentReference[oaicite:13]{index=13}
4. Azure Container Appsとの比較：Fargateは実行基盤、Container Appsはアプリ基盤です
Azure Container Apps は、オーケストレーションや基盤を強く意識せずにコンテナ化アプリを実行できる Azure のマネージドサービスです。公式概要では、KEDA ベースのオートスケール、リビジョン管理、複数バージョンへのトラフィック分割、そして多くのアプリで scale to zero が可能であることが明記されています。さらに、価格ページでは、scale to zero し、イベントやリクエスト時だけ課金するモデルをサポートし、必要に応じて最小キャパシティを保持することもできると説明されています。:contentReference[oaicite:14]{index=14}
この世界観は、Cloud Run にかなり近いです。つまり、Azure Container Apps も 「HTTP やイベント起点で、アプリケーションをサーバーレスに動かす」 という体験に寄っています。さらに、KEDA 対応のさまざまなスケールトリガーを使えるため、HTTP だけでなく、キュー、メッセージング、イベントソースに応じたスケーリングも行いやすいです。:contentReference[oaicite:15]{index=15}
これに対して Fargate は、やはり ECS/EKS 上のコンピュート です。Fargate 単体には、Container Apps のような「リビジョン単位でのトラフィック分割」や「アプリ中心のリリース体験」はありません。Azure Container Apps はブルー/グリーンや A/B テストのために複数リビジョンへトラフィックを分けられることが公式に示されていますが、Fargate ではそのレイヤーは ECS/EKS＋ロードバランサーやデプロイ戦略側で設計することになります。:contentReference[oaicite:16]{index=16}
したがって、比較するときは、
- Azure Container Apps：アプリケーション実行・スケール・リビジョン運用まで一体で見たい
- AWS Fargate：ECS/EKS の実行先としてサーバーレス化したい
という違いを意識すると、かなり納得しやすいです。Azure が得意なのはアプリの“見せ方”と“動かし方”まで含んだ体験、Fargate が得意なのはコンテナオーケストレーションの“下支え”を消すことです。:contentReference[oaicite:17]{index=17}
5. 料金の考え方：Fargateは「常時動かすほど効く」、Cloud Run/Container Appsは「アイドルが多いほど有利」です
AWS Fargate の料金は非常に素直で、使った vCPU、メモリ、ストレージ に対して支払います。AWS の料金ページでは、Fargate は前払いなしで、実行されたコンテナに割り当てた vCPU、メモリ、ストレージ量に基づいて課金されると説明されています。つまり、コンテナをどれくらいのサイズで、どれくらいの時間動かしたかが、そのまま費用につながります。:contentReference[oaicite:18]{index=18}
Cloud Run は、前述のとおり 100 ミリ秒単位のリソース課金で、リクエストがなければ scale to zero できます。Azure Container Apps も、scale to zero 時はイベントやリクエストに反応している時間だけ課金され、最小キャパシティを残す場合でもアイドル時は割引レートで課金されます。さらに Azure Container Apps には、月間の無料リクエストや無料 vCPU 秒・GiB 秒があることも料金ページに示されています。:contentReference[oaicite:19]{index=19}
この違いを現場向けに言い換えると、
- アイドル時間が多い API / イベント処理 / 内部ツール なら Cloud Run や Container Apps が有利になりやすい
- 常時動くサービス、長時間ジョブ、ECS/EKS のオーケストレーションと一体で運用したいもの なら Fargate が自然
です。
Fargate は、scale to zero のアプリ基盤というより、“常時運用されるコンテナ群を、EC2 ノードなしで動かす” と考えると料金感がつかみやすいです。逆に、アクセスがまばらなワークロードでは、Cloud Run や Container Apps の従量課金モデルのほうがコスト効率が良く見えることが多いです。:contentReference[oaicite:20]{index=20}
6. Fargateが特に向いているワークロード
Fargate が特に向いているのは、まず ECS でサービス運用したいが EC2 ノードを持ちたくない ケースです。たとえば、社内 API、バックエンドサービス、バッチコンテナ、イベント処理ワーカー、内部向け管理ツールなどが典型です。ECS サービスとして複数タスクを安定運用しつつ、OS やノード管理を引き受けたくない場合、Fargate はとても収まりが良いです。:contentReference[oaicite:21]{index=21}
次に、EKS を使いたいが、ノードグループ運用を減らしたい ケースです。EKS on Fargate のドキュメントでも、Fargate はオンデマンドで適切なサイズのコンピュートを提供し、ワーカーノードの選定やスケーリングを自前で行わなくてよいと説明されています。Kubernetes を採用したい理由が「API や CRD、運用標準、周辺ツール」にある一方、ノード運用までは抱えたくないチームにはかなり魅力的です。:contentReference[oaicite:22]{index=22}
さらに、セキュリティ分離を強く意識するコンテナワークロードにも向いています。AWS の Fargate ドキュメント概要ページでは、ECS タスクや EKS Pod が専用のランタイム環境で動くことが案内されており、ワークロード分離の面でメリットがあります。複数チームや複数業務を同じコンテナ基盤で扱う場合、この点は地味ですが効いてきます。:contentReference[oaicite:23]{index=23}
7. Fargateが向かない、または慎重に考えたいケース
まず、単純な HTTP アプリをすぐ公開したいだけ の場合は、Cloud Run や Azure Container Apps のほうが体験が軽いことがあります。Fargate は ECS/EKS を前提にするので、アプリ実行の手前にオーケストレーションの設計が入ります。プロトタイプや小さな API なら、そのレイヤーが重く感じることもあります。:contentReference[oaicite:24]{index=24}
次に、ゼロスケール前提のスパiky なワークロード です。Cloud Run や Azure Container Apps は scale to zero を公式に明示しており、アクセスがない時間の課金をかなり抑えやすいです。Fargate はこのモデルとは違うため、まばらなアクセスの HTTP サービスでは、アプリ基盤型のほうがコストや運用感で優位になることがあります。:contentReference[oaicite:25]{index=25}
また、Kubernetes の細かいノード制御や DaemonSet 依存が強い設計 では、Fargate だけで解決しにくい場合があります。Fargate はノードを隠す代わりに、ノードレベルの自由度も減ります。ですので、「自由度を取るか、運用負荷を減らすか」のバランスを最初に決めておくことが大切です。:contentReference[oaicite:26]{index=26}
8. 現場で失敗しにくい導入パターン
おすすめは、いきなり全面的に Fargate へ寄せるのではなく、“ノード運用がつらいが、アプリは比較的シンプル” な 1 サービスから置き換える ことです。たとえば、社内 API、ジョブワーカー、非同期バッチなどが始めやすいです。これらは HTTP 公開や高度な配信戦略がなくても成立しやすく、Fargate の「ノードを消す」メリットを感じやすいからです。:contentReference[oaicite:27]{index=27}
サンプルとして、次のような進め方が現実的です。
サンプルA：社内 API の ECS on Fargate 化
- まず 1 つの内部 API を ECS サービスとして定義
- ロードバランサー配下で Fargate タスクとして実行
- ログとメトリクスを監視し、タスク数のオートスケーリングだけを追加
- ノードのパッチやスケール作業が消えるかを確認
サンプルB：イベント処理ワーカーの Fargate 化
- キューやイベントを処理するワーカーコンテナを Fargate へ載せる
- まずは常時 1〜2 タスクで運用
- 負荷特性が見えたらオートスケーリングを設計
このように、最初は「アプリ運用より、基盤運用を減らしたい」場面に当てると、Fargate の価値が見えやすいです。逆に、ゼロスケールやリビジョン配信が最重要なアプリなら、最初から Cloud Run や Container Apps を検討したほうが素直です。:contentReference[oaicite:28]{index=28}
まとめ
AWS Fargate は、Amazon ECS と Amazon EKS のための サーバーレス・コンピュートエンジン であり、サーバーやノードのプロビジョニング、設定、スケール、パッチ適用といった運用負荷を大きく減らせます。AWS 公式でも、Fargate は ECS/EKS と組み合わせて使う前提のサーバーレス基盤として説明され、ワークロード分離の利点も案内されています。:contentReference[oaicite:29]{index=29}
一方、Cloud Run は リクエスト駆動・scale to zero・100ms 単位課金 のアプリ基盤として強く、Azure Container Apps も KEDA ベースのスケール、リビジョン、トラフィック分割、scale to zero を持つアプリ基盤として整理しやすいです。:contentReference[oaicite:30]{index=30}
ですので、選び方をかなり実務的にまとめると、
- ECS/EKS の体験を保ちながらノード運用を消したい → AWS Fargate
- HTTP アプリやイベント駆動サービスを即座にサーバーレス化したい → Cloud Run
- アプリ中心の運用とリビジョン配信を Azure でまとめたい → Azure Container Apps
という整理がいちばんわかりやすいです。
最初の一歩としては、Fargate を選ぶ場合でも、まずは 1 つの ECS サービスか、1 つのワーカー系ワークロードだけを Fargate に載せてみる のがおすすめです。ノード管理が減ったときの嬉しさと、逆に残る責任範囲がはっきり見えるので、そこから次のサービスへ広げる判断がとてもしやすくなりますわ。