Capacidade On-Demand vs Provisionada do DynamoDB
O DynamoDB cobra o throughput de duas formas. O On-Demand cobra por requisição — você paga pelo que usa, escalando até zero. O Provisionado reserva uma taxa fixa de leitura/escrita que você paga, usando-a ou não, a um preço por unidade muito menor. Escolher o errado é uma das maneiras mais fáceis de pagar demais.
O log de auditoria torna a escolha concreta. As escritas de auditoria são instáveis e imprevisíveis: silenciosas de madrugada e então uma enxurrada quando um cliente roda uma operação em massa ou um incidente gera milhares de eventos. Esse formato de tráfego é toda a decisão.
Devo usar capacidade On-Demand ou Provisionada no DynamoDB?
O On-Demand cobra por requisição e escala até zero, tornando-o o padrão seguro para tráfego instável, novo ou imprevisível. O Provisionado reserva uma taxa fixa de leitura/escrita a um preço por unidade muito menor, valendo a pena apenas quando o tráfego sustentado e estável mantém essa reserva bem utilizada. Escolha o On-Demand, a menos que o seu volume seja comprovado e previsível.
- On-Demand = pague por requisição, escala até zero. Sem capacidade a planejar; você paga um preço maior por leitura/escrita, mas só quando o tráfego acontece.
- Provisionado = reserve uma taxa estável, pague por ela sempre. Muito mais barato por unidade se a taxa for bem utilizada; você arca com o custo da capacidade ociosa.
- Tráfego instável / desconhecido → On-Demand. Tráfego estável, previsível e de alto volume → Provisionado (opcionalmente com auto-scaling).
- Você pode trocar de modo, mas apenas um número limitado de vezes por 24 horas — não é um botão por requisição.
O problema: pagar por capacidade que você não usa
Com a capacidade Provisionada você se compromete com, digamos, 1.000 unidades de escrita por segundo. Se o log de auditoria tem em média 50 escritas/segundo mas você provisionou para o pico do dia de incidente, você paga por 1.000 o tempo todo e usa um vigésimo disso. Provisione para a média e a enxurrada do dia de incidente sofre throttling — as escritas são rejeitadas.
Então a capacidade fixa força um trade-off ruim em tráfego instável: pagar demais constantemente, ou sub-provisionar e descartar escritas quando mais importa. O On-Demand existe justamente para remover esse trade-off.
Como os dois modos funcionam
O On-Demand cobra pelas unidades de requisição de leitura e escrita que você de fato consome, sem capacidade a configurar — ele acomoda picos de tráfego instantaneamente e escala até zero quando ocioso. Você paga um prêmio por requisição por essa elasticidade.
O Provisionado reserva um número de Read Capacity Units (RCU) e Write Capacity Units (WCU) por segundo. O preço por unidade é muito menor, mas você paga pela reserva continuamente, usada ou não. Exceda-a e o DynamoDB faz throttling, a menos que o auto-scaling esteja ativado para crescer a capacidade dentro de limites configurados — embora o auto-scaling reaja ao longo de minutos, então um pico súbito ainda pode sofrer throttling antes de ele acompanhar.
O ponto de equilíbrio é a utilização. Grosso modo: se o seu tráfego sustentado e previsível mantém a capacidade Provisionada bem utilizada, o Provisionado vence no preço; se o tráfego é instável, em rajadas ou desconhecido, o On-Demand vence por não cobrar pela reserva ociosa.
Um exemplo prático: a conta do log de auditoria
O log de auditoria escreve ~50 eventos/segundo em média, mas dispara para milhares durante incidentes, com o tráfego de leitura bem menor (exportações de conformidade, a investigação ocasional). Cada evento é pequeno — bem abaixo de 1 KB.
No Provisionado, você teria que reservar para a rajada (pagando por ela o tempo todo) ou arriscar dar throttling na enxurrada do dia de incidente — o pior momento para descartar escritas de auditoria. No On-Demand, as horas tranquilas custam quase nada e a rajada é absorvida automaticamente; você paga exatamente pelas escritas que aconteceram.
Para essa carga de trabalho, o On-Demand é o padrão certo. A regra geral: comece no On-Demand para qualquer tabela nova ou instável, e só mude para o Provisionado quando o tráfego se provar estável o suficiente para manter uma reserva utilizada.
Coloque seus próprios números — leituras/escritas por segundo, tamanho do item, armazenamento — para ver os dois modos lado a lado para uma região:
Para o panorama multi-região completo com o free tier aplicado, use a Calculadora de Preços do DynamoDB.
Faça no DynoTable
A decisão de capacidade parte de números reais: o tamanho dos itens, quantos são, com que velocidade são escritos. Chutar isso é como as tabelas acabam mal-provisionadas.
Para transformar um evento de amostra na RCU/WCU que ele realmente consome, passe-o pela calculadora de tamanho de item. Depois, baseie a decisão na sua tabela real: o DynoTable expõe seus metadados — contagem e tamanho dos itens — e te permite inspecionar itens representativos para que você os dimensione com precisão.
Armadilhas e próximos passos
- Trocar de modo tem limite de taxa. Você pode alternar entre On-Demand e Provisionado, mas apenas um número limitado de vezes por 24 horas — trate como uma decisão pensada, não um botão que você gira.
- O auto-scaling não é instantâneo. Ele reage ao longo de minutos, então um pico abrupto no Provisionado pode dar throttling antes de a capacidade crescer. Para tráfego genuinamente em rajadas, o On-Demand absorve o pico diretamente.
- Uma partição quente dá throttling independentemente do modo. Até o On-Demand tem limites por partição — chaves desiguais podem dar throttling enquanto a tabela parece estar abaixo da capacidade. Veja partições quentes.
- Os GSIs têm sua própria capacidade. Cada índice é cobrado separadamente e pode dar throttling nas escritas da tabela base se for sub-provisionado — veja por que um GSI dá throttling nas escritas da tabela base.
O modo de capacidade define o que você paga para rodar a tabela em uma região. A seguir: replicá-la entre regiões com Global Tables do DynamoDB.
Baixe o DynoTable para ler o tamanho real e a contagem de itens da sua tabela antes de se comprometer com um modo de capacidade.