Capacidade On-Demand vs Provisionada no DynamoDB
O DynamoDB cobra 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 pela qual você paga usando-a ou não, a um preço por unidade muito mais baixo. Escolher o modo errado é uma das formas 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 durante a madrugada, e depois uma enxurrada quando um cliente executa uma operação em massa ou um incidente gera milhares de eventos. Esse formato de tráfego é a decisão inteira.
Devo usar capacidade On-Demand ou Provisionada no DynamoDB?
O On-Demand cobra por requisição e escala até zero, tornando-se 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 mais baixo, vencendo apenas quando um tráfego sustentado e estável mantém essa reserva bem utilizada. Escolha On-Demand a menos que seu volume seja comprovado e previsível.
- On-Demand = pagamento por requisição, escala até zero. Sem capacidade para 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 ou desconhecido pede On-Demand. Tráfego estável, previsível e de alto volume pede Provisionado (opcionalmente com auto-scaling).
- Você pode trocar de modo, mas o limite é assimétrico: de Provisionado para On-Demand é limitado a quatro vezes por 24 horas, enquanto de On-Demand para Provisionado é irrestrito — não é um botão de alternância por requisição.
O problema: pagar por capacidade que você não usa
Com capacidade Provisionada você se compromete com, digamos, 1.000 unidades de escrita por segundo. Se o log de auditoria faz 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 vinte avos disso. Provisione para a média e a enxurrada do dia de incidente sofre throttling — escritas são rejeitadas.
Então a capacidade fixa força uma troca ruim em tráfego instável: pagar demais o tempo todo, ou sub-provisionar e perder escritas quando mais importa. O On-Demand existe justamente para remover essa troca.
Como os dois modos funcionam
O On-Demand cobra pelas unidades de requisição de leitura e escrita que você realmente consome, sem capacidade para configurar — ele acomoda picos instantaneamente até o dobro do seu pico de tráfego anterior e escala até zero quando ocioso. Além desse salto de 2x dentro de uma janela curta, ele ainda pode aplicar throttling enquanto acelera. 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 mais baixo, mas você paga pela reserva continuamente, usada ou não. Ultrapasse-a e o DynamoDB aplica throttling, a menos que o auto-scaling esteja habilitado para crescer a capacidade dentro de limites configurados — embora o auto-scaling reaja ao longo de minutos, então um pico repentino ainda pode sofrer throttling antes de ele acompanhar.
O ponto de cruzamento é a utilização. Grosseiramente: se 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 por reserva ociosa.
Um exemplo trabalhado: 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 mais baixo (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 24/7) ou arriscar o throttling da enxurrada do dia de incidente — o pior momento para perder escritas de auditoria. No On-Demand, as horas silenciosas quase não custam nada e uma rajada até o dobro do pico recente é absorvida sem configuração; 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ó passe para o Provisionado quando o tráfego for comprovadamente 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 completo com múltiplas regiões e o free tier aplicado, use a Calculadora de Preços do DynamoDB.
Faça isso no DynoTable
A decisão de capacidade parte de números reais: quão grandes são os itens, quantos existem, com que velocidade estão sendo 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 fundamente a decisão na sua tabela real: o DynoTable expõe seus metadados — contagem e tamanho dos itens — e permite que você inspecione itens representativos para dimensioná-los com precisão.
Armadilhas e próximos passos
- Trocar de modo tem taxa limitada, e de forma assimétrica. De Provisionado para On-Demand é limitado a quatro trocas por 24 horas; de On-Demand para Provisionado é irrestrito. Trate como uma decisão ponderada, não como 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 sofrer throttling antes de a capacidade crescer. Para tráfego genuinamente em rajadas, o On-Demand lida melhor com o pico — até o dobro do seu pico anterior instantaneamente. Se você sabe que um pico vai exceder isso (um lançamento ou promoção), configure a warm throughput na tabela com antecedência para pré-provisionar a folga da rajada.
- Uma partição quente sofre throttling independentemente do modo. Até o On-Demand tem limites por partição — chaves desiguais podem sofrer throttling enquanto a tabela parece abaixo da capacidade. Veja partições quentes.
- têm sua própria capacidade. Cada índice é cobrado separadamente e pode aplicar throttling nas escritas da tabela base se for sub-provisionado — veja por que um GSI aplica throttling nas escritas da tabela base.
O modo de capacidade define o que você paga para operar a tabela em uma região. A seguir: replicá-la entre regiões com DynamoDB Global Tables.
Baixe o DynoTable para ler o tamanho e a contagem de itens reais da sua tabela antes de se comprometer com um modo de capacidade.