Spot Instances: Como Economizar até 90% em AWS, Azure e GCP em 2026

O Que São Spot Instances e Por Que Elas Merecem Sua Atenção

Se você trabalha com infraestrutura em nuvem, provavelmente já ouviu falar de Spot Instances. Mas se ainda não mergulhou nesse assunto, está deixando dinheiro na mesa — literalmente.

Em poucas palavras, Spot Instances são máquinas virtuais que aproveitam a capacidade ociosa dos data centers dos provedores de nuvem. Como ninguém está usando essa capacidade naquele momento, a AWS, Azure e GCP oferecem esses recursos com descontos que vão de 60% a impressionantes 90% em relação ao preço sob demanda. O truque? Quando a demanda por capacidade aumenta, o provedor pode interromper sua instância com pouco aviso prévio. É um trade-off justo, mas que exige planejamento.

E os números não mentem. Segundo o Kubernetes Cost Benchmark Report 2025, clusters rodando exclusivamente em Spot tiveram uma redução média de custos de 77%. Mesmo combinando instâncias on-demand com Spot, a economia ficou em 59%. São números que fazem qualquer CFO prestar atenção.

Neste guia, vamos destrinchar como as Spot Instances funcionam em cada um dos três grandes provedores, ver exemplos práticos com Terraform e Kubernetes, e entender as estratégias que realmente funcionam para maximizar a economia sem comprometer a resiliência das suas aplicações. Então, vamos lá.

Comparação Detalhada: Spot na AWS, Azure e GCP

AWS EC2 Spot Instances

A AWS foi quem inventou o conceito de Spot Instances, e continua sendo referência nesse espaço. Os descontos chegam a 90%, mas o modelo de precificação é o mais dinâmico entre os três provedores — estamos falando de uma média de 197 variações de preço por mês para cada tipo de instância em cada região. Isso mesmo, quase 200 mudanças mensais.

Características principais:

• Desconto: até 90% em relação ao preço on-demand
• Aviso de interrupção: 2 minutos antes da revogação
• Modelo de preço: flutuante, baseado em oferta e demanda em tempo real
• Taxa de interrupção média: inferior a 5% (historicamente, 95% das Spot rodam até o fim)
• Cobrança: por segundo, com mínimo de 60 segundos

Uma novidade relevante: em janeiro de 2026, a AWS lançou o EC2 Capacity Manager com métricas de interrupção de Spot. Na prática, isso dá uma visibilidade centralizada sobre o uso de capacidade Spot em toda a organização. As novas métricas incluem:

• Spot Usage Total Count: total de instâncias ou vCPUs Spot executadas em um período
• Spot Total Interruptions: número de instâncias interrompidas
• Spot Interruption Rate: percentual de instâncias que sofreram interrupções

Honestamente, isso é um divisor de águas para quem gerencia frotas grandes de Spot. Agora dá pra tomar decisões baseadas em dados reais, comparar regiões e zonas de disponibilidade, e ajustar a diversificação da frota com muito mais confiança.

Azure Spot Virtual Machines

As Azure Spot VMs oferecem até 80% de desconto. Menos que a AWS? Sim. Mas o modelo de precificação é bem mais previsível — as mudanças de preço acontecem menos de uma vez por mês em média. Para muitas equipes, essa estabilidade vale ouro.

Características principais:

• Desconto: até 80% em relação ao preço on-demand
• Aviso de interrupção: 30 segundos (via Azure Scheduled Events)
• Modelo de preço: relativamente estável
• Políticas de despejo: "Stop/Deallocate" (padrão) ou "Delete"
• Preço máximo: configurável pelo usuário

O grande diferencial do Azure aqui é a política "Stop/Deallocate". Em vez de simplesmente destruir a VM quando ela é despejada, o Azure a pausa — preservando discos e configuração. Quando a capacidade volta a ficar disponível, você pode retomá-la. Isso é fantástico para workloads que toleram pausas mas não querem perder estado.

GCP Spot VMs (antes chamadas Preemptible VMs)

O Google Cloud entra na disputa com descontos de até 91% — tecnicamente o maior desconto entre os três. E o modelo de precificação é o mais calmo: mudanças acontecem apenas algumas vezes por mês.

Características principais:

