Azure RI, Savings Plan e CSP: desconto não é economia sem governança

Reserva de Instância e Azure Savings Plan podem reduzir custos no Azure, mas só geram economia real quando são analisados junto com consumo, preço efetivo do contrato, risco de mudança e governança FinOps.

A melhor decisão não é a que mostra o maior desconto no portal. É a que continua fazendo sentido depois de considerar uso real, contrato, risco técnico e governança financeira.

Na teoria, todos ajudam a reduzir custo. Na prática, cada um resolve um problema diferente.

A Reserva de Instância, também chamada de RI, funciona melhor para workloads estáveis.
O Savings Plan funciona melhor para consumo recorrente, mas mais flexível.
O contrato Enterprise, MCA ou CSP define a base comercial, os descontos, as permissões, a visibilidade de billing e o modelo de governança financeira.

O erro comum é olhar apenas para o percentual de desconto e concluir que a compra vale a pena.

Mas em cloud enterprise a pergunta correta não é:

“Qual opção dá mais desconto?”

A pergunta correta é:

“Qual opção gera economia real considerando meu consumo, meu contrato, meu risco de mudança e minha governança?”

Resumo prático

RI é melhor para workloads estáveis e previsíveis.
Savings Plan é melhor para consumo recorrente, mas flexível.
Contrato Enterprise/CSP pode alterar o preço efetivo e mudar a análise.
RI e Savings Plan podem coexistir, mas não devem ser comprados sem estratégia.
O ganho real precisa ser medido por utilização, cobertura, custo amortizado e economia efetiva.

O problema: desconto não é a mesma coisa que economia

Uma reserva ou um Savings Plan pode reduzir o valor unitário de determinados recursos. Porém, isso não significa automaticamente que a empresa economizou.

A economia real depende de alguns fatores:

o recurso precisa continuar existindo;
o consumo precisa ser recorrente;
o compromisso precisa ser utilizado;
o preço precisa ser comparado com o valor real do contrato;
o benefício precisa ser acompanhado;
o custo precisa ser alocado corretamente para as áreas consumidoras.

Sem isso, o desconto vira apenas uma promessa.

Em outras palavras: compromisso financeiro sem governança pode virar desperdício de longo prazo.

Conceitos rápidos antes de decidir

Antes de comparar RI, Savings Plan e contrato, vale alinhar alguns conceitos.

Reserva de Instância

A Reserva de Instância é um compromisso de uso por 1 ou 3 anos. Em geral, ela é mais indicada para workloads contínuos, estáveis e com baixa chance de mudança de região, família, tipo de instância ou configuração. A Microsoft posiciona reservas como mais adequadas para cargas altamente estáveis e Savings Plan para cargas dinâmicas ou em evolução.

Exemplo prático: uma VM de produção que roda 24×7, na mesma região, com o mesmo tamanho e sem previsão de modernização no curto prazo.

Savings Plan

O Azure Savings Plan é um compromisso de gasto por hora. Em vez de reservar uma instância específica, a empresa se compromete a consumir um valor horário em serviços elegíveis. Ele tende a ser mais flexível do que RI, porque pode cobrir diferentes serviços e regiões elegíveis até o limite do compromisso contratado.

Exemplo prático: uma área que consome compute de forma recorrente, mas alterna entre VMs, App Service, Azure Container Apps, Functions Premium ou outras opções elegíveis.

Contrato Enterprise, MCA ou CSP

O contrato é a camada comercial e administrativa. Ele pode envolver descontos negociados, parceiro CSP, modelo de faturamento, visibilidade de custos, permissões e regras internas de compra.

Por isso, RI e Savings Plan não devem ser analisados apenas contra o preço público. A comparação precisa considerar o preço efetivo que a empresa já paga.

Chargeback

Chargeback é o processo de repassar internamente o custo para a área, produto, centro de custo ou unidade de negócio que consumiu o recurso.

