Como reduzir custo na AWS com auto-scaling

Índice

1. O problema do custo na nuvem
2. Auto-scaling: o gancho principal
3. Spot Instances: poder de fogo por menos
4. Right-sizing: o tamanho certo
5. Reserved Instances e Savings Plans
6. Cálculo real de economia
7. Monitoramento e alertas
8. Erros comuns

O problema do custo na nuvem {#o-problema}

A nuvem tem uma pegadinha silenciosa. No modelo tradicional, você comprava um servidor por R$ 10.000 e ele era seu para sempre. Na nuvem, você paga por hora — R$ 0,10 parece barato, mas 24 horas × 365 dias = R$ 876/ano por servidor. E raramente são só um.

Analogia: é como um táxi. Uma corrida de R$ 15 é barata. Mas se você usa táxi todo dia, várias vezes ao dia, no fim do mês gastou mais do que compraria um carro. A nuvem cobra por uso — e o uso, sem supervisão, só cresce.

O problema se agrava por três motivos:

1. Recursos ficam esquecidos: alguém cria um servidor para testar, esquece de apagar, ninguém percebe. Meses depois, você está pagando por algo que ninguém usa.
2. Sizing errado: servidores superdimensionados (maiores que o necessário) rodam por meses usando 10% da capacidade — você paga por 100%.
3. Sem elasticidade: servidores rodam 24/7 no mesmo tamanho, mesmo quando o tráfego cai 80% à noite.

A boa notícia: dá para cortar 40-60% da conta sem perder performance. Vamos ver como.

Auto-scaling: o gancho principal {#auto-scaling}

Auto-scaling (escalonamento automático) é a prática de adicionar ou remover servidores automaticamente conforme a demanda.

Analogia: imagine uma loja que tem 2 caixas. De segunda a quarta, é suficiente. Na sexta à tarde, a fila explode — a loja abre mais 4 caixas. No sábado de manhã, sem movimento, fecha 2. A loja não mantém 6 caixas abertas o tempo todo — só quando precisa.

Na AWS, o Auto Scaling Group (ASG) faz exatamente isso com instâncias EC2 (servidores). Você define um mínimo, um máximo e regras de quando escalar.

Como funciona um ASG

Um ASG precisa de três coisas:

1. Launch template (modelo de inicialização): a "receita" do servidor — tipo de instância, imagem (AMI), rede, regras de segurança.
2. Grupo de subnets: em quais zonas (datacenters) os servidores podem ser criados.
3. Políticas de escalonamento: as regras que dizem quando adicionar ou remover instâncias.

# Terraform: Auto Scaling Group básico

resource "aws_launch_template" "web" {
  name_prefix   = "web-"
  image_id      = "ami-0c7217cdde317cfec"  # Amazon Linux 2023
  instance_type = "t3.micro"
  key_name      = "minha-chave"

  user_data = base64encode(<<-EOF
    #!/bin/bash
    # user_data = script executado quando o servidor nasce
    yum install -y nginx
    systemctl start nginx
  EOF
  )
}

resource "aws_autoscaling_group" "web" {
  name                = "web-asg"
  vpc_zone_identifier = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  desired_capacity    = 2   # Quantos servidores queremos agora
  min_size            = 2   # Mínimo — nunca menos que isso
  max_size            = 10  # Máximo — limite de custo

  launch_template {
    id      = aws_launch_template.web.id
    version = "$Latest"
  }
}

Políticas de escalonamento

Existem três tipos principais:

# Política target tracking: mantém CPU média em 50%
resource "aws_autoscaling_policy" "web_cpu" {
  name                   = "web-cpu-policy"
  autoscaling_group_name = aws_autoscaling_group.web.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 50.0  # Mantém CPU em 50%
  }
}

Com essa configuração:

• Se CPU passar de 50%, o ASG adiciona servidores
• Se CPU cair, o ASG remove servidores (até o mínimo de 2)
• Nunca passa de 10 servidores (limite de custo)

A economia do auto-scaling

Considere uma aplicação com tráfego previsível:

Sem ASG, você mantém 5 servidores sempre (no pico, talvez não aguente; fora do pico, você paga demais). Com ASG, o número varia de 2 a 8 — e a média diária é ~4,2 servidores em vez de 5. Mas a grande economia está em combinar com Spot Instances (próxima seção).

Spot Instances: poder de fogo por menos {#spot}

Spot Instances são servidores AWS que ficaram sobrando, oferecidos com desconto de até 90%. O truque: a AWS pode interromper seu servidor com 2 minutos de aviso quando precisar da capacidade de volta.

Analogia: é como aquelas passagens de última hora que as companhias aéreas vendem barato para não voar com assentos vazios. O preço é ótimo, mas se alguém aparecer com bilhete cheio, você cede o lugar.

Quando usar Spot Instances

Configurando Spot no ASG

resource "aws_autoscaling_group" "web" {
  name                = "web-asg-spot"
  vpc_zone_identifier = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  desired_capacity    = 4
  min_size            = 2
  max_size            = 12

  # Mix: 2 On-Demand (garantidos) + resto Spot
  mixed_instances_policy {
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.web.id
        version            = "$Latest"
      }

      # Spot: usa tipos equivalentes para aumentar chance de conseguir
      override {
        instance_type = "t3.micro"
      }
      override {
        instance_type = "t3a.micro"   # Variante AMD (equivalente)
      }
      override {
        instance_type = "t2.micro"    # Geração anterior (equivalente)
      }
    }

    instances_distribution {
      on_demand_base_capacity                  = 2  # 2 servidores garantidos
      on_demand_percentage_above_base_capacity = 0  # Resto 100% Spot
      spot_allocation_strategy                 = "price-capacity-optimized"
    }
  }
}

