Google Cloud stellt Ausgabenobergrenzen allgemein bereit, doch Anfragen mit bereitgestelltem Durchsatz laufen weiter

Am 30. Oktober 2026 kündigte Google Cloud die allgemeine Verfügbarkeit von Ausgabenlimits in Google Cloud Budgets an. Die Version ergänzt eine API, Berichte zu geschätzten Live-Kosten und eine automatische monatliche Zurücksetzung für berechtigte Dienste, damit ausufernde Nutzung ohne Löschen von Ressourcen begrenzt werden kann. Das Limit kann nutzungsabhängig abgerechnete Anfragen und Anfragen mit zugesagten Nutzungsrabatten stoppen, aber niemals Anfragen mit Provisioned Throughput: reservierte Kapazität bedient den Verkehr weiter. Die Ausgabe dieser Website vom 2. November bewahrt das ursprüngliche Ankündigungsdatum und diese entscheidende Ausnahme.

Die neue API ist über die bestehende Cloud Billing Budgets API erreichbar. Verantwortliche können ein Limit für berechtigte Dienste innerhalb eines Projekts programmatisch erstellen, ändern, aufheben oder löschen. Ein kurzlebiges Entwicklungssandbox oder ein experimentelles Agentenprojekt kann damit schon bei der Einrichtung eine kleine finanzielle Schranke erhalten, statt auf eine spätere manuelle Rechnungskontrolle angewiesen zu sein. Das bedeutet weder, dass alle Google-Cloud-Produkte durch das Limit gestoppt werden, noch, dass bereits angefallene Gebühren verschwinden. Vor der Aussage, ein Projekt sei geschützt, müssen Dienstberechtigung, Abrechnungsmodell, Berechtigungen und tatsächliche Konfiguration geprüft werden.

Für KI-Dienste sollen geschätzte Live-Kosten das Auslösen eines Limits innerhalb weniger Minuten nach Nutzung ermöglichen. In Cost Reports lassen sich nun die schnelleren Schätzwerte ansehen, auf denen die Sperre beruhte; die langsamere Verarbeitung endgültiger Nettokosten muss dafür nicht abgewartet werden. Schätzung und spätere Rechnung können sich in Zeitpunkt und Betrag unterscheiden. Ein Vorfallprotokoll sollte Einstellungen, Auslösezeit, Live-Bericht, abgewiesene Anfragen und die endgültigen Gebühren enthalten. Die Angabe „innerhalb weniger Minuten“ beschreibt unterstützte KI-Dienste und ist keine Garantie, dass jede einzelne Kostenposition exakt am Grenzwert endet.

Laut API-Leitfaden werden alle Limits zu Beginn der nächsten Budgetperiode automatisch auf CONFIGURED zurückgesetzt; gesperrte Dienste laufen wieder. Eine manuelle Aufhebung stellt den Dienst nur innerhalb der laufenden Periode vorzeitig wieder her. Bei AWAITING_NEXT_PERIOD löst das Limit in dieser Periode nicht erneut aus, außer Betrag und inputState werden auf einen höheren Wert beziehungsweise CONFIGURED geändert. Der Blog erwähnt manual override, doch der Leitfaden dokumentiert keine integrierte Option zum Abschalten der Rücksetzung über Perioden hinweg oder zur Pflichtfreigabe vor Wiederaufnahme. Eine externe Genehmigungskontrolle wäre ein zusätzlicher Gestaltungsvorschlag, keine Produktfunktion. Fehlerhafte Aufgaben vor dem Periodenwechsel untersuchen.

Standardmäßig gehen Warnungen bei 50, 80 und 100 Prozent des Limits an Abrechnungsadministratoren und Projekteigentümer. Gerade bei automatisch erstellten Projekten sollte geprüft werden, ob diese Rollen tatsächlich besetzt sind und die Nachrichten ankommen. Berechtigungen für Ausgabenlimits lassen sich bei Bedarf benutzerdefinierten Rollen zuweisen, doch das Recht zum Aufheben eines Limits sollte begrenzt und protokolliert werden. Ein kleiner Grenzwert in einer nicht produktiven Sandbox ist ein guter Anfang: kontrollierte Nutzung erzeugen und Warnung, Live-Bericht, Anfrageablehnung und Rücksetzung beobachten. Für legitime unterbrochene Arbeit und weiterhin entstehende Kosten braucht es getrennte Wiederherstellungs- und Eskalationswege.

Die wichtigste Grenze betrifft Provisioned Throughput. Google schreibt ausdrücklich, dass Anfragen mit reservierter Kapazität durch Ausgabenlimits niemals angehalten werden und auch nach Erreichen des Schwellenwerts normal weiterlaufen. Nutzungsabhängige Anfragen sowie solche mit zugesagtem Nutzungsrabatt werden dagegen gestoppt. Wer beide Modelle verwendet, darf aus einer abgewiesenen On-Demand-Anfrage kein vollständiges Einfrieren der Gesamtkosten ableiten. Reservierungen, feste Verpflichtungen und ihre Vertragskosten müssen separat erfasst und über passende Abrechnungsberichte überwacht werden. Das Limit sollte als Schranke für berechtigte Anfragen beschrieben werden, nicht als absolute Obergrenze der gesamten Cloud-Rechnung.

Zur Abnahme Projekte, berechtigte Dienste, API-Rechte und Warnungsempfänger erfassen. Die automatische Rücksetzung in der nächsten Periode von der vorzeitigen manuellen Aufhebung und AWAITING_NEXT_PERIOD unterscheiden, das nur in der laufenden Periode unter den dokumentierten Bedingungen erneutes Auslösen verhindert. In einer entbehrlichen Umgebung das Limit kontrolliert auslösen und Zeiten, Schätzwerte, Antwortcodes und spätere Abrechnung festhalten; berechtigte On-Demand- und tatsächlich genutzte Provisioned-Throughput-Anfragen getrennt prüfen. Eine periodenübergreifende Freigabe als externe Kontrolle gesondert testen, nicht als integrierten Schalter.

Die allgemeine Verfügbarkeit erleichtert die automatisierte Einrichtung und die Untersuchung ausgelöster Limits; die monatliche Rücksetzung verändert zusätzlich den Betriebsablauf. Der tatsächliche Schutz hängt weiterhin von Dienst und Abrechnungsmodell ab: API und Anfrageverhalten verifizieren und Provisioned Throughput sowie andere laufende Verpflichtungen mit eigenen finanziellen Kontrollen steuern.