Exemplo: se uma área usa 30% de um benefício contratado, ela recebe 30% daquele custo no rateio interno.

Showback

Showback é parecido com chargeback, mas sem cobrança interna direta. Ele mostra o custo para dar visibilidade e gerar responsabilidade.

Exemplo: a área não recebe uma cobrança contábil, mas recebe um relatório mostrando quanto consumiu e quanto poderia otimizar.

Custo amortizado

Custo amortizado é a distribuição do valor de uma compra ao longo do tempo. Se uma reserva anual foi paga à vista, o custo amortizado ajuda a distribuir esse valor por mês ou por dia, facilitando chargeback e showback.

A documentação da Microsoft explica que a amortização é útil quando a organização precisa distribuir custos de reservas ou Savings Plans entre usuários, departamentos ou áreas consumidoras.

Comparativo rápido

Tabela comparativa entre Reserva de Instância, Savings Plan, contrato Enterprise ou CSP, chargeback e showback no Azure.

Legenda: RI, Savings Plan e contrato atuam em camadas diferentes. Chargeback e showback ajudam a transformar desconto em responsabilidade financeira.

É possível usar RI e Savings Plan ao mesmo tempo?

Sim. É possível ter Reserva de Instância e Savings Plan simultaneamente no Azure.

Isso pode fazer muito sentido em ambientes enterprise.

Uma parte do ambiente pode ser extremamente estável e adequada para RI. Outra parte pode ser recorrente, mas mais dinâmica, sendo melhor candidata a Savings Plan.

O ponto importante é entender que não se trata de “somar descontos” sobre o mesmo consumo.

Quando há reservas e Savings Plans, a Microsoft informa que o Azure aplica primeiro o benefício da reserva, porque ele é mais restritivo e normalmente oferece maior desconto. Depois, o Savings Plan pode ser aplicado ao consumo elegível restante.

Na prática, RI deve cobrir a base estável do consumo. Savings Plan deve cobrir a camada flexível e recorrente que sobra. O objetivo não é empilhar desconto sobre o mesmo recurso, mas desenhar uma cobertura inteligente para perfis diferentes de workload.

O erro é comprar RI e Savings Plan ao mesmo tempo apenas porque apareceram recomendações no portal.

A recomendação deve ser ponto de partida, não aprovação automática.

Cuidado com o contrato CSP ou Enterprise

Um dos pontos mais importantes é este: o preço público do Azure pode não ser o preço real pago pela empresa.

Empresas com Enterprise Agreement, Microsoft Customer Agreement ou contrato via CSP podem ter condições comerciais, descontos, créditos ou regras específicas.

Por isso, antes de comprar RI ou Savings Plan, é necessário comparar a recomendação contra o preço efetivo do contrato.

A própria documentação de Cost Management mostra que o arquivo de detalhes de custo diferencia o preço de mercado, o preço negociado e o preço efetivo usado para cobrança e reconciliação.

Em contratos CSP, existe outro cuidado: a Microsoft documenta que descontos de Savings Plan são aplicados sobre preços estimados de varejo e não são cumulativos com Partner Earned Credit. Quando há Savings Plan, o desconto do Savings Plan é aplicado; quando não há, parceiros elegíveis continuam recebendo os créditos aplicáveis.

Além disso, em cenários CSP, a visibilidade de custos no tenant do cliente pode aparecer com base em preços pay-as-you-go de varejo e não incluir descontos ou créditos do parceiro.

Esse ponto muda completamente a análise.

A empresa não deve perguntar apenas:

“Quanto a RI ou o Savings Plan prometem economizar?”

Ela precisa perguntar:

“Quanto isso economiza em cima do preço que eu realmente pago hoje?”

Quando o contrato pode mudar a conta de RI e Savings Plan?

Em alguns cenários, o contrato atual pode ter uma condição tão boa que o ganho incremental de RI ou Savings Plan fica pequeno.

Isso pode acontecer quando existe:

