Leitfaden

So begrenzen Sie Firebase-Ausgaben im Blaze-Tarif

21. Oktober 2026 · 6 Min. Lesezeit

Im Blaze-Tarif gibt es kein projektweites Ausgabenlimit. Die sechs Limits, die Sie stattdessen kombinieren können, von Budget-Schwellenwerten über maximale Instanzen und API-Kontingente bis zu einem automatischen Kill Switch.

Gibt es im Blaze-Tarif ein Ausgabenlimit?

Nicht für das gesamte Projekt. Im Blaze-Tarif zahlen Sie, was Sie nutzen, und das Budget, das Sie beim Upgrade festlegen, ist eine Warnung: Firebase sagt, Budgetwarnungen "do not cap your usage or charges" (begrenzen weder Ihre Nutzung noch Ihre Kosten) (Tarife). Was Sie tun können: mehrere Limits kombinieren, von denen jedes einen Teil des Risikos abdeckt. Hier sind sie, vom günstigsten zum stärksten.

1. Legen Sie ein Budget mit sinnvollen Schwellenwerten fest

Es stoppt nichts, aber es ist das Signal, an dem alles andere hängt. Die Standardwerte von Google sind 50 %, 90 % und 100 % der tatsächlichen Ausgaben; Firebase empfiehlt "50% and 100% of Actual as well as 150% of Forecasted" (50 % und 100 % der tatsächlichen sowie 150 % der prognostizierten Ausgaben) (Budgetwarnungen). Denken Sie daran, dass die erste Benachrichtigung mehrere Stunden auf sich warten lassen kann.

2. Aktivieren Sie Spend Caps, wo es sie gibt

Die Spend Caps von Firebase (Preview) pausieren einen Dienst für den Rest des Monats, wenn er sein Budget erreicht. Sie decken nur Firebase AI Logic, App Hosting, Cloud Functions for Firebase und Extensions ab, und Google weist darauf hin, dass sie "not 'hard caps'" (keine „harten Obergrenzen“) sind: Mehrkosten während der Meldeverzögerung werden trotzdem abgerechnet.

3. Begrenzen Sie die Skalierung Ihrer Functions

Eine außer Kontrolle geratene Function kostet umso mehr, je mehr Instanzen sie bekommt. Legen Sie ein Maximum fest: Firebase nennt das eine Möglichkeit, "to control your costs" (Ihre Kosten zu kontrollieren) (Functions verwalten). Am Limit werden zusätzliche HTTP-Anfragen bis zu 30 Sekunden in die Warteschlange gestellt und erhalten dann einen 429.

import { onRequest } from "firebase-functions/v2/https";

export const api = onRequest({ maxInstances: 10 }, async (req, res) => {
  // ...
});

4. Begrenzen Sie API-Anfragen mit Kontingenten

Bei den meisten Google APIs können Sie ein Anfragekontingent pro Tag oder pro Minute festlegen. Google beschreibt diese als Obergrenzen für "requests per day, requests per minute, or requests per minute per user" (Anfragen pro Tag, pro Minute oder pro Minute und Nutzer) (API-Nutzung begrenzen) und stellt klar, dass sie das Volumen regeln, nicht das Geld, und mit einer gewissen Verzögerung greifen. Nützlich für KI-APIs, bei denen ein einziger geleakter Schlüssel Tausende Anfragen erzeugen kann.

5. Schließen Sie die Türen, die Angreifer nutzen

Security Rules und App Check verhindern, dass Fremde Ihre Datenbank lesen oder Ihre Callable Functions auf Ihre Rechnung aufrufen. Ausführlich behandelt in Denial-of-Wallet-Angriffe.

6. Handeln Sie automatisch, wenn ein Schwellenwert überschritten wird

Das Einzige, was aus einem Budget ein Limit macht, ist etwas, das darauf reagiert. Sie können eine Function mit dem Pub/Sub-Topic des Budgets verbinden, die die Abrechnung deaktiviert (Schritt-für-Schritt-Anleitung zum Selbstbauen), oder FireShield nutzen, das dies für Sie erledigt, mit einem sanfteren ersten Schritt: einem signierten Webhook, über den sich Ihre App selbst herunterregeln kann, bevor die Abrechnung getrennt wird.

Welche brauche ich?

Nebenprojekt: Budget + maximale Instanzen für Functions + ein automatischer Hard Kill bei 100 %. Ein Tag Ausfall ist besser als eine Überraschungsrechnung.
Produkt mit Nutzern: alles oben Genannte, ein Soft Kill bei einem niedrigeren Schwellenwert, damit die App eingeschränkt weiterläuft statt auszufallen, und Spitzenerkennung für die Dienste, die am schnellsten außer Kontrolle geraten können.