• Desconto: até 91% em relação ao preço on-demand
• Aviso de interrupção: 30 segundos (porém o Google não garante esse aviso)
• Modelo de preço: o mais estável dos três
• Sem limite de tempo: diferente das antigas Preemptible VMs (que tinham limite de 24h), as Spot VMs rodam indefinidamente
• Cobrança: se a VM for preemptada nos primeiros 60 segundos, não há cobrança

Um detalhe importante: se você ainda usa Preemptible VMs no GCP, vale a pena migrar para Spot VMs. O modelo legado tem aquele limite de 24 horas que não existe mais nas Spot VMs. Para novas implementações, vá direto de Spot VMs.

Tabela Comparativa

Característica	AWS Spot	Azure Spot	GCP Spot
Desconto máximo	até 90%	até 80%	até 91%
Aviso de interrupção	2 minutos	30 segundos	30 segundos*
Volatilidade de preço	Alta (~197 mudanças/mês)	Baixa (<1 mudança/mês)	Muito baixa
Limite de execução	Sem limite	Sem limite	Sem limite
Retomada após despejo	Não	Sim (Stop/Deallocate)	Não

* O GCP não garante o envio de notificação de preempção.

Quais Workloads Rodam Bem em Spot?

Nem tudo funciona em Spot Instances — e tudo bem. A ideia aqui não é migrar 100% da sua infra, mas identificar os workloads que são tolerantes a falhas e conseguem lidar com interrupções sem drama.

1. Processamento em Lote (Batch Processing)

Se o trabalho pode ser dividido em tarefas menores e independentes, é um candidato perfeito. Quando uma instância cai, você reexecuta só aquela tarefa específica, não o lote inteiro. Pense em ETL, renderização de vídeo, simulações científicas.

2. Pipelines de CI/CD

Build falhou porque a instância foi interrompida? Basta reiniciar. Pipelines de CI/CD são naturalmente resilientes e podem gerar uma economia expressiva quando movidos para Spot.

3. Containers e Microserviços Stateless

A grande maioria dos microserviços modernos não mantém estado local. Se um container morre, o Kubernetes redireciona o tráfego para outras réplicas e sobe um novo. Simples assim.

4. Treinamento de Machine Learning

Com checkpoints periódicos, interrupções viram apenas um pequeno inconveniente. Um caso real que vale mencionar: uma startup migrou 90% do treinamento para Spot e reduziu os gastos com GPU de US$ 800.000 para US$ 380.000 por mês — economia de 52%. Nada mal, não é?

5. Computação de Alta Performance (HPC)

Simulações, modelagem financeira, análises genômicas — tudo isso envolve tarefas paralelizáveis que distribuem naturalmente entre múltiplas instâncias Spot.

6. Ambientes de Dev e Teste

Esse talvez seja o caso mais óbvio. Interrupções em ambientes não-produtivos não afetam ninguém, e o custo de reiniciar é praticamente zero.

Implementação Prática com Terraform

Chega de teoria — vamos ver código. O Terraform é a ferramenta ideal para gerenciar Spot Instances de forma declarativa e reproduzível. Vou mostrar exemplos para cada provedor.

AWS Spot Instance com Terraform

# Requisição de Spot Instance na AWS
resource "aws_spot_instance_request" "worker" {
  ami                    = "ami-0abcdef1234567890"
  instance_type          = "m5.xlarge"
  spot_price             = "0.08"
  wait_for_fulfillment   = true
  spot_type              = "one-time"

  tags = {
    Name        = "spot-worker"
    Environment = "production"
    ManagedBy   = "terraform"
  }

  # Handler de interrupção
  user_data = <<-EOF
    #!/bin/bash
    # Script para lidar com interrupção Spot
    TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
      -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

    while true; do
      RESPONSE=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
        http://169.254.169.254/latest/meta-data/spot/instance-action)
      if [ "$RESPONSE" != "404" ]; then
        echo "Interrupção detectada. Iniciando graceful shutdown..."
        # Drena conexões e salva estado
        /opt/scripts/graceful-shutdown.sh
        break
      fi
      sleep 5
    done
  EOF
}

# Auto Scaling Group com estratégia mista
resource "aws_autoscaling_group" "mixed_fleet" {
  name                = "mixed-spot-ondemand"
  desired_capacity    = 6
  max_size            = 12
  min_size            = 2
  vpc_zone_identifier = var.subnet_ids

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 20
      spot_allocation_strategy                 = "capacity-optimized"
    }

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.worker.id
        version            = "$Latest"
      }

      override {
        instance_type = "m5.xlarge"
      }
      override {
        instance_type = "m5a.xlarge"
      }
      override {
        instance_type = "m5d.xlarge"
      }
      override {
        instance_type = "m4.xlarge"
      }
    }
  }
}