desconto comercial já negociado;
Azure Consumption Discount;
condição CSP específica;
crédito ou incentivo aplicável;
preço efetivo menor que o preço público;
consumo elegível menor do que o estimado;
workload com risco alto de mudança.

A Microsoft também documenta que, em alguns casos raros, uma taxa de consumo do Azure pode ser menor do que a taxa do Savings Plan; nesses casos, o Azure usa a menor taxa disponível.

Isso reforça um ponto essencial: a decisão precisa ser baseada em dados reais de billing, não apenas em percentual de desconto divulgado.

Compromisso de 1 ou 3 anos: por que estudar com cuidado

Compromissos de 3 anos geralmente parecem mais atrativos porque podem oferecer maior desconto. Mas também aumentam o risco.

Em três anos, uma arquitetura pode mudar completamente.

A aplicação pode ser modernizada.
A VM pode ser redimensionada.
A carga pode sair de IaaS para PaaS.
A região pode mudar.
O produto pode ser encerrado.
O contrato pode ser renegociado.
A área de negócio pode perder orçamento.
Uma nova estratégia de plataforma pode substituir a anterior.

No caso de Savings Plan, o cuidado é ainda maior: a Microsoft informa que compras de Savings Plan não podem ser canceladas ou reembolsadas.

Já reservas possuem mecanismos de troca ou reembolso, mas também dependem de regras e permissões específicas. A documentação oficial indica, por exemplo, que é necessário ter acesso de proprietário ou administrador da reserva para trocar ou reembolsar uma reserva existente.

Por isso, a decisão não deve ser:

“Três anos dá mais desconto, então vamos comprar.”

A decisão deve ser:

“Temos confiança suficiente de que esse consumo continuará existindo durante esse período?”

O erro mais comum: comprar antes de otimizar

Um erro muito comum é comprar compromisso para cobrir desperdício.

Antes de RI ou Savings Plan, a empresa deveria revisar:

recursos parados;
VMs superdimensionadas;
ambientes sem owner;
workloads temporários;
recursos fora do horário de uso;
SKUs maiores do que o necessário;
ausência de tags;
falta de centro de custo;
workloads que já deveriam ter sido desligados.

A própria documentação da Microsoft recomenda uma sequência racional: fazer right-size primeiro, corrigir reservas subutilizadas, considerar trade-in quando fizer sentido e só depois comprar novas reservas ou Savings Plans.

Desconto em recurso desperdiçado continua sendo desperdício.

Sinais de que ainda não é hora de comprar

Nem todo ambiente está maduro para assumir compromisso de 1 ou 3 anos.

Evite comprar RI ou Savings Plan quando:

não existe owner técnico da workload;
a aplicação está em processo de modernização;
o consumo dos últimos meses é muito irregular;
a empresa ainda não fez right-size;
os recursos não possuem tags confiáveis;
não existe centro de custo definido;
o contrato CSP/EA/MCA ainda não foi analisado;
não há processo de revisão antes da renovação;
a economia depende de 100% de utilização para fazer sentido.

Nesses casos, a melhor ação não é comprar compromisso. É organizar o ambiente primeiro.

Fluxo de decisão FinOps para avaliar Reserva de Instância, Savings Plan e contrato Enterprise ou CSP no Azure.

Legenda: A compra deve ser a última etapa do processo, não o início. Primeiro otimize, depois assuma compromisso.

Modelo prático de decisão

Uma forma simples de decidir é usar este raciocínio:

1. O workload é estável?

Se roda 24×7, tem baixa variação, baixa chance de mudança e ciclo de vida conhecido, pode ser candidato a RI.

2. O consumo é recorrente, mas a arquitetura muda?

Se existe consumo constante de compute, mas com mudança de região, SKU, família ou serviço, pode ser candidato a Savings Plan.

3. O contrato já tem desconto relevante?

Se sim, compare RI e Savings Plan contra o preço efetivo, não contra o preço público.

