⚖️

EC2 Profissional: Auto Scaling e Load Balancers

⏱ 15 min de leitura·+80 XP

EC2 + Auto Scaling + Load Balancer é o padrão de referência do SAA-C03 para workloads escaláveis. Não basta saber que existem — você precisa escolher tipo de instância, purchasing model, LB adequado, scaling policy e placement group para cada cenário. Este módulo mapeia todas as decisões.

Onde isso entra no exame

📘 Domain 2 + 3 — Resilient & High-Performing· 50%

Auto Scaling e ELB aparecem em 80% das questões de resiliência. ASG provê elasticidade; ELB distribui e faz health check. É a dupla inseparável.

EC2 Instance Families — leitura de nomenclatura

Família	Caso de uso	Exemplo
T (burstable)	Workloads intermitentes com CPU credits	t3.medium
M (general)	Web, apps balanceadas CPU/memória/rede	m6i.large
C (compute)	HPC, batch, scientific, gaming server	c7g.xlarge
R (memory)	Caching (Redis), in-memory analytics	r6i.2xlarge
X / u- (high memory)	SAP HANA, in-memory DBs enormes	x2idn.32xlarge
I / D / H (storage)	NoSQL, data warehouse, Hadoop	i4i.xlarge
P / G / Trn / Inf (accelerated)	ML training/inference, gráficos	p5.48xlarge, g5.xlarge
A (ARM/Graviton)	20-40% mais barato para mesmas cargas	a1.medium, c7g (Graviton3)

💡

Nomenclatura: m6g.large = família M, geração 6, Graviton (g), tamanho large. Sufixos: g=Graviton, a=AMD, i=Intel, n=network-optimized, d=NVMe SSD local.

Purchasing Options — deep dive SAA

Opção	Desconto	Compromisso	Quando usar
On-Demand	0%	Nenhum	Workloads imprevisíveis, POCs
Reserved Standard	Até 72%	1 ou 3 anos, instância fixa	Carga estável e previsível
Reserved Convertible	Até 66%	1 ou 3 anos, pode trocar família	Carga estável mas evolutiva
Savings Plans Compute	Até 66%	$/h por 1 ou 3 anos	Flexibilidade entre EC2/Lambda/Fargate
Savings Plans EC2 Instance	Até 72%	$/h família específica	Família fixa, mas muda tamanho/AZ
Spot Instances	Até 90%	Pode ser interrompido com 2 min aviso	Batch, CI/CD, stateless, tolerante
Dedicated Host	Varia	Por host físico	Compliance, BYOL Windows
Dedicated Instance	Varia	Isolamento de hardware	Compliance menos estrito
Capacity Reservation	Preço on-demand	Reserva de capacidade específica	Garantia de availability, sem desconto

⚠️

Savings Plans vs Reserved:Savings Plans são mais flexíveis — commit em $/h, não em instância. Cobrem EC2 + Lambda + Fargate. RIs são mais granulares e podem dar descontos ligeiramente maiores em casos específicos. Para SAA: default recomenda Savings Plans salvo questão explicitamente dizer “commit em instância”.

EC2 Lifecycle e User Data

• User Data — script executado na primeira boot (bash/cloud-init). Usado para instalar software, configurar app.
• AMI — snapshot de EC2 para criar novas. Custom AMI acelera boot vs User Data.
• Instance Metadata Service (IMDS) — endpoint 169.254.169.254 com info da instância. IMDSv2 é obrigatório em novas instâncias (tokens, SSRF-safe).
• EC2 Instance Connect — SSH browser-based sem precisar chave pública permanente.
• Session Manager (SSM) — acesso shell sem expor SSH (usa agent + IAM role).

Auto Scaling Groups (ASG)

🗺️ Auto Scaling Group conectado a ALB


           Internet
              │
              ▼
         ┌────────┐
         │  ALB   │
         └───┬────┘
             │ health check
             ▼
   ┌─────────────────────────┐
   │ Target Group             │
   └──┬──────┬──────┬─────┬──┘
      │      │      │     │
   EC2-1  EC2-2  EC2-3  EC2-4  ◄── ASG mantém min/desired/max
   AZ-a   AZ-a   AZ-b   AZ-b       com health checks + scaling policy

