AWS

Spot Instances na AWS: guia prático de FinOps para quem não pode cair

Quando Spot compensa, como usar Spot Fleet e interruption notices, e quais workloads nunca devem ir para Spot — com foco em redução real de custo.

AWSEC2SpotCost Optimization

Spot Instances podem cortar 50–70% do compute On-Demand — ou gerar incidente se você colocar a API monolítica lá sem plano. Este guia separa o que funciona do hype.

O que é Spot (em uma frase)

Você usa capacidade ociosa da AWS com desconto, aceitando que a instância pode receber aviso de interrupção em 2 minutos quando a AWS precisa da capacidade de volta.

Não é “servidor barato permanente”. É compute elástico com preço variável.

Workloads ideais para Spot

Bom candidatoPor quê
Batch / filas (Celery, SQS workers)Tarefa idempotente, retry natural
CI/CD runnersJob curto, pode reenfileirar
Render / transcode / ETLCheckpoint e restart
Kubernetes (Karpenter / Cluster Autoscaler)Repõe nó em outra AZ/tipo
Ambientes dev/stagingTolerância a queda

Workloads que não devem ir para Spot (sozinhos)

  • API síncrona sem réplicas On-Demand ou sem graceful shutdown
  • Banco de dados primário (RDS Spot existe, mas exige arquitetura específica)
  • Singleton crítico sem HA
  • Jobs que não persistem estado a cada 2 minutos

Arquitetura mínima segura

  1. Base On-Demand ou Reserved para tráfego estável (núcleo da API).
  2. Spot para picos e workers.
  3. Application Load Balancer com health check — instância Spot interrompida sai do pool.
  4. Graceful shutdown: capturar SIGTERM, drenar conexões, commitar fila.

Interruption notice

A metadata em http://169.254.169.254/latest/meta-data/spot/instance-action avisa antes da interrupção. Agents como o Node Termination Handler (EKS) ou scripts systemd podem:

  • Marcar nó como draining
  • Reenfileirar jobs
  • Snapshot parcial se necessário

Spot Fleet vs. Auto Scaling com mixed instances

  • Spot Fleet: mistura tipos (m6i.large, m5.large, m5a.large) para aumentar chance de capacidade.
  • ASG com mixed instances policy: percentual On-Demand + Spot, diversificação por família.

Dica FinOps: diversificar 3+ famílias reduz interrupções mais do que perseguir o tipo mais barato do dia.

Estratégia de bid (modo atual)

Hoje a maioria das contas usa capacity-optimized ou price-capacity-optimized — a AWS escolhe pools com menos chance de interrupção. Evite estratégias legadas de bid manual salvo caso de uso específico documentado.

Quanto economizar (expectativa realista)

Exemplo educativo — instância que custa US$ 0,10/h On-Demand:

ModeloCusto horário aprox.Uso
On-Demand 24/7$0,10Baseline API
Spot médio$0,03–0,05Workers 16h/dia
Savings Plan 1a~$0,06–0,07Baseline comprometido

Economia total da conta raramente é 70% — compute é só uma fatia. Combine Spot com NAT/data transfer e RDS.

Checklist antes de ligar Spot em produção

  • Health check e LB configurados?
  • Shutdown graceful testado (SIGTERM)?
  • Pelo menos 2 famílias de instância no pool?
  • Métricas de interrupção no CloudWatch?
  • Runbook se Spot secar na AZ (fallback On-Demand)?

Simular preços

Use o comparador EC2 para On-Demand e planeje Spot como ~30–40% desse valor em workloads estáveis de pool — o preço Spot oscila.


Por Mauricio Nascimento de Oliveira.

Publicar no LinkedIn

Abre o LinkedIn com título, início do artigo e link. Você pode editar antes de publicar.

Ver texto da publicação
Spot Instances na AWS: guia prático de FinOps para quem não pode cair

Spot Instances podem cortar 50–70% do compute On-Demand — ou gerar incidente se você colocar a API monolítica lá sem plano. Este guia separa o que funciona do hype.

👉 Leia o artigo completo: https://finopspro.com.br/blog/spot-instances-aws-guia-pratico

— FinOps Pro
Publicar no LinkedIn Só o link

Artigos Relacionados