AWS Savings Plans vs Reserved Instances 2026: o guia de decisão que os engenheiros realmente precisam

Por Dima Kramskoy — Senior Cloud Architect na DoiT International

A pergunta que todo mundo faz errado

Quando eu cuidava de tickets de otimização de nuvem, essa era a pergunta nº 1 dos clientes: "Devemos usar Savings Plans ou Reserved Instances?". Eu via essa dúvida três, quatro vezes por semana, vinda de clientes diferentes.

É a pergunta errada.

A pergunta certa é: como vão estar seus workloads daqui a 12 meses?

Por que essa virada importa: uma empresa que planeja migrar para Graviton vai jogar dinheiro fora com Standard RIs que não conseguem acompanhar os workloads quando eles vão para novas famílias de instância. Já um time com um cluster RDS sólido como uma rocha, que não muda de configuração há dois anos, está deixando dinheiro na mesa ao usar Compute Savings Plans — quando um Standard RI entregaria de 6 a 9 pontos percentuais a mais de desconto.

A decisão entre SP e RI não é sobre produtos. É sobre direção arquitetural. Sua estratégia de commitments deve espelhar seu roadmap de infraestrutura — e não o contrário.

E aqui vai a verdade desconfortável: a maioria dos clientes com quem trabalho não sabe como vão estar seus workloads daqui a 12 meses. Não têm certeza se vão migrar para Graviton no próximo trimestre, partir para containers ou dobrar a capacidade de compute. Isso não é falha de planejamento — é a realidade. Se você não sabe para onde seu workload está indo, essa É a sua resposta. Incerteza = flexibilidade. Escolha pelo menos um Compute Savings Plan — ou, melhor ainda, deixe uma ferramenta carregar o risco do commitment por você (mais sobre isso no final).

Deixa eu te apresentar o framework que uso com clientes enterprise, atualizado com tudo o que mudou em 2025–2026.

Resposta rápida: fluxograma de decisão

Antes de mergulhar fundo, o caminho rápido:

INÍCIO: qual é seu principal workload de compute?
│
├─ Apenas EC2, uma única família de instância, estável há 12+ meses
│   └─ → EC2 Instance Savings Plan ou Standard RI
│       ├─ Precisa de reserva de capacidade? → Standard RI Zonal
│       └─ Quer gestão mais simples? → EC2 Instance SP
│
├─ EC2 em várias famílias de instância
│   └─ → Compute Savings Plan
│
├─ Planejando migração para Graviton (x86 → arm64)
│   └─ → Compute Savings Plan (aplica automaticamente à nova família)
│
├─ Fargate, Lambda ou serverless-first
│   └─ → Compute Savings Plan (único tipo que cobre esses)
│
├─ RDS / Aurora / camada de banco de dados
│   └─ Config estável, desconto máximo? → Standard RI (até 69%)
│   └─ Multi-engine, Gen 7+, flexibilidade? → Database SP (até 35%)
│
└─ Em re-arquitetura ativa ou saindo da AWS
    └─ → Não comprometa. Use On-Demand/Spot até estabilizar.

Tabela comparativa rápida

O que mudou em 2025–2026

Quatro mudanças relevantes desde minha última revisão de otimização de custos:

1. Database Savings Plans foram lançados (dezembro de 2025)

O maior anúncio do re:Invent 2025 para FinOps. Os Database Savings Plans cobrem 10 serviços — Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS e OpenSearch.

O porém: só existem prazos de 1 ano (sem opção de 3), apenas na modalidade No Upfront, e exigem instâncias Gen 7+ (db.r7g, db.m7g). O desconto máximo é de ~35%, bem abaixo dos 69% atingíveis com Standard RDS RIs. Ou seja, não substituem os DB RIs — são uma jogada de flexibilidade para organizações com parques de banco diversos e em evolução.

2. Restrições de compartilhamento de RI/SP (junho de 2025)

A AWS proibiu MSPs e revendedores de compartilhar descontos de RI/SP entre vários clientes finais. Se você compra por meio de um parceiro, seus commitments agora ficam restritos ao seu próprio uso. Compradores enterprise diretos: praticamente não foram afetados.

