AWS Auto Scaling (Grupos e Políticas)

O AWS Auto Scaling é o mecanismo nativo de elasticidade para instâncias EC2, ECS e outros recursos, e o Auto Scaling Group (ASG) é a sua peça central: um conjunto gerenciado de instâncias que se ajusta automaticamente entre limites mínimo e máximo conforme políticas de escala, substituindo instâncias não saudáveis e mantendo o balanceamento entre zonas de disponibilidade. Em produção, o ASG transforma infraestrutura em um sistema autorregulado: capacidade cresce em picos de demanda, encolhe em madrugadas, e instâncias defeituosas desaparecem sem plantão. O desenho correto exige mais do que ativar o recurso, porque políticas mal calibradas causam flapping, escala tardia em picos e custo desperdiçado em mínimos altos. A combinação de launch template, política de target tracking, health checks integrados ao ALB e instance refresh cobre o ciclo completo de vida da frota, da criação da instância à troca de AMI. Este arquivo detalha grupos, políticas e as práticas que separam um ASG maduro de um configurado por padrão.

Auto Scaling Group e launch template

O ASG define três números que governam a frota: min, max e desired. O min garante capacidade de piso, o max protege contra explosão de custo, e o desired é o alvo que as políticas de escala movem dinamicamente. O que rodará nas instâncias vem de um launch template, que especifica AMI, tipo de instância, security groups, role do IAM, user data e configurações de disco; separar template de grupo permite versionar a configuração e atualizá-la com instance refresh sem recriar o grupo.

A distribuição entre zonas é automática: o ASG espalha instâncias de forma equilibrada pelas sub-redes declaradas, e quando uma AZ degrada, as instâncias perdidas são recriadas nas demais. Esse comportamento é o fundamento da alta disponibilidade em EC2 e não deve ser contornado por preferências de zona.

Políticas de escalabilidade

O ASG oferece três famílias de política, cada uma para um padrão de demanda distinto, e a escolha correta é a maior alavanca de qualidade da escala.

O target tracking é a política padrão recomendada: você define a métrica e o alvo, e o serviço calcula os ajustes contínuos, com proteção embutida contra flapping. Métricas úteis de track incluem CPU média do grupo, número de requisições por target do ALB, latência p95 e métricas customizadas publicadas pela aplicação, como profundidade de fila processada por instância.

Uma prática relevante de calibragem é separar a sensibilidade de escala-out e scale-in: a entrada em escala precisa ser rápida o suficiente para proteger a experiência do usuário, enquanto a saída deve ser conservadora, evitando descartar capacidade em picos breves e reescalar logo em seguida. O target tracking já incorpora essa assimetria, e step scaling permite definir degraus explícitos quando o comportamento precisa ser auditável e previsível por parte do time.

# Grupo com launch template e três zonas
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name prod-api-asg \
  --launch-template LaunchTemplateName=prod-api-lt,Version='$Latest' \
  --min-size 3 --max-size 30 --desired-capacity 6 \
  --vpc-zone-identifier "subnet-a,subnet-b,subnet-c" \
  --target-group-arns arn:aws:elasticloadbalancing:...:targetgroup/api/tg \
  --health-check-type ELB --health-check-grace-period 120 \
  --default-cooldown 180

# Target tracking: CPU média de 60% do grupo
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name prod-api-asg \
  --policy-name cpu-60 --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 60.0,
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"}
  }'

# Escala agendada para pico de campanha
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name prod-api-asg \
  --scheduled-action-name pico-black-friday \
  --start-time 2025-11-27T10:00:00Z \
  --min-size 10 --max-size 40 --desired-capacity 20

Health checks e substituição automática

O ASG pode considerar uma instância não saudável por três sinais: status do EC2, health check do ELB e health check customizado do sistema. O health check do ELB é o padrão de produção para instâncias atrás de load balancer, porque captura falhas que o hypervisor não percebe, como aplicação travada respondendo erros 5xx. Ao detectar saúde ruim após o período de graça, o ASG encerra a instância e lança outra do launch template, mantendo o desired.

O período de graça existe para não matar instâncias durante o bootstrap: aplicações que demoram minutos para aquecer cache e conectar dependências precisam de um valor compatível, e essa calibragem evita o loop clássico de instâncias mortas ao nascer. Para substituição proposital, a desconexão com lifecycle hooks permite drenar conexões, exportar logs e executar encerramento limpo antes do terminate.

Instance refresh: troca de frota para novas AMIs

Quando a AMI ou a configuração do launch template muda, o instance refresh substitui a frota de forma controlada, criando instâncias novas em ondas, respeitando um percentual mínimo de instâncias saudáveis e reverte automaticamente se a nova versão não convergir nos health checks. É o equivalente do rolling deployment para a infraestrutura, e elimina o antigo padrão manual de atualizar um grupo instância por instância.

# Inicia troca gradual da frota para a nova versão do template
aws autoscaling start-instance-refresh \
  --auto-scaling-group-name prod-api-asg \
  --preferences '{
    "MinHealthyPercentage": 90,
    "InstanceWarmup": 120,
    "CheckpointPercentages": [20, 50, 100],
    "CheckpointDelay": 300
  }'

