Resumo

Imagine que sua aplicação roda em 2 instâncias EC2. Numa Black Friday, o tráfego multiplica por 10 — as 2 instâncias saturam e o site cai. No dia seguinte, o tráfego volta ao normal, mas você esqueceu de desligar as instâncias extras e paga por capacidade ociosa o mês inteiro.

Auto Scaling Group (ASG) resolve esse problema: é o serviço que ajusta automaticamente quantas instâncias EC2 existem, seguindo regras que você define — para cima quando a demanda sobe, para baixo quando ela cai, sempre respeitando limites mínimos e máximos.

• ASG: gerencia um conjunto de instâncias, definindo tamanho mínimo, desejado e máximo.
• Launch Template: o "molde" que diz ao ASG qual AMI, tipo de instância e configuração usar ao criar uma instância nova.
• Políticas de scaling: as regras que decidem quando o ASG aumenta ou reduz a capacidade (Target Tracking, Step, Simple, Scheduled, Predictive).
• Mixed instances policy: combina On-Demand e Spot numa única ASG para otimizar custo sem perder disponibilidade.

---

1. O que é um Auto Scaling Group, na prática

Um ASG é definido por três números:

• Minimum capacity: o piso. O ASG nunca deixa a quantidade de instâncias cair abaixo disso, mesmo sem tráfego nenhum.
• Desired capacity: quantas instâncias o ASG tenta manter rodando agora. É esse número que sobe ou desce quando uma política de scaling age.
• Maximum capacity: o teto. Protege seu bolso — o ASG nunca escala além disso, mesmo que a métrica continue subindo.

Exemplo: min=2, desired=2, max=10. Em operação normal, 2 instâncias rodam. Se o CPU médio disparar, uma política de scaling aumenta o desired — digamos, para 5 — e o ASG lança 3 instâncias novas automaticamente. Se depois o tráfego cair, o desired volta a diminuir e o ASG termina as instâncias excedentes.

O ASG não sabe sozinho o que colocar dentro de cada instância nova. Isso vem do Launch Template: um molde reutilizável com AMI, tipo de instância, security groups, chave SSH, user data etc. (o Launch Configuration é a versão antiga do mesmo conceito — ainda aparece em provas mais antigas, mas está sendo descontinuado; a AWS recomenda Launch Template para tudo hoje).

---

2. Políticas de scaling — o "quando" e o "quanto"

Todas as políticas abaixo fazem a mesma coisa no fundo: mudam o desired capacity. A diferença está em como elas decidem o novo valor.

2.1 Target Tracking

Você define uma métrica-alvo (ex: "CPU médio em 60%") e o ASG cuida do resto — como um termostato. Se o CPU sobe pra 80%, o ASG adiciona instâncias até a média voltar a 60%. Se cai pra 30%, remove instâncias até subir de volta a 60%.

É a política recomendada pela AWS para a maioria dos casos, porque você não precisa calcular thresholds manualmente.

2.2 Step Scaling

Você define faixas (steps) e uma ação para cada uma. Exemplo:

Dá mais controle fino que o Target Tracking, mas exige que você desenhe os degraus manualmente.

2.3 Simple Scaling

O ancestral do Step Scaling: uma única ação por alarme (ex: "se CPU > 70%, adicione 1 instância"), sem faixas. Depois de agir, espera o cooldown period terminar antes de avaliar de novo. É a opção menos usada hoje — a prova costuma cobrá-la mais para você reconhecer a diferença para Step Scaling do que para recomendá-la.

2.4 Scheduled Scaling

Para picos previsíveis: "todo dia útil às 9h, suba o desired para 10; às 18h, volte para 2." Não depende de métrica nenhuma — é um agendamento, tipo um cron job de capacidade. Ideal para sistemas com padrão de tráfego conhecido (horário comercial, campanhas com data marcada).

2.5 Predictive Scaling

Usa machine learning (analisando histórico de uso) para antecipar picos recorrentes e escalar antes deles acontecerem, em vez de reagir depois que a métrica já subiu. Útil quando o "aquecimento" da instância (boot + inicialização da aplicação) demora e reagir tarde significa alguns minutos de degradação.

💡 Regra prática para a prova: padrão conhecido e fixo → Scheduled. padrão variável reagindo a métrica → Target Tracking/Step. padrão recorrente mas quer antecipar → Predictive.

---

3. Cooldown period — por que ele existe