3. Recurso Group Sharing — GA (novembro de 2025)

Esse passou meio despercebido, mas resolve uma dor real. Agora dá para controlar exatamente quais contas da sua Organization se beneficiam dos commitments compartilhados, usando dois modos:

• Prioritized Group Sharing: o commitment se aplica primeiro ao grupo designado e depois transborda para o restante da organização
• Restricted Group Sharing: isolamento completo — apenas o grupo designado se beneficia

Isso acaba com o problema de "o time errado se beneficiando do nosso RI", que assombrou o consolidated billing por anos. Usa Cost Categories para definir os grupos. Se você gerencia uma organização multi-BU com modelos de chargeback, isso muda o jogo.

4. Os RIs NÃO foram descontinuados

Apesar das especulações recorrentes, as Reserved Instances continuam totalmente suportadas. As páginas de preços da AWS são mantidas ativamente (última atualização em maio de 2026), o Cost Explorer ainda gera recomendações de RI e o RI Marketplace continua operacional. A AWS claramente prioriza os Savings Plans no desenvolvimento de novos recursos e na documentação, mas os RIs não vão a lugar nenhum.

Mais uma coisa: Savings Plans com commitments acima de US$ 100/hora não podem ser devolvidos. Abaixo de US$ 100/hora, você tem uma janela de 7 dias dentro do mesmo mês-calendário, com no máximo 10 devoluções por ano. Em escala enterprise, esses commits são permanentes. Planeje-se de acordo.

Análise aprofundada: Compute SP vs EC2 SP vs Standard RI vs Convertible RI

Esta é a comparação completa que eu gostaria que existisse quando eu precisava tomar essas decisões:

*Clientes EDP não podem vender no RI Marketplace.

Ordem de aplicação no billing (isso importa)

A AWS aplica os descontos nesta ordem de prioridade:

1. As Reserved Instances são aplicadas primeiro (ao uso correspondente)
2. Os EC2 Instance Savings Plans entram em segundo
3. Os Compute Savings Plans são aplicados por último (cobertura mais ampla)

Dentro de cada camada, o uso com maior percentual de economia é coberto primeiro. Isso significa que dá para empilhar os três sem conflitos — a AWS otimiza a aplicação automaticamente.

Portabilidade de workloads: quando flexibilidade vence desconto

A diferença de desconto entre Compute SP (66%) e EC2 Instance SP (72%) é de cerca de 6 pontos percentuais. Em condições enterprise típicas (1 ano, no-upfront), ela encolhe para 2 a 4 pontos. Deixa eu te mostrar quando pagar esse "prêmio de flexibilidade" é a escolha óbvia.

Migração para Graviton

Sair de x86 (m5, c5, r5) para Graviton (m7g, c7g, r7g):

• Compute SP: sem fricção. O desconto se aplica automaticamente às instâncias Graviton no momento em que você as sobe.
• EC2 Instance SP: quebra. m5 ≠ m7g — família de instância diferente.
• Standard RI: completamente inutilizável para as novas instâncias. Commitment encalhado.
• Convertible RI: exige troca manual, valor igual ou maior, e continua travado à região.

Se você está no caminho da migração para Graviton (e deveria estar — são 20 a 40% melhores em preço-performance), os Compute SPs são estruturalmente superiores.

Containerização / transição para serverless

Saindo de EC2 para ECS/Fargate ou Lambda:

• Compute SP: cobre Fargate e Lambda automaticamente. Seu desconto vai junto.
• Todo o resto: cobertura zero para compute em container ou serverless.

Expansão cross-region

Abrindo uma nova região ou consolidando de 4 regiões para 2:

• Compute SP: o desconto se aplica globalmente em todas as regiões.
• Todos os outros: travados por região. A consolidação encalha seus commitments.

A matemática

