Olá pessoALL,

Se você comprasse uma reserva de três anos hoje, contaria com o exchange pra ajustar o compromisso depois de uma migração? No meu comparativo anterior entre Reservations e Savings Plans, usei essa possibilidade como argumento a favor das reservas. Precisei rever esse ponto com os anúncios da Microsoft. Aqui na AzureBrasil.cloud, a compra precisa fazer sentido pro que o cliente vai rodar durante o contrato, inclusive depois das migrações previstas.

O que os dois anúncios mudam na decisão

Em 18 de março de 2026, a Microsoft anunciou o Savings Plan for Databases. A proposta era assumir um gasto por hora durante um ano e receber preços menores em bancos de dados elegíveis. O anúncio estimava economia entre 0% e 35%, dependendo do serviço, localização e uso. Os 35% vinham de um cenário com Azure SQL Database serverless, comparado ao Pay As You Go, ou PAYG.

Em junho, escrevi o comparativo entre Savings Plan for Databases e Reservations. Defendi reservas para ambientes estáveis e destaquei o exchange, a troca de uma reserva por outra, como saída para mudanças futuras.

Mas a política anunciada em 30 de julho colocou uma data nessa flexibilidade: 1º de fevereiro de 2027. Em 20 de setembro, o artigo You Get One Exchange Left voltou ao assunto e reforçou a necessidade de revisar os compromissos antes da compra.

Eu também simplifiquei demais a recomendação de Savings Plan pra "uso variável". Um ambiente que muda de serviço e mantém gasto recorrente é bem diferente de outro que passa a madrugada inteira sem consumo. Quando fui conferir a aplicação do benefício, ficou claro que aquela recomendação precisava dessa condição.

Se já existe uma migração prevista ou uma redução de capacidade aprovada, isso entra na conta antes da compra. O consumo vai continuar existindo depois dessas mudanças?

Pra nós, como Microsoft Solutions Partner focado em Azure, o trabalho é comparar o desconto com o planejamento do cliente. Preciso entender o que vai mudar na arquitetura, como o ambiente opera e quanto cabe no orçamento.

Como funciona o Savings Plan for Databases hoje

O Savings Plan for Databases é um compromisso financeiro por hora. Dentro do escopo contratado, o Azure aplica o benefício automaticamente ao consumo elegível, começando pelo maior desconto. O valor já descontado consome o compromisso, e o excedente segue a tarifa PAYG aplicável ao cliente.

O prazo também mudou desde o lançamento. O Microsoft Learn revisado em 14 de setembro de 2026 informa termos de um ou três anos, assim como as páginas atuais de preços, como a de MySQL. O anúncio de março falava em um ano. Pra decidir hoje, precisamos comparar os dois prazos.

A cobertura documentada inclui Azure SQL Database, inclusive Hyperscale e serverless, Azure SQL Managed Instance, PostgreSQL, MySQL, Cosmos DB, DocumentDB e Database Migration Service. Confira os componentes elegíveis do seu serviço antes de estimar economia.

As licenças de SQL Server em VMs e SQL Server no Azure Arc também consomem o plano. Porém, entram ao preço normal de PAYG, conforme a observação do Learn. Você pode aproveitar o compromisso com esse gasto sem receber desconto na licença.

Pra comparar as opções, separe os componentes da fatura. Compute (processamento), licença, storage (armazenamento), backup e rede precisam aparecer individualmente na conta.

O compromisso horário é o gasto que você assume, mas a fatura ainda inclui excedentes e outras cobranças. E tem o câmbio: o FAQ de faturamento da Microsoft explica a conversão entre moeda de preço e de cobrança no Microsoft Customer Agreement (MCA) e no Microsoft Partner Agreement (MPA). Um valor definido em dólares pode variar em reais.

Como fica seu direito ao exchange

A mudança alcança reservas dos serviços cobertos por Savings Plans. No anúncio, a lista inclui Azure Virtual Machines, Azure Dedicated Host e Azure App Service. Nos bancos, inclui PostgreSQL, MySQL, DocumentDB, Cosmos DB, Azure SQL Database e Azure SQL Managed Instance.

O anúncio oficial mantém compras, renovações e a flexibilidade de tamanho das instâncias de VM. O ajuste está na possibilidade de trocar reservas elegíveis por outras.

Pela documentação da política, a data de compra ou renovação determina seu direito à troca:

Situação da reserva elegível	Direito ao exchange
Comprada antes de 1/02/2027, com troca antes do corte	Segue a política atual de exchanges
Comprada antes do corte e ainda ativa depois dele	Mantém um exchange final
Resultado desse exchange final	A nova reserva não pode ser trocada novamente
Comprada em ou após 1º/02/2027	Sem exchange
Renovada em ou após o corte, inclusive automaticamente	A nova compra segue a regra sem exchange
Troca parcial de uma reserva anterior ao corte	As quantidades originais restantes mantêm um exchange final cada

