Azure Container Apps vs AWS ECS on Fargate: a thorough serverless-container comparison (scale-to-zero, GPU, cost, migration)

"To run containers serverless, which is better — AWS Fargate or Azure Container Apps?" — when considering a multi-cloud setup, when migrating from AWS to Azure, or when choosing a cloud for a new project, this question always comes up.

I've run AWS ECS on Fargate in production. The lumber-distribution B2B SaaS that won the METI Minister's Award (221 APIs) and the worker fleet of the payment platform with 0 double charges in production both run on Fargate. From that experience, I can say: Azure Container Apps (ACA) is astonishingly the same shape as Fargate, and the key points port over almost as-is. On top of that, there are decisive differences too.

This article cross-checks the ACA spec faithful to the Microsoft Learn official documentation with Fargate production-operation knowledge and shows "which to choose when" by a judgment axis. For ACA alone in production, see the Azure Container Apps production-operations guide, and for Fargate alone, the AWS ECS on Fargate production-operations guide. This piece concentrates on "the differences between the two."

The conclusion first, in 3 lines

• By default, choose by "the cloud you're on." The two build production quality (scale, resilience, security) in almost the same shape, and there's little reason to switch over deliberately.
• If you need scale-to-zero, event-driven, serverless GPU, automatic HTTPS, or first-class Jobs, ACA is one notch clearer.
• If you need larger task sizes, the steep Fargate Spot discount, tight AWS ecosystem coupling, or per-task ENI isolation, Fargate.

The same philosophy: what the two share

First grasping "the same" makes migration and comparison far easier. The two are implementations of the same serverless container philosophy, and the following are almost common.

• Server management disappears: OS patching, node scaling, and capacity management are handled by the platform. You write only the container definition.
• CPU/memory are fixed pairs: both choose from prescribed combinations, not free combinations. ACA has a fixed ratio of memory = vCPU × 2, and Fargate also has a fixed memory range selectable per vCPU tier.
• Horizontal scale only: handle with count, not vertical scale (making one machine bigger). ACA states Vertical scaling isn't supported., and Fargate also scales horizontally by task count.
• Graceful shutdown on SIGTERM: both, on scale-in, do SIGTERM → grace → SIGKILL. ACA is 30 seconds (extendable with terminationGracePeriodSeconds), and Fargate is stopTimeout (default 30 seconds, max 120 seconds). The premise of idempotent worker design is the same too.
• Identity-based authentication: hold no password, access Azure/AWS resources by role/identity. ACA is managed identity (Entra), Fargate is a task role (IAM). The concept is the same.
• Secret injection: ACA is Key Vault references, Fargate is valueFrom from Secrets Manager/SSM. Neither bakes secrets into the image.
• Staged deployment: split traffic by % for canary/Blue-Green. ACA is revisions + traffic splitting, Fargate is CodeDeploy's Blue/Green or rolling + circuit breaker.

In other words, the discipline of "how to build for production" you gained with Fargate — right-sizing, idempotency, graceful shutdown, least privilege, keyless CI/CD — works as-is on ACA. It's not relearning but a substitution of vocabulary.

The architectural difference: how the orchestrator is hidden

The biggest structural difference is the distance from Kubernetes.

• Fargate: ultimately the "capacity" of ECS (or EKS). You operate with the vocabulary of ECS task definitions, services, and clusters, and choose Fargate as their execution foundation. ECS's API is plainly visible.
• ACA: a managed layer built on Kubernetes, KEDA, Dapr, and Envoy, but Azure Container Apps doesn't provide direct access to the underlying Kubernetes APIs. (official) — the Kubernetes API is not visible at all. No kubectl, no CRDs.

This difference shows in "where you can step down to." When Fargate isn't enough, go to ECS → EKS (raw Kubernetes); when ACA isn't enough, go to AKS. Both prepare a path to "graduate from managed and grasp the Kubernetes control plane." At that boundary, ACA adopts OSS (KEDA/Dapr/Envoy), so there's the reassurance that its settings and concepts are contiguous with Kubernetes.

Scale: scale-to-zero and event-driven

