AWS SAA-C03/03 - Computação2 min

Auto Scaling

Perguntas-guia

Responda com suas palavras antes de ler o resto da nota.

Que problema isso resolve?
Quando usar / quando NÃO usar?
Qual o principal trade-off (custo, latência, operação)?
Que sinal no enunciado aponta pra isso?
Com o que isso é confundido na prova?

Conceito

Auto Scaling Group (ASG) mantém um número saudável de instâncias entre um mínimo e um máximo, substituindo o que falha e acompanhando a demanda.

Peças: Launch Template (o molde da instância) + min / desired / max + AZs + health check + política de escala.

Políticas de escala

Política	Como funciona	Use quando
Target Tracking	Mantém uma métrica num alvo (ex: CPU em 60%)	Padrão — mais simples, cobre a maioria
Step Scaling	Degraus por faixa de alarme	Reagir diferente conforme a severidade
Simple Scaling	Um ajuste por alarme + cooldown	Legado
Scheduled	Hora marcada	Pico previsível (Black Friday, 8h)
Predictive	ML prevê e escala antes	Padrão cíclico recorrente

Health check: EC2 vs ELB

EC2: olha o status da instância (hardware/SO).
ELB: olha se a instância responde à requisição.

Se o app trava mas o SO continua vivo, só o health check do ELB detecta. Isso é questão recorrente.

Detalhes que caem

Cooldown evita escalar de novo antes de estabilizar (padrão 300 s).
Warm-up ignora a métrica da instância nova enquanto ela sobe.
Lifecycle hooks pausam a instância em Pending ou Terminating pra você instalar algo ou drenar conexão.
Termination policy padrão: equilibra AZs, depois mata a de launch template mais antigo, depois a mais perto da hora cheia de faturamento.
ASG em múltiplas AZs é o que dá alta disponibilidade — uma AZ só não basta.
ASG com mix On-Demand + Spot reduz custo mantendo uma base garantida.

Trade-offs

Escalar por CPU é o reflexo automático e frequentemente errado: numa arquitetura com fila, a métrica certa é o tamanho da fila (ApproximateNumberOfMessagesVisible), porque o worker pode estar ocioso em CPU e com backlog gigante. Escalar rápido demais gera thrashing e custo; devagar demais derruba a experiência.

Sinais de prova

"Escalar conforme o backlog de mensagens" → target tracking na métrica da SQS, não CPU
"Pico previsível de horário" → Scheduled scaling
"App trava mas a instância continua rodando" → health check do tipo ELB
"Alta disponibilidade" → ASG em múltiplas AZs + ELB
"Executar script antes de terminar a instância" → lifecycle hook
"Reduzir custo mantendo capacidade base" → ASG com mix On-Demand/Spot

Relacionado

Parte de 03 - MOC Computação · Documentação AWS