Pular para o conteúdo principal

Lab : Otimização de Custos

Objetivo​

Analisar uma infraestrutura AWS e propor recomendações de otimização com justificativas e estimativas de economia.

Cenário​

Contexto​

TechStartup Inc. gasta $15.000/mês na AWS e deseja reduzir seus custos em 30% sem impactar a performance.

Infraestrutura Atual​

┌─────────────────────────────────────────────────────────────┐
│ INFRAESTRUTURA TECHSTARTUP │
├─────────────────────────────────────────────────────────────┤
│ │
│ COMPUTE ($8.500/mês) │
│ ───────────────────── │
│ • 10x m5.xlarge (produção web) 24/7 $1.400 │
│ • 5x m5.large (produção API) 24/7 $350 │
│ • 3x r5.2xlarge (produção DB) 24/7 $900 │
│ • 5x m5.large (staging) 24/7 $350 │
│ • 8x c5.xlarge (batch processing) 24/7 $1.100 │
│ • 4x t3.large (dev) 24/7 $250 │
│ • 2x m5.xlarge (CI/CD runners) 24/7 $280 │
│ Outros (Lambda, misc) $3.870 │
│ │
│ STORAGE ($3.000/mês) │
│ ───────────────────── │
│ • EBS gp2 volumes 5 TB $500 │
│ • S3 Standard 20 TB $460 │
│ • EBS Snapshots 10 TB $500 │
│ • RDS Storage 2 TB $200 │
│ • Backup/Archive $1.340 │
│ │
│ NETWORK ($2.500/mês) │
│ ───────────────────── │
│ • NAT Gateways (3x) $300 │
│ • Data Transfer $2.000 │
│ • Load Balancers (5x) $200 │
│ │
│ OUTROS ($1.000/mês) │
│ ─────────────────── │
│ • CloudWatch, Secrets Manager, etc. │
│ │
│ TOTAL : $15.000/mês │
│ │
└─────────────────────────────────────────────────────────────┘

Métricas de Utilização​

RecursoCPU AvgMem AvgHoras ativas
Web (prod)35%45%24/7
API (prod)40%50%24/7
DB (prod)65%70%24/7
Staging15%20%9h-18h dias úteis
Batch80%60%2h/dia (noite)
Dev10%15%9h-18h dias úteis
CI/CD25%30%Variável

Parte 1 : Análise de Custos​

Exercício 1.1 : Identificação dos Problemas​

Identifique as 5 principais fontes de desperdício:

#RecursoProblemaImpacto Estimado
1??$?/mês
2??$?/mês
3??$?/mês
4??$?/mês
5??$?/mês
💡 Solução
#RecursoProblemaImpacto Estimado
1Staging 24/7Deveria ser desligado fora do horário$250/mês
2Dev 24/7Idem, desperdício noite/final de semana$180/mês
3Batch 24/7Só roda 2h/dia$900/mês
4Web superdimensionadoCPU 35% → right-size$400/mês
5Sem RI/SPTudo On-Demand$2.500/mês

Exercício 1.2 : Análise por Tag​

O tagging atual está incompleto. Proponha uma estratégia de tagging:

TagObrigatórioValores Possíveis
?Sim/Não?
?Sim/Não?
?Sim/Não?
?Sim/Não?
💡 Solução
TagObrigatórioValores Possíveis
EnvironmentSimproduction, staging, development
ProjectSimweb-app, api, batch, infra
OwnerSimteam-frontend, team-backend, team-data
CostCenterSimCC-PROD, CC-DEV, CC-OPS
AutoShutdownNãotrue, false
ExpiryDateNãoYYYY-MM-DD

Parte 2 : Plano de Otimização​

Exercício 2.1 : Right-Sizing​

Proponha novos tipos de instância:

AtualNovoJustificativaEconomia
m5.xlarge (web)??$?
m5.large (staging)??$?
t3.large (dev)??$?
💡 Solução
AtualNovoJustificativaEconomia
10x m5.xlarge (web)10x m5.largeCPU 35% OK com large$700/mês
5x m5.large (staging)3x t3.mediumStaging pouco usado, burstable OK$280/mês
4x t3.large (dev)4x t3.mediumDev muito subutilizado$100/mês

Exercício 2.2 : Scheduling​

Configure o desligamento automático dos ambientes não-prod:

# Complete o script de scheduling
# Staging : desligar 18h, ligar 9h (dias úteis)
# Dev : desligar 19h, ligar 8h (dias úteis)

# EventBridge rule para desligar staging às 18h
aws events put-rule \
--name stop-staging-evening \
--schedule-expression "cron(_______________)" \
--state ENABLED

# Lambda ou SSM Automation target
# ...
💡 Solução
# Desligar staging às 18h UTC, Seg-Sex
aws events put-rule \
--name stop-staging-evening \
--schedule-expression "cron(0 18 ? * MON-FRI *)" \
--state ENABLED

# Ligar staging às 9h UTC, Seg-Sex
aws events put-rule \
--name start-staging-morning \
--schedule-expression "cron(0 9 ? * MON-FRI *)" \
--state ENABLED

# Desligar dev às 19h UTC, Seg-Sex
aws events put-rule \
--name stop-dev-evening \
--schedule-expression "cron(0 19 ? * MON-FRI *)" \
--state ENABLED

# Ligar dev às 8h UTC, Seg-Sex
aws events put-rule \
--name start-dev-morning \
--schedule-expression "cron(0 8 ? * MON-FRI *)" \
--state ENABLED

Economia staging: 14h/dia × 5 dias × 4 semanas = 280h/mês (vs 720h) → Redução ~60% = $210/mês

Economia dev: 13h/dia × 5 dias × 4 semanas = 260h/mês → Redução ~65% = $160/mês

Exercício 2.3 : Spot Instances​

Identifique os workloads candidatos para Spot:

WorkloadCandidato Spot?Justificativa
Web (prod)??
Batch processing??
CI/CD runners??
💡 Solução
WorkloadCandidato Spot?Justificativa
Web (prod)❌ NãoCrítico, não pode ser interrompido
Batch processing✅ SimExecução curta, pode retomar, 60-90% economia
CI/CD runners✅ SimTolera interrupção, jobs podem retry

Economias Spot:

  • Batch: $1.100 × 70% = $770/mês de economia
  • CI/CD: $280 × 65% = $180/mês de economia

Exercício 2.4 : Reserved Instances / Savings Plans​

Calcule a cobertura ideal:

Workload estável 24/7 (candidato RI/SP):
- Produção web: 10 instâncias → ?
- Produção API: 5 instâncias → ?
- Produção DB: 3 instâncias → ?

Calcule economia com 1-year Savings Plan (-30%):
💡 Solução

Workload estável (após right-sizing):

  • Web: 10x m5.large = ~$700/mês
  • API: 5x m5.large = ~$350/mês
  • DB: 3x r5.2xlarge = ~$900/mês

Total elegível RI/SP: $1.950/mês

Com Compute Savings Plan 1-year (-30%):

  • Economia: $1.950 × 30% = $585/mês

Compromisso mensal: $1.365/mês (vs $1.950)

Parte 3 : Otimização de Storage​

Exercício 3.1 : Migração gp2 → gp3​

EBS gp2 atual: 5 TB = $500/mês
Migração para gp3: calcule economia
💡 Solução

gp2 pricing: $0,10/GB/mês = 5000 × $0,10 = $500/mês

gp3 pricing: $0,08/GB/mês = 5000 × $0,08 = $400/mês

Economia: $100/mês (20%)

Além disso: gp3 oferece 3000 IOPS básicos gratuitos vs gp2 que escala com o tamanho.

Exercício 3.2 : S3 Lifecycle Policies​

Proponha regras de lifecycle para S3:

ClasseApósDadosEconomia
Standard0 diasAtivosReferência
????
????
💡 Solução
ClasseApósDadosCusto/GB
Standard0 dias< 30 dias$0,023
Standard-IA30 dias30-90 dias$0,0125
Glacier90 dias> 90 dias$0,004

Estimativa com 20 TB:

  • Se 30% ativo, 40% IA, 30% arquivado
  • Standard: 6 TB × $0,023 = $138
  • IA: 8 TB × $0,0125 = $100
  • Glacier: 6 TB × $0,004 = $24
  • Total: $262/mês vs $460 = $198 economia (43%)

Parte 4 : Síntese​

Exercício 4.1 : Tabela Resumo​

Complete a tabela de economias:

CategoriaAçãoEconomia/mês%
ComputeRight-sizing$??%
ComputeScheduling$??%
ComputeSpot$??%
ComputeSavings Plans$??%
Storagegp2→gp3$??%
StorageS3 Lifecycle$??%
TOTAL$??%
💡 Solução
CategoriaAçãoEconomia/mês% do total
ComputeRight-sizing$1.0807,2%
ComputeScheduling$3702,5%
ComputeSpot (batch+CI)$9506,3%
ComputeSavings Plans$5853,9%
Storagegp2→gp3$1000,7%
StorageS3 Lifecycle$1981,3%
TOTAL$3.28321,9%

Custo inicial: $15.000/mês Custo otimizado: $11.717/mês Economia: $3.283/mês ou ~22%

Para atingir 30%, ações adicionais:

  • Revisar arquitetura (serverless?)
  • Negociar EDP com AWS
  • Otimizar data transfer

Entregável Final​

Documento a Produzir​

  1. Análise do ambiente atual com identificação dos desperdícios
  2. Estratégia de tagging completa
  3. Plano de otimização detalhado com cálculos
  4. Tabela resumo das economias
  5. Recomendações prioritárias (quick wins vs longo prazo)

Critérios de Avaliação​

CritérioPontos
Análise correta dos desperdícios/20
Estratégia de tagging/15
Cálculos de economia/25
Plano acionável/25
Qualidade do documento/15
Total/100

Semana seguinte: MODULE 15 - CloudFormation