Guida
Come limitare la spesa di Firebase sul piano Blaze
21 ottobre 2026 · 6 min di lettura
Sul piano Blaze non esiste un limite di spesa per l'intero progetto. I sei limiti che puoi combinare al suo posto, dalle soglie di budget alle istanze massime, dalle quote API a un kill switch automatico.
Esiste un limite di spesa sul piano Blaze?
Non per l'intero progetto. Sul piano Blaze paghi ciò che usi, e il budget che imposti al momento dell'upgrade è un avviso: Firebase dice che gli avvisi di budget "do not cap your usage or charges" (cioè, «non limitano il tuo utilizzo né i tuoi addebiti») (piani tariffari). Quello che puoi fare è combinare diversi limiti, ognuno dei quali copre una parte del rischio. Eccoli, dal più economico al più forte.
1. Imposta un budget con soglie sensate
Non fermerà nulla, ma è il segnale da cui dipende tutto il resto. I valori predefiniti di Google sono 50%, 90% e 100% della spesa effettiva; Firebase suggerisce "50% and 100% of Actual as well as 150% of Forecasted" (cioè, «50% e 100% dell'effettivo e 150% del previsto») (avvisi di budget). Ricorda che la prima notifica può richiedere diverse ore per arrivare.
2. Attiva i limiti di spesa dove esistono
I limiti di spesa di Firebase (Preview) sospendono un servizio per il resto del mese quando raggiunge il suo budget. Coprono solo Firebase AI Logic, App Hosting, Cloud Functions for Firebase ed Extensions, e Google precisa che "not 'hard caps'" (cioè, «non sono limiti rigidi»): le eccedenze durante il ritardo di rendicontazione vengono comunque fatturate.
3. Limita lo scaling delle tue funzioni
Una funzione fuori controllo costa di più quante più istanze ottiene. Imposta un massimo: Firebase lo definisce un modo "to control your costs" (cioè, «per controllare i tuoi costi») (gestire le funzioni). Al limite, le richieste HTTP in eccesso restano in coda fino a 30 secondi e poi ricevono un 429.
import { onRequest } from "firebase-functions/v2/https";
export const api = onRequest({ maxInstances: 10 }, async (req, res) => {
// ...
});4. Limita le richieste API con le quote
La maggior parte delle API Google consente di impostare una quota di richieste al giorno o al minuto. Google le descrive come limiti su "requests per day, requests per minute, or requests per minute per user" (cioè, «richieste al giorno, richieste al minuto o richieste al minuto per utente») (limitare l'utilizzo delle API), e chiarisce che regolano il volume, non il denaro, ed entrano in vigore con una certa latenza. Utili per le API di IA, dove una sola chiave trapelata può generare migliaia di richieste.
5. Chiudi le porte usate dagli attaccanti
Le regole di sicurezza e App Check impediscono agli estranei di leggere il tuo database o di chiamare le tue funzioni callable a tue spese. Sono trattate in dettaglio in attacchi denial of wallet.
6. Agisci automaticamente quando una soglia viene superata
L'unica cosa che trasforma un budget in un limite è qualcosa che agisce su di esso. Puoi collegare al topic Pub/Sub del budget una funzione che disattiva la fatturazione (guida fai da te passo passo), oppure usare FireShield, che lo fa per te con un primo passo più morbido: un webhook firmato che permette alla tua app di degradarsi da sola prima che la fatturazione venga interrotta.
Quali mi servono?
- Progetto personale: budget + istanze massime delle funzioni + un Hard Kill automatico al 100%. Perdere un giorno di disponibilità è meglio di una fattura a sorpresa.
- Prodotto con utenti: tutto quanto sopra, un Soft Kill a una soglia più bassa così che l'app si degradi invece di morire, e il rilevamento dei picchi sui servizi che possono andare fuori controllo più in fretta.
