A promessa é irresistível para qualquer diretor financeiro ou líder de FinOps: corte a fatura computacional da AWS em até 90% utilizando Instâncias Spot. A diretoria aprova a migração, os engenheiros alteram os Auto Scaling Groups e, no final do mês, a economia é celebrada.
No entanto, semanas depois, alertas começam a disparar. Transações financeiras ficam presas no status “processando”, arquivos são gravados pela metade no banco de dados e clientes reclamam de erros 500 intermitentes.
O que parecia uma vitória financeira revelou-se uma falha arquitetural grave. O desconto massivo das instâncias Spot existe porque a AWS pode tomar esses servidores de volta a qualquer momento. Se a sua aplicação não for projetada para absorver essa interrupção, o desligamento abrupto corromperá os dados em trânsito.
1. A Anatomia da Interrupção (O Aviso de 2 Minutos)
Quando a AWS precisa de capacidade computacional de volta (ou quando o preço de mercado da instância ultrapassa o seu limite), ela emite um Spot Instance Interruption Notice (Aviso de Interrupção de Instância Spot).
O problema é que este aviso ocorre exatos 2 minutos antes do servidor ser aniquilado.
Esse sinal é enviado silenciosamente para o Instance Metadata Service (IMDS) do servidor e para o Amazon EventBridge. Se a sua infraestrutura não estiver escutando ativamente esse canal, o servidor será desligado de forma abrupta (“puxada de tomada”). Qualquer Pod do Kubernetes processando um pagamento, redimensionando uma imagem ou escrevendo no banco de dados morrerá no meio da operação.
2. A Solução no Kubernetes: AWS Node Termination Handler
Para rodar instâncias Spot com segurança em ambientes conteinerizados como o Amazon EKS, você precisa de um componente de infraestrutura focado exclusivamente em capturar esses dois minutos de aviso.
A arquitetura correta exige a implantação do AWS Node Termination Handler (NTH).
Quando o NTH detecta o aviso de interrupção emitido pela AWS, ele executa um processo de salvamento (Graceful Shutdown) perfeitamente orquestrado:
- Cordoning: Ele marca o nó como “NÃO PROGRAMÁVEL”, impedindo que o Kubernetes envie novas requisições ou inicie novos Pods naquela máquina condenada.
- Draining: Ele envia um sinal de encerramento (
SIGTERM) para a sua aplicação. - Grace Period: A sua aplicação, ao receber o
SIGTERM, para de aceitar novas conexões, finaliza a gravação dos dados que já estavam em andamento no banco, fecha as conexões com o RDS e desliga pacificamente.
3. A Prova de Fogo com Engenharia do Caos (AWS FIS)
A regra de ouro da resiliência na nuvem é: se você não testou a falha, ela não funciona.
Muitas empresas configuram o manipulador de interrupções, mas descobrem na produção que o código da aplicação ignorava os sinais de SIGTERM. Para validar a arquitetura sem afetar os clientes, engenheiros de elite utilizam o AWS Fault Injection Simulator (FIS).
Com o AWS FIS, você injeta falhas deliberadas no seu ambiente de homologação, forçando a AWS a revogar suas instâncias Spot em horários programados. Isso permite que a sua equipe de observabilidade valide se os logs de encerramento amigável estão funcionando e se nenhum dado foi perdido durante o expurgo.
A diferença entre um ambiente amador e uma operação corporativa de alto nível não está em evitar as falhas, mas em orquestrá-las. Adotar Instâncias Spot é a melhor decisão financeira que sua empresa pode tomar, desde que o ambiente seja hostil por design. Implemente o tratamento de sinais, drene suas conexões e faça do caos um processo rotineiro. Quando o encerramento do servidor se torna um evento controlado, a sua nuvem atinge a verdadeira elasticidade.
