Cloud Run vs App Runner vs Container Apps (2026): App Runner Is Closed

Most of the small services I have shipped in fourteen years never needed Kubernetes. They needed a container, an HTTPS URL, autoscaling, a rollback button and a bill that drops towards zero at night. For years that meant one of three products: Google Cloud Run, AWS App Runner or Azure Container Apps. In 2026 the trio broke up. AWS closed App Runner to new customers and pointed everyone at ECS Express Mode, Google added worker pools and Blackwell GPUs to Cloud Run, and Microsoft shipped Container Apps Express. This post compares Cloud Run vs App Runner vs Azure Container Apps (plus ECS Express Mode) as they stand today: what changed, the limits that bite, what one instance costs warm and busy, and how cold starts work.

What happened to AWS App Runner, and what replaces it?

The App Runner documentation now opens with a banner: the service is "no longer open to new customers". The availability change page says existing customers can keep using it as normal, including creating new services, and that AWS will keep investing in security and availability while adding no new features. Per Encore's write-up, AWS published the change on 31 March 2026 and the door closed on 30 April 2026. There is no shutdown date. It is maintenance mode, which means plan a move, not panic.

The recommended destination is Amazon ECS Express Mode, announced on 21 November 2025 in all regions at no extra charge. You give it a container image and two IAM roles, and one API call creates an ECS service on Fargate, an Application Load Balancer with an HTTPS listener and ACM certificate, security groups, target-tracking autoscaling and a default URL. The defaults are canary deployments, one to 20 tasks, a 60% CPU target and port 80, and the API reference adds 0.25 vCPU, 512 MiB and a /ping health check. Up to 25 Express services share one ALB through host-header rules, per the launch post.

The real difference is philosophical. App Runner hid everything; Express Mode is a generator, and every resource it creates sits in your account, visible and editable. That helps debugging and invites drift: the first console tweak to the ALB leaves a resource that neither Express Mode nor your Terraform fully owns. AWS's migration guide runs both stacks side by side, shifts Route 53 weights from 10/90 to 100/0, and keeps App Runner for 24 to 48 hours as the rollback path.

Cloud Run in 2026: services, jobs, worker pools and GPUs

Cloud Run is still the yardstick, and it now has four resource types.