4. Existe risco de modernização ou desligamento?

Se sim, cuidado com compromissos longos.

5. Existe owner técnico e financeiro?

Se não existe dono, a compra não está madura.

6. Existe processo de chargeback ou showback?

Se não existe visibilidade de quem consome, pode ser difícil provar economia depois.

Checklist antes de comprar RI ou Savings Plan

Antes de assumir qualquer compromisso, valide:

Consumo dos últimos 30, 60 e 90 dias.
Baseline de uso, não apenas pico.
Workloads candidatos por subscription, região e SKU.
Risco de resize, migração, modernização ou desligamento.
Preço público versus preço efetivo do contrato.
Impacto de desconto CSP, EA, MCA ou ACD.
Diferença entre compromisso de 1 e 3 anos.
Escopo correto do benefício.
Owner técnico.
Owner financeiro.
Centro de custo.
Modelo de chargeback ou showback.
Utilização esperada.
Economia estimada versus economia real.
Processo de revisão antes da renovação.
Estratégia para compromissos subutilizados.

Se essas respostas não estiverem claras, a compra ainda não deveria ser aprovada.

O que acompanhar depois da compra

A governança não termina na compra. Na verdade, começa depois dela.

As principais métricas são:

Um ponto importante: o Azure Cost Management possui recursos de cost allocation para distribuir custos de serviços compartilhados, mas a Microsoft informa que cost allocation não oferece suporte a compras, incluindo reservas e Savings Plans. Por isso, processos de chargeback relacionados a esses benefícios podem exigir tratamento interno complementar.

Exemplo prático

Imagine uma empresa com três grupos de workloads.

O primeiro grupo possui VMs de produção que rodam 24×7 há mais de um ano, na mesma região e com baixa chance de mudança. Esse grupo pode ser bom candidato para Reserva de Instância.

O segundo grupo possui aplicações em modernização. Parte roda em VM, parte em App Service, parte em containers. O consumo é recorrente, mas a arquitetura muda. Esse grupo pode ser melhor candidato para Savings Plan.

O terceiro grupo está em um contrato CSP com desconto comercial relevante. Antes de comprar qualquer compromisso adicional, a empresa precisa comparar RI e Savings Plan contra o preço efetivo já negociado. Caso contrário, pode assumir compromisso de 1 ou 3 anos achando que está economizando, quando o ganho incremental talvez não justifique o risco.

Esse exemplo mostra que a melhor estratégia pode ser híbrida:

RI para cargas estáveis;
Savings Plan para consumo flexível;
contrato como base comercial;
chargeback/showback para prestação de contas;
monitoramento contínuo para provar economia.

Conclusão

Reserva de Instância, Savings Plan e contrato Enterprise/CSP são instrumentos importantes para otimização de custos no Azure. Mas nenhum deles deve ser tratado como atalho automático de economia.

A RI funciona melhor para workloads previsíveis.
O Savings Plan funciona melhor para consumo recorrente e flexível.
O contrato Enterprise ou CSP define a base comercial e pode alterar completamente a análise de economia.
Chargeback e showback ajudam a transformar custo em responsabilidade.
O custo amortizado ajuda a distribuir corretamente compromissos de 1 ou 3 anos.

É possível usar RI e Savings Plan ao mesmo tempo, desde que exista planejamento.

Também é essencial comparar qualquer recomendação contra o preço efetivo do contrato, principalmente em ambientes com CSP, EA, MCA ou descontos comerciais.

No fim, economia real em Azure não vem apenas da compra certa.

Vem da combinação entre:

FinOps, arquitetura, contrato, governança, chargeback/showback e monitoramento contínuo.

Em cloud, economia sustentável não nasce da compra de um compromisso. Nasce da capacidade de provar, mês a mês, que esse compromisso continua fazendo sentido.

Sem isso, desconto vira apenas mais uma linha complexa na fatura.