Entre todas as alavancas de otimização de custo na AWS, nenhuma move o ponteiro da fatura tão rápido quanto trocar o modelo de compra de capacidade computacional: pagar sob demanda por uma carga que roda 24 horas por dia, 7 dias por semana, pode custar até 72% a mais do que o mesmo uso coberto por um compromisso de Savings Plans ou Reserved Instances. O problema é que a AWS oferece hoje pelo menos cinco variações desses dois modelos — Compute Savings Plans, EC2 Instance Savings Plans, SageMaker Savings Plans, Reserved Instances Standard e Convertible, cada uma em escopo Regional ou Zonal — e escolher errado significa comprar um compromisso rígido demais para uma infraestrutura que muda, ou perder desconto por medo de errar. Este guia entra na mecânica de cada modelo, mostra quando escolher um ou outro por tipo de carga, e como combiná-los na mesma conta AWS.
Se sua empresa ainda não tem um programa de FinOps estruturado — com visibilidade de gasto por time, rotina de revisão e não só uma auditoria pontual —, vale ler primeiro nosso guia completo de FinOps AWS antes de otimizar o modelo de compra: escolher entre RI e Savings Plans é uma tática dentro de uma prática maior de gestão de custo, e funciona melhor com essa base já montada.
O Que São Reserved Instances
Reserved Instances (RIs) são um desconto de faturamento aplicado ao uso de instâncias On-Demand que já rodam na sua conta — não são instâncias físicas separadas, mas um compromisso de compra que reduz o preço cobrado quando o uso real bate com os atributos reservados. Como explica a documentação oficial da AWS sobre Reserved Instances, o preço de uma RI é determinado por quatro atributos fixos: tipo de instância (família + tamanho), região, tenancy (compartilhada ou dedicada) e plataforma (Linux/Unix ou Windows). Qualquer uso que não bater exatamente com esses atributos simplesmente não recebe o desconto — ele continua sendo cobrado à tarifa On-Demand cheia.
Esse é o ponto central para entender RIs: o compromisso é com uma configuração específica de instância, não com um valor de gasto. Se a equipe migrar de m5.xlarge para m6g.xlarge no meio do prazo, a Reserved Instance comprada para o m5.xlarge perde a cobertura — a nova instância volta a pagar preço cheio, e a antiga RI segue sendo cobrada mesmo sem uso correspondente, porque a AWS não permite cancelar RIs após a compra.
O Que São Savings Plans
Savings Plans são um modelo de desconto mais recente, e a própria AWS já recomenda esse caminho como primeira opção: "we recommend Savings Plans over Reserved Instances", segundo o guia oficial de Savings Plans. A diferença fundamental é o que você está comprando. Em vez de travar um tipo de instância específico, você se compromete com um valor de gasto por hora — medido em dólares por hora (USD/hora) — por um período de 1 ou 3 anos. Qualquer uso elegível dentro desse valor comprometido recebe o desconto, independentemente de família de instância, tamanho, sistema operacional ou, dependendo do tipo de plano, até da região.
Na prática, isso resolve o problema mais comum das RIs tradicionais: times técnicos mudam de tipo de instância com frequência — para acompanhar uma nova geração mais eficiente, ajustar dimensionamento, ou mover carga entre serviços — e um Savings Plan acompanha essa mudança sem perder o benefício, desde que o gasto por hora continue dentro do valor contratado. Uso acima do compromisso é cobrado à tarifa On-Demand normal, exatamente como acontece quando o uso de uma RI excede a cobertura.
Os Três Tipos de Savings Plans
A AWS oferece três variações de Savings Plans, com escopo de cobertura diferente:
Compute Savings Plans — o mais flexível dos três. Cobre uso de EC2 em qualquer família de instância, tamanho, sistema operacional, tenancy ou região, e se estende também a AWS Fargate e AWS Lambda. Oferece desconto de até 66% sobre o preço On-Demand, segundo a página oficial de preços de Compute Savings Plans.
EC2 Instance Savings Plans — desconto maior (até 72%), mas em troca de menos flexibilidade: o compromisso fica atrelado a uma família de instância específica (por exemplo, m5) dentro de uma região, embora ainda permita variar tamanho, sistema operacional e tenancy dentro dessa família.
SageMaker Savings Plans — cobre uso de instâncias do Amazon SageMaker AI, independentemente de família, tamanho de instância, componente ou região, seguindo a mesma lógica de compromisso em USD/hora dos demais planos.
Em todos os três, o pagamento pode ser feito como All Upfront, Partial Upfront ou No Upfront — quanto maior o valor pago adiantado, maior o desconto total, seguindo o mesmo princípio das Reserved Instances.
Standard vs Convertible: os Dois Tipos de Reserved Instances
Dentro do universo de RIs, a AWS também oferece duas classes de oferta, com um trade-off direto entre desconto e flexibilidade:
Standard Reserved Instances — entregam o desconto mais alto entre os dois tipos, mas só podem ser modificadas (por exemplo, trocar a Availability Zone dentro da mesma região, ou dividir a reserva), nunca trocadas por um tipo de instância diferente.
Convertible Reserved Instances — oferecem desconto menor que as Standard, mas podem ser trocadas por outra Convertible RI com atributos diferentes — outra família de instância, outro sistema operacional — desde que o valor da nova reserva seja igual ou maior. Também podem ser modificadas como as Standard.
Um erro comum é comprar Standard RIs achando que está "economizando mais" sem considerar o horizonte de mudança da carga: se a arquitetura tem qualquer chance de evolução em 1 a 3 anos, a diferença de desconto entre Standard e Convertible costuma valer menos do que o risco de ficar com uma reserva presa a uma configuração obsoleta.
Regional vs Zonal: o Escopo da Reserva
Além do tipo de oferta, toda Reserved Instance tem um escopo — Regional ou Zonal —, e essa escolha não afeta o preço, apenas o comportamento da reserva. De acordo com a documentação da AWS sobre escopo de Reserved Instances:
| Característica | RI Regional | RI Zonal |
|---|---|---|
| Reserva capacidade física | Não | Sim |
| Flexibilidade entre Availability Zones | Desconto se aplica em qualquer AZ da região | Só na AZ especificada |
| Flexibilidade de tamanho de instância | Sim, dentro da família (Linux/Unix, tenancy padrão) | Não — só o tamanho exato comprado |
| Permite enfileirar compra futura | Sim | Não |
A regra prática: se o objetivo é só desconto de preço, RI Regional é mais flexível e cobre qualquer AZ da região automaticamente. Se o objetivo inclui garantir capacidade disponível numa AZ específica — importante em regiões ou tipos de instância com histórico de indisponibilidade em picos de demanda —, a RI Zonal é a única que reserva capacidade de verdade.
Reserved Instances vs Savings Plans: Comparativo Direto
| Critério | Reserved Instances | Savings Plans |
|---|---|---|
| O que você compra | Configuração específica de instância (tipo, região, tenancy, plataforma) | Compromisso de gasto em USD/hora |
| Desconto máximo vs On-Demand | Até 72% | Até 72% (EC2 Instance) / até 66% (Compute) |
| Flexibilidade de família/tamanho | Baixa (Standard) a média (Convertible) | Alta (Compute) a média (EC2 Instance, dentro da família) |
| Cobre Fargate e Lambda | Não | Sim (Compute Savings Plans) |
| Reserva capacidade física | Só RI Zonal | Não |
| Pode revender o compromisso | Sim, no RI Marketplace (só Standard) | Não |
| Prazo de compromisso | 1 ou 3 anos | 1 ou 3 anos |
| Opções de pagamento | All / Partial / No Upfront | All / Partial / No Upfront |
| Melhor uso | Carga fixa de longuíssimo prazo, sem previsão de mudança de arquitetura | Workload estável mas com expectativa de evolução de tipo/região/serviço |
Quando Escolher Cada Modelo por Tipo de Carga
A decisão certa depende menos de "qual desconto é maior no papel" e mais do comportamento real da carga de trabalho:
Carga estável, mas em evolução técnica constante — times que atualizam gerações de instância, migram entre EC2 e Fargate, ou ainda estão redesenhando a arquitetura se beneficiam mais de Compute Savings Plans. A perda de alguns pontos percentuais de desconto máximo compensa não ficar preso a uma configuração que já não existe mais em produção.
Carga fixa de longuíssimo prazo, arquitetura madura — bancos de dados legados, sistemas monolíticos estáveis ou cargas regulatórias que não têm plano de migração nos próximos anos se beneficiam de EC2 Instance Savings Plans ou até RI Standard, capturando o desconto máximo sem pagar o custo de flexibilidade que não vai usar.
Necessidade de garantir capacidade numa AZ específica — só a RI Zonal resolve isso. Nenhuma Savings Plan reserva capacidade física; elas garantem preço, não disponibilidade.
Workloads de IA/ML em SageMaker — SageMaker Savings Plans é o único caminho de desconto de compromisso disponível para esse serviço, e vale considerar assim que o uso de treinamento ou inferência gerenciada se tornar previsível mês a mês.
Processamento em lote, jobs tolerantes a interrupção — nem RI nem Savings Plans são a resposta certa aqui; vale revisar as opções de Spot Instances, que ficam fora do escopo deste guia mas cobrem exatamente esse padrão de uso.
Como Combinar Reserved Instances e Savings Plans na Mesma Conta
Não é incomum — e frequentemente é o ideal — usar os dois modelos ao mesmo tempo em contas AWS maduras. A estratégia mais comum em empresas de médio porte é:
- Cobrir a base de carga mais previsível e estável (o "piso" de uso que nunca cai, mesmo em baixa temporada) com Compute Savings Plans, pelo desconto alto com flexibilidade de trocar tipo de instância conforme a arquitetura evolui.
- Reservar RIs Zonal pontuais só onde existe necessidade real de capacidade garantida numa AZ específica — não como regra geral, mas como exceção justificada.
- Deixar o restante do uso variável — picos sazonais, ambientes de teste, cargas imprevisíveis — em On-Demand ou Spot, sem tentar forçar cobertura de compromisso onde não existe previsibilidade.
Quem já tem RIs compradas antes de migrar para Savings Plans não precisa escolher um ou outro de uma vez: a AWS aplica primeiro o desconto das RIs existentes e só depois cobre o restante do uso elegível com o Savings Plan, então os dois modelos convivem naturalmente até as RIs antigas expirarem.
Cobertura e Utilização: as Duas Métricas que Importam
Comprar o modelo certo não é o fim do trabalho — é preciso acompanhar duas métricas continuamente, disponíveis no AWS Cost Explorer:
Cobertura (coverage) — que percentual do uso elegível total está sendo pago com desconto (RI ou Savings Plan) versus On-Demand. Cobertura baixa significa dinheiro deixado na mesa: uso que já é previsível o suficiente para merecer compromisso, mas ainda paga preço cheio.
Utilização (utilization) — que percentual do compromisso comprado está sendo efetivamente consumido. Utilização baixa é o oposto do problema anterior: compromisso comprado além do necessário, sendo pago mesmo sem uso correspondente — no caso de RIs No Upfront ou Partial Upfront, isso é dinheiro saindo todo mês sem retorno.
O ponto de equilíbrio saudável fica entre cobertura alta (perto de 80-90% do uso estável coberto por compromisso) e utilização próxima de 100% do que foi comprado. Revisar essas duas métricas mensalmente — não uma vez por ano — é o que evita tanto o desperdício de pagar On-Demand desnecessariamente quanto o de manter compromisso ocioso.
Erros Comuns na Compra de RIs e Savings Plans
Comprar RI de 3 anos sem visibilidade de roadmap técnico — o desconto maior do prazo longo não compensa se a equipe já sabe que vai trocar de arquitetura em 12 meses. Nesse cenário, Savings Plans de 1 ano ou Compute Savings Plans (mais flexíveis) protegem melhor contra essa incerteza.
Ignorar o RI Marketplace ao encerrar um projeto — Standard Reserved Instances não utilizadas podem ser revendidas no Reserved Instance Marketplace, recuperando parte do valor investido, desde que tenham ao menos um mês restante de prazo e já estejam ativas há pelo menos 30 dias na conta. Convertible RIs não podem ser revendidas — mais um motivo para considerar esse fator na hora da compra.
Comprar RI Zonal por padrão sem precisar de reserva de capacidade — quando o objetivo é só desconto, RI Zonal trava flexibilidade de AZ sem trazer benefício de preço adicional sobre a Regional. É desconto igual com mais rigidez, sem necessidade.
Não revisar cobertura e utilização depois da compra inicial — tratar a compra de RI/Savings Plan como projeto de uma vez, em vez de rotina contínua, é o mesmo erro que compromete qualquer prática de FinOps: a fatura muda toda semana, e o compromisso de compra precisa ser revisado com a mesma frequência.
Misturar volume discount com intenção de revender — Reserved Instances compradas com desconto por volume não podem ser listadas no RI Marketplace; se existe qualquer chance de precisar revender, vale considerar esse detalhe antes de fechar a compra.
Casos de Uso por Porte de Empresa
Empresas de 30 a 100 funcionários, primeira conta AWS madura — normalmente ainda estão validando arquitetura e não têm 12 meses de histórico de uso estável. Nesse estágio, Compute Savings Plans de 1 ano, com pagamento No Upfront, é o ponto de entrada mais seguro: desconto real sem travar decisão de infraestrutura ainda incerta.
Empresas de 100 a 300 funcionários, cargas já estabilizadas — já dá para segmentar: Compute Savings Plans para a base flexível, e RIs Zonal pontuais para bancos de dados ou serviços críticos que exigem garantia de capacidade. É o perfil que mais se beneficia de revisar cobertura e utilização mensalmente com apoio de um parceiro AWS certificado, porque o volume de decisões já justifica acompanhamento especializado.
Empresas acima de 300 funcionários, múltiplas contas e cargas heterogêneas — o cenário mais complexo, com AWS Organizations envolvendo várias contas, cada uma com padrão de uso diferente. Aqui, RIs Convertible e EC2 Instance Savings Plans entram como ferramentas específicas para cargas maduras dentro de um portfólio maior dominado por Compute Savings Plans, geralmente sustentado por uma consultoria AWS especializada que acompanha as recomendações do Cost Explorer continuamente — o mesmo tipo de disciplina que aparece no pilar de Otimização de Custos do AWS Well-Architected Framework.
Perguntas Frequentes sobre Savings Plans e Reserved Instances
Savings Plans e Reserved Instances podem ser usados ao mesmo tempo na mesma conta AWS?
Sim. A AWS aplica primeiro o desconto das Reserved Instances já compradas e, depois, cobre o uso elegível restante com o Savings Plan — os dois modelos convivem sem conflito até as RIs existentes expirarem.
Qual o desconto máximo real: Reserved Instances ou Savings Plans?
Os dois chegam a até 72% sobre o preço On-Demand no melhor cenário (RI Standard de 3 anos All Upfront, ou EC2 Instance Savings Plans de 3 anos All Upfront). Compute Savings Plans, por ser o mais flexível dos três tipos, tem teto um pouco menor, de até 66%.
É possível cancelar uma Reserved Instance ou um Savings Plan depois da compra?
Não. Nenhum dos dois modelos pode ser cancelado após a compra. Reserved Instances Standard podem ser revendidas no RI Marketplace (Convertible não podem); Savings Plans não têm mecanismo de revenda — o compromisso precisa ser consumido ou fica ocioso até o fim do prazo.
O que acontece se meu uso ficar abaixo do valor comprometido no Savings Plan?
Você continua pagando o valor por hora comprometido, mesmo sem uso correspondente — é um compromisso fixo, não um teto. Por isso a métrica de utilização precisa ser acompanhada de perto antes de aumentar qualquer compromisso.
Reserved Instances cobrem Fargate e Lambda como os Savings Plans cobrem?
Não. Reserved Instances são específicas para EC2 (e outros serviços com RI próprio, como RDS e ElastiCache, cada um com seu programa separado). Só o Compute Savings Plans estende a cobertura para AWS Fargate e AWS Lambda além do EC2.
Vale a pena comprar Reserved Instances de 3 anos para economizar mais?
Só se houver confiança real de que a configuração de instância vai continuar a mesma pelos 3 anos — o que é raro em empresas que ainda evoluem arquitetura com frequência. Na dúvida, um Savings Plan de 1 ano entrega quase o mesmo desconto com muito menos risco de ficar preso a uma configuração obsoleta.
Como saber se minha empresa já está pronta para comprar Savings Plans ou Reserved Instances?
O sinal mais confiável é ter pelo menos 30 a 60 dias de histórico de uso estável no AWS Cost Explorer, mostrando uma base de consumo que não varia muito de semana para semana. Comprar compromisso sobre uso ainda imprevisível é a principal causa de baixa utilização depois.
Escolher Entre Reserved Instances e Savings Plans é Decisão de Arquitetura, Não Só de Preço
Reserved Instances e Savings Plans resolvem o mesmo problema — reduzir o custo de compute que roda de forma previsível — mas partem de premissas diferentes sobre o quanto a infraestrutura vai mudar. Não existe resposta certa de forma absoluta: o modelo certo depende de quanto a arquitetura ainda vai evoluir, se existe necessidade real de capacidade garantida numa AZ específica, e da disciplina que a equipe tem para revisar cobertura e utilização mês a mês, não uma vez por ano. Empresas que tratam essa escolha como decisão pontual de compra tendem a acumular RIs presas a configurações abandonadas; as que revisam continuamente — dentro de uma prática maior de análise de custos AWS — conseguem manter desconto alto sem perder a flexibilidade que a nuvem deveria oferecer.
Artigos Relacionados
Para aprofundar em temas conectados à otimização de custo de computação na AWS:
- FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — a prática mais ampla de gestão financeira de nuvem, da qual a escolha entre RI e Savings Plans é apenas uma tática dentro do pilar de Otimização.
- AWS Well-Architected Framework: o Guia Avançado — entenda como o pilar de Otimização de Custos do framework se conecta com a disciplina de cobertura e utilização descrita aqui.
- Amazon EC2 para Pequenas Empresas: Guia Completo — para quem ainda está estruturando o uso de EC2 antes de considerar qualquer modelo de compromisso de compra.
- Consultoria AWS Especializada: o Guia Completo — para empresas que preferem terceirizar a análise contínua de cobertura, utilização e recomendação de compra.
