Você está pagando 100% On-Demand na AWS enquanto 75% de sua infraestrutura roda 24×7? A escolha entre Reserved Instances e On-Demand não é binária — e essa percepção equivocada custa às empresas brasileiras milhões anualmente. Organizações maduras em FinOps não escolhem um modelo único, mas orquestram portfolios híbridos onde cada workload usa o pricing model que maximiza economia sem sacrificar agilidade. Este artigo detalha a metodologia de otimização que líderes de infraestrutura utilizam para reduzir custos AWS entre 45-65%, com análise comparativa de cenários reais, cálculos práticos e decision trees para diferentes perfis de uso.
A escolha entre modelos de billing AWS representa uma das decisões mais impactantes na otimização de custos cloud, com potencial de economia entre 40-75% comparado ao modelo On-Demand puro.
Reserved Instances (RIs) oferecem descontos significativos em troca de compromisso de uso, enquanto On-Demand proporciona máxima flexibilidade sem contratos.
A estratégia ideal raramente é binária – ambientes de produção maduros adotam abordagens híbridas que balanceiam previsibilidade de custo com agilidade operacional. Segundo análises da Infomach, clientes que implementam estratégias FinOps estruturadas alcançam redução média de 28% nos custos AWS nos primeiros 3 meses, com otimização contínua elevando esse número para 45-60% após 12 meses.
Comparação Estruturada dos Modelos
TABELA COMPARATIVA DETALHADA
| DIMENSÃO | ON-DEMAND | RESERVED INSTANCES (1Y) | RESERVED INSTANCES (3Y) | SAVINGS PLANS | SPOT INSTANCES |
|---|---|---|---|---|---|
| Desconto vs OD | Baseline (0%) | ~30-40% | ~50-65% | ~30-66% (flexível) | ~60-90% |
| Compromisso | Zero | 1 ano | 3 anos | 1 ou 3 anos | Zero |
| Flexibilidade | Total (start/stop sob demanda) | Limitada (tipo/região/SO fixo)* | Limitada | Alta (família de instâncias) | Limitada (interrupções) |
| Pagamento | Por hora consumida | All/Partial/No Upfront | All/Partial/No Upfront | Por hora, compromisso $/h | Por hora (leilão) |
| Melhor para | Dev/Test, cargas imprevisíveis | Produção estável (>75% uptime) | Infraestrutura crítica 24×7 | Workloads dinâmicos (containers) | Batch, Big Data, CI/CD |
| Break-even | – | ~8-10 meses de uso contínuo | ~14-18 meses | ~6-9 meses | Imediato |
| Risco de Desperdício | Baixo (paga só o que usa) | Médio (paga se não usar) | Alto | Médio | Baixo |
| Marketplace | N/A | Sim (revenda de RIs não usados) | Sim | Não | Não |
| Tipos Disponíveis | Todos | Standard / Convertible | Standard / Convertible | Compute / EC2 Instance | Tipos variáveis |
Notas Importantes:
- Convertible RIs permitem mudança de família de instância com pequena redução de desconto (~5%)
- Valores variam por região e tipo de instância (ex: m5.large vs c5.xlarge)
Cenários de Otimização Financeira
CASO 1: Startup em Crescimento
Cenário:
- 10x m5.large (8vCPU, 32GB RAM)
- Uso 24×7 em produção
- Região: us-east-1
Cálculo de Custos (mensais):
ON-DEMAND:
10 instâncias × $0.096/hora × 730 horas = $700.80/mês
RESERVED 1Y (No Upfront):
10 instâncias × $0.063/hora × 730 horas = $459.90/mês
ECONOMIA: $240.90/mês (34%) ou $2,890/ano
RESERVED 3Y (All Upfront):
10 instâncias × $0.054/hora × 730 horas = $394.20/mês
Pagamento único: $14,185 (equivalente a ~36 meses)
ECONOMIA: $306.60/mês (44%) ou $11,037 em 3 anos
SAVINGS PLAN (Compute, 1Y):
Compromisso: $450/mês ($0.0616/hora normalizado)
Flexibilidade: pode migrar para m5a.xlarge, c5.large, Fargate
ECONOMIA: ~$250/mês (36%) + agilidade arquitetural
Recomendação: Savings Plan 1Y – melhor balanço entre economia e flexibilidade para startup que ainda ajusta arquitetura.
CASO 2: Empresa Enterprise com Workload Híbrido
Profile de Uso:
- Baseline constante: 50 instâncias (produção crítica)
- Camada variável: 10-40 instâncias (picos diurnos)
- Batch processing noturno: 20-100 instâncias (3h/dia)
Estratégia Híbrida Otimizada:
CAMADA 1 - BASELINE (50 instâncias):
→ Reserved 3Y All-Upfront
→ Economia: 65% vs On-Demand
→ ROI garantido (uptime >95%)
CAMADA 2 - VARIÁVEL (média 25 instâncias):
→ Savings Plan 1Y Compute
→ Cobre picos com flexibilidade de tipo
→ Economia: 40% vs On-Demand
CAMADA 3 - BATCH (média equivalente a 12.5 instâncias full-time):
→ Spot Instances com Spot Fleet
→ Economia: 70% vs On-Demand
→ Configurar instance diversification (5+ tipos)
→ Implementar checkpointing para tolerar interrupções
CAMADA 4 - SPIKES INESPERADOS:
→ On-Demand (auto-scaling)
→ Representa <5% do compute total
→ Custo aceitável pela garantia de elasticidade
Resultado Consolidado:
ANTES (100% On-Demand): $18,500/mês
DEPOIS (Estratégia Híbrida):
- RIs (Baseline): $3,250/mês
- Savings Plan: $3,000/mês
- Spot (Batch): $450/mês
- On-Demand (Spikes): $600/mês
TOTAL: $7,300/mês
ECONOMIA TOTAL: $11,200/mês (60.5%) ou $134,400/ano
Decision Tree para Escolha de Modelo
┌─────────────────────────────────────────┐
│ Workload tem uso >75% 24x7? │
└────┬────────────────────────────┬───────┘
│ SIM │ NÃO
│ │
▼ ▼
┌────────────────────┐ ┌──────────────────────┐
│ Arquitetura estável│ │ Workload tolerante │
│ por >1 ano? │ │ a interrupções? │
└─┬──────────────┬───┘ └──┬──────────────┬────┘
│ SIM │ NÃO │ SIM │ NÃO
│ │ │ │
▼ ▼ ▼ ▼
┌──────────┐ ┌────────┐ ┌────────────┐ ┌──────────┐
│ RI 3Y │ │ RI 1Y │ │ Spot │ │On-Demand │
│ Standard │ │Convert.│ │ Instances │ │+ Savings │
│ │ │ │ │ │ │ Plan │
└──────────┘ └────────┘ └────────────┘ └──────────┘
Max. Economia Economia Max. Economia Flexibilidade
(65%) +Flex(40%) +Risco(70-90%) Total
Critérios de Decisão Detalhados:
- Reserved Instances 3Y Standard:
- Uso comprovado >85% por 6+ meses
- Infraestrutura crítica de longo prazo (DB primário, AD controllers)
- Budget aprovado para upfront payment
- Reserved Instances 1Y Convertible:
- Workload estável mas arquitetura pode evoluir
- Primeira compra de RIs (testar estratégia)
- Possível mudança de região/tipo em 12 meses
- Savings Plans:
- Ambientes containerizados (ECS/EKS) com variação de tipos
- Microserviços com scaling horizontal frequente
- Multi-região com shifting de carga
- Spot Instances:
- EMR, Spark, batch ETL, rendering
- Testes de carga, CI/CD runners
- Dev/staging de componentes stateless
- Requisito: aplicação com checkpointing ou idempotência
- On-Demand:
- Novos projetos em fase de sizing
- Picos sazonais curtos (<1 semana)
- Ambientes de desenvolvimento ocasionais
Estratégias Avançadas de Otimização
1. RI Portfolio Management
python# Análise de Coverage e Utilization
import boto3
ce= boto3.client('ce')
# Coverage: % de horas cobertas por RIs
response= ce.get_reservation_coverage(
TimePeriod={'Start':'2024-01-01','End':'2024-01-31'},
Granularity='MONTHLY'
)
# Target: >80% para workloads estáveis
# Utilization: % de RIs efetivamente utilizadas
response= ce.get_reservation_utilization(
TimePeriod={'Start':'2024-01-01','End':'2024-01-31'},
Granularity='MONTHLY'
)
# Target: >95% (ou revender no Marketplace)
2. Right-Sizing Antes de Comprar RIs
bash# AWS Compute Optimizer - identifica over-provisioning
aws compute-optimizer get-ec2-instance-recommendations \\
--instance-arns arn:aws:ec2:us-east-1:123456789:instance/i-xxxxx
# Exemplo de output:
# i-xxxxx: m5.2xlarge → m5.large (50% economia mantendo performance)
Regra de Ouro: Nunca compre RIs antes de 30+ dias de análise de CloudWatch metrics (CPU, Memory, Network) – pode economizar 20-40% adicional via right-sizing prévio.
3. Auto-Scaling com Priorização de RIs
yaml# Launch Template com mixed instances policy
mixed_instances_policy:
launch_template:
launch_template_specification:
launch_template_name: prod-app-template
instances_distribution:
on_demand_base_capacity:2# Mínimo On-Demand
on_demand_percentage_above_base:0# Resto usa Spot
spot_allocation_strategy: capacity-optimized
spot_instance_pools:5
spot_max_price:"0.05"# Limite de preço
4. Tag-Based Cost Allocation
bash# Tagueamento obrigatório para análise de ROI
Environment: Production/Staging/Development
CostCenter: Engineering/Marketing/Finance
RIEligible: true/false
Owner: team-name
# CloudWatch Dashboard personalizado por tag
aws cloudwatch put-dashboard \\
--dashboard-name RI-Efficiency \\
--dashboard-body file://ri-dashboard.json
Considerações para Savings Plans
Compute Savings Plans vs EC2 Instance Savings Plans:
| TIPO | DESCONTO | FLEXIBILIDADE | USE CASE |
|---|---|---|---|
| Compute Savings Plans | Até 66% | EC2, Fargate, Lambda (qualquer região) | Arquiteturas cloud-native modernas |
| EC2 Instance Savings Plans | Até 72% | Família de instâncias específica | Workloads estáveis com tipo definido |
Cálculo de Compromisso Savings Plans:
PASSO 1: Analise últimos 30-60 dias de uso
- Use AWS Cost Explorer → Savings Plans Recommendations
PASSO 2: Identifique baseline consistente
- Piso de uso diário (exemplo: $50/dia = $1,500/mês compromisso)
PASSO 3: Comece conservador (70-80% do baseline)
- Primeiro Savings Plan: $1,200/mês
- Monitore cobertura por 30 dias
PASSO 4: Ajuste trimestralmente
- Adicione novos Savings Plans conforme crescimento
- Cancele apenas por não-renovação (não há cancelamento early)
ERRO COMUM: Comprar Savings Plans baseado em projeções de crescimento futuro → resulta em underspending e perda de desconto. MELHOR PRÁTICA: Base em dados históricos, adicione incrementalmente.
Melhores Práticas FinOps
- Visibilidade Completa: Implemente AWS Cost Anomaly Detection + alertas automáticos via SNS/Slack para desvios >15% vs baseline.
- Revisão Mensal de RI Portfolio: Analise utilization (<80% = candidato a venda no Marketplace) e coverage (<70% = oportunidade de compra).
- Reserved Capacity para RDS/ElastiCache: Bancos de dados produção geralmente têm 90%+ uptime → RIs com 50-70% economia são no-brainer.
- Automatize Scheduling: Use AWS Instance Scheduler para desligar dev/test environments fora do horário comercial → 65% economia adicional.
- Establish Showback/Chargeback: Dashboards por equipe/projeto criam accountability e incentivam otimização orgânica.
Da Teoria à Economia Mensurada
A otimização financeira cloud não é projeto único, mas disciplina contínua:
- Análise de baseline histórico (30+ dias de CloudWatch) antes de qualquer compra de RIs evita over-commitment e permite right-sizing prévio • Estratégias híbridas (RIs para baseline + Savings Plans para variável + Spot para batch) entregam 60%+ de economia vs On-Demand puro • Governança via tags e dashboards por centro de custo cria accountability que sustenta otimização orgânica
A Infomach implementa práticas FinOps estruturadas em migrações cloud e ambientes existentes, com análise de workloads, recomendações personalizadas de purchasing strategy e dashboards de monitoramento contínuo. Nossos clientes AWS alcançam ROI médio de 28% de redução de custos nos primeiros 90 dias, com otimização progressiva chegando a 55% em 12 meses através de revisões trimestrais de RI portfolio e automação de scheduling.
Quanto sua empresa está deixando na mesa por falta de estratégia FinOps? Uma análise de 30 dias de sua infraestrutura AWS pode revelar oportunidades de economia equivalentes a meses de budget desperdiçado.
[Solicite Análise Gratuita de Otimização AWS] → https://lp.infomach.com.br/contato