Pick the wrong serverless container platform and you will not find out for thirty days, when the bill lands. AWS Fargate, Google Cloud Run, and Azure Container Apps all promise to run a Docker container without anyone touching a server, but the three platforms price, scale, and start up in genuinely different ways. A team running a steady, always-on API will pay roughly $29.55 per vCPU-month on Fargate. A team running a bursty internal tool that idles most of the day can pay under $5 a month on Cloud Run. Picking based on the wrong workload profile is how “serverless” bills turn into a monthly surprise.
This comparison walks through current pricing, hard limits, cold-start numbers from independent benchmarks, and the operational tradeoffs that specs sheets do not show. It covers AWS Fargate (the compute engine behind ECS and EKS’s Fargate launch type), Google Cloud Run (Google’s request-driven and now instance-based container platform), and Azure Container Apps (Microsoft’s Kubernetes-and-KEDA-based serverless layer). By the end you should know which one fits your workload, what migrating between them actually costs in engineering time, and where each platform quietly breaks down at scale.
What “Serverless Containers” Actually Means in 2026
Serverless containers sit between raw virtual machines and functions-as-a-service. You package an app as a container image, hand it to the platform, and the provider handles the host OS, patching, and (on some plans) scaling the number of running instances up or down based on traffic. You never provision an EC2 instance, a VM, or a Kubernetes node pool yourself, even though two of the three platforms compared here run on Kubernetes under the hood.
AWS Fargate launched first, in 2017, as a capacity provider for ECS, and later extended to EKS pods. It treats every task as a fixed-size allocation of vCPU and memory that keeps running (and billing) whether or not it’s handling traffic. Google Cloud Run, built on the open-source Knative project, took the opposite approach: request-driven billing, per-second granularity, and true scale-to-zero from day one. Azure Container Apps arrived later, in 2022, and split the difference. It is built on Kubernetes, KEDA, and Dapr internally, exposing a Consumption plan that scales to zero like Cloud Run alongside a Dedicated plan that behaves more like Fargate.
The practical difference shows up the moment traffic stops. Fargate tasks keep running (and billing) until you stop them. Cloud Run and Container Apps on their Consumption plans can drop to zero running instances and zero cost, then cold-start back up when the next request arrives. That single design choice explains most of the pricing gap you will see in the tables below.
AWS Fargate: Pricing, Limits, and What Changed in 2026
AWS Fargate bills per second for the vCPU and memory a task reserves, regardless of whether the container is actively processing a request. As of the current AWS pricing page for Linux/x86 workloads in us-east-1, on-demand compute runs $0.04048 per vCPU-hour and $0.004445 per GB-hour. There is no free tier for Fargate compute. You’re billed from the first second a task starts, though AWS Free Tier promotional credits can offset early usage on new accounts.
Fargate Spot cuts that price by up to 70%, following the same interruption model as EC2 Spot: AWS can reclaim Spot capacity with a two-minute warning, so it fits batch jobs, CI runners, and stateless workers better than customer-facing APIs. Independent 2026 cost calculators put effective Fargate Spot rates around $0.012 per vCPU-hour and $0.0013 per GB-hour, though the exact discount floats with regional capacity.
The biggest Fargate news of 2026 landed in June: AWS shipped 32 vCPU task configurations with up to 244 GiB of memory, on both x86 and ARM, across Fargate and Fargate Spot, in every commercial and GovCloud region. That’s double the previous 16 vCPU ceiling and pushes Fargate into territory previously reserved for large EC2 instances, aimed at AI inference and heavy data-processing tasks that don’t need a full Kubernetes node pool to manage.
Fargate does not scale to zero. A running service keeps at least one task (and its bill) alive continuously. What people call a “cold start” on Fargate is really new-task provisioning, and it is slow compared to the other two platforms: community-measured task placement in ECS typically runs 10 to 30 seconds, driven by image pull time, ENI attachment, and health-check grace periods, not container startup itself.
Google Cloud Run: Pricing, Limits, and What Changed in 2026
Cloud Run bills in two ways depending on configuration. Google’s request-based Tier 1 pricing charges $0.000024 per vCPU-second and $0.0000025 per GiB-second, plus $0.40 per million requests beyond the free tier. A separate instance-based mode, aimed at always-on workloads like AI agents, bills a flat rate whether or not the instance is handling requests, with Google’s own example pricing out a continuously running 1 vCPU / 1 GiB instance at roughly $51.84 for 30 days. Worth flagging for anyone building a cost model: Google’s own documentation pages show two slightly different per-second rates ($0.000018 vs $0.000024 per vCPU-second) depending on which pricing table you land on, which Google has not fully reconciled in its public docs. Use the Tier 1 request-based figures above for budgeting and confirm against your own billing console before committing to a number.
The free tier is generous relative to Fargate’s zero: roughly 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests per month, permanently free, not a 12-month trial allowance. That’s enough to run a genuinely low-traffic API, webhook receiver, or internal tool for nothing.
Cloud Run’s defining feature is scale-to-zero with fast, request-driven autoscaling. A single container instance supports up to 1,000 concurrent requests, with a default of 80 (or 80 times the number of vCPUs when created via CLI or Terraform). Container sizing tops out at 8 vCPU and 32 GiB of memory per instance. 2026 brought several concrete additions: NVIDIA L4 GPU support for Cloud Run services and jobs, a public preview of hard-isolated “Cloud Run sandboxes” for running untrusted AI-generated code, and GA of automated cross-region failover, rolled out after a Netherlands region outage earlier in the year pushed Google to prioritize it.
Cold starts are where Cloud Run built its reputation. With predictive scaling and prewarming, typical HTTP workloads report sub-100ms to 500ms cold starts in field measurements. GPU-backed services are the exception: heavy inference images with large model weights can still take 35 to 40 seconds to cold-start, so GPU workloads should generally run with a minimum of one warm instance rather than scaling to zero.
Azure Container Apps: Pricing, Limits, and What Changed in 2026
Azure Container Apps’ Consumption plan bills active and idle CPU time separately. Active vCPU time (while the replica is serving a request) costs $0.000024 per vCPU-second, the same headline rate as Cloud Run’s Tier 1 pricing. Idle vCPU time, when a replica is warm but not processing a request, drops to $0.000003 per vCPU-second, and memory bills at $0.000003 per GiB-second across both states. The free tier matches Cloud Run’s figures closely: 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests per month.
Consumption-plan containers cap out at 2 vCPU and 4 GiB of memory per container, noticeably smaller than Fargate’s 32 vCPU ceiling or Cloud Run’s 8 vCPU limit. Teams that need bigger containers move to Container Apps’ Dedicated workload profiles, which trade scale-to-zero for reserved, VM-backed capacity that behaves closer to Fargate.
Because Container Apps is built on KEDA underneath, it scales on more than just HTTP concurrency. Queue depth, cron schedules, and custom metrics can all trigger scale-out. That flexibility comes at the cost of a clean concurrency number: unlike Cloud Run’s published 1,000-requests-per-instance ceiling, Microsoft does not publish a single “requests per replica” maximum. Scaling is instead governed by whatever KEDA scale rule you configure alongside CPU and memory limits.
2026 updates leaned toward AI workloads and observability: GA of confidential compute for Container Apps, managed OpenTelemetry export to New Relic, Dynatrace, and Elastic, and a preview of “Container Apps Sandboxes,” ephemeral environments with snapshot and resume support built for running AI agent code safely. A newer “Container Apps Express” preview promises sub-second cold starts and per-second billing on a fast path from image to running app, though it remains in preview as of this writing.
Published cold-start numbers for Container Apps span a wide range depending on tuning. Hands-on labs measuring true scale-to-zero (minReplicas set to 0) report roughly 19 to 20 seconds for the first request after an idle period, and complex images built on frameworks like GraalVM native images have been clocked as high as 15 to 37 seconds. A 2025 comparison of Azure hosting options put plain Container Apps cold starts around 6 seconds against 9 seconds for App Service and 22 seconds for an AKS virtual node, while keeping a minimum of one replica warm cuts response latency to roughly 140ms at the cost of paying for that idle replica continuously.
Full Specs Comparison Table
| Spec | AWS Fargate | Google Cloud Run | Azure Container Apps (Consumption) |
|---|---|---|---|
| On-demand vCPU price | $0.04048/vCPU-hr | $0.0864/vCPU-hr (Tier 1) | $0.0864/vCPU-hr active, $0.0108/vCPU-hr idle |
| On-demand memory price | $0.004445/GB-hr | $0.0090/GiB-hr (Tier 1) | $0.0108/GiB-hr |
| Discounted/Spot pricing | Fargate Spot, up to 70% off | No Spot; committed-use discounts available | No Spot; Dedicated plan reserved pricing |
| Free tier | None | ~180K vCPU-sec, ~360K GiB-sec, 2M requests/mo | 180K vCPU-sec, 360K GiB-sec, 2M requests/mo |
| Scale-to-zero | No | Yes | Yes (minReplicas=0) |
| Max vCPU per container/task | 32 vCPU (since June 2026) | 8 vCPU | 2 vCPU |
| Max memory per container/task | 244 GiB | 32 GiB | 4 GiB |
| Concurrency per instance | App-managed, no platform cap | Up to 1,000, default 80 | KEDA-managed, no published cap |
| Cold start (typical) | 10-30 sec (new task placement) | Sub-100ms to 500ms (prewarmed) | 1-3 sec tuned, up to 20 sec scale-to-zero |
| Underlying orchestration | Proprietary AWS compute engine | Knative-based | Kubernetes + KEDA + Dapr |
| GPU support | Via EC2/EKS, not native Fargate | NVIDIA L4 (GA 2026) | Serverless GPU (workload profiles) |
| Approximate region count | ~30 commercial + 2 GovCloud | ~25-30 | ~25-30 |
| Native scaling triggers | Application Auto Scaling (CPU/memory/custom) | HTTP concurrency, CPU | HTTP, queue depth, cron, custom KEDA metrics |
A note on the concurrency row: Cloud Run’s 1,000-requests-per-instance ceiling is the only one of the three platforms with an official, documented number. Fargate and Container Apps both leave concurrency to the application and its autoscaling configuration, which makes Cloud Run easier to reason about but Fargate and Container Apps more flexible for workloads with unusual traffic shapes.
Real Monthly Costs: Three Traffic Scenarios
Sliplane’s March 2025 pricing breakdown, still the most cited independent comparison of the three platforms’ raw compute rates, converts each platform’s per-second pricing into a monthly cost for continuous use. Fargate comes out cheapest per vCPU and per GB when a container runs 24/7, because Cloud Run and Container Apps both price in the overhead of request-driven billing and autoscaling infrastructure.
| Scenario | AWS Fargate | Google Cloud Run | Azure Container Apps |
|---|---|---|---|
| Continuous use, per vCPU/month | $29.55 | $47.30 (instance-based) / $63.08 (request-based) | $63.08 |
| Continuous use, per GB/month | $3.25 | $5.26 (instance-based) / $6.57 (request-based) | $7.88 |
| Low traffic, under 50K requests/mo | $25-$35/mo (always billing) | $2-$5/mo (mostly free tier) | $5-$8/mo |
| Sustained 1M+ requests/mo | $40-$80/mo | $40-$80/mo | $40-$80/mo |
The pattern that falls out of both rows: the cost gap between platforms is largest at the extremes and narrowest in the middle. A container that idles most of the day and only occasionally handles traffic can cost 10x more on Fargate than on Cloud Run, simply because Fargate never stops billing. A container that runs flat-out around the clock flips that math, because Cloud Run and Container Apps’ request-driven pricing carries a premium once you strip away the free tier and the idle discount. Once traffic is high and steady enough that all three platforms are running near-continuously, the three converge to within a rounding error of each other.
Cold Start Benchmarks: What Independent Testing Shows
Cold start is the single most workload-dependent number in this comparison, so treat any single figure with suspicion and look at ranges from multiple sources instead.
A 2026 benchmark published by tech-insider.org, comparing Fargate 2026.2 against Cloud Run 2026.1.0, measured Fargate cold starts averaging 1.2 seconds for a 512MB container against a 320ms baseline on Cloud Run, a roughly 3.8x gap, and found Cloud Run delivering about 2.1x higher throughput per vCPU on CPU-bound workloads. That tracks with a separate 2025 academic study in the International Journal of Intelligent Systems and Applications in Engineering, which measured Fargate task startup latency for containerized workloads at 430-520ms across common size tiers once capacity was already provisioned, distinct from the longer new-task placement window Fargate incurs when scaling from zero running tasks.
A 2025 LLM-deployment performance study comparing Fargate against Azure Container Apps for inference workloads found Fargate posting a median response time of 395.50ms against 588.37ms for Container Apps, about 33% faster, likely reflecting Fargate’s always-warm nature against Container Apps’ more aggressive default scale-down behavior. A separate practitioner benchmark published in 2026 measured Cloud Run Node.js cold starts under 500ms against roughly 800ms for a comparable Container Apps deployment in the same test, consistent with Cloud Run’s request-driven architecture prioritizing fast cold starts over Container Apps’ more general-purpose KEDA scaling model.
The consistent theme across all three sources: Cloud Run wins on cold-start latency for typical small HTTP workloads, Fargate wins on steady-state response time because it rarely actually goes cold, and Container Apps lands in between, with cold-start performance that improves significantly once you tune minimum replica counts away from true scale-to-zero.
Scale-to-Zero and Concurrency, Compared Head to Head
Fargate’s refusal to scale to zero is a deliberate tradeoff, not an oversight. AWS designed Fargate tasks to behave like long-lived compute, which is why ECS and EKS both treat a Fargate task the same way they’d treat an EC2-backed task for health checks, load balancer registration, and service discovery. If your workload needs to be always warm anyway, for example a production API behind a load balancer with real traffic around the clock, Fargate’s lack of scale-to-zero costs nothing extra, because you were never going to scale to zero in the first place.
Cloud Run’s scale-to-zero is the platform’s core value proposition, and Google has spent 2026 investing in making the zero-to-one transition faster rather than avoiding it: predictive scaling, prewarming, and the new sandboxed execution mode all reduce the practical cost of scaling from zero. The tradeoff is architectural. Request-based Cloud Run services are stateless by design, and anything requiring persistent in-memory state, long-lived WebSocket connections, or background processing outside a request context needs the newer instance-based mode, which reintroduces some of Fargate’s always-on billing model.
Azure Container Apps sits in the middle by design, and its KEDA foundation is genuinely more flexible than either competitor for event-driven scaling. A queue-triggered worker on Container Apps can scale out based on queue depth rather than HTTP traffic, something neither Fargate nor Cloud Run does natively without extra glue code (Application Auto Scaling custom metrics on Fargate, or Cloud Tasks/Pub-Sub triggers on Cloud Run). That flexibility is also why Container Apps lacks a clean concurrency number to point to: scaling behavior depends entirely on which KEDA scaler you’ve configured.
Security and Compliance Considerations
All three platforms inherit their parent cloud’s identity and network controls, so the meaningful differences are in isolation model and recent security-focused features rather than baseline security posture. Fargate tasks run on AWS’s proprietary microVM-backed compute, with each task isolated at the kernel level from other customers’ workloads, and integrate directly with IAM task roles, VPC networking, and AWS Secrets Manager.
Cloud Run’s new sandboxed execution mode, in public preview through 2026, specifically targets a use case the other two platforms handle less directly: running untrusted, AI-generated code with hard isolation guarantees and fast cold starts, aimed at agentic AI products that execute model-generated scripts. Azure Container Apps shipped general-availability confidential compute in 2026, using hardware-based trusted execution environments to keep data encrypted even while in use, along with its own preview of “Sandboxes” for AI agent workloads with snapshot and resume support.
For regulated workloads, the practical decision usually comes down to existing compliance certifications and data residency rather than platform-specific features, since AWS, Google Cloud, and Azure all maintain comparable baseline certifications (SOC 2, ISO 27001, FedRAMP where applicable) across these services. Teams already committed to one cloud for compliance reasons rarely have a real choice among the three regardless of technical merits.
Developer Experience, Observability, and Vendor Lock-In
Pricing and cold starts get most of the attention in these comparisons, but the day-to-day experience of deploying, debugging, and monitoring a service matters just as much once a team lives with a platform for a year. Fargate’s deploy story runs through ECS or EKS, which means teams get the full breadth of AWS’s ecosystem (CloudWatch, X-Ray, IAM, Application Auto Scaling) but also inherit ECS’s more verbose task-definition JSON and a steeper initial learning curve than either competitor. Teams already fluent in Kubernetes generally prefer running Fargate through EKS rather than plain ECS, since it lets them reuse existing manifests and tooling.
Cloud Run’s developer experience is consistently rated the simplest of the three: a single gcloud run deploy command can take a container from a local Dockerfile to a live HTTPS endpoint with a generated URL, without touching a load balancer, a VPC, or an IAM role unless the workload specifically needs one. That simplicity is also Cloud Run’s biggest lock-in risk. Teams that lean on Cloud Run-specific features, like its request-based concurrency model or the newer instance-based billing mode, write deployment configuration that doesn’t translate directly to Fargate or Container Apps without rework.
Azure Container Apps’ observability story improved substantially in 2026 with managed OpenTelemetry export straight to New Relic, Dynatrace, and Elastic, removing a step that used to require standing up a separate collector. Its reliance on Dapr for service-to-service communication is a double-edged sword: Dapr’s sidecar pattern gives Container Apps built-in state management, pub/sub, and service invocation that neither Fargate nor Cloud Run offers natively, but it also means an app built around Dapr’s building blocks needs meaningful rework to run cleanly on a competitor’s platform.
On raw portability, all three platforms score reasonably well because they consume standard OCI container images rather than a proprietary packaging format the way early functions-as-a-service platforms once did. The lock-in that actually bites teams tends to come from the scaling and secrets layer, not the container runtime itself. A service that reads secrets through AWS Secrets Manager’s SDK, scales via a custom Application Auto Scaling policy, and logs to CloudWatch in a Fargate-specific format will need real engineering time to move, even though the container image underneath would run unmodified on Cloud Run or Container Apps. Teams that expect to move between clouds, or that want to keep the option open, generally do better injecting configuration and secrets through environment variables and a provider-agnostic secrets client (like an internal wrapper around each cloud’s SDK) rather than calling cloud-specific SDKs directly from application code.
Five Real-World Use Cases: Who Should Run What
A fintech API handling steady, predictable transaction volume around the clock. Fargate fits best here. Continuous traffic means scale-to-zero adds no value, and Fargate’s lower per-vCPU rate ($29.55/month vs $51-63 for the other two) compounds into real savings at scale. The 32 vCPU task ceiling also gives headroom for heavier compliance and fraud-scoring workloads without splitting into more containers.
An internal admin dashboard used by a 40-person company a few hours a day. Cloud Run is the clear winner. Traffic this bursty spends most of its time at zero running instances, so the bill stays inside the free tier or close to it, versus Fargate charging for 24 hours of reserved capacity whether anyone opens the dashboard or not.
A media company’s image and video processing pipeline triggered by queue messages. Azure Container Apps’ native KEDA queue-depth scaling handles this without custom autoscaling logic. Jobs scale out directly against queue length, run to completion, and scale back to zero, a pattern that requires more manual wiring on Fargate or Cloud Run.
An AI startup running always-on autonomous agents that need persistent memory between calls. Cloud Run’s newer instance-based billing mode, or Container Apps’ Sandboxes preview, both target this directly. Google’s own pricing example, a continuously running 1 vCPU/1 GiB instance at $5.70 for 30 days, undercuts Fargate’s equivalent cost while still supporting the sandboxed execution AI agent workloads increasingly need.
A gaming company running nightly batch jobs for matchmaking analytics and leaderboard recalculation. Fargate Spot is purpose-built for this: up to 70% off on-demand pricing for interruption-tolerant, stateless batch work that can checkpoint and resume if AWS reclaims capacity, which nightly batch jobs generally can.
Migration Guide: Moving a Container Between Platforms
Because all three platforms run standard OCI container images, migrating between them is mostly a configuration exercise rather than a rewrite, provided the app doesn’t depend on platform-specific services like AWS Secrets Manager SDK calls baked directly into application code.
Step 1: Audit for platform-specific dependencies. Check for direct SDK calls to cloud-specific services (IAM roles, Secrets Manager, Cloud SQL Auth Proxy, Key Vault references) and abstract them behind environment variables or a config layer before migrating.
Step 2: Confirm the container respects the target platform’s port and startup conventions. Cloud Run requires the container to listen on the port defined by the PORT environment variable. Fargate and Container Apps are more flexible but still expect a fast, deterministic startup for health checks to pass.
Step 3: Re-map resource sizing. A Fargate task sized at 4 vCPU / 8 GB needs to be split or resized for Container Apps’ 2 vCPU / 4 GiB Consumption ceiling. Cloud Run’s 8 vCPU / 32 GiB ceiling covers most Fargate sizes below its high end.
Step 4: Re-implement autoscaling triggers. Moving from Fargate’s Application Auto Scaling to Cloud Run means switching to concurrency-based scaling. Moving to Container Apps means picking or writing a KEDA scaler if you need anything beyond basic CPU/HTTP scaling.
Step 5: Rebuild CI/CD deploy targets. Each platform has its own deploy primitive: ECS task definitions and services for Fargate, Cloud Run services/jobs via gcloud or Terraform, and Container Apps resources via az CLI, Bicep, or Terraform. Infrastructure-as-code tools like Terraform or OpenTofu can target all three from the same pipeline with provider-specific resource blocks.
# Deploying the same image to each platform, command-line equivalents
# AWS Fargate (via ECS)
aws ecs update-service --cluster my-cluster --service my-service \
--task-definition my-task:LATEST --force-new-deployment
# Google Cloud Run
gcloud run deploy my-service \
--image gcr.io/my-project/my-image:latest \
--cpu 1 --memory 512Mi --min-instances 0 --max-instances 10
# Azure Container Apps
az containerapp update \
--name my-app --resource-group my-rg \
--image myregistry.azurecr.io/my-image:latest \
--min-replicas 0 --max-replicas 10Step 6: Re-test cold-start behavior under real traffic patterns before cutting over. The biggest migration risk isn’t the deploy itself, it’s discovering post-migration that your assumed cold-start numbers don’t match production traffic shape. Load-test the new platform with realistic idle-then-burst patterns, not just sustained load, since that’s exactly where the three platforms diverge most.
AWS Fargate: Pros and Cons
Pros: Lowest raw compute price for continuous, steady workloads. Largest container ceiling at 32 vCPU and 244 GiB, useful for AI inference and heavy batch jobs. Deep integration with ECS and EKS for teams already on AWS. Fargate Spot offers real savings for interruption-tolerant work.
Cons: No scale-to-zero means idle capacity always costs money. No free tier at all. Slowest cold start of the three when a new task does need to be placed. Concurrency and scaling require more manual configuration than Cloud Run or Container Apps.
Google Cloud Run: Pros and Cons
Pros: True scale-to-zero with the fastest cold starts in this comparison for typical HTTP workloads. Generous, permanent free tier. Simple, well-documented concurrency model (up to 1,000 requests per instance). New instance-based billing and sandboxed execution mode target AI agent workloads directly.
Cons: Smaller container ceiling than Fargate (8 vCPU / 32 GiB max). Conflicting published pricing figures across Google’s own documentation pages create real budgeting risk. GPU-backed cold starts remain slow (35-40 seconds) despite fast CPU cold starts.
Azure Container Apps: Pros and Cons
Pros: Most flexible native scaling triggers via KEDA (queue depth, cron, custom metrics), no glue code required. Built-in Dapr support simplifies microservice patterns like service invocation and pub/sub. Confidential compute is generally available. Dedicated plan offers a clean upgrade path when Consumption limits are outgrown.
Cons: Smallest container ceiling of the three (2 vCPU / 4 GiB on Consumption). Widest and least predictable cold-start range, from roughly 1 second tuned to 20+ seconds on true scale-to-zero. No published concurrency-per-replica ceiling makes capacity planning harder than on Cloud Run.
Hidden Costs the Headline Pricing Doesn’t Show
Every pricing comparison, including this one, leads with vCPU and memory rates because those are the numbers vendors publish cleanly. In practice, the line items that catch teams off guard are the ones that don’t show up on a pricing landing page. Fargate tasks running inside a VPC each get their own elastic network interface, and if that task needs outbound internet access from a private subnet, it routes through a NAT gateway, which bills separately by the hour plus per-GB data processed, a cost that has nothing to do with the vCPU-hour rate quoted above and can quietly double a small service’s bill.
Cloud Run’s request-based pricing looks simple until a service needs to call another Google Cloud service across regions, or until CPU is only allocated “during request processing” by default, a setting that throttles background work outside the request lifecycle unless you explicitly switch to CPU-always-allocated, which itself changes the billing model closer to an always-on instance. Teams that don’t catch this setting early sometimes see background jobs silently stall or under-perform, not because of a platform bug but because of a billing-and-CPU-allocation tradeoff baked into the default configuration.
Azure Container Apps’ hidden cost tends to show up in logging and observability rather than networking. The managed OpenTelemetry export added in 2026 is a genuine convenience, but Log Analytics ingestion (the default destination for Container Apps’ system and console logs) bills separately by the GB ingested and retained, and a chatty application can generate a logging bill that rivals the compute bill it’s supposed to be observing. All three clouds bill container registry storage and image pulls separately from compute as well, a cost that scales with deploy frequency and image size rather than traffic, and one that CI-heavy teams doing dozens of daily deploys should model explicitly rather than assume is negligible.
The Verdict: Which Platform Wins
There is no single winner across all three platforms, because they were built to win different workloads. For continuous, predictable traffic, AWS Fargate’s $29.55 per vCPU-month beats both competitors by 40-50%, and the 32 vCPU ceiling gives room to grow without re-architecting. For bursty, low-traffic, or genuinely idle-most-of-the-day workloads, Google Cloud Run’s scale-to-zero and sub-500ms cold starts make it the only platform of the three that doesn’t punish you for having quiet periods, and its free tier alone covers many internal tools outright.
Azure Container Apps earns its place for one specific reason the other two don’t fully replicate: native, code-free scaling on non-HTTP triggers like queue depth and cron schedules, backed by real Dapr support for teams building event-driven microservices. It is rarely the cheapest or the fastest, but for queue-driven and Azure-native shops it removes glue code the other two platforms require.
If forced to pick one default for a team with no strong cloud preference and a typical mix of steady and bursty services, Cloud Run is the safer starting point in 2026: it has the widest free tier, the fastest cold starts for the workloads most teams actually run, and the clearest documented concurrency model. Teams with already-heavy, steady, AWS-native infrastructure should stay on Fargate rather than migrate for marginal savings. Teams building event- or queue-driven pipelines on Azure should lean into Container Apps’ KEDA integration rather than fighting it.
Frequently Asked Questions
Is AWS Fargate more expensive than Google Cloud Run?
For continuous, always-on workloads, Fargate is cheaper per vCPU ($29.55/month vs $51-63/month). For bursty or low-traffic workloads, Cloud Run is usually far cheaper because it scales to zero and Fargate doesn’t, so the answer flips depending entirely on your traffic pattern.
Does AWS Fargate support scale-to-zero?
No. Fargate tasks continue running, and billing, until explicitly stopped. Teams that need true scale-to-zero on AWS typically look at Lambda instead, though that trades container flexibility for function-based constraints.
Which platform has the fastest cold starts?
Google Cloud Run, for typical CPU-bound HTTP workloads, with independent benchmarks reporting sub-100ms to 500ms cold starts thanks to predictive scaling and prewarming. GPU-backed Cloud Run services are the exception and can still take 35-40 seconds to cold-start.
Can I run a container larger than 8 vCPU on Cloud Run?
No, 8 vCPU and 32 GiB of memory is Cloud Run’s current per-instance ceiling. Workloads needing more compute per container should look at AWS Fargate, which supports up to 32 vCPU and 244 GiB as of its June 2026 update.
Is Azure Container Apps built on Kubernetes?
Yes. Microsoft built Container Apps on top of Kubernetes, KEDA for event-driven autoscaling, and Dapr for microservice communication patterns, though none of that infrastructure is exposed directly to the user the way a self-managed AKS cluster would be.
Which platform is cheapest for a low-traffic side project?
Google Cloud Run, generally by a wide margin. Its permanent free tier (roughly 180,000 vCPU-seconds and 2 million requests per month) covers most side projects and internal tools entirely, while Fargate bills from the first second regardless of traffic.
Do these platforms support GPUs for AI inference?
Google Cloud Run added GA support for NVIDIA L4 GPUs in 2026. Azure Container Apps offers serverless GPU through its workload profiles. AWS Fargate does not natively support GPUs. GPU workloads on AWS typically run on EC2 or EKS with GPU-backed node groups instead.
How hard is it to migrate a container between these three platforms?
Migration is usually a configuration and redeploy exercise, not a rewrite, since all three run standard OCI images. The main friction points are platform-specific SDK calls, resource-size re-mapping given each platform’s different vCPU/memory ceilings, and rebuilding autoscaling triggers for the target platform’s scaling model.
