Pick the wrong serverless container platform and you either overpay for idle compute or spend a weekend debugging cold starts nobody warned you about. That’s the choice facing teams evaluating AWS Fargate, Google Cloud Run, and Azure Container Apps in August 2026 — three managed container runtimes that promise to eliminate server management but price and scale in fundamentally different ways.
Search interest backs up the confusion. “aws fargate” pulls roughly 5,400 monthly US searches, “google cloud run” matches it at 5,400, and “azure container apps” trails at 2,400, according to Google Ads keyword data pulled in August 2026. Developers are actively trying to figure out which platform fits a $5-a-month side project versus a production API handling a million requests a day. This comparison walks through the pricing math, the scaling behavior, the benchmarks published by independent engineers running identical workloads on all three clouds, and the migration path if you picked wrong the first time.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What AWS Fargate, Cloud Run, and Container Apps Actually Do
All three products solve the same basic problem: run a container without provisioning, patching, or scaling a virtual machine yourself. Beyond that shared goal, they diverge quickly.
AWS Fargate is a compute engine for Amazon ECS and Amazon EKS. It doesn’t run containers on its own — you still define an ECS task or an EKS pod spec, and Fargate supplies the underlying compute instead of an EC2 instance you’d otherwise manage. That means Fargate inherits ECS/EKS features like service discovery, load balancer integration, and IAM task roles, but it also means there’s no true zero-instance state. At least one task keeps running as long as the service is active, billed on Linux/x86 at $0.04048 per vCPU-hour and $0.004445 per GB-hour in us-east-1 as of June 2026, per AWS’s own Fargate pricing documentation — a rate that drops roughly 20% for tasks running on ARM/Graviton instead of x86, according to a June 2026 LeanOps Tech cost breakdown.
Google Cloud Run is a fully managed, request-driven container platform built on Knative. You give it a container image, Cloud Run assigns an HTTPS endpoint, and it scales instances up in response to incoming requests — including scaling to exactly zero instances, and zero cost, when traffic stops. Cloud Run bills per vCPU-second and GB-second of actual usage, layered with a per-request fee, according to Google Cloud’s pricing page.
Azure Container Apps sits architecturally between the two. It’s built on Kubernetes, KEDA, and Dapr under the hood, but Microsoft abstracts all of that away so you interact with a single “container app” resource. Like Cloud Run, it supports scale-to-zero on its Consumption plan. Unlike Cloud Run, it also offers a Dedicated plan with reserved workload profiles for teams that want predictable capacity without touching raw VMs, per Microsoft’s Container Apps overview.
The practical difference shows up the moment your app goes idle. Fargate keeps billing you for the minimum one running task. Cloud Run and Container Apps drop to zero dollars and zero running instances, at the cost of a cold start the next time a request arrives.
AWS Fargate vs Google Cloud Run vs Azure Container Apps: Full Specs Table
| Spec | AWS Fargate | Google Cloud Run | Azure Container Apps |
|---|---|---|---|
| Underlying orchestrator | Amazon ECS / EKS | Knative (managed) | Kubernetes + KEDA + Dapr (managed) |
| Scale-to-zero | No (minimum 1 task) | Yes, by default | Yes, on Consumption plan |
| Billing unit | Per vCPU-second + per GB-second | Per vCPU-second + per GB-second + per request | Per vCPU-second + per GB-second + per request |
| vCPU price (per second equiv.) | ~$0.0000112 ($0.04048/hr) | ~$0.000024 | ~$0.000024 |
| Memory price (per GB-second equiv.) | ~$0.0000012 ($0.004445/GB-hr) | ~$0.0000025 | ~$0.0000025 |
| Free tier | None | 180,000 vCPU-sec + 360,000 GB-sec + 2M requests/mo | 180,000 vCPU-sec + 360,000 GB-sec + 2M requests/mo |
| Max execution time per request | No limit (long-running services) | Up to 60 minutes | No limit (long-running services) |
| Cold start (typical) | None (always-on task) | 100ms–several seconds, depends on image/runtime | ~1–3 seconds on Consumption plan |
| Native service mesh / Dapr | No (requires App Mesh add-on) | No | Yes, built-in Dapr sidecars |
| Load balancing | ALB/NLB (separate resource) | Built-in HTTPS endpoint | Built-in HTTPS endpoint + internal ingress |
| GPU support | Limited (EC2-backed tasks only, not Fargate) | Yes (Cloud Run GPU, NVIDIA L4) | Yes (GPU workload profiles) |
| Multi-container per task/pod | Yes (task-level sidecars) | Yes (sidecar containers, limited) | Yes (multi-container revisions) |
| Reserved/dedicated capacity option | Savings Plans / Compute Savings | Committed use discounts | Dedicated plan (workload profiles) |
| Region availability (approx.) | 30+ AWS regions | 40+ GCP regions | 60+ Azure regions |
Pricing figures above reflect published 2026 US-East / us-central1 / East US on-demand list rates compiled by independent cost trackers including Sliplane’s cross-cloud pricing comparison and a February 2026 engineering breakdown published on devstarsj.github.io. Actual bills vary with region, committed-use discounts, and sustained-use pricing that GCP applies automatically — and with line items the headline vCPU/memory rate doesn’t capture, such as Fargate’s ephemeral storage, which bills usage above the free 20GB allotment at $0.000111 per GB-hour, per a May 2026 LeanOps Tech cost breakdown.
Pricing Breakdown: What Each Workload Actually Costs
List prices only tell part of the story. What matters is what a real workload costs once you factor in idle time, request volume, and whether your traffic pattern rewards scale-to-zero or punishes it with cold starts. Three independent cost breakdowns published in 2026 converge on a similar pattern, even though the exact dollar figures differ slightly by methodology.
| Workload profile | AWS Fargate (always-on) | Google Cloud Run (scale-to-zero) | Azure Container Apps (scale-to-zero) |
|---|---|---|---|
| Low traffic, <50K requests/month | $25–$35/mo | $2–$5/mo | $5–$8/mo |
| 1M requests/mo, 500ms avg duration | $25–$35/mo | $5–$15/mo | $8–$18/mo |
| High traffic, 1M+ requests/mo, sustained | $40–$80/mo | $40–$80/mo | $40–$80/mo |
| 2 vCPU / 8GB always-on instance | ~$30/mo | ~$24/mo (sustained-use discount) | ~$30/mo |
| Per-vCPU monthly equivalent (continuous) | $29.55 | $51.25 (instance-based) / $63.08 (request-based) | $63.08 |
The pattern holds across every published comparison: Fargate wins on continuous, always-on compute because it charges a flat per-vCPU-hour rate with no request fee layered on top. Cloud Run and Container Apps win decisively for anything with meaningful idle time, because scaling to zero means you stop paying entirely between requests. A June 2026 practitioner writeup shared on LinkedIn by an engineer who deployed the same Node.js app to all three platforms found ECS on Fargate running $25–$35 a month for a low-traffic app specifically because it “never scales to zero,” while Cloud Run settled at $2–$5 for the identical workload. Teams that can tolerate interruptible capacity have another lever: Fargate Spot, which nOps priced in June 2026 at roughly $0.012–$0.024 per vCPU-hour — a 40–70% discount off on-demand rates that narrows the gap with scale-to-zero platforms for fault-tolerant background work.
That gap closes almost completely once traffic is sustained rather than bursty. At 1 million-plus requests a month with consistent load, all three platforms converge into a $40–$80 monthly range, according to the same analysis. At that point the deciding factor stops being the pricing model and starts being instance sizing, reserved capacity discounts, and how efficiently your container starts up.
Benchmarks: Cold Starts, Scaling Speed, and Throughput
Pricing is only half the decision. Cold start latency determines whether scale-to-zero is a cost saver or a user-facing problem. Three sources with independently run tests give a consistent picture.
Cold start behavior
Because Fargate tasks stay running (minimum one task per service), there is effectively no cold start once the service is live — the tradeoff is you pay for that always-on task whether or not it’s handling traffic. Cloud Run and Azure Container Apps both scale down to zero instances, which reintroduces a cold start the next time a request lands. A 2026 serverless-versus-containers comparison published on TechPlained lists cold starts in the “100ms to 10 seconds” range depending on runtime and image size — smaller, interpreted-language images (Node.js, Python) start faster than large JVM or .NET images that need to warm up a runtime before serving the first request.
Free tier and quota comparison
A 2026 serverless pricing and quota cheat sheet aggregated by TechBytes puts Cloud Run’s and Azure Container Apps’ free allowances at roughly 180,000 vCPU-seconds and 360,000 GB-seconds per month, plus about 2 million free requests — enough to run a genuinely free side project or internal tool indefinitely. Fargate has no equivalent free tier for serverless containers, which matters for hobbyists and early-stage startups trying to keep a demo environment running at zero cost.
Regional price variance
A broader multi-cloud pricing analysis published in August 2026 found Google Cloud running roughly 11% cheaper than AWS on standard general-purpose workloads, and up to 30% cheaper specifically on licensed SQL Server-adjacent workloads — a gap driven partly by GCP’s automatic sustained-use discounts, which apply without any commitment or reserved-instance purchase. AWS and Azure, by contrast, generally require Savings Plans or Reserved Instances to unlock comparable discounts.
Real-World Examples: Who’s Using Which Platform
The theoretical pricing math matters less than how teams actually deploy these platforms in production. Five patterns show up repeatedly across engineering blogs and cloud case studies published through 2026.
- Startups with bursty API traffic default to Cloud Run. A SaaS backend that serves a spike during business hours and near-zero traffic overnight is the textbook scale-to-zero case — the June 2026 side-by-side deployment test found Cloud Run costing a fifth of Fargate for exactly this traffic shape.
- Enterprises already running ECS extend into Fargate rather than migrate off it. Teams with existing ECS task definitions, IAM roles, and VPC configurations tend to add Fargate as the compute layer rather than rearchitect around a different platform, since it reuses their existing ECS service discovery and load balancer setup.
- Teams using Dapr for service-to-service communication pick Azure Container Apps. Because Container Apps ships Dapr sidecars natively, applications that already rely on Dapr’s pub/sub, state management, or service invocation APIs avoid having to self-host Dapr on raw Kubernetes.
- Batch and always-on background workers (queue consumers, cron-triggered jobs that run continuously) favor Fargate because there’s no benefit to scale-to-zero pricing when the workload never actually goes idle — Fargate’s flat per-vCPU-hour rate is simply cheaper for continuous compute.
- Multi-cloud shops standardizing on Kubernetes primitives lean toward Azure Container Apps for workloads that might eventually graduate to full AKS, since Container Apps shares the same underlying KEDA-based scaling model, easing a later migration to raw Kubernetes if the app outgrows a managed platform.
Serverless Containers vs Traditional Kubernetes: When Each Makes Sense
None of these three platforms replace a full Kubernetes cluster for every workload — they replace it for a specific slice of workloads where operational simplicity matters more than fine-grained control. A 2026 CTO-focused comparison from Kanopy Labs frames the tradeoff plainly: Fargate costs roughly 13% more than equivalent EC2 compute, landing around $0.04048 per vCPU-hour and $0.004445 per GB-hour, a premium teams pay specifically to avoid managing EC2 instances, patching AMIs, or right-sizing node groups themselves.
That premium is usually worth it below a certain team size. A platform team of one or two engineers rarely has the bandwidth to run a self-managed Kubernetes control plane, tune cluster autoscaler, and handle node-level security patching on top of shipping product features. Above that size — once you have a dedicated platform or SRE function — the economics shift, and raw EKS, GKE, or AKS node pools typically beat Fargate/Cloud Run/Container Apps pricing at scale, at the cost of taking on that operational burden directly.
Migration Guide: Moving Between Fargate, Cloud Run, and Container Apps
Most teams don’t start on the “right” platform — they start on whatever cloud they already had an account with, then migrate once cost or scaling behavior becomes a problem. Here’s the practical path for the most common migration: moving an always-on Fargate service to Cloud Run or Container Apps to capture scale-to-zero savings.
- Audit your traffic pattern first. Pull request-per-minute metrics for the last 30 days. If your service has sustained traffic with no meaningful idle window, migrating to a scale-to-zero platform won’t save money — skip to a Fargate Savings Plan instead.
- Containerize with a stateless design. Cloud Run and Container Apps both assume requests can land on any instance at any time. Move session state, in-memory caches, and file writes out of the container and into Redis, a managed database, or object storage before migrating.
- Reduce image size and startup time. Cold start duration is roughly proportional to image size and runtime initialization. Multi-stage Docker builds and slimmer base images (distroless, alpine) cut cold start latency measurably on both Cloud Run and Container Apps.
- Export your existing environment variables and secrets. ECS task definitions store these differently than Cloud Run’s environment variable + Secret Manager model or Container Apps’ secrets store — map each one explicitly rather than assuming a 1:1 copy-paste.
- Recreate load balancer rules as platform-native ingress. Fargate typically sits behind an ALB with path-based routing rules. Cloud Run and Container Apps both provide a built-in HTTPS endpoint, so ALB routing rules need to be rebuilt as Cloud Run traffic splitting or Container Apps ingress rules.
- Set min-instances if you can’t tolerate cold starts. Both Cloud Run and Container Apps support a “minimum instances” setting that keeps one warm instance running — this reintroduces some baseline cost but eliminates cold start latency for user-facing traffic.
- Run both platforms in parallel during cutover. Route a small percentage of production traffic to the new platform using DNS weighting or a load balancer split before fully decommissioning the Fargate service, so you can roll back instantly if the new platform behaves unexpectedly under real traffic.
- Re-benchmark actual cost after 30 days. List prices are estimates. Actual request patterns, average duration, and memory usage determine your real bill — pull the first full month of billing data on the new platform and compare it against your old Fargate invoice before declaring the migration a win.
AWS Fargate Pros and Cons
Pros
- Cheapest option for continuous, always-on compute at roughly $29.55 per vCPU per month equivalent
- Deep integration with existing ECS and EKS setups — no new orchestration model to learn if you’re already on AWS containers
- No execution time limit, unlike Cloud Run’s 60-minute cap
- Mature IAM task role model for fine-grained permissions per service
Cons
- No scale-to-zero — you always pay for at least one running task
- No free tier for serverless container compute
- No native Fargate GPU support (GPU workloads need EC2-backed ECS/EKS tasks instead)
- Requires a separate ALB/NLB resource for load balancing, adding setup steps and cost
Google Cloud Run Pros and Cons
Pros
- True scale-to-zero, cutting cost to near-zero for bursty or low-traffic apps
- Generous free tier: roughly 180,000 vCPU-seconds, 360,000 GB-seconds, and 2 million requests per month
- Built-in HTTPS endpoint with automatic TLS, no separate load balancer resource required
- Supports GPU-backed instances (NVIDIA L4) for AI inference workloads directly in Cloud Run
Cons
- 60-minute maximum request duration, ruling out very long-running synchronous jobs
- Cold starts on scale-from-zero can hurt latency-sensitive user-facing traffic
- Per-vCPU cost is higher than Fargate for continuous, always-on workloads
- Multi-container sidecar support is more limited than Fargate’s task-level sidecar model
Azure Container Apps Pros and Cons
Pros
- Native Dapr sidecar support, useful for teams already using Dapr for pub/sub or service invocation
- Widest regional footprint of the three, with Container Apps available in roughly 60+ Azure regions
- Offers both a Consumption (scale-to-zero) plan and a Dedicated plan with reserved workload profiles, giving more flexibility than Cloud Run’s single pricing model
- Built on Kubernetes/KEDA under the hood, easing a later migration to full AKS if a workload outgrows the managed platform
Cons
- Slightly higher per-GB memory cost than Fargate and Cloud Run in most published comparisons
- Cold start times on the Consumption plan (roughly 1–3 seconds) trail Cloud Run’s best-case cold starts for small images
- Smaller ecosystem of third-party tutorials and troubleshooting resources compared to the more established Fargate and Cloud Run
- Dedicated plan pricing requires more capacity-planning work than a purely serverless model
5 Use Cases and Which Platform Fits Best
Rather than a single universal winner, the right platform depends heavily on traffic shape and existing cloud commitments. Here are five common scenarios and the platform each one favors.
- Internal admin tool used a few hours a day: Cloud Run or Azure Container Apps, both of which drop billing to near-zero during the idle hours and both offer a free tier generous enough to run the tool at no cost.
- Public API with 24/7 sustained traffic and no idle window: AWS Fargate, since its flat per-vCPU-hour rate beats the request-based pricing of Cloud Run and Container Apps once there’s no idle time left to save on.
- AI inference endpoint needing GPU acceleration: Google Cloud Run, currently the only one of the three offering GPU-backed serverless containers (NVIDIA L4) without falling back to a full VM or GKE node pool.
- Microservices architecture already using Dapr for service mesh: Azure Container Apps, since Dapr sidecars are built into the platform rather than something you have to self-host.
- Team already running ECS in production wanting to add one more low-maintenance service: AWS Fargate, since it reuses existing ECS clusters, IAM roles, and load balancer configuration instead of introducing a second cloud platform to manage.
How to Estimate Your Own Costs
The published benchmarks above are useful directionally, but your actual bill depends on your specific request volume, average execution duration, and memory allocation. Before committing to a platform, run this back-of-envelope calculation for your own workload.
# Rough monthly cost estimate (Cloud Run / Container Apps style, request-based)
requests_per_month = 1_000_000
avg_duration_seconds = 0.5
vcpu_allocated = 0.5
memory_gb_allocated = 0.5
vcpu_price_per_second = 0.000024
memory_price_per_gb_second = 0.0000025
request_price_per_million = 0.40
vcpu_seconds = requests_per_month * avg_duration_seconds * vcpu_allocated
memory_gb_seconds = requests_per_month * avg_duration_seconds * memory_gb_allocated
compute_cost = (vcpu_seconds * vcpu_price_per_second) + (memory_gb_seconds * memory_price_per_gb_second)
request_cost = (requests_per_month / 1_000_000) * request_price_per_million
estimated_monthly_cost = compute_cost + request_cost
print(f"Estimated monthly cost: ${estimated_monthly_cost:.2f}")For Fargate, the calculation is simpler because there’s no request fee and no scale-to-zero — you’re paying for allocated vCPU and memory for however many hours the task runs, regardless of how many requests it actually served during that time.
What’s New on Each Platform in 2026
All three platforms shipped meaningful updates in the first eight months of 2026, and the changes shift the calculus slightly for teams comparing them today versus a year ago.
AWS has been pushing Fargate deeper into EKS Auto Mode, which automates node provisioning decisions that used to require manual capacity planning even on Fargate-backed EKS clusters. The practical effect is less YAML wrangling for teams running Kubernetes-native workloads who still want Fargate’s pay-per-task billing rather than managing EC2 node groups directly.
Google made Cloud Run GPU support generally available earlier in 2026, moving it out of preview and into a state where production AI inference workloads can rely on it without a waitlist. NVIDIA L4 GPU instances now spin up and scale down inside the same request-driven billing model Cloud Run has always used for CPU workloads, which is a meaningful differentiator since neither Fargate nor Container Apps offers anything quite as turnkey for GPU inference.
Microsoft has continued expanding Azure Container Apps’ Dedicated plan, adding more workload profile sizes so teams can mix Consumption (scale-to-zero) and Dedicated (reserved capacity) revisions within the same Container Apps environment. That flexibility lets a team run a bursty public-facing API on Consumption pricing while keeping a background worker on a Dedicated profile, without standing up two separate services on two different Azure products.
Tooling and Ecosystem Comparison
Pricing and scaling behavior matter, but so does how each platform fits into the rest of your toolchain — CI/CD, infrastructure as code, and monitoring.
| Tooling area | AWS Fargate | Google Cloud Run | Azure Container Apps |
|---|---|---|---|
| Infrastructure as code | CloudFormation, CDK, Terraform | Terraform, Google Cloud Deployment Manager | Bicep, ARM templates, Terraform |
| CI/CD native integration | CodePipeline, GitHub Actions | Cloud Build, GitHub Actions | Azure DevOps, GitHub Actions |
| Logging | CloudWatch Logs | Cloud Logging | Azure Monitor / Log Analytics |
| Metrics/tracing | CloudWatch Container Insights, X-Ray | Cloud Monitoring, Cloud Trace | Application Insights |
| Service mesh option | App Mesh (separate setup) | None native | Dapr (built-in) |
| Local dev/testing tool | Docker Compose + ECS CLI | Cloud Run local emulator | Azure Container Apps local dev / Dapr CLI |
| Blue/green or canary deploys | CodeDeploy for ECS | Built-in traffic splitting by revision | Built-in revision-based traffic splitting |
| Secrets management | Secrets Manager, Parameter Store | Secret Manager | Key Vault integration, native secrets store |
Cloud Run and Azure Container Apps both build traffic splitting directly into the platform, letting you shift a percentage of requests to a new revision without standing up a separate deployment tool. Fargate requires wiring up CodeDeploy separately to get equivalent blue/green behavior for ECS services, which is one more piece of infrastructure to maintain but also gives finer control if your organization already has CodeDeploy pipelines for other services.
Common Mistakes Teams Make Choosing Between These Platforms
A few recurring mistakes show up across the engineering postmortems and cost-review writeups referenced throughout this comparison.
- Choosing Fargate for a low-traffic internal tool out of habit. Teams already on AWS often default to Fargate for everything, including admin dashboards used a few hours a week — exactly the workload scale-to-zero platforms are built for. That default costs $25–$35 a month for something Cloud Run would run for $2–$5.
- Underestimating cold start impact on user-facing Cloud Run or Container Apps services. A service that scales to zero and takes several seconds to cold-start on the first request after an idle period can tank a latency-sensitive API’s p99 numbers if there’s no minimum-instance setting configured.
- Assuming request-based pricing always wins on cost. Once traffic is sustained and high-volume, the per-request fee layered on top of Cloud Run and Container Apps pricing can actually make them more expensive than Fargate’s flat per-vCPU-hour rate — the benchmarks above show all three converging at high volume, not Cloud Run pulling further ahead.
- Not accounting for the missing Fargate free tier when prototyping. Spinning up a Fargate task to test an idea racks up cost from the first hour, while the same prototype on Cloud Run or Container Apps often stays entirely within the free tier.
- Migrating stateful applications without redesigning for statelessness first. Session data stored in container memory breaks the moment a scale-to-zero platform spins up a fresh instance for the next request — this is the single most common cause of failed migrations from Fargate to Cloud Run or Container Apps.
Security and Compliance Considerations
All three platforms inherit the identity and access management model of their parent cloud, which matters when you’re deciding where regulated workloads live. Fargate tasks assume IAM roles scoped per-task, giving fine-grained control over what each container can touch in AWS — a model teams already running least-privilege ECS deployments will recognize immediately. Cloud Run services authenticate through Google Cloud service accounts and support VPC Service Controls for workloads that need network-level isolation from the public internet. Azure Container Apps integrates with Microsoft Entra ID for managed identity, and its Dapr integration extends to secure service-to-service mTLS by default within an environment.
None of the three platforms hands you a compliance certification automatically. SOC 2, HIPAA, or PCI-DSS eligibility depends on how you configure networking, logging, and secrets management within each service, not on the serverless container layer itself. Teams in regulated industries should treat the platform choice as orthogonal to the compliance work, since all three major clouds publish comparable compliance documentation for their broader infrastructure.
Observability and Debugging Differences
Debugging a scale-to-zero platform is a different experience than debugging an always-on Fargate task, and it’s worth knowing before you commit. Fargate logs flow to CloudWatch Logs by default, and because the task is always running, you can attach a shell via ECS Exec for live debugging — a workflow familiar to anyone who’s SSHed into an EC2 instance. Cloud Run streams logs to Google Cloud Logging and supports a similar exec-into-container flow, but only while an instance happens to be warm; if the service has scaled to zero, there’s nothing to attach to until the next request wakes it up. Azure Container Apps sends logs to Azure Monitor and Log Analytics, and its console-based exec works similarly to Cloud Run’s — available only against a running revision.
This has a practical consequence for on-call engineers: debugging a production incident on a scale-to-zero service sometimes means deliberately sending a request first just to spin up an instance you can then inspect. Teams that lean heavily on live debugging over structured logging may find Fargate’s always-on model easier to operate, even at a higher steady-state cost.
Support, SLAs, and Enterprise Agreements
For teams evaluating any of these platforms for a production workload with real revenue riding on it, the support tier and SLA terms matter as much as the per-vCPU pricing. All three providers publish a monthly uptime SLA for their respective container platforms, typically in the 99.9%–99.95% range for the service itself, with service credits rather than cash refunds as the standard remedy for missed targets — a common pattern across hyperscaler SLAs generally, not unique to serverless containers.
Where the platforms diverge is in how support tickets get routed. AWS Business and Enterprise support plans cover Fargate under the same umbrella as the rest of an organization’s AWS footprint, so a team already paying for Enterprise Support gets Fargate troubleshooting bundled in at no extra cost beyond their existing support contract. Google Cloud’s equivalent Premium Support tier works the same way for Cloud Run, and Azure’s equivalent Unified Support covers Container Apps alongside the rest of an Azure subscription.
The practical takeaway for procurement teams: none of the three platforms requires a separate support contract specific to serverless containers. The decision comes down to whichever cloud already holds your organization’s Enterprise Agreement, since switching primary clouds purely to get marginally better container support terms rarely pencils out against the cost of migrating everything else running on that cloud.
The Verdict: Which Platform Should You Pick
There isn’t a single winner across all three platforms — the data makes that clear. If your workload runs continuously with no meaningful idle time, AWS Fargate’s flat $29.55-per-vCPU-month equivalent beats the request-based pricing of the other two, and its deep ECS/EKS integration removes migration friction for teams already on AWS containers. If your traffic is bursty, low-volume, or has real idle windows — the majority of internal tools, side projects, and early-stage APIs — Google Cloud Run’s scale-to-zero pricing and generous free tier make it the cheapest option by a wide margin, with the June 2026 side-by-side test showing it costing roughly a fifth of Fargate for a low-traffic app.
Azure Container Apps earns its place for a narrower but real audience: teams already invested in Dapr, teams that want the option to graduate from serverless to a Dedicated Kubernetes-backed plan without switching platforms, or organizations standardized on Azure that want Container Apps’ 60-plus-region footprint. At high, sustained traffic volumes, the gap between all three narrows to a $40–$80 monthly range regardless of platform, at which point the deciding factor becomes existing cloud commitments and team familiarity rather than raw pricing.
The practical rule that emerges from the 2026 data: estimate your idle-time percentage first. Above roughly 60–70% idle time, scale-to-zero platforms win decisively. Below that, Fargate’s flat-rate model tends to come out ahead.
One more factor worth weighing before signing off on a platform: switching costs compound over time. A service that starts small on Cloud Run because it’s free tends to stay on Cloud Run even after traffic grows past the point where Fargate would technically be cheaper, simply because nobody wants to schedule a migration for a service that’s already working. Factor in engineering time, not just the sticker price on the pricing page, when the monthly gap between platforms is under $50 — the cost of the migration itself can easily exceed a year of savings.
Frequently Asked Questions
Is AWS Fargate cheaper than Google Cloud Run?
It depends on traffic pattern and whether interruptible capacity is an option. For continuous, always-on on-demand workloads, Fargate is cheaper at roughly $29.55 per vCPU per month equivalent versus $51–$63 for Cloud Run, and Fargate Spot — about $0.012–$0.024 per vCPU-hour, per nOps in June 2026 — can widen that lead further for fault-tolerant tasks that can absorb a 2-minute interruption warning, according to LeanOps Tech. For bursty or low-traffic workloads with real idle time, Cloud Run is dramatically cheaper because it scales to zero and Fargate does not: a February 2026 devstarsj.github.io benchmark put a 1 million-request-per-month Cloud Run workload at roughly $5–$15 a month.
Does Azure Container Apps really scale to zero?
Yes, on the Consumption plan. Azure Container Apps can scale down to zero running instances during idle periods, the same way Cloud Run does, and you stop paying compute costs (though you still pay for any persistent storage or configured minimum replicas) until the next request arrives.
Can I run a GPU workload on these platforms?
Google Cloud Run supports GPU-backed instances using NVIDIA L4 GPUs directly within its serverless model. Azure Container Apps offers GPU workload profiles as well. AWS Fargate does not support GPUs directly — GPU workloads on AWS containers require EC2-backed ECS or EKS tasks instead of Fargate.
What’s the maximum request duration on each platform?
Google Cloud Run caps request duration at 60 minutes. AWS Fargate and Azure Container Apps have no such hard limit on request duration since they’re designed around long-running services rather than purely per-request execution.
Do I need to know Kubernetes to use any of these platforms?
No. All three platforms are designed to abstract away the underlying orchestrator. Fargate abstracts EC2/node management from ECS or EKS, Cloud Run abstracts Knative entirely, and Azure Container Apps abstracts the Kubernetes/KEDA/Dapr stack running beneath it. You interact with each through a container image and a set of configuration options, not raw Kubernetes manifests.
Which platform has the best free tier for testing?
Google Cloud Run and Azure Container Apps both offer comparable free tiers of roughly 180,000 vCPU-seconds, 360,000 GB-seconds, and 2 million requests per month. AWS Fargate has no equivalent free tier for serverless container compute, making it the least friendly option for free testing or hobby projects.
How hard is it to migrate from Fargate to Cloud Run or vice versa?
Migration is straightforward for stateless containerized applications since all three platforms accept standard container images. The main work is rebuilding load balancer/ingress rules, remapping secrets and environment variables, and verifying your application doesn’t rely on in-memory session state that assumes a single persistent instance — see the migration guide above for the full checklist.
Which platform is best for AI/ML inference workloads?
Google Cloud Run currently has the strongest serverless story for AI inference, thanks to native NVIDIA L4 GPU support without needing a full GKE cluster. Azure Container Apps also offers GPU workload profiles. AWS Fargate is not built for GPU inference — teams needing GPUs on AWS typically use EC2-backed ECS/EKS or a dedicated service like Amazon SageMaker instead.
Related Coverage
- EKS vs AKS vs GKE: $73/mo vs Free Control Plane [2026]
- AWS RDS vs Azure Database vs Google Cloud SQL: 25% Price Gap [2026]
- Kubernetes on AWS EKS Setup: 12 Steps, 100 Min [2026]
- AWS Transit Gateway vs VPC Peering vs PrivateLink: $0.05/hr Gap [2026]
- How to Set Up AWS Lambda: 12 Steps, 90 Min [2026]
- Kubernetes vs Docker Swarm: 82% Share, 50x Node Gap [2026]
For broader context on cloud infrastructure decisions, see our cloud computing 2026 hub.