Componentes:

• Launch Template (preferido) ou Launch Configuration (legacy) — template da instância
• Min / Desired / Max — limites da capacidade
• Subnets — ASG distribui entre AZs das subnets
• Health Check — EC2 (status check) ou ELB (target group)
• Cooldown — período antes de próxima scaling action (default 300s)
• Termination Policy — qual instância terminar primeiro (OldestInstance, NewestInstance, etc.)

Scaling Policies

Policy	Como funciona	Uso
Target Tracking	Mantém métrica em valor-alvo (CPU=70%)	Padrão recomendado — simples
Step Scaling	Ações diferentes por faixa (CPU 60-70 → +1; 70-90 → +3)	Controle fino de ajuste
Simple Scaling	Uma ação por threshold, com cooldown	Casos simples, legacy
Scheduled Scaling	Muda capacidade em horário (scale up 9h, down 18h)	Padrões previsíveis (business hours)
Predictive Scaling	ML prevê demanda e escala antecipadamente	Padrões cíclicos (daily/weekly)

💡

Warm pools: ASG pode manter pool de instâncias pre-baked em estado stopped. Quando precisa scale up, start é mais rápido que launch (segundos vs minutos). Ideal para apps com boot lento.

Os 4 Elastic Load Balancers

LB	Camada	Protocolos	Features-chave
Application LB (ALB)	L7	HTTP, HTTPS, gRPC, WebSocket	Host/path routing, cognito auth, WAF integration, HTTP/2
Network LB (NLB)	L4	TCP, UDP, TLS	Ultra-low latency, static IP por AZ, 1M+ req/s
Gateway LB (GWLB)	L3/4	IP (GENEVE)	Insere appliances 3rd party (firewall, IDS) na rota
Classic LB (CLB)	L4/L7	TCP, SSL, HTTP	LEGACY — evitar em deployments novos

ALB vs NLB — quando usar

Critério	ALB	NLB
HTTP inspection	✅ Header/path/host routing	❌ É só L4
WebSocket / gRPC	✅	✅ (TCP passthrough)
UDP	❌	✅
Static IP	❌ (DNS só)	✅ 1 por AZ (+ Elastic IP)
Preserve client IP	Via X-Forwarded-For	✅ Nativo
Latência	~400 ms overhead	~100 µs overhead
TLS termination	✅	✅ (TLS listener)
Cross-zone LB	Grátis (default)	Pago (opcional)
Uso típico	Web apps, APIs	Gaming, IoT, voIP, TCP/UDP

Target Groups e Health Checks

LBs roteiam para target groups. Um TG pode ter targets: EC2 instances, IPs (ENIs, on-prem via DX), Lambda functions, ALB (para chainear ALB atrás de NLB).

Target type	Uso
instance	EC2 IDs (LB usa private IP)
ip	IPs específicos (cross-VPC via peering, on-prem via DX)
lambda	Invoca Lambda diretamente (ALB only)
alb	ALB como target de NLB (pattern híbrido)

💡

Health check detalhes: path (ALB: HTTP path; NLB: TCP port), interval, timeout, healthy threshold (N sucessos para marcar healthy), unhealthy threshold. Instância unhealthy é removida do LB mas não terminada pelo ASG (a menos que health check type seja ELB).

Placement Groups — quando cada um

Tipo	Layout	Uso
Cluster	Instâncias em mesmo rack/AZ	HPC, ML training — baixa latência, 10 Gbps bandwidth
Spread	Cada instância em host físico distinto (max 7/AZ)	Aplicações críticas, evita failure shared
Partition	Grupos lógicos em racks separados (até 7 partitions/AZ)	Hadoop, Cassandra, Kafka — isolamento por partition

Elastic IP (EIP)