Depois que uma ação de scaling acontece, a instância nova leva um tempo para "esquentar" — subir o sistema operacional, iniciar a aplicação, começar a responder de verdade. Se o ASG avaliasse a métrica de novo imediatamente, ele ainda veria CPU alto (porque a instância nova ainda não está ajudando) e escalaria de novo, desnecessariamente.

O cooldown period é uma pausa (padrão: 300 segundos) depois de uma ação de scaling, durante a qual o ASG não reage a novos alarmes. Isso evita reação exagerada a um pico momentâneo que já está sendo resolvido.

Exemplo: CPU sobe para 85%, ASG adiciona 2 instâncias, entra em cooldown de 5 minutos. Durante esse tempo, mesmo que o alarme dispare de novo, o ASG não age — ele está "esperando o efeito da última ação aparecer".

⚠️ Cooldown se aplica principalmente a Simple Scaling e Step Scaling. Target Tracking tem sua própria lógica de espera interna, mais dinâmica.

---

4. Health checks — como o ASG sabe que uma instância está "boa"

• EC2 health check: pergunta só ao hypervisor "essa instância está rodando (status running)?". Não sabe nada sobre a aplicação dentro dela — uma instância pode estar running com a aplicação travada, e ainda assim passar nesse check.
• ELB health check: além do status EC2, também considera o resultado do health check configurado no Load Balancer (ex: GET /health retornando 200). É mais preciso porque valida que a aplicação está respondendo, não só que a máquina está ligada.

Se uma instância falha no health check, o ASG a marca como não saudável e a substitui automaticamente — esse é um dos motivos centrais de usar ASG: auto-cura, não só auto-scaling.

Health check grace period: tempo que o ASG espera após lançar uma instância antes de começar a checar sua saúde — dá tempo da aplicação inicializar sem ser terminada precocemente por ainda não estar respondendo.

---

5. Lifecycle hooks — pausando o ciclo de vida

Por padrão, uma instância passa direto por estados como Pending → InService (ao subir) e Terminating → Terminated (ao descer). Um lifecycle hook insere uma pausa nesse fluxo — Pending:Wait ou Terminating:Wait — para você rodar uma ação customizada antes de continuar.

Casos de uso reais:

• Antes de terminar uma instância: drenar conexões ativas, copiar logs, remover a instância do sistema de monitoramento.
• Antes de colocar uma instância nova em serviço: rodar configuração adicional, registrar em um service discovery, baixar segredos.

Sem lifecycle hook, essas ações teriam que acontecer de forma reativa (ou nem aconteceriam) — o hook garante que o ASG espera você terminar antes de seguir.

---

6. Warm pools

Problema: se sua aplicação demora 5 minutos para inicializar (boot pesado, cache warm-up, dependências), um scale-out reativo a um pico de tráfego chega tarde — o pico já passou (ou piorou) até a instância ficar pronta.

Warm pool mantém um conjunto de instâncias pré-inicializadas, mas em estado parado (stopped) ou hibernado, fora do grupo "ativo" que recebe tráfego. Quando o ASG precisa escalar, ele pega instâncias do warm pool (que já passaram pela parte lenta do boot) em vez de criar do zero — reduzindo drasticamente o tempo até a instância estar pronta para tráfego.

---

7. Mixed instances policy — combinando Spot e On-Demand

Uma única ASG pode misturar tipos de compra:

• On-Demand: mais caro, mas nunca é interrompido pela AWS. Bom para a capacidade baseline (o mínimo que sempre precisa estar de pé).
• Spot: até 90% mais barato, mas a AWS pode retomar a instância a qualquer momento com 2 minutos de aviso. Bom para capacidade extra, tolerante a interrupção.

Configurações importantes:

• Allocation strategy (como escolher entre os pools de Spot disponíveis):
  • lowest-price: sempre pega o Spot mais barato disponível no momento.
  • capacity-optimized: prioriza pools com menor chance de interrupção, mesmo que não seja o mais barato — melhor quando disponibilidade importa mais que centavos.
• Instance weighting: permite dizer que uma instância maior "vale" por 2 ou 4 unidades de capacidade, útil quando você mistura tamanhos diferentes de instância na mesma ASG.

Exemplo de exam: "70% Spot, 30% On-Demand" significa que a base de disponibilidade fica garantida em On-Demand, e a maior parte do custo variável é otimizada via Spot.

---

8. Termination policy — qual instância morre no scale-in

Quando o ASG precisa reduzir capacidade, ele precisa escolher qual(is) instância(s) terminar. Por padrão, a lógica considera, nessa ordem:

