SW BBANG P

Seu Auto Scaling Group está terminando instâncias que parecem saudáveis no console EC2 — o status mostra running , o sistema operacional responde ao SSH, mas o ASG insiste em substituí-las. Esse comportamento quase sempre aponta para uma divergência entre o tipo de health check configurado e o que a aplicação realmente precisa para ser considerada saudável. TL;DR — Auto Scaling Group Health Check: EC2 vs ELB Aspecto EC2 (padrão) ELB O que verifica Status do hipervisor e hardware Resposta HTTP/TCP da aplicação Quando usar Workloads sem load balancer Instâncias registradas em Target Group Instância 'running' mas app travada Considerada saudável Considerada unhealthy → terminada Risco principal Servir tráfego com app quebrada Terminações em cascata se health check mal configurado Grace period Aplica-se a ambos Aplica-se a ambos Como os Health Checks do ASG Funcionam O ASG avalia a saúde d...

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...