Überraschende Firebase-Rechnungen vermeiden: eine Checkliste

Firebase hat eine Seite namens Avoid surprise bills. Sie ist ein guter Anfang und deckt drei Dinge ab: Code testen, Nutzung beobachten, Budgets einrichten. Unten steht dasselbe als Checkliste, in derselben Reihenfolge, mit dem, was jeder Schritt offen lässt, und den Schritten, die die Seite nicht nennt.

Eine Sache gleich vorweg: "Firebase pricing plans apply to the entire project, not just to individual apps registered in the project." (die Firebase-Tarife gelten für das ganze Projekt, nicht nur für einzelne darin registrierte Apps). Jede App im Projekt (Web, iOS, Android, ein Test-Build, der auf die Produktion zeigt) zählt zur selben Rechnung.

Google empfiehlt die Local Emulator Suite, die Firestore, Cloud Functions, Realtime Database und mehr auf deinem Rechner ausführt, damit "you don't incur any Firebase costs that might result from testing against services in production" (dir keine Firebase-Kosten durch Tests gegen Produktionsdienste entstehen). Beim Testen nennt sie zwei Muster, auf die man achten sollte:

• "Forgetting to add a limit to a database query with millions of results" (vergessen, eine Abfrage mit Millionen Ergebnissen zu begrenzen)
• "Combinations of Cloud Functions that cause excessive fan-out workloads or even infinite loops" (Kombinationen von Cloud Functions, die übermäßigen Fan-out oder sogar Endlosschleifen auslösen)

Was offen bleibt: Der Emulator zeigt, was dein Code tut, nicht was echte Nutzer oder ein Fremder damit anstellen. Er bemerkt keinen Listener, der sich in der echten App auf jedem Screen neu anmeldet, und keinen Bot, der deine Funktion aufruft. Für Lesemuster, die beim Testen durchrutschen: wie du findest, was deinen Firestore liest.

Googles zweiter Schritt: "You need to know what normal usage patterns look like for your app" (du musst wissen, wie die normale Nutzung deiner App aussieht). Jedes Produkt hat in der Firebase-Konsole einen Tab Usage, und Settings, Usage and billing zeigt das ganze Projekt im Vergleich zum kostenlosen Kontingent.

Zwei Einschränkungen. Die Zahlen laufen unterschiedlich schnell: "Cloud Firestore and Cloud Storage usage are calculated daily" (Firestore- und Storage-Nutzung wird täglich berechnet) und "Cloud Functions usage is calculated monthly" (die von Cloud Functions monatlich). Und das Firestore-Dashboard ist eine Schätzung: "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (das Dashboard zeigt die abgerechneten Vorgänge nicht exakt, die abgerechnete Nutzung ist wahrscheinlich höher) (Firestore-Doku zur Nutzung).

Was offen bleibt: Jemand muss hinschauen. Ein Dashboard zeigt die Spitze dem, der es öffnet, und um 3 Uhr nachts öffnet es niemand. Ist die Rechnung schon höher als erwartet, führt wie du findest, was dir berechnet wird durch die Abrechnungsberichte bis zur SKU und zum Tag.

Beim Wechsel zu Blaze fordert Firebase dich auf, ein Budget anzulegen. Tu das, aber wisse, was es ist: "Budget alerts do not pause services." (Budgetwarnungen pausieren keine Dienste). Sie sind da, "so that you can take action, if needed" (damit du bei Bedarf handeln kannst).

Was offen bleibt: Die Warnung kommt Stunden nach den Kosten, und jemand muss trotzdem handeln. Warum, in Googles eigenen Worten: warum Budgetwarnungen deine Rechnung nicht stoppen.

Budgets mit Spend Cap sind die neuere Option: Erreicht ein Dienst 100 % seines Budgets, gilt: Cloud Billing "pauses that service for the rest of the month" (pausiert diesen Dienst für den Rest des Monats). Sie decken nur Firebase AI Logic, App Hosting, Cloud Functions for Firebase und Extensions ab.

Was offen bleibt: Firestore, Realtime Database, Cloud Storage und Hosting sind nicht abgedeckt. Und Google warnt: "Spend caps are not "hard caps"." (Spend Caps sind keine „harten Obergrenzen“). Die Durchsetzung "can be delayed by several minutes" (kann sich um mehrere Minuten verzögern), und was in dieser Zeit anfällt, wird normal berechnet.

Googles Seite handelt vom Beobachten der Kosten. Die meisten fünfstelligen Rechnungen in unseren Horrorgeschichten kamen von woanders: etwas außerhalb der App, das kostenpflichtige Dienste aufrief. Drei Dinge, die sich vor dem Launch lohnen:

• Schränke deine API-Schlüssel ein. Beschränke jeden Schlüssel auf die APIs und Apps, die ihn brauchen, und halte die Gemini API von jedem Schlüssel fern, der in deiner App ausgeliefert wird: wie du einen Firebase-API-Schlüssel einschränkst.
• Aktiviere App Check und strenge Sicherheitsregeln. Damit nur deine App an deine Datenbank und deine Callable Functions kommt: Denial-of-Wallet-Angriffe.
• Begrenze die Instanzen deiner Funktionen. Eine außer Kontrolle geratene Funktion kostet umso mehr, je mehr Instanzen sie bekommt. Setze ein Maximum: wie du die Firebase-Kosten begrenzt.

Googles Seite zeigt in dieselbe Richtung: Sie schlägt vor, Budgetbenachrichtigungen zu nutzen, um die Abrechnung des Projekts zu deaktivieren. Du kannst das selbst mit einer Funktion am Pub/Sub-Topic des Budgets bauen (Schritt-für-Schritt-Anleitung), lies aber vorher was passiert, wenn die Abrechnung stoppt: Es fährt alle kostenpflichtigen Dienste im Projekt herunter.

Oder lass FireShield das übernehmen. Es reagiert auf jede Budgetbenachrichtigung, sobald sie ankommt, kann einen Soft-Kill-Webhook senden, damit deine App sich selbst drosselt, bevor die Abrechnung getrennt wird, und im Pro-Tarif überwacht es die Nutzung jedes Dienstes auf Spitzen, sodass ein Ausreißer innerhalb einer Stunde auffällt und nicht erst im nächsten Kostenbericht.

1. In der Local Emulator Suite testen, mit einem Limit für jede Abfrage.
2. Die normale Nutzung pro Produkt kennen und nach jedem Release prüfen.
3. Ein Budget anlegen, im Wissen, dass es nur Warnungen sendet.
4. Spend Caps für AI Logic, App Hosting, Cloud Functions und Extensions einschalten.
5. API-Schlüssel einschränken, App Check aktivieren, Funktionsinstanzen begrenzen.
6. Etwas anschließen, das auf das Budget reagiert, ohne auf einen Menschen zu warten.