SW BBANG P

Você acabou de subir um cluster de instâncias privadas e percebe que o yum update trava — sem rota de saída para a internet. A pergunta imediata é: NAT Gateway gerenciado ou uma instância EC2 fazendo NAT? A escolha errada aqui aparece tarde, geralmente quando o tráfego aumenta ou quando você precisa escalar e descobre que a solução escolhida não acompanha. TL;DR — NAT Gateway vs NAT Instance Critério NAT Gateway NAT Instance (EC2) Gerenciamento Totalmente gerenciado pela AWS Você opera, patcha e monitora Alta disponibilidade Redundância interna por AZ Você implementa com Auto Scaling + script Escalabilidade Automática até limites do serviço Limitada pelo tipo de instância EC2 Custo base Cobrança por hora + por GB processado Custo da instância EC2 + EIP Security Gro...

Você acabou de modelar sua tabela DynamoDB e chegou na tela de configuração de capacidade. O tráfego da aplicação ainda é incerto — pode ser 10 requisições por segundo, pode ser 10.000. Escolher o modo errado aqui significa ou pagar por capacidade ociosa ou ver a aplicação throttlada em produção. Este post detalha como os modos de capacidade do DynamoDB funcionam internamente, quando cada um faz sentido, e como migrar entre eles sem surpresas. TL;DR — Modos de Capacidade DynamoDB Critério On-Demand Provisionado Tráfego previsível ❌ Custo mais alto ✅ Mais econômico Tráfego imprevisível ou novo ✅ Sem risco de throttling ❌ Risco de under-provisioning Picos esporádicos e intensos ✅ Absorve automaticamente ⚠️ Depende de Auto Scaling Custo por unidade Mais caro por RCU/WCU individual Mais barato com uso consistente Configuração operacional Zero Requer monitoramento e ajuste Troca de modo Uma vez a ca...