This is ACA's structural winning path.

Scale-to-zero: ACA's clear advantage

ACA states Most applications can scale to zero. (official) — if HTTP or event-driven, it makes replicas 0 when idle and wakes them when a request arrives. No billing during that time.

On the other hand, an ECS service has no standard mechanism to wake from 0 on an HTTP request. You can set desiredCount to 0, but it won't wake automatically even when a request arrives. To drop a spiky/low-traffic use to zero on Fargate, you need to build a Lambda + α or another contraption.

This directly affects cost. For intermittent workloads like "an internal tool used only on weekday afternoons," "an API with a few thousand requests a month," or "an irregular webhook receiver," with ACA the unused time is effectively free. With Fargate, keeping at least 1 task always running (= billed 24 hours) is the realistic compromise.

Event-driven: KEDA built-in vs. your own metrics

ACA uses KEDA (Kubernetes Event-driven Autoscaling) (official). It can straightforwardly scale many event sources from "queue length" — Service Bus, Event Hubs, Kafka, Redis, Queue Storage, etc. The scaling algorithm is also published: desiredReplicas = ceil(currentMetricValue / targetMetricValue).

Fargate is basically Application Auto Scaling's target tracking. To scale on an SQS backlog, the standard is to emit "queue length ÷ task count" as a custom metric to CloudWatch yourself (Fargate autoscaling design). It works, but ACA's event-driven is more "standard-equipped" and clearer.

Resources and GPU: size is Fargate, GPU is ACA

Task size

• ACA (Consumption): 0.25–4 vCPU / memory is vCPU × 2 (max 8 GiB). For larger / dedicated hardware, Dedicated up to D32 (32 vCPU/128 GiB), E32 (32 vCPU/256 GiB).
• Fargate: 0.25–16 vCPU per task / memory up to 120 GB. Being able to take a lot in a single task is Fargate's strength.

For "I want to put heavy processing for one request in one container," Fargate's 16 vCPU matters. For "slice it small and handle with count," no difference appears.

GPU: ACA's serverless GPU vs. Fargate's lack of support

This is clear.

• ACA: provides serverless GPU. Consumption-GPU-NC24-A100, Consumption-GPU-NC8as-T4 (NVIDIA T4 / A100) are per replica and moreover scale-to-zero possible (Workload profiles). You can also choose Dedicated's NC24/48/96-A100.
• Fargate: no GPU support. If you need a GPU, you have to go to ECS's EC2 launch type, AWS Batch, or SageMaker.

If you want to run AI inference cheaply and intermittently in containers, ACA's serverless GPU is a powerful option. You can drop the whole GPU to zero during request-free time — a feat Fargate doesn't have, greatly lowering cost for uses like self-hosting a quantized LLM.

Ingress / HTTPS: ACA "doesn't assemble it yourself"

ACA states When you enable ingress, you don't need to create an Azure Load Balancer, public IP address, or any other Azure resources (official). HTTPS, FQDN, certificate, HTTP/2, gRPC, and WebSocket are automatic, and HTTPS is always TLS 1.2/1.3. The request timeout is 240 seconds.

With Fargate, you wire ALB (target type=ip) + ACM cert + target group + listener rules yourself (Fargate networking). Flexible but many steps. For "just publish an HTTPS API in the shortest time," ACA is overwhelmingly faster.

Jobs: ACA is first-class, AWS is assembly

"Processing that runs and finishes" can be handled in ACA as first-class Jobs with Manual / Schedule (cron, UTC) / Event (KEDA) (Jobs). You can declaratively set retries, parallelism, completion count, and timeout, and an event-driven job can even be a self-hosted GitHub Actions Runner.

In AWS, you assemble the same thing with ECS RunTask + EventBridge Scheduler or AWS Batch. What you can do is equivalent, but ACA can handle "apps and jobs in the same environment, the same vocabulary," so the cognitive load is lower.

Deployment and rollback: the same philosophy, different vocabulary

Both provide a safe-side deployment of "don't switch over if it fails."

