Cloud Run Kosten sind vCPU-Sekunden und GiB-Sekunden Arbeitsspeicher je Instanz, auf 100 Millisekunden aufgerundet, nach einem von zwei Abrechnungsmodellen: anfragebasiert, wo eine Instanz ihren aktiven Satz nur zahlt, während sie Anfragen bearbeitet, und einen Leerlaufsatz, während eine Mindestinstanz wartet, plus ein Preis je Million Anfragen; oder instanzbasiert, wo die Instanz einen niedrigeren Satz für jede Sekunde ihres Bestehens zahlt, Anfragen inklusive. Jobs und Worker-Pools zahlen eigene Sekundensätze, eine monatliche Freimenge deckt kleine Dienste, und Netz, flüchtiger Speicher und GPUs kommen obendrauf. Cloud Run Functions sind Cloud-Run-Dienste und zahlen dasselbe. Auf der Rechnung dominieren die Mindestinstanzen bei Diensten, die warm gehalten werden, die CPU-Sekunden bei Diensten, die ausgelastet sind, und der Egress bei Diensten, die große Antworten liefern.
Preisdimensionen
Google verkauft Cloud Run je Sekunde des Bestehens oder der Aktivität einer Instanz, nie je Container; jeder Satz hat seine eigene SKU je Region, und Frankfurt liegt in der teureren der zwei Preisstufen.
| Dimension | Einheit | Was sie treibt | Optional |
|---|---|---|---|
| Anfragebasierte Abrechnung | vCPU-Sekunde und GiB-Sekunde, während eine Instanz Anfragen bearbeitet, zum aktiven Satz; ein niedrigerer Leerlaufsatz für CPU und Speicher, während eine Mindestinstanz wartet; USD je Million Anfragen | Dienste, deren CPU nur während Anfragen zugeteilt ist | Ja, die Vorgabe für Dienste |
| Instanzbasierte Abrechnung | vCPU-Sekunde und GiB-Sekunde für jede Sekunde des Bestehens einer Instanz, zu einem niedrigeren Satz als aktiv, Anfragen frei | Dienste mit dauerhaft zugeteilter CPU, Hintergrundarbeit, WebSockets | Ja |
| Mindestinstanzen | Der Leerlaufsatz je vCPU-Sekunde und GiB-Sekunde für Instanzen, die ohne Anfrage warm gehalten werden; Instanzen, die der Autoscaler über das Minimum hinaus hält, zahlen keinen Leerlauf | Dienste, die ohne Kaltstart antworten müssen | Ja |
| Jobs | vCPU-Sekunde und GiB-Sekunde der Job-Tasks zu eigenem Satz | Batch- und geplante Arbeit | Ja |
| Worker-Pools | vCPU-Sekunde und GiB-Sekunde der Pool-Instanzen zu eigenem Satz, keine Anfragen | Queue-Konsumenten und lang laufende Worker | Ja |
| Freimenge | 180.000 vCPU-Sekunden, 360.000 GiB-Sekunden und 2 Millionen Anfragen im Monat zu anfragebasierten Sätzen, 240.000 vCPU-Sekunden und 450.000 GiB-Sekunden zu instanzbasierten und Job-Sätzen, bewertet zum Satz von us-central1 | Jedes Rechnungskonto, einmal im Monat über seine Dienste | Ja |
| GPUs | GPU-Sekunde je angeschlossenem Beschleuniger, solange die Instanz besteht, mit dauerhaft zugeteilter CPU | Inferenzdienste mit einer L4 | Ja |
| Flüchtiger Speicher | GiB-Stunde für flüchtigen Speicher im Arbeitsspeicher oder auf Datenträger über den Arbeitsspeicher hinaus | Dienste, die große temporäre Dateien schreiben | Ja |
| Netzwerk | Ausgehender Internetverkehr zu Netzwerksätzen, mit 1 GiB frei innerhalb Nordamerikas im Monat; eingehend frei; zu anderen Google-Cloud-Diensten in der Region frei | Antworten und Aufrufe aus der Region hinaus | Ja (Netzwerkpreise) |
| Kaufoption | Flexible Committed Use Discounts über ein oder drei Jahre decken Cloud-Run-CPU und -Speicher, 17 und 46 Prozent günstiger in Frankfurt am Lesedatum | Gleichmäßige Last | Ja (Google Cloud Committed Use Discounts) |
Das Abrechnungsmodell ist die Entscheidung: Anfragebasiert zahlt rund 55 Prozent mehr je vCPU-Sekunde als instanzbasiert, aber nur für die Sekunden, in denen eine Anfrage läuft, so dass ein Dienst, der alle paar Sekunden eine Anfrage beantwortet, einen Bruchteil des Lebens seiner Instanz zahlt, während ein Dienst, der die meiste Zeit beschäftigt ist, mehr zahlt als mit instanzbasierter Abrechnung, wo jede Sekunde zum niedrigeren Satz zählt. Mindestinstanzen ändern die Rechnung: Eine warme Instanz zahlt jede Wartesekunde den Leerlaufsatz, rund ein Zehntel des aktiven Satzes für CPU und den vollen Satz für Speicher, so dass ein Minimum von einer Instanz mit 1 vCPU und 512 MiB wenige Dollar im Monat kostet und ein Minimum von zehn mit 4 vCPUs und 16 GiB Hunderte. Die Nebenläufigkeit ist der verborgene Hebel: Eine Instanz, die 80 Anfragen zugleich bearbeitet, zahlt ihre Sekunden einmal, eine auf eine Anfrage begrenzte zahlt sie je Anfrage. Cloud Run Functions sind seit der Zusammenführung der zweiten Generation mit Cloud Run Dienste und zahlen nach denselben Modellen, mit Nebenläufigkeit eins als Vorgabe bei Funktionen, die für eine Anfrage zugleich geschrieben sind. Die Mechanik aller drei Anbieter erklärt Serverlose Funktionen; was die Wahl zwischen Container und VM kostet, Architekturentscheidungen und Kosten.
So erscheint es in den Abrechnungsdaten
Im Abrechnungsexport tragen die Zeilen service.description Cloud Run und eine sku.description je Ressource, Modell und Region: Cloud Run CPU Allocation Time (europe-west3) und Cloud Run Memory Allocation Time (europe-west3) für anfragebasierte aktive Zeit, Cloud Run Idle CPU Allocation Time und Cloud Run Idle Memory Allocation Time für Mindestinstanzen, Cloud Run Requests je Million, Cloud Run Services CPU Always Allocated und Memory Always Allocated für instanzbasierte Abrechnung, Cloud Run Jobs CPU und Cloud Run Jobs Memory für Jobs, Cloud Run Worker Pools CPU für Worker-Pools, Cloud Run GPU L4 je Sekunde; usage.unit ist Sekunde für vCPU, Gibibyte-Sekunde für Speicher und Anzahl für Anfragen. resource.name im Export mit Ressourcendetails nennt Dienst, Job oder Worker-Pool, und die Labels des Dienstes in labels sind die Zuordnung je Team; eine über die Functions-API bereitgestellte Funktion trägt die Labels, die das Deployment gesetzt hat. Die Freimenge erscheint als credits.type FREE_TIER neben den Zeilen, die sie ausgleicht, zum Satz von us-central1, so dass sie in Frankfurt weniger Sekunden deckt, als ihr Name sagt.
Ein flexibles Commitment, das Cloud Run deckt, erscheint als COMMITTED_USAGE_DISCOUNT neben den CPU- und Speicherzeilen; einen Nutzungsrabatt gibt es nicht. Den Aufbau des Exports beschreibt Google-Cloud-Abrechnungsexport; im FOCUS-Export trägt ServiceName Cloud Run, ServiceCategory Compute, SkuId die SKU und ChargeCategory Usage (FOCUS-Spalten). Was der Export nicht zeigt, ist, warum die Sekunden berechnet wurden: Die Metriken des Dienstes, abrechenbare Instanzzeit je Zustand, Zahl der Containerinstanzen und Anfragen, trennen aktiv von Leerlauf und beschäftigt von wartend.
Stellhebel
Konfiguration: Der erste Hebel ist das Abrechnungsmodell je Dienst, anfragebasiert für Dienste, die zwischen Anfragen warten, und instanzbasiert für Dienste, die dauernd arbeiten oder Hintergrund-Threads fahren; der zweite die Nebenläufigkeit, weil eine Instanz, die viele Anfragen zugleich bedient, ihre Sekunden einmal zahlt, und eine Nebenläufigkeit von eins auf einem Dienst, der 50 vertrüge, die Instanzen vervielfacht; der dritte die Zahl der Mindestinstanzen, weil jede warme Instanz den ganzen Monat Leerlaufsekunden zahlt und ein Minimum von null stattdessen einen Kaltstart kostet. Die Instanzgröße ist der vierte: CPU und Speicher zahlen je Sekunde proportional, und ein Dienst mit 2 vCPUs, der eine nutzt, zahlt das Doppelte (Rightsizing).
Kaufoption: Der flexible Committed Use Discount deckt Cloud Run, Compute Engine und GKE in einer Ausgabenzusage, was ihn zum Weg macht, eine gleichmäßige Cloud-Run-Grundlast zu rabattieren, ohne sich auf einen Dienst festzulegen (Commitment-Strategie).
Architektur: Jobs für Batch-Arbeit statt eines Dienstes, der abfragt, Worker-Pools für Queue-Konsumenten statt eines Dienstes mit Mindestinstanz, und eine VM oder GKE für Dienste, die rund um die Uhr unter Volllast laufen, wo instanzbasiertes Cloud Run rund das Doppelte einer E2-vCPU auf Compute Engine kostet (Compute-Engine-Preise, Google-Kubernetes-Engine-Preise). Antworten hinter einem CDN, wo sie sich wiederholen, weil Egress je GiB zahlt.
Wo es schiefgeht
- Zehn warme Instanzen für eine Anfrage je Minute. Mindestinstanzen zahlen den ganzen Monat Leerlaufsekunden.
Idle CPU Allocation Timeneben einer kleinen Anfragezahl ist der Hinweis; ein Minimum von eins, oder null mit einem Kaltstart, den die Nutzer vertragen. - Nebenläufigkeit eins auf einem Webdienst. Jede Anfrage bekommt ihre eigene Instanz und ihre eigenen Sekunden. Die Einstellung vervielfacht oder teilt die Rechnung, ohne den Code zu ändern.
- Anfragebasierte Abrechnung auf einem ausgelasteten Dienst. Ein Dienst, der 90 Prozent der Zeit Anfragen bearbeitet, zahlt den aktiven Satz für fast sein ganzes Leben; instanzbasiert ist ab rund zwei Dritteln Auslastung günstiger.
- Der Hintergrund-Thread wird nicht berechnet, bis er es wird. Anfragebasiert wird die CPU zwischen Anfragen gedrosselt; Arbeit, die zwischen Anfragen laufen muss, braucht instanzbasierte Abrechnung, und dann zählt jede Sekunde.
- Die Funktion fragt ab. Eine Funktion, die ein Scheduler jede Sekunde aufruft, zahlt jedes Mal eine Anfrage und Sekunden. Ein Job oder ein Worker-Pool leistet dasselbe zum niedrigeren Satz.
- Die Antwort ist der Egress. Ein Dienst, der Bilder liefert, zahlt je GiB ins Internet mehr als seine CPU. Ein CDN davor speichert die Wiederholungen.
- Die Freimenge zum falschen Satz gezählt. Die freien Sekunden sind zum Preis von us-central1 bewertet und gleichen in Frankfurt weniger Sekunden aus; die Credit-Zeile zeigt die Differenz.
Beispiel
Listenpreise in USD für Frankfurt (europe-west3), gelesen am 2026-10-21 von der Preisseite von Cloud Run: Anfragebasierte Abrechnung kostet 0,0000336 USD je vCPU-Sekunde und 0,0000035 USD je GiB-Sekunde, während eine Instanz Anfragen bearbeitet, 0,0000035 USD je vCPU-Sekunde und je GiB-Sekunde, während eine Mindestinstanz wartet, und 0,40 USD je Million Anfragen; instanzbasierte Abrechnung 0,0000216 USD je vCPU-Sekunde und 0,0000024 USD je GiB-Sekunde für jede Sekunde des Bestehens; Jobs 0,00001512 USD je vCPU-Sekunde und 0,00000168 USD je GiB-Sekunde; Worker-Pools 0,000013493 USD und 0,000001482 USD; mit dreijährigem flexiblem Commitment 0,000011664 USD je vCPU-Sekunde instanzbasiert; flüchtiger Speicher 0,000131507 USD je GiB-Stunde.
Ein Dienst mit 1 vCPU und 512 MiB, der 10 Millionen Anfragen im Monat zu je 200 ms bei Nebenläufigkeit 1 bearbeitet, zahlt 2.000.000 vCPU-Sekunden und 1.000.000 GiB-Sekunden nach anfragebasierter Abrechnung, 67,20 plus 3,50 plus 4,00 = 74,70 USD vor der Freimenge; dieselben Anfragen bei Nebenläufigkeit 20 zahlen ein Zwanzigstel der Sekunden, 7,54 USD, weil sich die Instanzen überlappen. Ein Minimum von einer solchen Instanz fügt 2.628.000 Leerlaufsekunden hinzu, 9,20 plus 4,60 = 13,80 USD im Monat; ein Minimum von zehn Instanzen mit 4 vCPUs und 16 GiB fügt 1.840 USD Leerlaufzeit hinzu. Ein rund um die Uhr ausgelasteter Dienst mit 2 vCPUs und 4 GiB zahlt 213,72 USD im Monat instanzbasiert und 213,72 × 1,56 = 332,90 USD anfragebasiert, wenn er die ganze Zeit Anfragen bearbeitete; dieselben 2 vCPUs auf einer e2-standard-2 kosten 63,02 USD. Ein nächtlicher Job, der 30 Minuten auf 4 vCPUs und 8 GiB läuft, kostet 30 × (7.200 × 0,00001512 + 14.400 × 0,00000168) = 3,99 USD im Monat. Die Zahlen zeigen, dass Nebenläufigkeit und Mindestinstanzen, nicht der Anfragepreis, die Rechnung entscheiden, und dass Cloud Run günstig ist für stoßweise Dienste und teuer für Dienste, die nie ruhen.
Quellen
Gelesen am 2026-10-21. Preise: Cloud Run Preise. Dienst: Abrechnungseinstellungen für Cloud-Run-Dienste, Mindestinstanzen, Maximale gleichzeitige Anfragen je Instanz. Abrechnungsdaten: Struktur des Standard-Exports der Cloud-Billing-Daten.