Em US$ 5 milhões de gasto anual com compute, uma diferença de 6 pontos percentuais custa cerca de US$ 300 mil ao longo de 3 anos. Parece muito — até você perceber que uma migração de Graviton fracassada (porque você não pode largar os RIs travados) te custa a melhoria de performance de 20 a 40% em toda a sua frota. O prêmio de flexibilidade é um seguro, e é um seguro barato.

Os antipadrões (o que acontece quando você erra)

Em mais de 10 anos otimizando custos em nuvem, já vi esses erros custarem milhões para várias organizações. Estes são os cinco mais caros:

Antipadrão 1: comprometer-se com o pico em vez da baseline

O erro: comprar commitments com base no uso máximo observado.

O que acontece: você se compromete com US$ 50/hora porque é o seu pico de segunda de manhã. Sua baseline sustentada é de US$ 35/hora. Você está rodando a 70% de utilização do seu commitment — os outros 30% são desperdício puro.

O custo: em um commit de US$ 50/hora, 30% de desperdício = US$ 131 mil/ano queimados.

A correção: comprometa-se com 70 a 80% do seu piso sustentado (use 60 a 90 dias de dados). Cubra os picos com Spot e On-Demand.

Antipadrão 2: Standard RIs para workloads prestes a migrar

O erro: comprar Standard RIs de 3 anos para uma frota m5 com migração para Graviton no roadmap.

O que acontece: seis meses depois, você está pronto para migrar para m7g. Seus Standard RIs não acompanham. Não são convertíveis. Se você é cliente EDP, também não pode vendê-los no Marketplace. Você está pagando por instâncias que não usa mais.

O custo: um RI de 3 anos encalhado em r5.4xlarge: commitment de ~US$ 278/mês gerando zero benefício pelos 30 meses restantes = US$ 8.340 desperdiçados por instância. Multiplique isso por toda uma frota.

A correção: se qualquer mudança arquitetural está planejada dentro da janela do commitment, use Compute SPs.

Antipadrão 3: deixar commitments expirarem silenciosamente

O erro: nenhum monitoramento de expiração nem fila de renovação.

O que acontece: um lote de RIs expira numa terça. Ninguém percebe até a fatura do fim do mês chegar. Sua taxa efetiva pula de US$ 278/mês para US$ 736/mês por r5.4xlarge — um aumento de 62%+ da noite para o dia.

O custo: uma frota de 20 instâncias voltando para On-Demand por apenas um mês: ~US$ 9.160 de gasto inesperado.

A correção: alertas de expiração no AWS Budgets + compras de Savings Plan enfileiradas antes da data de expiração.

Antipadrão 4: ignorar compute fora do EC2

O erro: comprometer-se apenas com EC2, enquanto mais de 40% do gasto de compute está em Lambda, Fargate ou EKS.

O que acontece: uma parcela significativa do gasto serverless/container fica nas tarifas cheias de On-Demand. Empresas que otimizam só os commitments de EC2 acham que "terminaram", enquanto deixam de 20 a 30% de economia na mesa nos workloads que mais crescem.

O custo: US$ 200 mil/ano em Lambda + Fargate em On-Demand quando um Compute SP economizaria de 20 a 66% = US$ 40 mil a US$ 132 mil/ano de economia perdida.

A correção: audite TODOS os serviços elegíveis. Um único Compute SP cobre EC2, Lambda e Fargate ao mesmo tempo.

Antipadrão 5: comprometer-se durante uma re-arquitetura ativa

O erro: comprar commitments enquanto faz right-sizing, replataformização ou migração.

O que acontece: você se compromete com US$ 80/hora hoje. Nos 6 meses seguintes, a otimização reduz sua baseline para US$ 55/hora. Você fica preso a US$ 25/hora de desperdício pelo resto do prazo.

O custo: US$ 25/hora × 8.760 horas restantes em um prazo de 1 ano = US$ 219 mil em commitment encalhado.

A correção: estabilize primeiro, comprometa-se depois. Use commitments escalonados, alinhados ao seu nível de confiança — commits pequenos durante a migração, commits maiores quando os padrões de uso se consolidarem.

Framework de decisão

Esta é a tabela para tirar print:

A estratégia em camadas (o que eu recomendo para a maioria das organizações)

Não escolha um único tipo. Combine-os em camadas:

1. Camada 1 — Compute SPs (60 a 80% da baseline): cubra seu piso mínimo de compute com flexibilidade máxima
2. Camada 2 — EC2 Instance SPs: coloque por cima nas famílias em que você tem confiança (captura 6pp extras de desconto)
3. Camada 3 — Standard RIs: reserve para workloads ultraestáveis da camada de dados + necessidades de capacidade
4. Camada 4 — On-Demand/Spot: mantenha workloads variáveis e incertos sem commitment

Comece com prazos de 1 ano para validar os padrões. Depois de 12 meses de dados de uso estáveis, adicione prazos de 3 anos para a sua baseline comprovada (15 a 22 pontos percentuais a mais de desconto).

Como a DoiT automatiza isso

Lembra do que falei sobre incerteza? A maioria dos clientes não sabe como vão estar seus workloads daqui a 12 meses. Foi exatamente para esse cenário que o FlexSave for Compute foi criado.

O resumo em uma frase: você recebe as taxas de desconto de um Savings Plan de 1 ano, sem nenhum commitment da sua parte. A DoiT assume o risco.

O que ele faz:

• Monitora seu uso on-demand — analisa o que está rodando, o que está estável e o que está mudando
• Aplica automaticamente os mecanismos ótimos de desconto — cobre workloads elegíveis que ainda não estão cobertos pelos seus próprios RIs/SPs
• Ajusta continuamente — migrando para Graviton? Reduzindo escala? Indo para Fargate? O FlexSave se adapta sem você precisar abrir uma planilha
• Nenhum commitment da sua parte — a DoiT assume o risco do commitment. Você fica com o desconto. Pode sair quando quiser.
• Cobre a stack completa de compute — EC2, ECS, EKS, Fargate, Lambda, SageMaker (não só EC2)

Para bancos de dados: os novos Database Savings Plans da AWS (dez/2025) são sua melhor aposta para RDS e Aurora. O FlexSave foca em compute — onde a incerteza e a necessidade de flexibilidade são maiores.

Para ter visibilidade do que acontece no seu portfólio de commitments, o DoiT Cloud Analytics entrega métricas de utilização, cobertura e desperdício em um só lugar — para você sempre saber se sua estratégia está funcionando.

A combinação resolve os dois problemas: o FlexSave cuida da execução do "eu não sei o que vem depois" e o Cloud Analytics dá a visão de controle. Incerteza deixa de ser problema quando sua ferramenta se adapta junto com você.

TL;DR

1. Compute SPs são a escolha padrão para a maioria das organizações — o prêmio de flexibilidade (2 a 4pp em prazos típicos) quase sempre vale a pena para times com qualquer mudança arquitetural no roadmap.

2. Standard RIs ainda vencem em workloads ultraestáveis — camadas de banco de dados, reservas de capacidade exigidas por compliance e workloads com 18+ meses de estabilidade comprovada.

3. Database Savings Plans (novos em dez/2025) são uma jogada de flexibilidade, não de desconto — 35% contra 69% dos Standard RIs. Escolha-os para parques multi-engine, Gen 7+.

4. Empilhe seus commitments em camadas — Compute SP como base, EC2 Instance SP para famílias em que você confia, Standard RIs para bancos estáveis e On-Demand para todo o resto.

5. Nunca se comprometa durante uma migração ativa — estabilize primeiro, comprometa-se depois. O custo de commitments encalhados sempre supera o custo de esperar.

A estratégia certa de commitments não é maximizar desconto — é alinhar seu commitment à sua direção arquitetural.

Pronto para parar de gerenciar isso na mão? Agende uma demo e veja como o FlexSave otimiza seus commitments da AWS automaticamente.

Dima Kramskoy é Senior Cloud Architect na DoiT International, com mais de 20 anos em engenharia de software, 10 certificações AWS e AWS Community Builder (2026). É especialista em FinOps e otimização de custos em nuvem para organizações enterprise.