Essa configuração garante 2 servidores On-Demand (pagos cheio, nunca caem) e preenche o resto com Spot. Se Spot cair, o ASG recria em outro tipo equivalente automaticamente.

Preços comparativos (us-east-1, 2026)

Dica: sempre configure um Spot Instance interruption handler — um script que detecta o aviso de 2 minutos e drena o servidor graciosamente antes da queda. No Kubernetes, o Node Termination Handler faz isso automaticamente.

Right-sizing: o tamanho certo {#right-sizing}

Right-sizing é o processo de ajustar cada servidor para o tamanho que ele realmente precisa — nem mais, nem menos.

Analogia: você não usa um caminhão para entregar uma pizza, nem uma bicicleta para transportar mudança. Cada carga precisa do veículo certo. Na nuvem, a mesma lógica: se seu servidor usa 10% de CPU e 20% de memória, ele está superdimensionado.

Como identificar oportunidades de right-sizing

Use o AWS Compute Optimizer (serviço gratuito da AWS) ou ferramentas como CloudWatch e Datadog para ver o uso real de cada instância durante 2-4 semanas.

Procure por:

• CPU média < 30%: a instância está grande demais
• CPU média > 80%: está pequena demais (e pode estar lenta)
• Memória média < 40%: superdimensionada (requere CloudWatch Agent para métricas de memória, que a AWS não coleta por padrão)
• Network < 10%: superdimensionada

Famílias de instâncias EC2

A AWS tem dezenas de famílias. As mais comuns:

Dica de economia: a variante "a" (t3a, m5a, c5a) usa processadores AMD em vez de Intel. São ~10% mais baratas e equivalentes em performance para a maioria dos casos.

Exemplo prático de right-sizing

Antes: 5 instâncias m5.xlarge (4 vCPUs, 16GB RAM), uso médio de CPU 15% e memória 25%.

Depois: 5 instâncias t3.medium (2 vCPUs, 4GB RAM), capacidade suficiente para o workload real.

Atenção: t3 é uma instância burstable (permite picos curtos de CPU usando créditos). Se sua app tem CPU sustentada alta, t3 não serve — use m5 ou c5. Monitore os créditos de CPU (CPUSurplusCredits no CloudWatch).

Reserved Instances e Savings Plans {#reservas}

Se você tem servidores que rodam 24/7 (e não podem ser Spot), pode comprometer com a AWS por 1 ou 3 anos em troca de desconto.

Existem duas opções principais:

Reserved Instances (RI)

Você reserva um tipo específico de instância em uma região específica por 1 ou 3 anos. Descontos de 30-72% sobre o preço On-Demand.

Savings Plans

Você se compromete a gastar um valor por hora em computação (ex.: $1/h) por 1 ou 3 anos. Mais flexível que RI — qualquer tipo de instância, qualquer região, desde que some o valor comprometido. Descontos similares.

Estratégia recomendada

A combinação ideal para a maioria das empresas:

1. Baseline em Savings Plans/RI: comprometa 60-70% do uso previsível (servidores que rodam sempre)
2. Spot para o elástico: use Spot no ASG para a capacidade variável
3. On-Demand para o resto: o que sobra para picos imprevisíveis

Exemplo de composição de uma frota de 20 servidores:

Comparado a 20 servidores On-Demand ($1.380/mês), a economia é 46%.

Cálculo real de economia {#calculo}

Vamos juntar tudo em um cenário realista.

Cenário inicial (sem otimização)

Uma startup tem 8 instâncias m5.large rodando 24/7 na us-east-1, sem auto-scaling, tudo On-Demand.

• Preço On-Demand m5.large: $0,096/h
• 8 instâncias × $0,096 × 730h = $561/mês

Cenário otimizado

Aplicando as quatro estratégias:

1. Right-sizing: 8 × m5.large → 6 × t3.medium (suficiente para o workload)
2. Auto-scaling: em vez de 6 fixos, mínimo 2 + máximo 10 (média ~4/dia)
3. Spot: ASG misto — 2 On-Demand + resto Spot
4. Savings Plan: as 2 On-Demand em Savings Plan de 1 ano

Cálculo:

Claro, 89% é otimista (depende do tráfego ser muito variável). Um cenário mais conservador, com menos variação, ficaria em 50-60% de economia — ainda extremamente significativo.

Outras otimizações rápidas

Monitoramento e alertas {#monitoramento}

Otimização não é evento único — é processo contínuo. Sem monitoramento, o custo volta a crescer.

AWS Cost Explorer

Ferramenta gratuita da AWS que mostra seus gastos por serviço, por região, por tag. Use para:

• Identificar tendências de crescimento
• Ver quais serviços mais consomem
• Filtrar por tag (ex.: Environment=prod)

AWS Budgets

Crie alertas de orçamento para ser avisado antes de estourar:

# Alerta quando gasto mensal passar de $500
resource "aws_budgets_budget" "monthly" {
  name              = "orcamento-mensal"
  budget_type       = "COST"
  limit_amount      = "500"
  limit_unit        = "USD"
  time_period_end   = "2087-06-15_00:00"
  time_period_start = "2026-01-01_00:00"
  time_unit         = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80    # Avisa ao chegar em 80% ($400)
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["finops@minhaempresa.com"]
  }
}

Tags: a base da governança

Sem tags, é impossível saber quem gastou o quê. Defina tags obrigatórias:

Use AWS Tag Policies para obrigar que todo recurso seja criado com essas tags.

Erros comuns {#erros-comuns}

1. Auto-scaling sem cooldown

Problema: sem período de cooldown (resfriamento), o ASG pode adicionar e remover servidores freneticamente — "thrashing". CPU sobe, adiciona; CPU cai, remove; CPU sobe de novo...

Solução: defina um cooldown de 300s (5 minutos) entre ações de escalonamento.

2. Mínimo do ASG muito alto

Problema: definir min_size = 5 "para garantir". À noite, com 0 tráfego, você mantém 5 servidores rodando sem necessidade.

Solução: o mínimo deve ser o número de servidores que aguenta seu tráfego de vale (mínimo do dia), não o de pico. Combinado com Spot, pode ser baixo.

3. Usar Spot para banco de dados

Problema: Spot cai sem aviso (com 2 min), banco cai, aplicação para, dados podem corromper.

Solução: banco de dados sempre em On-Demand ou RI/Savings Plans. Spot é para camada de aplicação (stateless, sem estado) que tolera quedas.

4. Comprar Reserved Instance sem analisar histórico

Problema: comprometer 1-3 anos em um tipo de instância que você pode não precisar mais depois de right-sizing.

Solução: faça right-sizing antes de comprar RI. Depois de estabilizar os tipos, compre RI para a baseline. Comece com Savings Plans (mais flexível) se inseguro.

5. Ignorar egress (transferência de dados)

Problema: focar só em EC2 e esquecer que transferência de dados entre regiões ou para a internet custa caro. Uma app que transfere 1TB/mês para clientes pode pagar $90 só de egress.

Solução: use CloudFront (CDN da AWS) para cachear conteúdo perto dos usuários — reduz tanto egress quanto latência. Transferência entre disponibilidades (AZs) na mesma região também cobra: evite arquiteturas que falam entre AZs excessivamente.

Precisa de ajuda com otimização de custos na AWS? A Inicialize Tec implementa auto-scaling, right-sizing e estratégias de Reserved/Spot para reduzir sua conta em até 60%. Conversamos sobre seu caso.