App Engine vs. Cloud Run: Google hat sich entschieden. Ihre Rechnung vielleicht nicht

Auf der Seite, die bei der Wahl der App-Engine-Umgebung helfen soll, hat Google einen Kasten ergänzt. Darin steht:

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.

Das ist Google, in der App-Engine-Dokumentation, mit dem Rat, etwas anderes zu nehmen. Derselbe Hinweis steht auf der offiziellen Vergleichsseite. Nach über einem Jahrzehnt hat die Plattform, die Serverless definiert hat, einen empfohlenen Nachfolger — und Google hält damit nicht mehr hinterm Berg.

Die naheliegende nächste Frage ist, ob Sie wechseln sollten. Die naheliegende Annahme — Cloud Run ist neuer, also günstiger — erweist sich auf eine konkrete und nützliche Weise als falsch.

Was aus Cloud Run geworden ist

Ein Grund, warum die Empfehlung Sinn ergibt: Cloud Run ist längst nicht mehr nur „Container hinter einer URL“. Es gibt inzwischen vier Ressourcentypen:

• Services — HTTP-Endpunkte, automatisch oder manuell skaliert, das direkte App-Engine-Äquivalent
• Jobs — laufen bis zur Fertigstellung, nach Zeitplan oder auf Abruf, mit Array-Jobs für parallele Tasks
• Worker Pools — dauerhaft laufende Hintergrund-Consumer für Kafka, Pub/Sub Pull und RabbitMQ, ganz ohne HTTP-Endpunkt
• Instances (Preview) — ein einzelner, langlebiger und einzeln adressierbarer Container für Agenten und zustandsbehaftete Workflows, bereitgestellt in etwa 20 Sekunden

App Engine deckt im Wesentlichen den ersten Punkt ab. Googles eigene Formulierung: Cloud Run laufe „auf weitgehend derselben Infrastruktur wie App Engine standard“ und vereine das Beste beider App-Engine-Umgebungen. Das ist zutreffend und erklärt, warum die Migration größtenteils mechanisch ist — bis zu dem Punkt, an dem sie es nicht mehr ist.

„At lower prices“, nachgerechnet

Liest man den Hinweis genau, leistet die Formulierung viel Arbeit. GPUs sind tatsächlich eine Cloud-Run-Fähigkeit, die App Engine nie hatte, in keiner Umgebung. Die meisten werden „at lower prices“ aber als „Cloud Run ist günstiger“ lesen — also prüfen wir das direkt.

Derselbe Workload — eine dauerhaft laufende Instanz mit 1 vCPU und 1 GiB — nach den veröffentlichten Tabellen für us-central1:

App Engine flexible: 0,0526 $ je vCPU-Stunde plus 0,0071 $ je GiB-Stunde. Cloud Run instanzbasiert: 0,000018 $ je vCPU-Sekunde plus 0,000002 $ je GiB-Sekunde. Geprüft am 7. September 2026.

Zum Listenpreis kostet Cloud Run rund 21 Prozent mehr pro Stunde als App Engine flexible für dieselbe dauerhaft laufende Instanz. Googles eigene Vergleichstabelle sagt das unumwunden, wenn man die Zeile liest: flexible 0,0526 $ je vCPU, Cloud Run 0,0648 $.

Woher kommt die Ersparnis also? Aus zwei Richtungen, denen App Engine nicht folgen kann:

Scale to Zero. App Engine flexible hat ein Minimum von einer Instanz und kann nicht auf null skalieren. Cloud Run schon. Wenn Ihr Dienst zwei Drittel des Tages im Leerlauf ist, findet der obige Vergleich nie statt — Sie zahlen schlicht nicht. (App Engine standard skaliert ebenfalls auf null, und bleibt deshalb eine echte Option.)

Committed Use Discounts. App Engine bietet keine. Cloud Run ist sowohl für Cloud-Run-CUDs als auch für Compute Flexible CUDs qualifiziert, und Letztere bündeln über GKE, Compute Engine und Cloud Run hinweg. Ein Dreijahres-Commitment landet 35 Prozent unter dem Normalpreis von App Engine flexible.

Die ehrliche Zusammenfassung: Cloud Run ist günstiger bei sprunghaftem Traffic oder wenn Sie sich binden wollen. Es ist teurer, wenn Sie eine Instanz zum Listenpreis unter Dauerlast fahren. Das ist ein echter Zielkonflikt, und der Hinweis verrät Ihnen nicht, auf welcher Seite Sie stehen.

Die Free Tiers haben unterschiedliche Formen

Das verdient eine eigene Notiz, denn hier entscheiden sich Hobbyprojekte und interne Tools.

Das sind keine vergleichbaren Einheiten. App Engine zählt Instanzstunden einer Klasse, deren vCPU-Äquivalenz Google selbst als ungefähr kennzeichnet; Cloud Run zählt Ressourcensekunden. Wer hier ein sauberes „X ist großzügiger“ präsentiert, übergeht das. Rechnen Sie beides gegen Ihr eigenes Profil.

Ein struktureller Unterschied zählt allerdings: Der Free Tier von App Engine gilt pro Projekt, der von Cloud Run pro Rechnungskonto, projektübergreifend aggregiert. Wer viele kleine Projekte betreibt, dreht damit die Rechnung um.

Wo App Engine weiterhin gewinnt