Services handle requests: up to 8 vCPU and 32 GiB per instance and a 60-minute request timeout per the limits page, with concurrency defaulting to 80 per vCPU and settable to 1,000. The pricing page offers request-based billing (CPU charged while a request is in flight, plus $0.40 per million requests) or instance-based billing (the instance's whole life at a lower rate, no request fee).

Jobs run to completion, with 168-hour task timeouts GA since 11 November 2025 per the release notes and up to 10,000 tasks per execution. GPU tasks can now run for up to 12 hours, in preview since 30 October 2026. Delayed jobs, in preview since 8 September 2026, let Google defer work by up to 12 hours for $0.0000126 per vCPU-second instead of $0.000018.

Worker pools (GA 14 April 2026) are for queue consumers: no URL, no autoscaling, a fixed instance count, and a lower $0.000011244 per vCPU-second.

GPUs are routine now. The GPU docs list the NVIDIA L4 (24 GB) and RTX PRO 6000 Blackwell (96 GB, GA 13 April 2026), one per instance, instance-based billing only, scale to zero supported, and starts in about 5 seconds. The L4 needs at least 4 vCPU and 16 GiB beside it and the RTX PRO 6000 at least 20 vCPU and 80 GiB, so the GPU price is never the whole bill: $0.0001867 a second for an L4 without zonal redundancy (about $0.67 an hour) and $0.00036522 for the RTX PRO 6000 (about $1.31).

The rest of 2026 removed reasons to add a load balancer: Identity-Aware Proxy on Cloud Run (GA 13 March), multi-region failover via service health (GA 29 June) and short cloud.run custom URLs (preview, 28 September).

Azure Container Apps in 2026: consumption, Express and serverless GPUs

Azure Container Apps is Kubernetes with the Kubernetes removed, and the seams are useful. Scaling is KEDA, so you can scale on a Service Bus queue or Kafka lag as well as HTTP. Defaults: zero to 10 replicas (up to 1,000), a replica per 10 concurrent requests, and a 300-second cool-down before the last one goes.

The consumption plan is tighter than Cloud Run: 4 vCPU and 8 GiB per replica in a workload profiles environment (2 vCPU and 4 GiB in a consumption-only one), linux/amd64 images only, and a fixed 240-second request timeout. The billing docs charge a cheaper idle rate only when a replica serves no HTTP requests, uses under 0.01 vCPU and receives under 1,000 bytes a second. The monthly free grant (180,000 vCPU-seconds, 360,000 GiB-seconds, 2 million requests) matches Cloud Run's.

Serverless T4 and A100 GPUs bill per second and scale to zero in 17 regions; the Azure retail price API lists East US at $0.000073 a second for a T4 (about $0.26 an hour) and $0.000529 for an A100 (about $1.90).

The 2026 headline is Container Apps Express, which reached general availability alongside the Sandboxes layer it runs on, as InfoQ reported on 1 October. Express skips the environment step and starts from prewarmed pools. The Learn page lists what is missing (custom domains, GPUs, jobs, traffic splitting, Dapr, zone redundancy) and the quotas page caps Express apps at 30 replicas. Sandboxes are also pitched at agent code execution; I build PandaStack, a Firecracker microVM cloud for that workload, so I am not neutral there.

Serverless container limits compared

These decide whether a workload fits before price comes up.

	Cloud Run	ECS Express Mode (Fargate)	Azure Container Apps (consumption)	AWS App Runner
Open to new customers	Yes	Yes, since 21 Nov 2025	Yes; Express GA in 2026	No, closed 30 Apr 2026
Largest instance	8 vCPU, 32 GiB	32 vCPU, 244 GB	4 vCPU, 8 GiB	4 vCPU, 12 GB
Request timeout	60 min	ALB idle timeout, 60 s default, up to 4,000 s	240 s	120 s
Scale to zero	Yes	No, 1 task minimum by default	Yes, the default	No, 1 provisioned instance minimum
Scales on	Concurrency (80 per vCPU default, max 1,000)	CPU (60%), memory or ALB requests per target	HTTP concurrency (10 default) or any KEDA scaler	Concurrency (100 default, max 200)
GPUs	L4, RTX PRO 6000	None	T4, A100	None
Batch and background	Jobs (168 h tasks), worker pools	ECS tasks	Jobs	None
Sources	quotas, GPU	Fargate sizes, ALB, defaults	containers, ingress, scale	sizes, timeout, autoscaling

Two rows matter more than they look. The request timeout ends projects in week three: a long LLM stream or a report export fits in Cloud Run's 60 minutes, not in App Runner's 120 seconds or Container Apps' 240. And AWS has no scale to zero here at all: ECS has no request-driven wake-up, so a service at zero tasks stays empty until a policy or a human adds one.

Cloud Run vs ECS Express vs Container Apps pricing: idle and busy

Unit prices are hard to compare across clouds, so I normalised them: one instance with 1 vCPU and 2 GiB for 30 days, either kept warm with no traffic (a minimum instance) or fully busy. Prices come from the Cloud Run pricing page for us-central1, the Azure retail price API for East US, and the AWS price lists for App Runner, Fargate and the ALB in us-east-1, all pulled this week.

# warm_vs_busy.py: one instance, 1 vCPU + 2 GiB, for 30 days. US list prices, October 2026.
# Excludes free tiers, request fees, egress, load balancer LCUs and discounts. Python 3.13.
SECONDS = 30 * 24 * 3600  # 2,592,000
HOURS = 30 * 24           # 720
VCPU, GIB = 1, 2

prices = {
    # name: (busy $/s for 1 vCPU + 2 GiB, warm-idle $/s for the same)
    "Cloud Run, request-based (us-central1)": (
        VCPU * 0.000024 + GIB * 0.0000025,       # active rate
        VCPU * 0.0000025 + GIB * 0.0000025),     # idle rate for min instances
    "Cloud Run, instance-based (us-central1)": (
        VCPU * 0.000018 + GIB * 0.000002,        # billed whether busy or not
        VCPU * 0.000018 + GIB * 0.000002),
    "Azure Container Apps, consumption (eastus)": (
        VCPU * 0.000024 + GIB * 0.000003,        # active rate
        VCPU * 0.000003 + GIB * 0.000003),       # idle rate for min replicas
    "App Runner (us-east-1)": (
        (VCPU * 0.064 + GIB * 0.007) / 3600,     # active instance
        (GIB * 0.007) / 3600),                   # provisioned instance: memory only
    "ECS Express Mode on Fargate x86 (us-east-1)": (
        (VCPU * 0.04048 + GIB * 0.004445) / 3600,  # a task costs the same idle or busy
        (VCPU * 0.04048 + GIB * 0.004445) / 3600),
}
ALB_MONTH = 0.0225 * HOURS  # Express Mode's ALB, shareable by up to 25 services

for name, (busy, idle) in prices.items():
    print(f"{name:46s} warm idle ${idle * SECONDS:6.2f}   busy ${busy * SECONDS:6.2f}")
print(f"{'+ one Application Load Balancer, hourly fee':46s} ${ALB_MONTH:.2f} a month")

# Output:
# Cloud Run, request-based (us-central1)         warm idle $ 19.44   busy $ 75.17
# Cloud Run, instance-based (us-central1)        warm idle $ 57.02   busy $ 57.02
# Azure Container Apps, consumption (eastus)     warm idle $ 23.33   busy $ 77.76
# App Runner (us-east-1)                         warm idle $ 10.08   busy $ 56.16
# ECS Express Mode on Fargate x86 (us-east-1)    warm idle $ 35.55   busy $ 35.55
# + one Application Load Balancer, hourly fee    $16.20 a month

Three things fall out of this.

First, the cheapest platform to keep warm is the one you can no longer join. App Runner bills an inactive provisioned instance for memory only, $10.08 a month here, which is a real reason for existing customers with many quiet services not to rush.

Second, Fargate is cheapest when genuinely busy ($35.55) but has the highest floor: one task minimum plus $16.20 a month for the ALB before LCUs. Shared by 25 services, the ALB is about 65 cents each; for one service it is almost half the bill.

Third, busy on Cloud Run and Container Apps means at least one request open, not CPU at 100%. Cloud Run bills request-based time from the start of the first request to the end of the last, and Azure only counts a replica idle when it serves no HTTP requests. In the AI era that matters: an endpoint streaming LLM tokens or holding server-sent events open pays the active rate for the whole stream, however little CPU it burns. For an always-on Cloud Run instance of this size, instance-based billing wins once a request is open more than about 67% of the time. Switch billing modes before you optimise code.

For Lambda, Workers and Vercel on the same unit of work, see Serverless in 2026.

Cold starts in 2026: which platforms scale to zero?

No vendor publishes cold-start numbers comparable across clouds, and as I argued in Sandbox Creation Time Benchmarks Measure Different Things, the stopwatch rarely starts in the same place twice. The docs do describe the mechanisms.

Cloud Run scales to zero by default, and the tips page says image streaming makes image size irrelevant to startup time. Startup CPU boost is on by default for new services per the gcloud reference, and the container contract allows four minutes to start listening. To avoid cold starts, pay for one minimum instance at the idle rate ($19.44 above).

Azure Container Apps also scales to zero by default. Its cold-start guide lists the levers (smaller images, a same-region registry, model files on a storage mount; the GPU docs add artifact streaming from a Premium registry) and even suggests a scheduled job to wake the app before 9am, which tells you how long a cold start can be.

ECS Express Mode has no scale from zero, so the cold start that matters is scale-out. A new Fargate task waits for its image unless it has a SOCI index for lazy loading, which the Fargate docs recommend above 250 MiB compressed.

App Runner keeps at least one provisioned instance whose memory you pay for and activates it on traffic, which is why it felt fast and why its warm price is so low.

Which serverless container platform should you choose?

• Starting fresh: Cloud Run. Largest instances, longest timeout, real scale to zero (GPUs included), plus jobs and worker pools.
• An AWS shop: ECS Express Mode, managed as code (there is an AWS::ECS::ExpressGatewayService CloudFormation resource) so nobody fixes the ALB by hand. For spiky, mostly idle HTTP apps, Lambda is still the AWS answer to scale to zero.
• An Azure shop: Container Apps on a workload profiles environment for VNets, GPUs, jobs or traffic splitting; Express for internal tools happy on an azurecontainerapps.io hostname.
• Already on App Runner: nothing forces a move this quarter. Inventory each service's port, variables, domain and certificate, build the Express Mode version in code, and move the quiet services last.

Whichever you pick, the hard parts are not the platform: an identity per service, images built and scanned in CI, one-command rollbacks and a budget alert. My guide to deploying Cloud Run with GitHub Actions sets that up with Workload Identity Federation and no long-lived keys. When your list of needs outgrows these platforms, that is usually when Kubernetes starts to pay for itself.

FAQ

Is AWS App Runner being discontinued?

App Runner closed to new customers on 30 April 2026 but is not shut down. Existing customers can keep using it, including creating new services, and AWS will maintain security and availability without new features. AWS recommends ECS Express Mode and publishes a DNS-based migration guide.

What is the AWS equivalent of Google Cloud Run?

The closest is ECS Express Mode, which turns a container image into a Fargate service behind a load balancer with one API call. Unlike Cloud Run it does not scale to zero and creates visible resources in your account. For scale to zero on AWS, Lambda is the nearer match.

Is Cloud Run cheaper than Azure Container Apps?

At list price they are close: both charge $0.000024 per active vCPU-second and $0.40 per million requests, with the same free grant. Cloud Run's memory is slightly cheaper ($0.0000025 versus $0.000003 per GiB-second) and its instance-based billing is cheaper for instances that almost always have a request open.

Can ECS Express Mode scale to zero?

Not the way Cloud Run does. Express Mode creates an ECS service with a default minimum of one task and target-tracking scaling on CPU, memory or ALB requests. At zero tasks nothing wakes it when a request arrives, so budget for one task plus the shared load balancer.

This quarter I would do three things. Put new HTTP services that do not need AWS or Azure on Cloud Run, instance-based for the always-on ones and request-based for the rest. For App Runner estates, write the Express Mode version in Terraform and migrate the busiest services first, where Fargate's lower active price pays for the ALB. And check the billing mode of every endpoint that streams model output, because that one setting moves the bill more than any code change I could make.

Related: Serverless in 2026: Lambda vs Cloud Run vs Workers, and When It Costs More, What Scale to Zero Cost Me to Build: 50s Sleeps, 14s Wakes and Is Kubernetes Still Worth It in 2026? v1.37, 82% in Production, Real Costs.