# Azure Container Apps vs AWS ECS on Fargate：サーバーレスコンテナ徹底比較（ゼロスケール・GPU・コスト・移行）

> Azure Container AppsとAWS ECS on Fargateを、本番運用の観点で徹底比較。ゼロスケール、KEDAイベント駆動、サーバーレスGPU、自動HTTPS、Jobs、デプロイ／ロールバック、コストモデル（無料枠・idleレート vs Spot・Graviton）、ネットワークとIDまでを、Microsoft Learn公式とFargate本番運用の知見から、どちらをいつ選ぶかの判断軸で解説します。

- 公開日: 2026-06-26
- 著者: 友田 陽大
- タグ: Azure, Container Apps, AWS, Fargate, コンテナ, サーバーレス, アーキテクチャ設計, コスト最適化
- URL: https://tomodahinata.com/blog/azure-container-apps-vs-aws-ecs-fargate-serverless-container-comparison-guide

## 要点

- 両者は『サーバー管理なしでコンテナを動かす』思想・CPU/メモリ固定ペア・SIGTERMグレースフルシャットダウン・IDベース認証・トラフィック分割デプロイまで驚くほど同型。基本は『今いるクラウド』で選んでよい
- Azure Container Appsが明確に有利：HTTP/イベント駆動の『ゼロスケール』、KEDAによる多彩なイベント駆動オートスケール、スケール可能なサーバーレスGPU、自動HTTPS（LB/証明書不要）、第一級のJobs、Dapr内蔵、小規模での寛大な無料枠
- AWS ECS on Fargateが有利：1タスク最大16 vCPUの大きめサイズ、Fargate Spotの大幅割引、タスク単位ENIの強い分離、ALB/IAM/ECSなどAWSエコシステムとの密結合、CodeDeployのネイティブBlue/Green
- ゼロスケールはACAの構造的な強み。ECSサービスはHTTPリクエストで0から起き上がる機構を標準で持たないため、スパイク／低トラフィック用途ではACAが原価で勝ちやすい
- GPUはACAがサーバーレスでゼロスケール可能（NC/T4・A100）、Fargateは非対応。AI推論をコンテナで安く間欠運用するならACAが選択肢になる

---

「サーバーレスでコンテナを動かすなら、AWSのFargateとAzureのContainer Apps、どっちがいいの？」——マルチクラウド構成を検討するとき、AWSからAzureへ移行するとき、あるいは新規でクラウドを選ぶとき、必ず出る問いです。

私は[AWS ECS on Fargateを本番運用](/blog/aws-ecs-fargate-production-guide)してきました。[経済産業大臣賞を受賞した木材流通B2B SaaS](/case-studies/lumber-industry-dx)（221本のAPI）も、[本番二重課金0件の決済基盤](/case-studies/payment-platform-reliability)のワーカー群も、Fargateの上で動いています。その経験から言えるのは、**Azure Container Apps（ACA）はFargateと驚くほど同型で、勘所はほぼそのまま移植できる**ということ。そのうえで、決定的に違う点もある。

この記事は、**[Microsoft Learn公式ドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/overview)に忠実なACAの仕様**と、**Fargateの本番運用知見**を突き合わせ、「どちらをいつ選ぶか」を判断軸で示します。ACA単体の本番運用は [Azure Container Apps 本番運用ガイド](/blog/azure-container-apps-production-guide)、Fargate単体は [AWS ECS on Fargate 本番運用ガイド](/blog/aws-ecs-fargate-production-guide) を参照してください。本稿は**「両者の差分」**に集中します。

---

## 結論を先に：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.`（[公式](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)）——**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.`（[公式](https://learn.microsoft.com/en-us/azure/container-apps/overview)）——HTTPまたはイベント駆動なら、アイドル時にレプリカを**0**にし、リクエストが来たら起こせます。その間は課金されません。

一方、**ECSサービスはHTTPリクエストで0から起き上がる機構を標準で持ちません**。`desiredCount`を0にはできても、リクエストが来ても自動では起きない。Fargateでスパイク／低トラフィックの用途をゼロまで落としたいなら、Lambda＋αや別の仕掛けを組む必要があります。

