Comment limiter les dépenses Firebase avec la formule Blaze

Pas pour l'ensemble du projet. Avec la formule Blaze, vous payez ce que vous consommez, et le budget défini lors du passage à Blaze est une alerte : Firebase indique que les alertes budgétaires "do not cap your usage or charges" (« ne plafonnent pas votre utilisation ni vos frais ») (formules tarifaires). Ce que vous pouvez faire, c'est cumuler plusieurs limites, chacune couvrant une partie du risque. Les voici, de la moins coûteuse à la plus forte.

Il n'arrêtera rien, mais c'est le signal sur lequel repose tout le reste. Les valeurs par défaut de Google sont 50 %, 90 % et 100 % des dépenses réelles ; Firebase suggère "50% and 100% of Actual as well as 150% of Forecasted" (« 50 % et 100 % du réel ainsi que 150 % du prévisionnel ») (alertes budgétaires). N'oubliez pas que la première notification peut mettre plusieurs heures à arriver.

Les plafonds de dépenses de Firebase (Preview) mettent un service en pause pour le reste du mois lorsqu'il atteint son budget. Ils ne couvrent que Firebase AI Logic, App Hosting, Cloud Functions for Firebase et les Extensions, et Google précise qu'ils ne sont "not 'hard caps'" (« pas des plafonds stricts ») : les dépassements survenus pendant le délai de remontée restent facturés.

Une fonction qui s'emballe coûte d'autant plus qu'elle obtient d'instances. Fixez un maximum : Firebase le présente comme un moyen "to control your costs" (« de maîtriser vos coûts ») (gérer les fonctions). À la limite, les requêtes HTTP supplémentaires attendent jusqu'à 30 secondes puis reçoivent une erreur 429.

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

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

La plupart des API Google permettent de définir un quota de requêtes par jour ou par minute. Google les décrit comme des plafonds de "requests per day, requests per minute, or requests per minute per user" (« requêtes par jour, requêtes par minute ou requêtes par minute et par utilisateur ») (plafonner l'utilisation des API), et précise bien qu'ils régulent le volume, pas l'argent, et s'appliquent avec une certaine latence. Utile pour les API d'IA, où une seule clé divulguée peut générer des milliers de requêtes.

Les règles de sécurité et App Check empêchent des inconnus de lire votre base de données ou d'appeler vos fonctions callable à vos frais. Elles sont détaillées dans les attaques par déni de portefeuille.

La seule chose qui transforme un budget en limite, c'est quelque chose qui agit en conséquence. Vous pouvez relier au sujet Pub/Sub du budget une fonction qui désactive la facturation (guide pas à pas pour le faire vous-même), ou utiliser FireShield, qui le fait pour vous avec une première étape plus douce : un webhook signé qui permet à votre application de se dégrader avant que la facturation ne soit coupée.

• Projet personnel : budget + instances maximales des fonctions + un Hard Kill automatique à 100 %. Perdre une journée de disponibilité vaut mieux qu'une facture surprise.
• Produit avec des utilisateurs : tout ce qui précède, un Soft Kill à un seuil plus bas pour que l'application se dégrade au lieu de s'arrêter, et la détection de pics sur les services qui peuvent s'emballer le plus vite.