Na troca parcial, imagine uma reserva original com dez unidades. Você troca duas depois do corte. As oito restantes preservam seu direito individual. As novas unidades resultantes da troca seguem a política nova.

As exceções da política incluem serviços sem cobertura de Savings Plans, produtos próximos do fim de vida e clouds sem esses planos. Azure VMware Solution é um exemplo sem alteração. Novos serviços que ganharem elegibilidade também entram na política. Confira a situação do produto quando for decidir.

Se precisar ajustar ou encerrar o compromisso, confira qual operação você está fazendo:

• Exchange troca uma reserva por outra, sujeito às regras e à elegibilidade.
• Cancelamento devolve a reserva conforme a política de reembolso. O limite é US$50 mil em compromisso cancelado numa janela móvel de 12 meses. Vale por billing profile (perfil de faturamento) ou enrollment (registro de cobrança EA).
• Trade-in converte reservas elegíveis em Savings Plan da categoria correspondente, compute ou databases.

No trade-in, o compromisso total novo precisa igualar ou superar o valor restante devolvido. Também começa um novo prazo de um ou três anos. Se restam US$1.800, o novo plano precisa assumir pelo menos US$1.800 ao longo do contrato. O valor por hora resultante pode não cobrir os mesmos recursos de antes.

Eu simularia a cobertura antes de confirmar o trade-in, porque a conversão muda as condições comerciais e a forma de aplicar o benefício.

Mas essa flexibilidade entre serviços mantém a obrigação financeira: Savings Plans não permitem cancelamento ou reembolso. Também não podem ser trocados por reservas ou por outro Savings Plan.

Quanto custa uma flexibilidade mal dimensionada

Na aplicação do Savings Plan, o benefício vale pra cada hora. O compromisso sem uso naquela hora expira. Uma hora movimentada mais tarde não recupera o que sobrou antes.

Neste exemplo hipotético, o consumo já está calculado pelas tarifas do plano:

Item em uma hora de pouco consumo	Valor
Compromisso contratado	US$5,00
Consumo elegível às tarifas do plano	US$1,00
Compromisso aproveitado	US$1,00
Compromisso pago sem aproveitamento	US$4,00
Utilização do compromisso	20%

Você paga US$5 nessa hora, aproveita US$1 e perde os US$4 restantes. Esse valor não vira saldo pro dia seguinte.

Se essa situação ocorrer por 12 horas diárias durante 30 dias, serão US$1.440 sem aproveitamento: US$4 × 12 × 30. É uma simulação, sem conversão cambial. Pra calcular economia líquida, ainda precisamos comparar o custo total com o PAYG daquele mesmo consumo.

US$5/h dá US$43.800 de compromisso ao longo de um ano de 365 dias. Eu olharia esse total antes de arredondar a compra "só um pouquinho pra cima".

Um banco de desenvolvimento que liga poucas horas por dia pode deixar benefício ocioso. Já vários bancos, com horários diferentes e consumo agregado recorrente, podem aproveitar melhor um plano dentro do escopo permitido.

Seu consumo continua recorrente quando você olha hora por hora? A média mensal esconde os intervalos de consumo baixo. Eu simularia essa distribuição depois de descontar as reservas existentes e considerar os desligamentos planejados. O compromisso precisa caber no consumo do ambiente que vai permanecer durante o contrato.

Quando escolher Reservations, Savings Plans ou PAYG

Continuo considerando Reservations uma opção forte pra uma configuração conhecida, com consumo contínuo e pouca chance de mudança. É o perfil em que consigo avaliar o desconto com mais confiança, e é também o que a orientação da Microsoft indica pra reservas.

O Savings Plan ganha espaço quando o consumo agregado continua existindo enquanto a arquitetura muda. Uma migração entre bancos elegíveis pode preservar gasto suficiente pra aproveitar o plano, mesmo com distribuição diferente entre serviços e regiões.

Cenário	O que eu avaliaria primeiro	Condição pra decidir
Ambiente estável, com configuração e consumo recorrentes	Reservation	Preço, compatibilidade e expectativa de uso durante o prazo
Modernização com gasto agregado recorrente em serviços elegíveis	Savings Plan	Continuidade do consumo horário após a migração
Desenvolvimento, testes ou projetos com consumo esporádico	PAYG	Risco de pagar compromisso durante períodos sem uso
Ambiente com parte estável e parte em evolução	Combinação	Dimensionar cada compromisso sobre o consumo que ele pode atender

Na minha comparação anterior, usei percentuais estimados pra ilustrar diferenças entre os modelos. Pra decidir uma compra, eu colocaria os preços do serviço e do contrato lado a lado, incluindo a tarifa PAYG negociada, o desconto da reserva e os componentes cobertos pelo plano.

