Reservas, Savings Plans e Spot: estratégia de portfolio
- ⬜✂️ Rightsizing sem medo: metodologia de cortar sem quebrar(FinOps & Cost Engineering)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Spectrum de commitments AWS
| Modelo | Desconto típico | Compromisso | Cabe em |
|---|---|---|---|
| Sob demanda | Nenhum | Nenhum | Carga imprevisível e curta |
| Plano de economia por gasto | Moderado a alto | Valor por hora, por 1 a 3 anos | Base estável, com liberdade de trocar instância |
| Reserva de capacidade específica | Alto | Família e região fixas | Carga que você tem certeza que não muda |
| Capacidade interruptível | Muito alto | Pode ser retomada com aviso curto | Trabalho tolerante a interrupção: lote, treino, processamento |
| ⚠ O erro comum | — | Comprometer 100% da carga | Deixe a ponta variável sob demanda — compromisso é sobre a BASE |
Savings Plans:
Compute SP:
Desconto ~66% (1yr) / ~72% (3yr)
Cobre: EC2, Fargate, Lambda
Flexível: family, region, OS, tenancy
EC2 Instance SP:
Desconto ~72% (1yr) / ~78% (3yr)
Fixa: family + region
Flexível: size, OS
SageMaker SP:
Dedicado SageMaker training + inference
Reserved Instances (legacy mas ainda usado):
Standard: desconto máximo, locked em instance type
Convertible: desconto menor, permite trocar family
Uso principal: RDS, ElastiCache, Redshift, OpenSearch
(onde Savings Plans não aplica)
Spot:
Desconto 60-90% vs on-demand
Interrupção com 2min warning
Capacity optimized allocation recomendado
Padrão pra batch, ML training, CI, workers stateless
Ondemand:
Full price, paga só pelo que usa
Buffer pra spikes imprevistos
Enterprise Discount Program (EDP):
Negociação direta com AWS em gasto alto
Usualmente 5-15% off em cima de tudo
Commitment plurianual significativoAlgoritmo de decisão simples
Passo 1 — analise baseline estável (12+ meses):
Identifique compute que está presente 24/7 por 1+ anos
Exemplo: 50 m5.xlarge prod backend, 10 c5.large workers
Passo 2 — cobertura SP proporcional:
Compute SP 1yr no-upfront pra ~70% dessa baseline
EC2 Instance SP pra famílias cristalizadas (RDS)
Passo 3 — Spot onde workload tolera:
Batch jobs, ML training, ECS/EKS worker nodes
Karpenter em EKS com provisioner Spot
AWS Batch com compute environment Fargate Spot
Passo 4 — on-demand pra spikes:
Autoscaling que cresce além do commitment coberto
Workloads novos ainda em descoberta de padrão
Passo 5 — revisão mensal:
Cost Explorer → Coverage % target 75-85%
Utilization % target > 90% (evitar commitment idle)
Ajustar nas próximas comprasQual é o critério central para escolher entre compromisso de longo prazo e capacidade sob demanda?
Pitfalls comuns
Comprar 3yr all-upfront cedo demais (trava workload que pode mudar, queima caixa), underutilizar commitment (paga por hora que não usa), Spot em workload não preparado (incidents por interrupção), ignorar RI sharing em Organization (cada conta compra sozinha, perde escala), overcommit só em Compute SP sem análise de stability.
Nunca compre 3yr em workload com menos de 12 meses de histórico. Comece com 1yr no-upfront — em 12 meses você tem dados pra justificar (ou não) upgrade pra 3yr.
Portfolio maduro em org AWS 2026: 60% Compute SP 1yr + 15% EC2 Instance SP 3yr baseline crítico + 15% Spot em workers/batch + 10% on-demand. Coverage 80%+, Utilization 95%+. Economia 25-40% sustentável sem virar projeto anual.
Perguntas frequentes
❓ Como montar a carteira de compromissos?
❓ Compromisso flexível ou reserva específica?
❓ Excedente serve para produção?
Fixando
Qual é a armadilha mais comum com capacidade interrompível?
Por que cobrir 100% da carga com compromisso costuma ser um erro?
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…