> **これは原価に直結します**。「平日昼だけ使う社内ツール」「月数千リクエストのAPI」「不定期のWebhook受け口」のような**間欠ワークロード**は、ACAなら使っていない時間は実質無料。Fargateだと最低1タスクを常時起動し続ける（=24時間課金）のが現実的な落としどころになります。

### イベント駆動：KEDA内蔵 vs 自前メトリクス

ACAは`uses KEDA (Kubernetes Event-driven Autoscaling)`（[公式](https://learn.microsoft.com/en-us/azure/container-apps/scale-app)）。Service Bus・Event Hubs・Kafka・Redis・Queue Storageなど、**多数のイベントソースを「キュー長」起点で素直にスケール**できます。スケールアルゴリズムも公開されていて、`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`。

Fargateは**Application Auto Scalingのターゲット追跡**が基本。SQSのバックログでスケールするには、「キュー長÷タスク数」を**カスタムメトリクスとして自分でCloudWatchに出す**のが定石です（[Fargateのオートスケール設計](/blog/aws-ecs-fargate-auto-scaling-target-tracking-sqs-worker-guide)）。動きはするが、**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](https://learn.microsoft.com/en-us/azure/container-apps/workload-profiles-overview)）。Dedicatedの`NC24/48/96-A100`も選べる。
- **Fargate**：**GPU非対応**。GPUが要るならECSのEC2起動タイプやAWS Batch、SageMakerに出る必要がある。

> **AI推論をコンテナで安く間欠運用したい**なら、ACAのサーバーレスGPUは強力な選択肢です。リクエストが無い時間はGPUごとゼロに落とせる——Fargateには無い芸当で、[量子化LLMのセルフホスト](/blog/llm-quantization-serving-economics-awq-fp8-kv-cache-vram-budget)のような用途で原価を大きく下げられます。

---

## 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://learn.microsoft.com/en-us/azure/container-apps/ingress-overview)）。**HTTPS・FQDN・証明書・HTTP/2・gRPC・WebSocketが自動**で付き、HTTPSは常にTLS 1.2/1.3。リクエストタイムアウトは240秒。

Fargateでは、`ALB（target type=ip）＋ACM証明書＋ターゲットグループ＋リスナールール`を**自分で配線**します（[Fargateのネットワーキング](/blog/aws-ecs-fargate-networking-alb-service-connect-vpc-guide)）。柔軟だが手数が多い。「とにかく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](https://learn.microsoft.com/en-us/azure/container-apps/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](/blog/aws-ecs-fargate-cicd-blue-green-codedeploy-github-actions-guide)）。

どちらも本番品質。ACAの**リビジョン＋トラフィック分割**は、トラフィックを数値で割り当てる操作が直感的で、カナリアの実装がやや軽い印象です。一方、Fargate＋CodeDeployは**bake time中の自動メトリクス監視→自動ロールバック**まで含めて作り込める。

CI/CDの鍵レス化（OIDC）は**両者共通**で、AzureはEntraのフェデレーション資格情報、AWSはIAM OIDCプロバイダ。同じ「短命トークンを信頼する」設計です（[GitHub Actions OIDCで鍵を捨てる](/blog/github-actions-oidc-keyless-cicd-aws-gcp-guide)）。

---

## コストモデル：無料枠・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](https://learn.microsoft.com/en-us/azure/container-apps/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のコスト最適化](/blog/aws-ecs-fargate-cost-optimization-spot-graviton-savings-plans-guide)）。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`。

---

## どちらを選ぶか：意思決定フロー

```text
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どちらのサーバーレスコンテナ基盤でも、本番品質の設計から移行・コスト最適化まで——速く・安く・安全に。ご相談は[お問い合わせ](/contact)、本番運用の詳細は [Azure Container Apps 本番運用ガイド](/blog/azure-container-apps-production-guide) と [AWS ECS on Fargate 本番運用ガイド](/blog/aws-ecs-fargate-production-guide) をどうぞ。