Nicht an vielen Stellen, aber an scharfen.

Reine Instanzgröße. Cloud Run endet bei 8 vCPU und 32 GiB. App Engine flexible geht bis 80 vCPU mit bis zu 6,5 GB je vCPU. Für einen großen Einzelinstanz-Workload ist der Wechsel zu Cloud Run ein Rückschritt, den keine Konfiguration heilt.

Gebündelte Legacy-Dienste. App Engine standard gibt Java-, Python-, Go- und PHP-Anwendungen Memcache, Task Queues, die Search API, Blobstore, Users und Images. Cloud Run hat nichts davon. Das ist die eigentliche Migrationsmauer — Umbau an der Anwendung, kein erneutes Deployment.

Automatische Health Checks. App Engine führt Readiness- und Liveness-Prüfungen für Sie durch. Auf Cloud Run definieren Sie Startup- und Liveness-Probes selbst — mehr Kontrolle, mehr Fehlerquellen.

Versions-URLs gratis. App Engine stellt Service- und Versions-URLs automatisch bereit. Bei Cloud Run sind nur Service-URLs exponiert; eine bestimmte Revision anzusprechen erfordert einen konfigurierten Traffic-Tag.

Eine Region, eine Anwendung. Jeder App-Engine-Service eines Projekts liegt in derselben Region, unter einer übergeordneten Anwendung mit einem default-Service. Cloud Run kennt keine Anwendungsressource, Services können in verschiedenen Regionen liegen. Das ist flexibler und ein Leitplanke weniger — derselbe Zielkonflikt, über den ich in was in eine Cloud Landing Zone gehört geschrieben habe.

Fünf Dinge, die am Migrationstag brechen

1. Die Concurrency springt von 10 auf 80. App Engine standard nutzt standardmäßig 10 gleichzeitige Requests pro Instanz, Cloud Run 80. Wer eine nicht threadsichere Anwendung unverändert übernimmt, sieht sie am ersten Tag unter Last brechen. Googles Empfehlung: entweder von 80 aus lasttesten oder mit Ihrem bekannten Wert 10 starten — Letzteres ist sicher, lastet Instanzen aber schlecht aus und kostet mehr.

2. Zwischen Requests wird die CPU gedrosselt. In App Engine standard ist CPU unabhängig vom Skalierungstyp durchgehend verfügbar. Bei requestbasierter Abrechnung in Cloud Run gibt es CPU während der Request-Verarbeitung, sonst gedrosselt. Background-Threads, In-Process-Scheduler und gepufferte Writer bleiben stehen. Die Lösung ist instanzbasierte Abrechnung — zufällig genau das Preismodell aus der Tabelle oben.

3. Die Deploy-Semantik dreht sich um. Jedes App-Engine-Deployment wendet die vollständige app.yaml an, und alles Nicht-Angegebene fällt auf Defaults zurück — ein Deployment ohne instance_class und Sie sind zurück auf F1. Cloud Run macht das Gegenteil: Nicht angegebene Einstellungen behalten die Werte der vorherigen Revision. Beide Verhalten überraschen Leute in jeweils beide Richtungen.

4. Ihr Entrypoint kann verschwinden. Cloud Runs Source-Deployments nutzen Buildpacks, und manche Sprachen haben keinen Default-Entrypoint. Python braucht ein Procfile oder die Build-Variable GOOGLE_ENTRYPOINT, und bei gcloud run deploy --source funktioniert ausschließlich die Procfile-Methode. Sonst schlägt der Build schlicht fehl.

5. Static-File-Handler gibt es nicht mehr. App Engine standard kann statische Inhalte über app.yaml-Handler ausliefern, ohne die Anwendung zu berühren. Cloud Run hat kein Äquivalent — liefern Sie sie wie dynamische Inhalte aus dem Container aus oder verschieben Sie sie nach Cloud Storage.

Zwei kleinere Punkte: Revisionen sind unveränderlich, Namen lassen sich also nicht wie App-Engine-Versions-IDs wiederverwenden, und aus GAE_SERVICE / GAE_VERSION werden K_SERVICE / K_REVISION.

Also welches

Wenn Ihre Antwort lautet „wir sollten ohnehin auf Kubernetes“, ist das ein anderes Gespräch — worin sich die Managed Control Planes wirklich unterscheiden, steht in was EKS, AKS und GKE wirklich verwalten.

Das Fazit

Google windet sich nicht mehr: Neues gehört auf Cloud Run, und die Dokumentation sagt das jetzt im App-Engine-Bereich. Die Empfehlung ist fundiert, und Cloud Runs vier Ressourcentypen decken tatsächlich mehr ab, als App Engine je konnte.

Aber „at lower prices“ ist eine Aussage über Zugang zu Fähigkeiten, kein Versprechen für Ihre Rechnung. Rechnen Sie mit Ihrem eigenen Traffic-Profil, bevor Sie eine Migration planen — denn die beiden Dinge, die Cloud Run günstiger machen, Skalierung auf null und ein mehrjähriges Commitment, sind genau die beiden Dinge, die ein konstanter, ungebundener Workload nicht tut.

Und wenn Ihre App-Engine-Anwendung auf gebündelten Diensten aufsitzt, sind die Kosten ohnehin nicht Ihr Problem. Der Umbau ist es.