Rightsizing sem medo: metodologia de cortar sem quebrar
- ⬜🚨 Cost anomaly detection: quando alertar(FinOps & Cost Engineering)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Metodologia em 6 passos
# Rightsizing Playbook
## 1. Observability completa (1-2 semanas)
- CloudWatch agent em EC2 com memory/disk metrics
- VPA em EKS (mode recommend, não apply)
- 30+ dias de histórico incluindo picos mensais
## 2. Identificar candidatos
- Compute Optimizer findings (filtrar "over-provisioned")
- Baseline: CPU < 30%, memory < 50% sustained 30d
## 3. Priorizar por impacto
- Top 20 candidatos por potential savings
- Tag-based: começar por non-prod antes de prod
## 4. Canary
- Apply em 1 instance (ou 10% do service)
- Monitoring apertado por 48-72h
- Métricas: latency p95/p99, error rate, CPU/mem
## 5. Rollout gradual
- 10% → 25% → 50% → 100% com check entre
- Rollback automático em alarm trigger
## 6. Validação pós
- Revisão 1 semana: economia real vs estimada
- Documentar aprendizados no runbookChaos testing para confiança
Antes de rightsize crítico, rode chaos test: FIS (Fault Injection Service) simulando load spike 2x baseline. Se workload atual aguenta sem stress mas rightsized quebra, buffer foi mal calibrado. Esse teste barato antes de deploy prod evita incident depois.
# AWS FIS: experiment stress CPU em instance candidata
Experiment:
Name: rightsize-validation-stress
Targets:
ec2-instances:
ResourceTags: { team: checkout, env: staging }
Actions:
stress-cpu:
ActionId: aws:ssm:send-command
Parameters:
documentArn: arn:aws:ssm::aws:document/AWSFIS-Run-CPU-Stress
duration: PT10M
cpu-load: 80
StopConditions:
- CloudWatchAlarm em error-rate spikePor que o ajuste de capacidade costuma ser adiado mesmo com desperdício evidente?
Rightsizing contínuo, não evento
Rightsizing one-shot volta a overprovision em 6 meses — workloads mudam, features acumulam. Maturidade: Compute Optimizer review mensal automático + alerts de drift (workload rodando com CPU < 20% 60 dias dispara review), policy "toda nova workload entra com instance menor possível, escala se necessário". Cultura, não projeto.
Combinação vencedora: Compute Optimizer + memory metrics via CWA + EKS VPA + FIS chaos test + canary deployment + rollback automation. Economia 20-40% sustentável sem trazer risco de prod incident.
Perguntas frequentes
❓ Como reduzir recurso sem quebrar?
❓ Recomendação automática de dimensionamento é confiável?
❓ Por onde começar a otimizar?
Fixando
Qual dado deve guiar a decisão de reduzir capacidade?
Por que testar a resiliência antes de reduzir capacidade ajuda?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…