1. Instância na AZ com mais instâncias no momento (mantém o grupo balanceado entre AZs).
2. Dentro dessa AZ, a instância mais próxima do próximo ciclo de cobrança por hora (para aproveitar o tempo já pago).
3. Se ainda houver empate, escolhida aleatoriamente.

Você pode customizar essa ordem (ex: OldestInstance, NewestInstance, ClosestToNextInstanceHour) ou proteger instâncias específicas contra scale-in com instance protection.

---

9. Scaling baseado em métricas customizadas (ex: fila SQS)

Nem toda decisão de escala vem de CPU. Um padrão clássico: uma fila SQS acumulando mensagens porque os workers não dão conta. Você pode escalar o ASG de workers usando uma métrica customizada — por exemplo, "mensagens visíveis na fila por instância" — via Target Tracking com métrica customizada, em vez de uma métrica padrão do EC2. Isso alinha a capacidade de processamento ao volume de trabalho real, não a um proxy indireto como CPU.

---

10. AZ Rebalancing e suspensão de processos

• AZ Rebalancing: se uma Availability Zone ficar indisponível e depois voltar, o ASG rebalanceia automaticamente as instâncias entre as AZs configuradas, para manter distribuição uniforme.
• Suspending processes: é possível pausar processos específicos do ASG (ex: AlarmNotification, Terminate) temporariamente — útil durante manutenções, para impedir que o ASG reaja enquanto você mexe manualmente nas instâncias.

---

11. Boas práticas

• Defina min/max realistas e alarmes de CloudWatch associados, para não sub-provisionar (queda) nem sobre-provisionar (custo desnecessário).
• Prefira ELB health check em vez de EC2 quando houver load balancer — é o que realmente reflete se a aplicação está saudável.
• Use lifecycle hooks para draining gracioso em vez de deixar conexões caírem abruptamente no scale-in.
• Combine Target Tracking (reativo) com Scheduled Scaling (proativo) quando você já sabe de picos previsíveis além dos reativos.
• Avalie warm pools se o tempo de boot da aplicação for um gargalo real de resposta a picos.

---

12. Exercícios e revisão

1. Projete um ASG com mixed instances policy: 70% Spot (allocation strategy capacity-optimized) e 30% On-Demand, garantindo baseline confiável.
2. Explique a diferença prática entre Target Tracking e Step Scaling, com um exemplo de quando cada um é mais apropriado.
3. Descreva um cenário onde EC2 health check deixaria passar um problema que ELB health check pegaria.
4. Explique por que um lifecycle hook Terminating:Wait é útil antes de encerrar uma instância que processa filas.

---

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Laboratório Prático

Objetivo: criar um Auto Scaling Group com Target Tracking baseado em CPU, integrado a um Application Load Balancer.

Pré-requisitos: uma VPC com pelo menos 2 subnets públicas em AZs diferentes; uma AMI ou Launch Template já criado.

Tempo estimado: 25 minutos

Possíveis custos: instâncias EC2 ficarão ativas durante o laboratório — lembre-se de fazer a limpeza ao final para não gerar cobrança contínua. Custo aproximado de poucos centavos se limpo em até 1 hora.

Passos:

1. Crie um Launch Template com uma AMI Amazon Linux, tipo t3.micro, e um user data simples que instale um servidor web (ex: httpd) respondendo em /health.
2. Crie um Target Group e um Application Load Balancer apontando para ele.
3. Crie o Auto Scaling Group, associando o Launch Template, escolhendo 2 subnets em AZs diferentes, e anexando-o ao Target Group criado.
4. Configure min=2, desired=2, max=6.
5. Defina o health check type como ELB com grace period de 60 segundos.
6. Crie uma política de Target Tracking com métrica Average CPU Utilization alvo em 50%.
7. Gere carga artificial na instância (ex: stress-ng ou um loop de CPU) e observe no console o ASG lançando novas instâncias.
8. Pare a carga e observe o scale-in acontecer após o CPU normalizar.

Resultado esperado: o grupo escala de 2 para mais instâncias sob carga, e retorna à capacidade mínima quando a carga cessa — tudo sem intervenção manual.

Limpeza dos recursos: delete o Auto Scaling Group (isso já termina as instâncias), depois o Target Group, o Load Balancer e o Launch Template, nessa ordem, para evitar dependências travadas.

---

Referências:

• Auto Scaling Groups: https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
• Scaling policies: https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html
• Lifecycle hooks: https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html
• Warm pools: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html
• Mixed instances policy: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html