Ein Dienst beantwortet nur wenige Anfragen und verursacht trotzdem mehr Kosten als erwartet. Ein anderer verarbeitet viele kurze Aufrufe günstig. Wer ausschließlich die Zahl der Requests begrenzt, misst deshalb nicht automatisch das, was später auf der Infrastrukturrechnung steht. Kostenkontrolle und Lastkontrolle greifen an unterschiedlichen Stellen.
Google meldete am 12. Oktober 2026 die allgemeine Verfügbarkeit von Budget spend caps für Cloud Run. Ein eingerichteter Ausgabendeckel kann die betroffenen Workloads pausieren. Das ist eine relevante Infrastrukturänderung. Sie wird aber erst verständlich, wenn man zwischen Budgetwarnung, Ausgabendeckel und Begrenzung einzelner Anfragen unterscheidet.
Drei Fragen, drei verschiedene Grenzen
Ein Anfragenlimit beantwortet beispielsweise: Wie viele Aufrufe darf ein bestimmter Client in einem Zeitraum senden? Eine Begrenzung gleichzeitiger Arbeit fragt: Wie viel darf parallel laufen? Ein Kostenlimit betrachtet dagegen den bewerteten Ressourcenverbrauch innerhalb seines Geltungsbereichs. Diese Größen hängen zusammen, sind aber nicht austauschbar.
Unser fiktiver Dienst hat zwei Aufgaben. Eine liefert eine kurze Statusantwort. Die andere verarbeitet ein umfangreiches Dokument. Beide beginnen mit genau einer Anfrage, beanspruchen aber unterschiedlich viel Arbeit. Selbst wenn beide Benutzer dieselbe Anzahl Aufrufe erhalten, folgt daraus keine gleiche Infrastrukturbelastung. Ein einzelner Zähler verschweigt die unterschiedliche Bedeutung seiner Einträge.
Ein Budgetalarm ist noch kein Stopp
Die offizielle Billing-Dokumentation unterscheidet reine Warnbudgets von spend caps. Für die beschriebenen Deckel werden geschätzte Bruttokosten genutzt; Einsparungen und Gutschriften sind dabei nicht eingerechnet. Der Geltungsbereich ist ein einzelnes Projekt und ein unterstützter Dienst, die Periode monatlich. Diese Bedingungen sollte ein Betreiber vor einer Konfiguration ausdrücklich lesen.
Auch die Durchsetzung ist nicht augenblicklich. Google weist darauf hin, dass Überschreitungen durch Verzögerungen weiterhin berechnet werden. Ein eingetragener Betrag ist deshalb keine mathematische Zusage, dass die endgültige Rechnung genau dort endet. Die Neuerung bietet einen technischen Eingriff, keinen Ersatz für das Verständnis ihrer Abrechnung.
Für Cloud Run beschreibt die Produktdokumentation konkrete Auswirkungen: Services können keine Anfragen mehr bedienen und liefern Fehler aus dem 5xx-Bereich; andere Ressourcentypen haben eigene Folgen. Ein Kostenstopp ist damit zugleich eine Verfügbarkeitsentscheidung. Diese Konsequenz gehört zur Planung, nicht erst in die Störungsmeldung.
Eine Trockenübung zeigt, welche Regel wann greift
Du musst keinen laufenden Dienst anhalten, um das Modell zu verstehen. Zeichne drei unabhängige Zähler auf: Aufrufe pro Client, gleichzeitig laufende Arbeit und geschätzte Kosten im betrachteten Zeitraum. Ordne ihnen jeweils eine Reaktion zu. Die erste Regel weist weitere Aufrufe eines Clients ab, die zweite begrenzt Parallelität, die dritte kann einen ganzen definierten Dienstumfang pausieren.
Clientgrenze: Wer darf wie oft anfragen?
Parallelitätsgrenze: Wie viel Arbeit läuft gleichzeitig?
Ausgabendeckel: Wann wird der betrachtete Dienst pausiert?Spiele anschließend zwei erfundene Fälle durch: viele kurze und wenige aufwendige Anfragen. Trage nur qualitative Unterschiede ein, keine ausgedachten Eurobeträge. Die Übung zeigt, welche Regel den jeweiligen Fall überhaupt sieht. Sie ist ein Denkmodell, kein gemessener Last- oder Kostentest.
Infrastruktur des Betreibers ist nicht das Kundenkontingent
KENJTEC verwendet Cloud Run für Plattformdienste; das ist in den Infrastruktur- und Ausrollquellen des Projekts nachvollziehbar. Daraus folgt nicht, dass die neue Google-Funktion automatisch aktiviert wurde. Ebenso wenig entsteht daraus ein individuell einstellbarer Infrastrukturdeckel für jedes KENJTEC-Kundenkonto. Ein Betreiberprojekt und ein Kundenabo sind unterschiedliche Abrechnungsgrenzen.
Für die Praxis lautet die wichtige Frage daher: Welche Nutzung soll eine Grenze schützen, und welche Arbeit würde bei ihrem Auslösen mit angehalten? Ein sinnvoller Plan beschreibt Warnung, Eingriff und Wiederaufnahme gemeinsam. Erst danach lässt sich beurteilen, wie ein Ausgabendeckel zu Anfragenlimits und den eigenen Verfügbarkeitsanforderungen passt.
Quellen und Stand
Recherche- und Dokumentationsstand: 25. Oktober 2026. Cloud Run release notes — October 12, 2026 · Billing settings for services — Budget spend caps · Manage spend cap budgets.