IPv4 público estático. Free enquanto associado a recurso em uso; pago se não associado ou em EC2 stopped ($0,005/h). Use para NAT Gateway, NLB em private mode, failover automático (reassociate).

Cenários de decisão

📋 API HTTP com 3 microservices (/users, /orders, /payments) atrás de um único domínio

✓ ALB com listener rules por path

ALB faz path-based routing nativamente. Listener rules: /users → TG-users, /orders → TG-orders, etc. Cada target group escalar independente.

📋 Gaming server UDP com 100k conexões simultâneas

✓ NLB

ALB não suporta UDP. NLB aguenta milhões de conexões, latência <100µs, preserva client IP nativamente.

📋 Workload de data processing que roda 1x por dia por 2h, tolerante a falha

✓ ASG com mix de Spot + On-Demand (80/20)

Spot dá até 90% off. Mix com On-Demand garante mínimo funcional se Spot for reclaimed. Launch template com multiple instance types diversifica.

📋 Cluster de ML training de 32 GPUs que precisa alta bandwidth inter-nó

✓ Instâncias p5 em Cluster Placement Group + EFA (Elastic Fabric Adapter)

Cluster PG garante proximidade física + 10 Gbps. EFA acelera RDMA para frameworks como NCCL. Single-AZ é aceitável pois workload é efêmero.

📋 App web com tráfego previsível: 9-18h alto, resto do dia baixo

✓ ASG com Scheduled Scaling + Target Tracking

Scheduled pre-escalar antes das 9h (warmup), scale down após 18h. Target tracking cuida de picos não-previstos. Combinação dá custo otimizado + reatividade.

⚠️

Pegadinhas EC2/ELB no SAA:

• Sticky sessions (ALB) via cookie — útil para apps stateful, mas limita LB.
• Connection draining / Deregistration delay — tempo para requests em flight terminarem (default 300s).
• Health check path deve retornar 200 — confundir 302/404 marca unhealthy.
• NLB preserva source IP nativamente; ALB coloca em X-Forwarded-For.
• Lifecycle hooks — ASG pode pausar antes de terminate para drenar connections (muito cobrado).
• Termination protection na EC2 e no ASG são distintos.
• Tenancy: Shared (default), Dedicated Instance (isolated HW), Dedicated Host (físico BYOL).

Perguntas típicas (Q&A)

❓ Como dar deploy zero-downtime com ASG e ALB?

Use Rolling update: ASG cria novas instâncias com nova AMI, desregistra velhas do TG após novas estarem healthy. Ou Blue/Green com CodeDeploy/Elastic Beanstalk: cria novo ASG, switch no ALB, destrói antigo.

❓ Como lidar com armazenamento local em ASG (logs, cache)?

Stateless é o padrão. Logs → CloudWatch Logs Agent. Cache → ElastiCache. Arquivos compartilhados → EFS. Dados persistentes não devem viver em disco da EC2 (que somem no scale-in).

❓ O que acontece se Spot for interrompido?

AWS envia notification 2 minutos antes via Instance Metadata. Sua app deve ter graceful shutdown (flush buffers, finish current work). ASG substitui automaticamente. Use Spot Fleet / Mixed Instances para diversificar e reduzir risco.

❓ ALB ou CloudFront para HTTPS com certificado custom?

Ambos suportam via ACM. CloudFront tem cache + edge; ALB é regional. Para web global: CloudFront na frente, ALB atrás. Para API regional interna: ALB direto já resolve.

✅

Take-aways:EC2 families: T/M (burst/general), C (compute), R/X (memory), I/D (storage), P/G/Trn/Inf (GPU/ML), A (ARM). Savings Plans > RIs em flexibilidade. ASG com target tracking é o default. ALB (L7, HTTP/HTTPS, path routing) vs NLB (L4, TCP/UDP, static IP, ultra-low latency) vs GWLB (appliances L3). Placement groups: Cluster (HPC), Spread (HA crítica), Partition (distributed DB). Stateless em ASG — tudo persistente fora (EFS, S3, RDS, ElastiCache).

🧩

Quiz rápido

3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito