Otimização de Custos: RI, Savings Plans e Spot
- ⬜⚖️ EC2 Profissional: Auto Scaling e Load Balancers(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Cost-Optimized é 20% do SAA-C03. O exame testa se você sabe escolher o modelo de compra certo (RI, SP, Spot), identificar over-provisioning (Compute Optimizer), usar ferramentas de monitoramento (Cost Explorer, Budgets, Trusted Advisor) e aplicar padrões arquiteturais que economizam sem sacrificar resiliência.
Modelos de compra de EC2 — o espectro completo
| Modelo | Desconto vs On-Demand | Commit | Flexibilidade | Caso |
|---|---|---|---|---|
| On-Demand | 0% | Nenhum | Total | Dev/test, spikes imprevisíveis |
| Compute Savings Plans | Até 66% | 1 ou 3 anos | Alta: cross-family, cross-region, Lambda/Fargate | Workloads estáveis mas que podem mudar tipo |
| EC2 Instance Savings Plans | Até 72% | 1 ou 3 anos | Família + região fixas | Workloads muito previsíveis em família específica |
| Standard RI | Até 72% | 1 ou 3 anos | Baixa: troca em mesma família | Legado, substituído por Savings Plans na maioria dos casos |
| Convertible RI | Até 54% | 1 ou 3 anos | Média: pode trocar família | Quando precisa de RI específica (Windows BYOL) |
| Spot | Até 90% | Nenhum | Tolera interrupção (2min aviso) | Batch, ML training, containers stateless |
| Dedicated Host | Variável | 1 ou 3 anos ou On-Demand | Host físico dedicado | Licenças BYOL, compliance |
| Capacity Reservation | Sem desconto extra | Flexível | Garante capacity em AZ específica | Eventos críticos, DR |
- → se tolera interrupção
- → se o uso é previsível
- → trava a família, ganha desconto
- → trava mais ainda
- → flexibiliza a família
- → garante capacidade
- Compute
- Gestão e governança
Duas perguntas em ordem: tolera interrupção (Spot) e o uso é previsível (Savings Plans ou RI). E lembre que Capacity Reservation garante máquina, não preço — é a distinção que a prova mais explora neste tema.
- Comece pela pergunta da interrupção. Se a carga tolera ser interrompida com dois minutos de aviso — batch, CI, processamento assíncrono, worker com fila — Spot dá o maior desconto de todos. Nenhum outro modelo chega perto.
- Depois, a pergunta da previsibilidade. Uso constante por 1 ou 3 anos justifica compromisso. Savings Plans de Compute é o mais flexível: vale para EC2 de qualquer família e região, e também para Fargate e Lambda. É a escolha padrão de compromisso.
- Mais desconto custa mais rigidez. SP de EC2 Instance trava a família e a região em troca de desconto maior. RI Standard vai além e trava quase tudo. RI Convertible aceita troca de família com desconto menor. É um eixo contínuo.
- RI ainda importa fora do EC2. Para RDS, ElastiCache, Redshift e OpenSearch não existe Savings Plans — o desconto por compromisso é via Reserved Instance. Questão sobre banco reservado é sempre RI.
- Capacity Reservation não é desconto. Ela garante que a capacidade estará disponível numa AZ — útil para DR e para evento com pico previsto. Você paga como On-Demand mesmo sem usar. Confundir com RI é erro comum: uma reserva PREÇO, a outra reserva MÁQUINA.
Recomendação atual da AWS: Savings Plans sobre RIs para novos commits. Mais flexíveis e desconto equivalente em Compute SP vs Standard RI. RIs ainda existem para workloads herdados.
Quando cada um ganha — decisão rápida
📋 Web app roda 24/7 com 20 EC2 m5.xlarge há 2 anos, crescendo lentamente
Carga previsível + tamanho estável = commit de 3 anos. Compute SP (não EC2 SP) porque se a empresa migrar para m6g Graviton, o SP cobre igual.
📋 Renderização de filmes 8h por noite, 500 EC2 c5.24xlarge, tolera instância morrer e reiniciar
Spot dá até 90% off. Diversificar em vários types reduz risco de interrupção simultânea. Checkpoint em S3 permite resume.
📋 Workload roda em Lambda + Fargate + EC2, com proporção variando mensalmente
Único SP que cobre Lambda e Fargate. Mistura de compute changes over time — Compute SP absorve.
📋 Oracle DB legado precisa rodar em hardware dedicado por licença BYOL
Licença Oracle exige core tracking. Dedicated Host expõe sockets/cores para compliance. Dedicated Instance não serve (não expõe hardware).' }
Spot Instances — detalhes críticos
Ferramentas de visibilidade e controle
| Ferramenta | Função |
|---|---|
| Cost Explorer | Visualização histórica + forecast. Drill-down por serviço/tag/account. |
| AWS Budgets | Alertas quando custo/uso excede threshold. Pode disparar ação (SNS, Lambda). |
| AWS Cost Categories | Agrupamentos customizados (ex: "time-A", "produto-X") para relatórios. |
| Cost Allocation Tags | Tags ativadas para aparecer em relatórios. Base de FinOps. |
| Trusted Advisor | 5 pilares (cost, performance, security, fault tolerance, service limits). Cost checks: idle EC2, unused EIPs, RI/SP opportunity. |
| Compute Optimizer | ML recomenda rightsizing para EC2, EBS, ASG, Lambda baseado em CloudWatch. |
| AWS Pricing Calculator | Estimativa de custo pré-deploy. |
| CUR (Cost & Usage Report) | Dump granular em S3 (hora por hora, recurso por recurso). Analisado com Athena/QuickSight. |
Uma frota EC2 roda 24x7 com carga estável há dois anos e continua em On-Demand. Qual é a primeira ação de otimização?
Padrões arquiteturais que economizam
Cenários de SAA
📋 Conta com 150 EC2 e 20TB EBS gp2, consultor recomenda economizar
Compute Optimizer identifica over-provisioning. gp3 reduz 20% do EBS. SP 1 ano captura ~30% sem commit longo.
📋 NAT Gateway cobrando $5.000/mês; tráfego é 90% para S3 e DynamoDB
Gateway Endpoints são grátis e rotam tráfego internamente. NAT Gateway só paga para os 10% restantes.
📋 Análise ad-hoc precisa processar 10TB de logs em S3 mensalmente
Athena não cobra compute idle. Parquet colunar reduz scan. Partitioning por data limita scope. Alternativa EMR cobraria cluster idle.
Q&A estilo exame
❓ Como alocar custo de infra compartilhada entre 3 departamentos?
❓ Budget alerta em $10k mas conta continua gastando. O Budget faz enforcement?
❓ Vale trocar x86 por Graviton (Arm)?
❓ Compute SP vale mais que EC2 SP quando?
Perguntas frequentes
❓ Reserva ou plano de economia?
❓ Quando usar instância de excedente?
❓ Como reduzir custo sem trocar arquitetura?
Fixando
Qual modelo de compra cobre EC2, Fargate E Lambda com o mesmo compromisso?
Qual afirmação sobre Spot Instances é correta?
Armadilhas: (1) RI/SP são pagamento garantido — se não usar, paga igual; (2) Spot pode morrer a qualquer momento, não rode sessão stateful; (3) gp2 ainda é default em muitos templates — trocar para gp3 economiza sem esforço; (4) NAT Gateway é um dos maiores ofensores de custo em VPC mal planejada; (5) data transfer OUT é caro (especialmente cross-region e para internet).
Take-aways: mapa mental — On-Demand (default), Savings Plans (estável), Spot (interruptível), RI (legado). Use Compute Optimizer para rightsizing, Budgets para guardrails, Cost Explorer para visibility, CUR para análise profunda. Arquitetura bem desenhada economiza mais que qualquer desconto de compra.
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…