Repare na estratégia capacity-optimized no Auto Scaling Group — ela aloca instâncias nos pools com mais capacidade disponível, o que na prática reduz bastante a probabilidade de interrupções. E a diversificação de tipos (m5, m5a, m5d, m4) não é cosmética: é crucial pra manter disponibilidade.

Azure Spot VM com Terraform

# Spot VM no Azure
resource "azurerm_linux_virtual_machine" "spot_worker" {
  name                = "spot-worker-vm"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_D4s_v3"
  admin_username      = "adminuser"

  # Configuração de Spot
  priority        = "Spot"
  eviction_policy = "Deallocate"
  max_bid_price   = 0.08

  admin_ssh_key {
    username   = "adminuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }

  tags = {
    environment = "production"
    type        = "spot-worker"
  }
}

# Scale Set com Spot VMs
resource "azurerm_linux_virtual_machine_scale_set" "spot_fleet" {
  name                = "spot-fleet"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  sku                 = "Standard_D2s_v3"
  instances           = 4

  priority        = "Spot"
  eviction_policy = "Delete"
  max_bid_price   = -1  # Preço máximo = preço on-demand

  admin_username = "adminuser"

  admin_ssh_key {
    username   = "adminuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }
}

Uma dica valiosa aqui: definir max_bid_price = -1 no Azure significa que você aceita pagar até o preço on-demand. Parece contraintuitivo, mas isso reduz muito a chance de despejo por preço — suas interrupções ficam limitadas apenas a situações de capacidade insuficiente, que são bem mais raras.

GCP Spot VM com Terraform

# Spot VM no Google Cloud
resource "google_compute_instance" "spot_worker" {
  name         = "spot-worker"
  machine_type = "n2-standard-4"
  zone         = "us-central1-a"

  scheduling {
    preemptible                 = false
    automatic_restart           = false
    provisioning_model          = "SPOT"
    instance_termination_action = "STOP"
  }

  boot_disk {
    initialize_params {
      image = "ubuntu-os-cloud/ubuntu-2204-lts"
      size  = 50
    }
  }

  network_interface {
    network = "default"
    access_config {}
  }

  metadata_startup_script = <<-EOF
    #!/bin/bash
    # Registra handler de shutdown para lidar com preempção
    shutdown_handler() {
      echo "Preempção detectada. Salvando estado..."
      /opt/scripts/save-checkpoint.sh
    }
    trap shutdown_handler SIGTERM
  EOF

  labels = {
    environment = "production"
    type        = "spot-worker"
  }
}

# Managed Instance Group com Spot VMs
resource "google_compute_instance_group_manager" "spot_mig" {
  name               = "spot-mig"
  base_instance_name = "spot-worker"
  zone               = "us-central1-a"
  target_size        = 4

  version {
    instance_template = google_compute_instance_template.spot_template.id
  }

  auto_healing_policies {
    health_check      = google_compute_health_check.default.id
    initial_delay_sec = 120
  }
}

No GCP, o parâmetro provisioning_model = "SPOT" substituiu o antigo preemptible = true. E a opção instance_termination_action = "STOP" faz a instância ser parada (em vez de deletada) durante a preempção — preservando o disco pra quando você quiser retomá-la.

Spot Instances no Kubernetes com Karpenter

Se você já usa Kubernetes, Spot Instances são quase uma combinação natural. O K8s já sabe lidar com pods morrendo e se recuperando. Mas o que realmente turbina essa história é o Karpenter — o provisionador de nós da AWS que faz o gerenciamento de Spot em clusters EKS ficar surpreendentemente simples.

Configuração do Karpenter para Spot

# NodePool do Karpenter com suporte a Spot
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-workers
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m5.xlarge
            - m5a.xlarge
            - m5d.xlarge
            - m6i.xlarge
            - m6a.xlarge
            - c5.xlarge
            - c5a.xlarge
            - r5.xlarge
        - key: topology.kubernetes.io/zone
          operator: In
          values:
            - us-east-1a
            - us-east-1b
            - us-east-1c
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "100"
    memory: 400Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
---
# NodePool para workloads críticos (on-demand)
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: critical-ondemand
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m5.xlarge
            - m6i.xlarge
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "20"
    memory: 80Gi

O padrão aqui é clássico e muito eficaz: dois NodePools separados. Um pra workloads tolerantes a falhas (Spot) e outro pros críticos (on-demand). Note a diversificação com 8 tipos de instância e 3 zonas — quanto mais opções você dá ao Karpenter, melhor ele se vira quando a capacidade fica apertada.

Configurando Pods para Nós Spot

# Deployment tolerante a Spot
apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-processor
spec:
  replicas: 6
  selector:
    matchLabels:
      app: batch-processor
  template:
    metadata:
      labels:
        app: batch-processor
    spec:
      # Tolera nós Spot
      tolerations:
        - key: "karpenter.sh/capacity-type"
          operator: "Equal"
          value: "spot"
          effect: "NoSchedule"
      # Prefere nós Spot
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              preference:
                matchExpressions:
                  - key: karpenter.sh/capacity-type
                    operator: In
                    values:
                      - spot
      # Graceful shutdown
      terminationGracePeriodSeconds: 120
      containers:
        - name: processor
          image: myapp/batch-processor:latest
          resources:
            requests:
              cpu: "500m"
              memory: "1Gi"
            limits:
              cpu: "1000m"
              memory: "2Gi"
          lifecycle:
            preStop:
              exec:
                command:
                  - /bin/sh
                  - -c
                  - |
                    echo "Recebido sinal de terminação"
                    /app/save-checkpoint.sh
                    sleep 10
      # Pod Disruption Budget
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: batch-processor-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: batch-processor

Três pontos que fazem toda a diferença nessa configuração:

• terminationGracePeriodSeconds: 120 — casado com os 2 minutos de aviso da AWS. Tempo suficiente pra um shutdown limpo
• preStop hook — executa o checkpoint antes de encerrar. Seu progresso não se perde
• PodDisruptionBudget — garante que pelo menos 3 réplicas fiquem de pé, mesmo durante interrupções. Isso evita que uma onda de preempções derrube o serviço inteiro

Estratégia FinOps: A Abordagem 20/80

Na minha experiência, a estratégia que mais funciona na prática é a abordagem 20/80: você mantém 20-30% da capacidade em instâncias on-demand (ou Reserved/Savings Plans) para o que é crítico, e joga os 70-80% restantes para Spot. É pragmática, é testável, e escala bem.

A Estratégia em Camadas

Camada 1 — Base Estável (20-30%):

• Reserved Instances ou Savings Plans pra workloads de missão crítica
• Bancos de dados, APIs de autenticação, serviços de pagamento
• Zero tolerância a interrupções

Camada 2 — Spot com Alta Resiliência (40-50%):

• Microserviços stateless com múltiplas réplicas
• Servidores web e APIs com balanceamento de carga
• Fallback automático pra on-demand se houver interrupção massiva

Camada 3 — Spot Agressivo (20-30%):

• Processamento em lote, CI/CD, ambientes de dev/test
• Treinamento de ML com checkpoints
• Workloads que podem ser interrompidos sem ninguém perceber

Calculando o ROI

Vamos aos números — porque no fim das contas, é isso que convence a liderança:

# Cenário: Frota de 100 instâncias m5.xlarge em us-east-1
# Preço on-demand: $0,192/hora por instância

# Custo 100% on-demand (mensal):
100 instâncias × $0,192/h × 730h = $14.016/mês

# Estratégia 20/80 com Spot (desconto médio de 70%):
# 20 instâncias on-demand:
20 × $0,192/h × 730h = $2.803/mês

# 80 instâncias Spot (~$0,058/h com 70% desconto):
80 × $0,058/h × 730h = $3.387/mês

# Custo total com estratégia Spot:
$2.803 + $3.387 = $6.190/mês

# Economia mensal: $14.016 - $6.190 = $7.826/mês (55,8%)
# Economia anual: $93.912

E esse é um cenário conservador, com desconto de apenas 70%. Com descontos de 85-90% (que são bem comuns em instâncias de gerações anteriores), a economia pode ultrapassar US$ 120.000 anuais pra a mesma frota. Dinheiro suficiente pra contratar mais um engenheiro, por exemplo.

Boas Práticas para Manter Tudo Resiliente

Spot Instances são poderosas, mas exigem que sua arquitetura esteja preparada. Aqui vão as práticas que separam uma implementação bem-sucedida de uma dor de cabeça.

1. Diversifique os Pools de Instância

Nunca, jamais, dependa de um único tipo de instância ou zona de disponibilidade. O ideal é configurar de 6 a 10 tipos de instância compatíveis em pelo menos 3 zonas. Quanto mais diversificado, menor a chance de interrupções simultâneas na frota inteira.

2. Implemente Handlers de Interrupção

Toda aplicação rodando em Spot precisa de um handler de interrupção que saiba:

• Detectar o sinal de terminação (SIGTERM no K8s, metadados de instância na AWS)
• Salvar o estado atual em armazenamento persistente
• Drenar conexões de forma elegante
• Notificar sistemas de monitoramento

3. Checkpointing e Estado Persistente

Para workloads de longa duração, implemente checkpointing periódico — salve o progresso a cada 5-10 minutos em S3, Azure Blob Storage ou GCS. Quando uma nova instância sobe, ela retoma do último checkpoint. Veja um exemplo em Python:

import boto3
import signal
import json
import os

class SpotCheckpointManager:
    """Gerenciador de checkpoints para workloads em Spot Instances."""

    def __init__(self, bucket, prefix):
        self.s3 = boto3.client('s3')
        self.bucket = bucket
        self.prefix = prefix
        self.state = {}

        # Registra handler para SIGTERM
        signal.signal(signal.SIGTERM, self._handle_termination)

    def save_checkpoint(self, state_data):
        """Salva checkpoint no S3."""
        checkpoint_key = f"{self.prefix}/checkpoint-latest.json"
        self.s3.put_object(
            Bucket=self.bucket,
            Key=checkpoint_key,
            Body=json.dumps(state_data),
            ContentType='application/json'
        )
        print(f"Checkpoint salvo: {checkpoint_key}")

    def load_checkpoint(self):
        """Carrega o último checkpoint do S3."""
        checkpoint_key = f"{self.prefix}/checkpoint-latest.json"
        try:
            response = self.s3.get_object(
                Bucket=self.bucket, Key=checkpoint_key
            )
            return json.loads(response['Body'].read().decode('utf-8'))
        except self.s3.exceptions.NoSuchKey:
            return None

    def _handle_termination(self, signum, frame):
        """Handler chamado quando a instância recebe SIGTERM."""
        print("Sinal de terminação recebido! Salvando estado...")
        self.save_checkpoint(self.state)
        print("Estado salvo com sucesso. Encerrando gracefully.")
        exit(0)


# Uso
manager = SpotCheckpointManager(
    bucket='meu-bucket-checkpoints',
    prefix='job-processamento-dados'
)

# Tenta retomar do último checkpoint
last_state = manager.load_checkpoint()
start_index = last_state.get('last_processed', 0) if last_state else 0

# Processamento principal
for i in range(start_index, total_items):
    process_item(items[i])
    manager.state = {'last_processed': i + 1}

    # Salva checkpoint a cada 1000 itens
    if (i + 1) % 1000 == 0:
        manager.save_checkpoint(manager.state)

4. Fallback Automático para On-Demand

Configure mecanismos que provisionem instâncias on-demand automaticamente quando não houver capacidade Spot. Na AWS, isso é o on_demand_percentage_above_base_capacity do ASG. No Karpenter, crie NodePools que priorizem Spot mas aceitem on-demand como alternativa. Nunca fique sem compute porque a Spot acabou.

5. Monitoramento e Observabilidade

Sem visibilidade, você está voando às cegas. Monte dashboards que mostrem:

• Taxa de interrupção por tipo de instância e região
• Tempo médio de execução antes da interrupção
• Economia acumulada vs. custo on-demand
• Frequência de indisponibilidade de capacidade Spot
• Taxa de sucesso dos checkpoints e recuperações

Ferramentas de Automação e Gerenciamento

O ecossistema de ferramentas para Spot amadureceu bastante. Aqui estão as que mais se destacam em 2026:

AWS Spot Fleet e EC2 Fleet

Ferramentas nativas da AWS que permitem solicitar múltiplos tipos de instância Spot com uma única requisição. O EC2 Fleet suporta estratégias como capacity-optimized, lowest-price e diversified.

Karpenter

O provisionador open-source da AWS para Kubernetes. Provisiona nós just-in-time em 30-60 segundos, com suporte nativo a Spot. O Karpenter observa pods não agendáveis e cria nós com o tamanho ideal. Um recurso interessante é a consolidação Spot-to-Spot (habilitada via feature gate SpotToSpotConsolidation=true), que rearranja workloads entre nós Spot para otimizar custos.

CAST AI

Plataforma que usa ML preditivo pra identificar os pools de Spot mais estáveis, fazer rightsizing baseado em uso real de CPU e memória, e migrar containers ao vivo. A integração com o Karpenter é particularmente interessante pra quem quer otimização de nível enterprise.

Spot.io (NetApp)

Plataforma multi-cloud que abstrai a complexidade do gerenciamento de Spot, oferecendo SLAs de disponibilidade e fallback automático entre diferentes pools.

Erros Comuns (e Como Não Cometê-los)

Depois de ver dezenas de implementações de Spot, esses são os erros que aparecem com mais frequência:

Erro 1: Depender de um Único Tipo de Instância

O problema: usar só m5.xlarge numa única zona.

A solução: diversifique pra pelo menos 6 tipos (m5, m5a, m5d, m6i, m6a, c5) em 3+ zonas.

Erro 2: Pular o Graceful Shutdown

O problema: a aplicação morre abruptamente, sem salvar nada.

A solução: handlers de SIGTERM, preStop hooks no K8s, scripts de checkpoint. Não é opcional.

Erro 3: Rodar Workloads Stateful sem Proteção

O problema: banco de dados em Spot sem replicação. É receita pra desastre.

A solução: mantenha workloads stateful em on-demand/reserved, ou garanta replicação síncrona com failover automático.

Erro 4: Ignorar o Monitoramento de Custos

O problema: assumir que Spot sempre é mais barato sem conferir.

A solução: tags de alocação de custos, dashboards de FinOps e alertas pra anomalias.

Erro 5: Preço Máximo Muito Baixo

O problema: definir um bid ridiculamente baixo e ser despejado o tempo todo.

A solução: no Azure, use max_bid_price = -1. Na AWS, prefira capacity-optimized em vez de lowest-price.

Próximos Passos: Seu Roteiro para Spot

Implementar Spot Instances é uma jornada, não um switch que você liga de uma vez. Aqui vai um roteiro que funciona bem na prática:

Fase 1 — Piloto (Semanas 1-4):

1. Escolha 2-3 workloads tolerantes a falhas em dev/test
2. Implemente com Terraform
3. Configure monitoramento básico de interrupções e custos
4. Compare a economia real com a projetada

Fase 2 — Expansão (Meses 2-3):

1. Mova pipelines de CI/CD e batch processing pra Spot
2. Implemente handlers de interrupção e checkpointing
3. Adote a frota mista (on-demand + Spot)
4. Monte dashboards de FinOps dedicados

Fase 3 — Produção (Meses 3-6):

1. Migre microserviços stateless de produção
2. Implemente Karpenter (ou equivalente) pro Kubernetes
3. Estabeleça a abordagem 20/80 com fallback automático
4. Defina KPIs e metas de economia pro time de FinOps

Fase 4 — Otimização Contínua:

1. Use ferramentas de ML preditivo (como CAST AI) pra identificar pools mais estáveis
2. Analise métricas do EC2 Capacity Manager pra otimizar diversificação
3. Revise regularmente a proporção on-demand vs. Spot
4. Compartilhe resultados e boas práticas entre equipes

Conclusão

Spot Instances são, sem exagero, uma das melhores estratégias de otimização de custos em nuvem disponíveis hoje. Estamos falando de economias de 60% a 90% — números que transformam o orçamento de infraestrutura de qualquer empresa.

Mas (e sempre tem um mas) o sucesso depende de fazer o dever de casa: diversificar instâncias, construir arquiteturas resilientes, automatizar tudo que puder e monitorar constantemente. Com as ferramentas de 2026 — Karpenter, CAST AI, EC2 Capacity Manager — o caminho ficou muito mais acessível do que era há dois anos.

Minha recomendação? Comece pequeno. Escolha um workload de baixo risco, configure um piloto, meça os resultados. Em poucos meses, sua organização pode estar economizando dezenas — ou centenas — de milhares de dólares por ano. Dinheiro que pode (e deve) ser redirecionado pra inovação e crescimento.