Capstone: redução de 30% de custo em app real
⏱ 18 min·⭐ 85 XP
Pré-requisitos (0/1)0%
- ⬜🔍 Observability de custo: tags, allocation, dashboards(FinOps & Cost Engineering)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Projeto proposto
🗺️ A ordem que encontra economia sem quebrar nada
1 · Marcar e atribuirantes de qualquer corte
Fatura total não diz o que cortar. Sem atribuição, você corta o barato e deixa o caro.
ÓBVIO▼
2 · Desligar o ociosoganho imediato
Ambiente esquecido, volume órfão, réplica sem uso. Não exige refatorar nada e costuma dar a maior fatia.
DIMENSIONAR▼
3 · Ajustar capacidadecom folga e reversão pronta
Segunda maior fatia, e a que exige medição de pico — não de média.
COMPROMETER▼
4 · Comprometer a basenunca o total
Desconto por compromisso sobre a parte estável da carga; a ponta fica flexível.
ARQUITETAR▼
5 · Mudar arquiteturapor último
É onde está o maior ganho potencial e o maior risco. Só depois de o resto estar feito.
Escolha aplicação real (próprio projeto, trabalho atual com anonimização, ou caso público). Produza case study de FinOps cobrindo: baseline, análise, intervenções, mensuração, aprendizados. Meta de 30% é ambiciosa mas atingível em app típico com medidas básicas bem executadas.
Entregáveis
# Capstone FinOps — Entregáveis
## 1. Baseline rigoroso (1 semana)
- Cost Explorer export 90 dias pré-intervention
- Breakdown por serviço, tag (team/env), hora do dia
- Anomalias excluídas e documentadas
- CUR em Athena se org usa (cobertura granular)
## 2. Análise + priorização (3-5 dias)
- Top 10 custos
- Compute Optimizer findings
- EBS/EIP/NAT órfãos
- Coverage atual de SPs/RIs
- Storage tier distribution (hot vs cold)
- Graviton compatibility audit
- Hipóteses rankeadas por (economia estimada / risco / esforço)
## 3. Intervenções ordenadas
Fase 1: cleanup (auto via Lambda + aprovação)
Fase 2: rightsizing canary → rollout
Fase 3: S3 Lifecycle + Intelligent-Tiering
Fase 4: Compute SP 1yr no-upfront cobrindo baseline
Fase 5 (paralelo): Graviton migration, Spot em workers
## 4. Mensuração (4+ semanas pós)
- Mesma janela, mesmas premissas
- Atribuição por alavanca (cleanup X%, rightsize Y%, SP Z%)
- Validação que nenhum SLO degradou
## 5. Writeup estruturado
- Problema + contexto da app
- Metodologia
- Resultados com gráficos (before/after)
- Limitações + falsos positivos removidos
- Lições aprendidas
- Próximos passos
## 6. Materiais complementares
- Dashboard Grafana/QuickSight publicável
- Scripts/Terraform/Lambdas usadas
- Runbook pra manutenção recorrenteQuiz rápido
Qual é o primeiro passo do capstone, antes de qualquer otimização?
Template de writeup
# Case Study: Reduzindo 32% em custo AWS do serviço X
## Contexto
Serviço backend stateless atrás de ALB + Fargate + Aurora Postgres,
50M requests/mês, baseline $18.4k/mês em us-east-1.
## Baseline (jan-mar 2026, excluída migração de fev)
Total: $18,430/mês Top 3 serviços:
- Fargate: $8,400 (45%)
- RDS: $5,200 (28%)
- NAT/DTO: $2,100 (11%)
- Outros: $2,730 (15%)
Observações:
- 0% cobertura SPs (workload novo, baseline instável até dez/25)
- EBS snapshots: 4TB de 180+ dias (órfãos)
- Fargate: CPU baseline 22%, memory 38% (overprovision claro)
- RDS db.r5.2xlarge single-AZ em prod (antipattern)
## Intervenções
[cleanup] Lambda automatizado removeu 4TB snapshots -$380/mês
[rightsize] Fargate 2vCPU/4GB → 1vCPU/3GB com 25% buffer -$2,600/mês
[architecture] Graviton ECS tasks (c7g) -$1,400/mês
[RDS] Multi-AZ habilitado (resiliência) + Reserved 1yr -$1,100/mês net
[commitments] Compute SP 1yr no-upfront 70% coverage -$600/mês
[S3] Lifecycle logs S3 Standard → IA → Glacier -$180/mês
TOTAL -$6,260/mês
## Resultado (abr-jun 2026)
Custo atual: $12,170/mês — redução 33.1% vs baseline
Métricas de app (latency p99, error rate) inalteradas
## Limitações
- Workload pode mudar se feature X ship em Q3 → revisar SP coverage
- Graviton migration exige testing adicional pra libs C++ (cobrimos main)
## Próximos passos
- Spot em Fargate workers não-críticos (potencial ~$800/mês adicional)
- RDS Performance Insights pra rightsize DB (potencial ~$1,000/mês)
- Revisão Compute SP coverage após 6 meses de baseline estável✅
Esse tipo de case study é portfolio de eng sênior/staff em 2026. Recruiter/hiring manager lê e vê: engineering rigoroso, foco em impact, honestidade com limitations, próximos passos executáveis. Abre portas pra roles de Cloud Architect, Staff Eng, FinOps Lead.
Perguntas frequentes
❓ Como estruturar um projeto de redução de custo?
Medindo a linha de base por serviço, listando alavancas em ordem de risco crescente, aplicando as sem risco primeiro e medindo depois de cada uma. Sem linha de base por serviço, o resultado final não é atribuível e ninguém aprende nada.
❓ Qual alavanca dá o maior corte com menor risco?
Desligar o que não é usado, seguido de mover dado frio para classe barata. As duas não afetam nada em produção e costumam somar mais que a otimização heroica de arquitetura. Começar pelo heroico é o padrão que atrasa o resultado.
❓ Como não perder a economia depois?
Com barreira preventiva no que causou o desperdício — política que exige etiqueta, que limita tipo de recurso, que expira ambiente de teste. Correção sem barreira volta, e o segundo projeto de redução encontra os mesmos itens.
Fixando
Quiz rápido
O que o relatório final do capstone precisa demonstrar, além do número?
Quiz rápido
Qual tipo de economia tende a se reverter sozinha com o tempo?
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…