Capacità On-Demand vs con Provisioning in DynamoDB
DynamoDB fattura il throughput in due modi. On-Demand addebita per richiesta — paghi per quello che usi, scalando a zero. Il Provisioning riserva una frequenza di lettura/scrittura fissa che paghi che la usi o no, a un prezzo per unità molto più basso. Scegliere quella sbagliata è uno dei modi più facili per pagare troppo.
L'audit log rende concreta la scelta. Le scritture di audit sono spiky e imprevedibili: tranquille di notte, poi un'ondata quando un cliente esegue un'operazione di massa o un incidente genera migliaia di eventi. Quella forma del traffico è tutta la decisione.
Devo usare la capacità On-Demand o con Provisioning di DynamoDB?
On-Demand addebita per richiesta e scala a zero, rendendola il default sicuro per traffico spiky, nuovo o imprevedibile. Il Provisioning riserva una frequenza di lettura/scrittura fissa a un prezzo per unità molto più basso, risultando conveniente solo quando il traffico sostenuto e costante mantiene quella prenotazione ben utilizzata. Scegli On-Demand a meno che il tuo volume non sia consolidato e prevedibile.
- On-Demand = paga per richiesta, scala a zero. Nessuna capacità da pianificare; paghi un prezzo più alto per lettura/scrittura ma solo quando c'è traffico.
- Provisioning = riserva una frequenza costante, la paghi sempre. Molto più economico per unità se la frequenza è ben utilizzata; ti mangi il costo della capacità inattiva.
- Traffico spiky / sconosciuto → On-Demand. Traffico costante, prevedibile, ad alto volume → con Provisioning (opzionalmente con auto-scaling).
- Puoi cambiare modalità, ma solo un numero limitato di volte ogni 24 ore — non è un interruttore per richiesta.
Il problema: pagare per capacità che non usi
Con la capacità con Provisioning ti impegni, diciamo, a 1.000 unità di scrittura al secondo. Se l'audit log fa in media 50 scritture/secondo ma hai provisionato per il picco del giorno dell'incidente, paghi 1.000 tutto il giorno e ne usi un ventesimo. Provisiona invece per la media e l'ondata del giorno dell'incidente viene throttlata — le scritture vengono rifiutate.
Quindi la capacità fissa impone uno scambio sbagliato sul traffico spiky: paga troppo costantemente, o sotto-provisiona e perdi scritture quando conta di più. On-Demand esiste proprio per rimuovere quello scambio.
Come funzionano le due modalità
On-Demand addebita le unità di richiesta di lettura e scrittura che consumi davvero, senza capacità da configurare — accoglie istantaneamente i picchi di traffico e scala a zero quando è inattivo. Paghi un premio per richiesta per quell'elasticità.
Il Provisioning riserva un numero di Read Capacity Units (RCU) e Write Capacity Units (WCU) al secondo. Il prezzo per unità è molto più basso, ma paghi la prenotazione continuamente, usata o no. Supérala e DynamoDB throttla, a meno che l'auto-scaling sia abilitato a far crescere la capacità entro limiti configurati — anche se l'auto-scaling reagisce nell'arco di minuti, quindi un picco improvviso può comunque throttlare prima che si adegui.
Il punto di crossover è l'utilizzo. In linea di massima: se il tuo traffico sostenuto e prevedibile tiene la capacità con Provisioning ben utilizzata, il Provisioning vince sul prezzo; se il traffico è spiky, a raffiche o sconosciuto, On-Demand vince non addebitando la prenotazione inattiva.
Un esempio pratico: la bolletta dell'audit log
L'audit log scrive ~50 eventi/secondo in media ma fa raffiche fino a migliaia durante gli incidenti, con un traffico di lettura molto più basso (export di compliance, la saltuaria indagine). Ogni evento è piccolo — ben sotto 1 KB.
Con il Provisioning, dovresti riservare per la raffica (pagandola 24/7) o rischiare di throttlare l'ondata del giorno dell'incidente — il momento peggiore per perdere scritture di audit. Con On-Demand, le ore tranquille costano quasi nulla e la raffica viene assorbita automaticamente; paghi esattamente le scritture che sono avvenute.
Per questo carico On-Demand è il default giusto. La regola generale: parti da On-Demand per qualsiasi tabella nuova o spiky, e passa al Provisioning solo una volta che il traffico si è dimostrato abbastanza costante da tenere una prenotazione utilizzata.
Inserisci i tuoi numeri — letture/scritture al secondo, dimensione degli Item, storage — per vedere le due modalità fianco a fianco per una region:
Per il quadro multi-region completo con il free tier applicato, usa il Calcolatore di prezzi DynamoDB.
Fallo in DynoTable
La decisione sulla capacità parte da numeri reali: quanto sono grandi gli Item, quanti sono, quanto velocemente vengono scritti. Tirarli a indovinare è il modo in cui le tabelle finiscono mal provisionate.
Per trasformare un evento di esempio nelle RCU/WCU che consuma davvero, passalo attraverso il calcolatore di dimensione degli Item. Poi basa la decisione sulla tua tabella reale: DynoTable mostra i suoi metadati — conteggio e dimensione degli Item — e ti lascia ispezionare Item rappresentativi così da dimensionarli accuratamente.
Trappole e prossimi passi
- Cambiare modalità è rate-limited. Puoi passare tra On-Demand e Provisioning, ma solo un numero limitato di volte ogni 24 ore — trattalo come una decisione ponderata, non una manopola da girare.
- L'auto-scaling non è istantaneo. Reagisce nell'arco di minuti, quindi un picco netto con il Provisioning può throttlare prima che la capacità cresca. Per traffico davvero a raffiche, On-Demand assorbe il picco direttamente.
- Una partizione calda throttla a prescindere dalla modalità. Anche On-Demand ha limiti per-partizione — chiavi sbilanciate possono throttlare mentre la tabella sembra sotto capacità. Vedi partizioni calde.
- Le GSI hanno la loro capacità. Ogni Index è fatturato separatamente e può throttlare le scritture della tabella base se sotto-provisionato — vedi perché una GSI throttla le scritture della tabella base.
La modalità di capacità definisce quanto paghi per far girare la tabella in una region. Prossimo: replicarla tra region con le DynamoDB Global Tables.
Scarica DynoTable per leggere la dimensione e il conteggio reali degli Item della tua tabella prima di impegnarti su una modalità di capacità.