「サーバーレスでコンテナを動かすなら、AWSのFargateとAzureのContainer Apps、どっちがいいの？」——マルチクラウド構成を検討するとき、AWSからAzureへ移行するとき、あるいは新規でクラウドを選ぶとき、必ず出る問いです。
私はAWS ECS on Fargateを本番運用してきました。経済産業大臣賞を受賞した木材流通B2B SaaS（221本のAPI）も、本番二重課金0件の決済基盤のワーカー群も、Fargateの上で動いています。その経験から言えるのは、Azure Container Apps（ACA）はFargateと驚くほど同型で、勘所はほぼそのまま移植できるということ。そのうえで、決定的に違う点もある。
この記事は、Microsoft Learn公式ドキュメントに忠実なACAの仕様と、Fargateの本番運用知見を突き合わせ、「どちらをいつ選ぶか」を判断軸で示します。ACA単体の本番運用は Azure Container Apps 本番運用ガイド、Fargate単体は AWS ECS on Fargate 本番運用ガイド を参照してください。本稿は**「両者の差分」**に集中します。
結論を先に：3行で
- 基本は「今いるクラウド」で選ぶ。両者の本番品質の作り方（スケール・回復性・セキュリティ）はほぼ同型で、わざわざ乗り換える理由は薄い。
- ゼロスケール・イベント駆動・サーバーレスGPU・自動HTTPS・第一級Jobsが要るなら ACA が一段わかりやすい。
- 大きめのタスクサイズ・Fargate Spotの大幅割引・AWSエコシステム密結合・タスク単位ENI分離が要るなら Fargate。
| 観点 | Azure Container Apps | AWS ECS on Fargate | どちらが有利 |
|---|---|---|---|
| ゼロスケール | HTTP/イベントで0に落とせる | サービスは0からHTTPで起きない | ACA |
| イベント駆動スケール | KEDA内蔵（多数のスケーラー） | App Auto Scaling＋カスタム | ACA |
| GPU | サーバーレスGPU（ゼロスケール可） | 非対応 | ACA |
| 自動HTTPS | Ingressで自動（LB/証明書不要） | ALB＋ACM証明書を自前で配線 | ACA |
| Jobs（バッチ/cron/イベント） | 第一級機能 | RunTask＋EventBridge / Batch | ACA |
| 最大タスクサイズ | 4 vCPU（Consumption）/ 32（Dedicated） | 最大16 vCPU（標準） | Fargate |
| スポット割引 | idleレート＋ゼロスケール | Fargate Spot（大幅割引） | Fargate |
| 分離境界 | 環境VNet | タスク単位ENI | Fargate |
| エコシステム密結合 | Azure（Entra/Key Vault/Service Bus） | AWS（IAM/ALB/SQS/ECR） | 引き分け |
同じ思想：両者は何が同じか
まず「同じ」を押さえると、移行や比較が一気に楽になります。両者はサーバーレス・コンテナという同じ思想の実装で、次がほぼ共通です。
- サーバー管理が消える：OSパッチ・ノードのスケール・容量管理をプラットフォームが担う。あなたはコンテナの定義だけ書く。
- CPU/メモリは固定ペア：両者とも自由な組み合わせではなく、決められた組み合わせから選ぶ。ACAは
メモリ=vCPU×2の固定比率、Fargateも各vCPU階層で選べるメモリ範囲が決まっている。 - 水平スケール一択：垂直スケール（1台を大きくする）ではなく、台数で捌く。ACAは
Vertical scaling isn't supported.、Fargateもタスク数で水平スケール。 - SIGTERMでグレースフルシャットダウン：両者ともスケールイン時に
SIGTERM→猶予→SIGKILL。ACAは30秒（terminationGracePeriodSecondsで延長可）、FargateはstopTimeout（既定30秒・最大120秒）。冪等なワーカー設計が前提になる点も同じ。 - IDベースの認証：パスワードを持たず、ロール／IDでAzure/AWSリソースへアクセス。ACAはマネージドID（Entra）、Fargateはタスクロール（IAM）。概念は同じ。
- シークレット注入：ACAはKey Vault参照、FargateはSecrets Manager/SSMから
valueFrom。どちらも秘密をイメージに焼かない。 - 段階的デプロイ：トラフィックを%で分けてカナリア/Blue-Green。ACAはリビジョン＋トラフィック分割、FargateはCodeDeployのBlue/Greenやローリング＋サーキットブレーカー。
つまり、Fargateで身につけた「本番でどう作るか」の規律——right-sizing、冪等性、グレースフルシャットダウン、最小権限、鍵レスCI/CD——はそのままACAで通用します。学び直しではなく、語彙の置き換えです。
アーキテクチャの違い：オーケストレーターの隠し方
最大の構造的違いは、Kubernetesとの距離です。
- Fargate：あくまでECS（またはEKS）の"容量"。あなたはECSのタスク定義・サービス・クラスタという語彙で操作し、その実行基盤としてFargateを選ぶ。ECSのAPIは普通に見える。
- ACA：Kubernetes・KEDA・Dapr・Envoyの上に建てられたマネージド層だが、
Azure Container Apps doesn't provide direct access to the underlying Kubernetes APIs.（公式）——Kubernetes APIは一切見えない。kubectlもCRDも無い。
この違いは「降りられる先」に出ます。Fargateで足りなくなったらECS→EKS（生のKubernetes）へ、ACAで足りなくなったらAKSへ。どちらも「マネージドを卒業してKubernetesの制御面を握る」道が用意されています。ACAはその境界で、OSS（KEDA/Dapr/Envoy）を採用しているぶん、設定や概念がKubernetesに地続きという安心感があります。
| 階層 | AWS | Azure |
|---|---|---|
| サーバーレス・コンテナ | ECS on Fargate | Azure Container Apps |
| マネージドKubernetes | EKS / EKS Auto Mode | AKS / AKS Automatic |
| 低レベルな単発コンテナ | ECS RunTask | Azure Container Instances |
| FaaS（関数） | Lambda | Azure Functions |
スケール：ゼロスケールとイベント駆動
ここがACAの構造的な勝ち筋です。
ゼロスケール：ACAの明確な優位
ACAはMost applications can scale to zero.（公式）——HTTPまたはイベント駆動なら、アイドル時にレプリカを0にし、リクエストが来たら起こせます。その間は課金されません。
一方、ECSサービスはHTTPリクエストで0から起き上がる機構を標準で持ちません。desiredCountを0にはできても、リクエストが来ても自動では起きない。Fargateでスパイク／低トラフィックの用途をゼロまで落としたいなら、Lambda＋αや別の仕掛けを組む必要があります。
これは原価に直結します。「平日昼だけ使う社内ツール」「月数千リクエストのAPI」「不定期のWebhook受け口」のような間欠ワークロードは、ACAなら使っていない時間は実質無料。Fargateだと最低1タスクを常時起動し続ける（=24時間課金）のが現実的な落としどころになります。
イベント駆動：KEDA内蔵 vs 自前メトリクス
ACAはuses KEDA (Kubernetes Event-driven Autoscaling)（公式）。Service Bus・Event Hubs・Kafka・Redis・Queue Storageなど、多数のイベントソースを「キュー長」起点で素直にスケールできます。スケールアルゴリズムも公開されていて、desiredReplicas = ceil(currentMetricValue / targetMetricValue)。
FargateはApplication Auto Scalingのターゲット追跡が基本。SQSのバックログでスケールするには、「キュー長÷タスク数」をカスタムメトリクスとして自分でCloudWatchに出すのが定石です（Fargateのオートスケール設計）。動きはするが、**ACAのほうがイベント駆動が"標準装備"**でわかりやすい。
| スケール | ACA | Fargate |
|---|---|---|
| HTTP同時実行 | スケールルール（concurrentRequests） | ALBリクエスト数のターゲット追跡 |
| キュー長 | KEDAスケーラーで直接 | カスタムメトリクス（バックログ/タスク）を自前で |
| CPU/メモリ | カスタムルール（ゼロ不可） | ターゲット追跡 |
| ゼロスケール | 可（HTTP/イベント） | サービスは標準で不可 |
| 上限 | 1,000レプリカ | アカウント上限の範囲 |
リソースとGPU：大きさは Fargate、GPUは ACA
タスクサイズ
- ACA（Consumption）：
0.25–4 vCPU/ メモリはvCPU×2（最大8 GiB）。より大きく／専用ハードが要るならDedicatedでD32（32 vCPU/128 GiB）・E32（32 vCPU/256 GiB）まで。 - Fargate：1タスク
0.25–16 vCPU/ メモリ最大120 GB。単一タスクで大きく取れるのはFargateの強み。
「1リクエストで重い処理を1コンテナに載せたい」ならFargateの16 vCPUが効きます。「小さく刻んで台数で捌く」なら差は出ません。
GPU：ACAのサーバーレスGPU vs Fargateの非対応
ここは明確です。
- ACA：サーバーレスGPUを提供。
Consumption-GPU-NC24-A100, Consumption-GPU-NC8as-T4（NVIDIA T4 / A100）がper replicaで、しかもゼロスケール可能（Workload profiles）。DedicatedのNC24/48/96-A100も選べる。 - Fargate：GPU非対応。GPUが要るならECSのEC2起動タイプやAWS Batch、SageMakerに出る必要がある。
AI推論をコンテナで安く間欠運用したいなら、ACAのサーバーレスGPUは強力な選択肢です。リクエストが無い時間はGPUごとゼロに落とせる——Fargateには無い芸当で、量子化LLMのセルフホストのような用途で原価を大きく下げられます。
Ingress / HTTPS：ACAは"自分で組まない"
ACAはWhen you enable ingress, you don't need to create an Azure Load Balancer, public IP address, or any other Azure resources（公式）。HTTPS・FQDN・証明書・HTTP/2・gRPC・WebSocketが自動で付き、HTTPSは常にTLS 1.2/1.3。リクエストタイムアウトは240秒。
Fargateでは、ALB（target type=ip）＋ACM証明書＋ターゲットグループ＋リスナールールを自分で配線します（Fargateのネットワーキング）。柔軟だが手数が多い。「とにかくHTTPSのAPIを最短で公開したい」ならACAが圧倒的に速い。
| Ingress | ACA | Fargate |
|---|---|---|
| HTTPS/証明書 | 自動（マネージド） | ALB＋ACMを自前 |
| LB構築 | 不要 | ALB/NLBを作る |
| HTTP/2・gRPC・WebSocket | 標準 | ALBの設定次第 |
| 内部公開 | Internal Ingressで簡単 | 内部ALB＋SGで構成 |
| タイムアウト | 240秒固定 | ALBで可変（既定60秒等） |
Jobs：ACAは第一級、AWSは組み立て
「走って終わる処理」は、ACAでは第一級のJobsとしてManual / Schedule（cron, UTC）/ Event（KEDA）で扱えます（Jobs）。リトライ・並列度・完了数・タイムアウトを宣言的に設定でき、イベント駆動ジョブはセルフホストのGitHub Actions Runnerにもなる。
AWSでは、同じことをECS RunTask＋EventBridge SchedulerやAWS Batchで組み立てます。できることは同等ですが、ACAは「アプリとジョブを同じ環境・同じ語彙」で扱えるぶん、認知負荷が低い。
| バッチ/ジョブ | ACA | AWS |
|---|---|---|
| 定期実行 | Schedule Job（cron） | EventBridge Scheduler＋RunTask |
| イベント駆動 | Event Job（KEDA） | EventBridge/SQS＋Lambda/RunTask |
| 大規模並列バッチ | parallelism設定 | AWS Batch |
| CI Runner | Event Jobで標準サポート | 自前構成 |
デプロイとロールバック：思想は同じ、語彙が違う
両者とも「失敗したら切り替えない」安全側のデプロイを提供します。
- ACA：リビジョン（不変スナップショット）。単一モードは新リビジョンが全プローブ通過＋旧台数までスケールしてから自動全切替（ゼロダウンタイム）。複数モードはトラフィックを%分割してカナリア/Blue-Green/A-B、ラベルで特定リビジョンへ安定URL。
- Fargate：ローリング更新＋デプロイサーキットブレーカーで自動ロールバック、またはCodeDeployのネイティブBlue/Green（bake time付き）（FargateのCI/CD）。
どちらも本番品質。ACAのリビジョン＋トラフィック分割は、トラフィックを数値で割り当てる操作が直感的で、カナリアの実装がやや軽い印象です。一方、Fargate＋CodeDeployはbake time中の自動メトリクス監視→自動ロールバックまで含めて作り込める。
CI/CDの鍵レス化（OIDC）は両者共通で、AzureはEntraのフェデレーション資格情報、AWSはIAM OIDCプロバイダ。同じ「短命トークンを信頼する」設計です（GitHub Actions OIDCで鍵を捨てる）。
コストモデル：無料枠・idle vs Spot・Graviton
課金の骨格は同じ（割り当てvCPU秒＋メモリ秒）ですが、最適化レバーが違います。
ACAの武器：無料枠 ＋ idleレート ＋ ゼロスケール
毎月サブスクリプションごとに、The first 180,000 vCPU-seconds・The first 360,000 GiB-seconds・The first 2 million HTTP requestsが無料（Billing）。さらに：
- ゼロスケール時は課金なし（
When a revision is scaled to zero replicas, no resource consumption charges are incurred.） - 最小レプリカで待機中のidleレート割引
- 環境内のサービス間通信・ヘルスプローブはリクエスト課金の対象外
→ 小規模・間欠ワークロードはACAが圧倒的に安い。無料枠だけで小さなサービスが回る。
Fargateの武器：Spot ＋ Graviton ＋ Savings Plans
- Fargate Spot：中断耐性ワークロード（バッチ・ステートレスワーカー）を大幅割引で。2分前に
SIGTERM警告。 - Graviton（ARM64）：x86より割安・電力効率が良い。
- Compute Savings Plans：常時稼働の予約割引。
→ 常時高負荷・大規模バッチはFargate Spot＋Gravitonが強い（Fargateのコスト最適化）。ACAにはFargate Spotの直接の等価物が無く、代わりに「ゼロスケール＋idle」で攻める設計になります。
| コスト最適化 | ACA | Fargate |
|---|---|---|
| 間欠/低トラフィック | ゼロスケール＋無料枠 | 最低1台常駐が現実的 |
| 常駐・最小台数 | idleレート割引 | Savings Plans |
| 中断耐性バッチ | ゼロスケール | Fargate Spot（大幅割引） |
| CPUアーキ | x86中心 | Graviton(ARM)で割安 |
ネットワークとセキュリティ：分離の粒度が違う
- 分離：Fargateは
各タスクが独立したENI（awsvpc）を持ち、タスク単位でカーネル/CPU/メモリ/ENIを共有しない強い分離。ACAは環境のVNetにアプリが相乗りする（環境＝セキュリティ境界）。厳格なタスク単位ネットワーク分離ならFargateが細かい。 - VNet/サブネット：ACAはワークロードプロファイル環境で
/27、UDR・NAT Gateway・Private Endpoint対応。FargateはVPC/サブネット/SGをフルに制御。どちらもegressロックダウン（Firewall経由）可能。 - ID：ACAはマネージドID（Entra）＋
identitySettingsのlifecycleで最小権限。Fargateは実行ロールとタスクロールの分離でpull権限とアプリ権限を分ける。思想は同じ「最小権限」。 - シークレット：ACAはKey Vault参照（30分以内の自動ローテーション＋参照リビジョン自動再起動）、FargateはSecrets Manager/SSMの
valueFrom。
どちらを選ぶか：意思決定フロー
Q1. すでにAWS / Azure に寄っている？
→ YES：素直にそのクラウドの基盤（Fargate / ACA）を選ぶ。差分は本記事で埋まる。
Q2. ワークロードが「間欠・低トラフィック・スパイク」？
→ YES：ACA（ゼロスケール＋無料枠で原価が劇的に下がる）
Q3. キュー/イベント駆動が中心？
→ YES：ACA（KEDAが標準装備で素直）
Q4. GPU推論をコンテナで安く間欠運用したい？
→ YES：ACA（サーバーレスGPU・ゼロスケール）。Fargateは非対応。
Q5. 1タスクで大きいサイズ（〜16 vCPU）or 中断耐性バッチを大幅割引で？
→ YES：Fargate（大きいタスク＋Fargate Spot）
Q6. タスク単位の厳格なネットワーク分離が要件？
→ YES：Fargate（タスク単位ENI）
それ以外：迷ったら「今いるクラウド」。両者の本番運用は同型。
結論
**「どっちが優れているか」ではなく「どっちが自分の制約に合うか」**です。すでにクラウドが決まっているなら、その基盤を選び、本記事の差分表で勘所を埋めれば十分。新規でクラウド自由なら——間欠ワークロード・イベント駆動・サーバーレスGPU・最短HTTPS公開を重視するならACA、大きめタスク・Spotの深い割引・AWSエコシステム密結合を重視するならFargate。
私はFargateを本番運用してきましたが、ACAのゼロスケール／サーバーレスGPU／第一級Jobs／自動HTTPSは、特定の用途で明確に体験が良いと感じます。逆に、大規模バッチをFargate Spotで叩くコスト効率や、タスク単位ENIの分離はFargateならでは。両方を知っていれば、案件ごとに最適なほうを選べる——それが一人×生成AIでマルチクラウドを扱う価値です。
AWS/Azureどちらのサーバーレスコンテナ基盤でも、本番品質の設計から移行・コスト最適化まで——速く・安く・安全に。ご相談はお問い合わせ、本番運用の詳細は Azure Container Apps 本番運用ガイド と AWS ECS on Fargate 本番運用ガイド をどうぞ。