---
title: "App Engine vs Cloud Run: Google Picked a Side. Your Bill Might Not Agree"
description: "Google now tells new users to pick Cloud Run over App Engine, in the App Engine docs. But at list price an always-on Cloud Run instance costs more per vCPU-hour than App Engine flexible. Here is where the savings actually come from, and what breaks on migration day."
author: Aleksei Aleinikov
date: 2026-09-07
lang: en
tags: [app-engine, cloud-run, google-cloud, serverless, cloud-migration, cloud-cost-optimization]
canonical: https://www.alekseialeinikov.com/en/blog/topics/cloud/app-engine-vs-cloud-run-2026
source: alekseialeinikov.com
---

# App Engine vs Cloud Run: Google Picked a Side. Your Bill Might Not Agree

Somewhere on the page that helps you choose an App Engine environment, Google added a box. It reads:

> For new Google Cloud users, we recommend using Cloud Run as the preferred alternative over App Engine. Cloud Run is a fully managed, modern application hosting platform that provides access to advanced capabilities, such as GPUs, at lower prices.

That is Google, in the App Engine documentation, telling you to use something else. The same banner appears on the official comparison page. After more than a decade, the platform that defined serverless has a recommended successor, and Google has stopped being coy about it.

The obvious next question is whether you should move. The obvious assumption — Cloud Run is newer, so it is cheaper — turns out to be wrong in a specific and useful way.

![App Engine vs Cloud Run in 2026: Google now recommends Cloud Run for new users.](https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-2026.webp)

## What Cloud Run turned into

Part of why the recommendation makes sense is that Cloud Run is no longer just "containers behind a URL". It now has four resource types:

- **Services** — HTTP endpoints, autoscaled or manually scaled, the direct App Engine equivalent
- **Jobs** — run to completion, on a schedule or on demand, with array jobs for parallel tasks
- **Worker pools** — always-on background consumers for Kafka, Pub/Sub pull, RabbitMQ, with no HTTP endpoint at all
- **Instances** (Preview) — a single long-lived, individually addressable container, aimed at agents and stateful workflows, provisioned in about 20 seconds

App Engine covers roughly the first of those. Google's own framing is that Cloud Run "runs on much of the same infrastructure as App Engine standard environment" while absorbing the best of both App Engine environments. That is a fair description, and it explains why the migration is mostly mechanical — right up until it isn't.

## "At lower prices", checked

Read the banner precisely and you will notice the phrase is doing a lot of work. GPUs genuinely are a Cloud Run capability that App Engine has never had, in either environment. But most people will read "at lower prices" as "Cloud Run is cheaper", so let us test that directly.

Here is the same workload — one always-on instance, 1 vCPU and 1 GiB — priced from the published tables in us-central1:

| Option | Per hour | Per month (730 h) |
| --- | --- | --- |
| App Engine flexible | $0.0597 | $43.58 |
| **Cloud Run, list price** | **$0.0720** | **$52.56** |
| Cloud Run, 1-year CUD | $0.0598 | $43.62 |
| Cloud Run, 3-year Compute Flexible CUD | $0.0389 | $28.38 |

*App Engine flexible: $0.0526 per vCPU-hour plus $0.0071 per GiB-hour. Cloud Run instance-based: $0.000018 per vCPU-second plus $0.000002 per GiB-second. Checked 7 September 2026.*

At list price, **Cloud Run costs about 21 percent more per hour than App Engine flexible for the same always-on instance.** Google's own comparison table states this plainly if you read the row: flexible is $0.0526 per vCPU, Cloud Run is $0.0648.

So where does the saving come from? Two places App Engine cannot follow:

**Scale to zero.** App Engine flexible has a minimum of one instance and cannot scale to zero. Cloud Run can. If your service is idle two thirds of the day, the comparison above never happens — you simply stop paying. (App Engine *standard* also scales to zero, which is why it remains a real option.)

**Committed use discounts.** App Engine offers none. Cloud Run is eligible for both Cloud Run CUDs and Compute Flexible CUDs, and the latter pool across GKE, Compute Engine and Cloud Run. A three-year commitment lands 35 percent below App Engine flexible's undiscounted rate.

The honest summary: Cloud Run is cheaper when your traffic is spiky, or when you are willing to commit. It is more expensive when you run one instance flat out at list price. That is a real trade-off, and the banner does not tell you which side you are on.

![Cost comparison: Cloud Run costs more at list price but wins through scale-to-zero and committed use discounts.](https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-cost-2026.webp)

## The free tiers are different shapes

Worth its own note, because this is where hobby projects and internal tools get decided.

| | Free allowance |
| --- | --- |
| App Engine standard, F classes | 28 instance-hours per day, per project |
| App Engine standard, B classes | 9 instance-hours per day, per project |
| App Engine flexible | None |
| Cloud Run, instance-based | 240,000 vCPU-seconds + 450,000 GiB-seconds per month |
| Cloud Run, request-based | 180,000 vCPU-s + 360,000 GiB-s + 2M requests per month |