A página de Cosmos DB com throughput provisionado em autoscale publica 12% de desconto em RU/s para Savings Plan. RU/s mede a capacidade de operações do banco. Na consulta feita em outubro de 2026, eram os mesmos 12% pra um e três anos.

Se o desconto é igual, qual benefício justifica assumir três anos naquele cenário? Eu começaria avaliando o prazo menor. Outros serviços podem apresentar condições diferentes. Compare a oferta atual antes de decidir.

Pra combinar os modelos, considere que o Azure aplica reservas compatíveis primeiro. Depois, o Savings Plan atende o consumo elegível restante dentro do seu compromisso, e o que ficar descoberto segue em PAYG. Compute e databases têm planos distintos, cada um com sua elegibilidade.

Essa combinação exige simulação após aplicar as reservas. Comprar dois compromissos dimensionados sobre a mesma base pode criar sobra, mesmo com tudo tecnicamente funcionando.

Como revisar seu ambiente antes de fevereiro

Antes de comprar ou renovar, eu faria esta revisão:

1. Inventarie compromissos e mudanças previstas

Em Reservations e Savings plans, registre serviço, quantidade ou valor horário, escopo, prazo, utilização e renovação. Relacione os compromissos às migrações, desligamentos e mudanças de capacidade aprovadas. Quem conhece o próximo projeto precisa participar dessa revisão junto com quem paga a fatura.

2. Revise arquitetura e licenciamento

No caso do Azure SQL com reserva utilizada a 100%, a cobertura do compute não resolvia todas as cobranças. A documentação de reservas de Azure SQL confirma que software, rede e storage ficam fora desse benefício.

Mas utilização alta ainda pode acompanhar uma arquitetura cara. Por que esse tier, ou camada de serviço? Quais requisitos de disponibilidade, desempenho e recuperação precisam ser atendidos? Avalie as alternativas antes de assumir outro prazo.

3. Elimine desperdícios antes de dimensionar

Revise recursos ociosos, capacidade excessiva e ambientes que podem desligar fora do expediente. No guia de otimização de Azure Storage, o ponto de partida também era entender o uso antes de escolher a estratégia.

Depois dos ajustes, gere novas simulações, porque a linha de base usada pra comprar compromissos pode ter diminuído. A orientação oficial de otimização segue essa ordem: primeiro remover desperdício, depois dimensionar os compromissos.

4. Simule o futuro e escolha o escopo

Compare manter as reservas, fazer exchange enquanto elegível, usar o exchange final ou realizar trade-in. Inclua o consumo posterior às mudanças previstas. Pra novas compras, compare os prazos disponíveis e preserve margem pra incerteza.

Escolha o escopo considerando aproveitamento e responsabilidade pelo orçamento. Coordenar compras evita que equipes dimensionem compromissos sobre o mesmo consumo. Eu documentaria quem acompanha cada benefício e quem decide na renovação.

5. Confira economia e desperdício nos relatórios

No portal, acesse Cost Management → Cost analysis → Amortized cost, no escopo permitido pelo seu contrato. Agrupe por tipo de cobrança e benefício. Procure tanto o consumo atendido quanto o compromisso sem utilização.

Os relatórios oficiais distinguem Actual Cost, usado pra reconciliar cobranças, de Amortized Cost, que distribui o custo do plano. Na visão amortizada, o desperdício aparece como UnusedSavingsPlan. A documentação também apresenta downloads e Cost Details API para cenários EA e MCA. Valide a disponibilidade e as permissões no seu contrato.

Pra responder ao financeiro quanto você economizou, compare o PAYG aplicável ao mesmo consumo com o custo completo dos compromissos, incluindo a parte ociosa.

O que eu mudaria na próxima compra

Eu deixaria de contar com exchanges sucessivos ao comprar uma reserva de três anos pra um ambiente em migração. A política de fevereiro de 2027 permite uma troca final pras reservas anteriores ao corte, e a reserva resultante já segue as novas condições.

Também colocaria uma condição na recomendação de Savings Plan pra uso variável: o gasto precisa continuar recorrente por hora. É com esse consumo em mãos que eu escolheria o compromisso e o prazo.

Aqui na AzureBrasil.cloud, quero que a recomendação de compra tenha essa análise por trás. Como Microsoft Solutions Partner, precisamos entender o roadmap do cliente e comparar os componentes da fatura, além de acompanhar o resultado depois. Se assumir compromisso aumenta o risco, nossa recomendação pode ser manter PAYG.

Se você quer revisar suas reservas e seus Savings Plans antes de fevereiro, fale com a nossa equipe. E compartilhe nos comentários: quais mudanças de arquitetura você já tem previstas durante o prazo dos seus compromissos?

[]s e até a próxima