Os checkpoints fazem a troca parar em percentuais intermediários para validação, uma prática valiosa quando a nova AMI traz mudança de sistema operacional, versão de runtime ou agentes de observabilidade. Combinado com pipeline de AMI dourada, o instance refresh automatiza o ciclo de patching de frota inteiro.

Cooldown, warm-up e estabilidade da escala

O cooldown é o intervalo mínimo entre ações de escala no mesmo grupo, evitando decisões em rajada enquanto métricas ainda refletiam o estado anterior; o default é 300 segundos em políticas simples, e target tracking controla a dinâmica internamente. O warm-up é o tempo até a instância nova estar pronta para receber carga na mesma proporção das antigas, e negligenciá-lo causa o efeito dobradiça: a métrica de CPU dispara ao entrar instância fria, o grupo escala mais, e o ciclo se repete até o teto.

A regra prática: meça o tempo real do bootstrap, da inicialização do processo ao primeiro health check saudável, e configure warmup e grace period ligeiramente acima desse valor. O cooldown complementa com folga para as métricas se assentarem, e as políticas de escala-out e scale-in bem separadas evitam oscilação permanente.

Integração com ALB e balanceamento entre zonas

O casamento ASG e ALB é o padrão de entrada de tráfego em EC2: cada instância nasce registrada no target group, os health checks do ALB decidem a saúde percebida, e o ASG reage a essa saúde substituindo instâncias. O desacoplamento é limpo: o ALB cuida da distribuição de requisições, o ASG cuida da quantidade de instâncias, e cada um tem métricas próprias de política.

O balanceamento entre zonas do ALB distribui requisições entre zonas proporcionalmente aos targets saudáveis de cada zona, e o ASG mantém a frota equilibrada, de modo que o conjunto garante que nenhuma zona concentre capacidade. Em picos, a escala do ASG registra as instâncias novas no target group em segundos, e o draining do ALB assegura que requisições em voo terminem antes de remover instâncias encerradas.

Lifecycle hooks: entrada e saída controladas

Os lifecycle hooks pausam a transição de estado de uma instância para permitir ações customizadas antes que ela entre em serviço ou seja encerrada. É o gancho oficial para bootstrap pesado, registro em catálogo de serviços, drenagem de conexões e exportação de logs.

O hook aguarda por um timeout configurável, que pode ser encerrado antecipadamente por sinal de conclusão do script de bootstrap ou de limpeza. Em produção, a automação dos hooks via Lambda e EventBridge cobre casos como rotulação dinâmica, integração com CMDB e teardown ordenado de dependências locais da instância.

Aplicação prática: desenho de um ASG de produção

Um ASG de produção maduro combina os elementos anteriores em uma configuração deliberada: min 3 para sobreviver à falha de uma AZ, max definido por teste de carga e orçamento, target tracking de CPU em 60% ou de requisições por instância, health check ELB com grace period medido, cooldown de 180 a 300 segundos, instance refresh automático a cada atualização de AMI no pipeline, e alarmes de proximidade de max, que indicam saturação estrutural antes da falha.

Esse desenho atende tanto a demanda repentina quanto a troca de versão, e os limites min e max têm dono e justificativa documentados. Quando o padrão de tráfego é previsível, políticas scheduled sobrepostas ao target tracking antecipam capacidade e evitam a latência de reação, e o predictive scaling aprende o padrão histórico quando o volume de dados é suficiente.

Erros comuns e boas práticas

• Configurar target de CPU muito alto, como 90%, e escalar tarde demais; alvos entre 50% e 70% reservam folga para a latência de criação de instância.
• Deixar max indefinidamente alto e descobrir custo exorbitante em loop de escala; o max é controle de custo, não só de capacidade.
• Usar health check apenas de EC2 atrás de ALB, mantendo instâncias travadas recebendo tráfego; habilite health check ELB.
• Ignorar warm-up e sofrer flapping com instâncias frias distorcendo métricas; meça o bootstrap real e configure o período.
• Alterar launch template direto em produção; versione templates em IaC e troque frota com instance refresh controlado.
• Criar ASG em uma única sub-rede; declare sub-redes de múltiplas AZs para que o balanceamento automático funcione.
• Esquecer lifecycle hooks de encerramento, perdendo logs e conexões ativas no terminate; drene e finalize com limpeza.
• Não alarmar a proximidade do max; um alarme em 80% do max sinaliza que a arquitetura precisa de revisão antes do teto.
• Rodar degradação de escala-in com instâncias de estado local não replicado; dados de sessão e disco local devem viver fora da instância.

Como prática consolidada, trate o ASG como código com parâmetros revisados por teste de carga, mantenha AMI dourada atualizada por pipeline, e audite mensalmente as políticas contra a demanda real. Um grupo bem calibrado é silencioso: escala sobe e desce, instâncias ruins somem, e o plantão só é acionado para o que realmente importa.