These are not comparable units. App Engine counts instance-hours of a class whose vCPU equivalence Google itself marks as approximate; Cloud Run counts resource-seconds. Anyone presenting a clean "X is more generous" verdict is glossing over that. Price both against your own shape.

One structural difference does matter: App Engine's free tier is **per project**, Cloud Run's is **per billing account, aggregated across projects**. If you run many small projects, that flips the arithmetic.

## Where App Engine still wins

Not many places, but they are sharp.

**Raw instance size.** Cloud Run tops out at 8 vCPU and 32 GiB. App Engine flexible goes to 80 vCPU with up to 6.5 GB per vCPU. For a big single-instance workload, moving to Cloud Run is a downgrade you cannot configure your way out of.

**Legacy bundled services.** App Engine standard gives Java, Python, Go and PHP apps Memcache, Task Queues, the Search API, Blobstore, Users and Images. Cloud Run has none of these. This is the actual migration wall, and it is application rework rather than a redeploy.

**Automatic health checks.** App Engine performs readiness and liveness checks for you. On Cloud Run you define startup and liveness probes explicitly — more control, more to get wrong.

**Version URLs for free.** App Engine exposes both service and version URLs automatically. In Cloud Run only service URLs are exposed; addressing a specific revision requires configuring a traffic tag.

**One region, one application.** Every App Engine service in a project lives in the same region, under a top-level application with a `default` service. Cloud Run has no application resource and services can sit in different regions. That is more flexible and one less guardrail — the same trade-off I wrote about in [what belongs in a cloud landing zone](https://www.alekseialeinikov.com/en/blog/topics/cloud/what-belongs-in-a-cloud-landing-zone-2026).

## Five things that break on migration day

![Migration mapping: what ports cleanly from App Engine to Cloud Run and what has no equivalent.](https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-migration-2026.webp)

**1. Concurrency goes from 10 to 80.** App Engine standard defaults to 10 concurrent requests per instance; Cloud Run defaults to 80. Lift and shift a non-thread-safe app and it breaks under load on day one. Google's guidance is either to load-test up from 80 or to start at your known-good 10 — the latter is safe but will under-utilise instances and cost you more.

**2. CPU is throttled between requests.** In App Engine standard, CPU is continuously available regardless of scaling type. With Cloud Run request-based billing, CPU is allocated during request processing and throttled otherwise. Background threads, in-process schedulers and buffered writers all stall. The fix is instance-based billing, which also happens to be the pricing model in the table above.

**3. Deploy semantics invert.** Every App Engine deploy applies the full `app.yaml`, and anything unspecified reverts to a default — deploy without `instance_class` and you are back on F1. Cloud Run does the opposite: unspecified settings keep the previous revision's values. Both behaviours surprise people moving in either direction.

**4. Your entrypoint may vanish.** Cloud Run's source deployments use buildpacks, and some languages have no default entrypoint. Python needs a `Procfile` or the `GOOGLE_ENTRYPOINT` build variable, and when using `gcloud run deploy --source` only the `Procfile` method works. Otherwise the build simply fails.

**5. Static file handlers are gone.** App Engine standard can serve static content through `app.yaml` handlers without touching your app. Cloud Run has no equivalent — serve it from the container like dynamic content, or move it to Cloud Storage.

Two smaller ones worth knowing: revisions are immutable so you cannot reuse names the way you reuse App Engine version IDs, and `GAE_SERVICE` / `GAE_VERSION` become `K_SERVICE` / `K_REVISION`.

## So which one

| Your situation | Pick |
| --- | --- |
| New project, any shape | **Cloud Run** — this is Google's recommendation and the product getting investment |
| Spiky or low traffic | **Cloud Run** — scale to zero is the whole argument |
| Steady 24/7 load, no commitment | **App Engine flexible** is cheaper at list price, but check a CUD first |
| Steady load, willing to commit | **Cloud Run** with a 3-year Compute Flexible CUD, ~35% below flexible |
| Needs more than 8 vCPU per instance | **App Engine flexible** — Cloud Run cannot go there |
| Needs GPUs | **Cloud Run** — App Engine has none |
| Heavy use of bundled services | **Stay** until you have budgeted the rework |
| Background queue consumers | **Cloud Run worker pools** — cheaper per vCPU-second than services |
| Hobby project, one project | **App Engine standard** free tier is still hard to beat |

If your answer is "we should probably be on Kubernetes anyway", that is a different conversation — I covered where the managed control planes actually differ in [what EKS, AKS and GKE actually manage](https://www.alekseialeinikov.com/en/blog/topics/cloud/managed-kubernetes-what-eks-aks-gke-actually-manage-2026).

## The bottom line

Google has stopped hedging: new work belongs on Cloud Run, and the docs now say so in the App Engine section. That guidance is sound, and Cloud Run's four resource types genuinely cover more ground than App Engine ever did.

But "at lower prices" is a claim about capability access, not a promise about your invoice. Run the numbers for your own traffic shape before you plan a migration, because the two things that make Cloud Run cheaper — scaling to zero and committing for years — are exactly the two things a steady, uncommitted workload does not do.

And if your App Engine app leans on bundled services, cost is not your problem at all. Rework is.