Cómo limitar el gasto de Firebase en el plan Blaze

No para todo el proyecto. En el plan Blaze pagas por lo que usas, y el presupuesto que fijas al pasarte a Blaze es una alerta: Firebase dice que las alertas de presupuesto "do not cap your usage or charges" («no limitan tu uso ni tus cargos») (planes de precios). Lo que sí puedes hacer es combinar varios límites, cada uno cubriendo parte del riesgo. Aquí los tienes, del más barato al más fuerte.

No detendrá nada, pero es la señal de la que depende todo lo demás. Los valores por defecto de Google son el 50%, el 90% y el 100% del gasto real; Firebase sugiere "50% and 100% of Actual as well as 150% of Forecasted" («el 50% y el 100% del gasto real y el 150% del previsto») (alertas de presupuesto). Recuerda que la primera notificación puede tardar varias horas en llegar.

Los límites de gasto de Firebase (Preview) pausan un servicio durante el resto del mes cuando alcanza su presupuesto. Solo cubren Firebase AI Logic, App Hosting, Cloud Functions for Firebase y Extensions, y Google señala que "not 'hard caps'" («no son límites estrictos»): los excesos durante el retraso del informe se siguen facturando.

Una función desbocada cuesta más cuantas más instancias consigue. Fija un máximo: Firebase lo describe como una forma "to control your costs" («de controlar tus costes») (gestionar funciones). En el límite, las peticiones HTTP adicionales esperan en cola hasta 30 segundos y luego reciben un 429.

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

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

La mayoría de las API de Google te permiten fijar una cuota de peticiones por día o por minuto. Google las describe como límites de "requests per day, requests per minute, or requests per minute per user" («peticiones por día, peticiones por minuto o peticiones por minuto por usuario») (limitar el uso de las API), y deja claro que regulan el volumen, no el dinero, y que se aplican con cierta latencia. Útiles para API de IA, donde una sola clave filtrada puede generar miles de peticiones.

Las reglas de seguridad y App Check impiden que desconocidos lean tu base de datos o llamen a tus funciones callable a costa de tu factura. Se tratan en detalle en ataques de denegación de cartera.

Lo único que convierte un presupuesto en un límite es algo que actúe sobre él. Puedes conectar una función al tema de Pub/Sub del presupuesto que desactive la facturación (guía paso a paso para hacerlo tú mismo), o usar FireShield, que lo hace por ti con un paso previo más suave: un webhook firmado que permite a tu app degradarse antes de que se corte la facturación.

• Proyecto personal: presupuesto + instancias máximas en las funciones + un Hard Kill automático al 100%. Perder un día de disponibilidad es mejor que una factura sorpresa.
• Producto con usuarios: todo lo anterior, un Soft Kill en un umbral más bajo para que la app se degrade en lugar de caer, y detección de picos en los servicios que pueden desbocarse más rápido.