• ACA: revisions (immutable snapshots). Single mode auto-switches fully after the new revision passes all probes + scales to the old count (zero downtime). Multiple mode splits traffic by % for canary/Blue-Green/A-B, and a label gives a stable URL to a specific revision.
• Fargate: rolling update + a deployment circuit breaker for auto-rollback, or CodeDeploy's native Blue/Green (with bake time) (Fargate CI/CD).

Both are production-quality. ACA's revisions + traffic splitting gives the impression that the operation of allocating traffic numerically is intuitive and the canary implementation is somewhat lighter. On the other hand, Fargate + CodeDeploy can be built out to include automatic metric monitoring during bake time → auto-rollback.

Keyless CI/CD (OIDC) is common to both — Azure with Entra federated credentials, AWS with the IAM OIDC provider. It's the same "trust a short-lived token" design (throw away keys with GitHub Actions OIDC).

Cost model: free tier, idle vs. Spot, Graviton

The skeleton of billing is the same (allocated vCPU-seconds + memory-seconds), but the optimization levers differ.

ACA's weapons: free tier + idle rate + scale-to-zero

Per subscription per month, The first 180,000 vCPU-seconds, The first 360,000 GiB-seconds, and The first 2 million HTTP requests are free (Billing). Furthermore:

• No billing when scaled to zero (When a revision is scaled to zero replicas, no resource consumption charges are incurred.)
• An idle-rate discount while waiting at minimum replicas
• Service-to-service communication and health probes within an environment are not subject to request billing

→ ACA is overwhelmingly cheaper for small/intermittent workloads. A small service runs on the free tier alone.

Fargate's weapons: Spot + Graviton + Savings Plans

• Fargate Spot: interruption-tolerant workloads (batch, stateless workers) at a steep discount. A SIGTERM warning 2 minutes prior.
• Graviton (ARM64): cheaper than x86 and power-efficient.
• Compute Savings Plans: a reservation discount for always-on.

→ Always-high-load, large-scale batch is strong with Fargate Spot + Graviton (Fargate cost optimization). ACA has no direct equivalent of Fargate Spot, and instead attacks with "scale-to-zero + idle."

Networking and security: the granularity of isolation differs

• Isolation: Fargate has each task with an independent ENI (awsvpc), with strong isolation not sharing kernel/CPU/memory/ENI per task. ACA has apps share the environment's VNet (the environment = the security boundary). For strict per-task network isolation, Fargate is finer-grained.
• VNet/subnet: ACA is /27 in a workload-profile environment, with UDR, NAT Gateway, and Private Endpoint support. Fargate fully controls VPC/subnet/SG. Both can do egress lockdown (via a firewall).
• Identity: ACA is managed identity (Entra) + least privilege via identitySettings lifecycle. Fargate separates pull permission and app permission with separate execution and task roles. The philosophy is the same "least privilege."
• Secrets: ACA is Key Vault references (auto-rotation within 30 minutes + auto-restart of the referencing revision), Fargate is valueFrom of Secrets Manager/SSM.

Which to choose: a decision flow

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）

それ以外：迷ったら「今いるクラウド」。両者の本番運用は同型。

Conclusion

It's not "which is superior" but "which fits your constraints." If the cloud is already decided, choose that foundation and fill the key points with this article's difference tables — that's enough. If cloud-free for a new project — emphasize intermittent workloads, event-driven, serverless GPU, shortest HTTPS publishing → ACA; emphasize larger tasks, Spot's deep discount, tight AWS ecosystem coupling → Fargate.

I've run Fargate in production, but I feel ACA's scale-to-zero / serverless GPU / first-class Jobs / automatic HTTPS are clearly a better experience for specific uses. Conversely, the cost-efficiency of hitting large-scale batch with Fargate Spot and the per-task ENI isolation are Fargate-specific. Knowing both lets you choose the optimal one per project — that's the value of handling multi-cloud with one person × generative AI.

For either AWS or Azure serverless container platform, from production-quality design to migration and cost optimization — fast, cheap, and safe. For consultation, go to contact; for production-operation details, see the Azure Container Apps production-operations guide and the AWS ECS on Fargate production-operations guide.