11 de junho de 2026•8 min de leitura

Ajuste fino de Azure Savings Plans com dados horários: como transformar uma recomendação de caixa-preta em uma decisão defensível

TL;DR: O portal do Azure mostra apenas um valor de recomendação para Savings Plans, mas esconde a série horária de uso PAYG que realmente importa. Este artigo mostra como extrair esses dados via API REST, usar um script PowerShell para gerar CSVs analíticos e tomar decisões de commitment defensíveis — sem chute ou sobra. Ideal para times de FinOps que querem sair do 'vibe' para o número exato.

A maioria de nós já dimensionou um compromisso do mesmo jeito que pede pizza para um almoço de equipe: estima, arredonda para cima e torce para ninguém reclamar. Funciona para pizza. É uma estratégia menos robusta para um Savings Plan de três anos.

O Azure Cost Management já produz recomendações de commitment, e elas são um ótimo ponto de partida. Mas o valor em destaque no portal esconde o sinal mais útil que um time de FinOps pode ter em mãos: o uso horário Pay-As-You-Go (PAYG) que o motor de recomendação realmente analisou. Assim que você coloca esse sinal em uma planilha, "right‑sized" deixa de ser um vibe e passa a ser um número que você pode defender em uma reunião de steering.

Este artigo mostra como extrair esses dados da API REST do Cost Management e compartilha um script PowerShell complementar que faz o trabalho pesado e produz saídas em CSV e Markdown amigáveis para análise.

Por que um único número recomendado não é suficiente?

Uma recomendação de Savings Plan é, em essência, uma otimização contra uma distribuição de gastos horários de compute em uma janela de lookback. O portal normalmente exibe o nível único de commitment que maximiza a economia sob uma suposição de "utilização razoável". Esse é um padrão sensato, mas responde apenas a uma pergunta.

As perguntas que profissionais de FinOps também querem responder incluem:

Como é a minha demanda PAYG hora a hora? Suave e previsível, ou irregular e sazonal?
Como a cobertura e a economia mudam se eu comprometer um pouco menos, ou um pouco mais?
O commitment recomendado vai me deixar com wastage nos fins de semana ou durante a noite?
Consigo correlacionar o perfil horário com janelas de manutenção, jobs em lote ou horário comercial?

Você não consegue responder a essas perguntas com um único valor em dólar. Você consegue responder a todas elas com a série horária e os níveis alternativos de commitment — e a API expõe ambos.

O que a API Benefit Recommendations oferece?

O endpoint é a operação Benefit Recommendations - List (api-version=2025-03-01). Apontado para qualquer um dos scopes suportados — Billing Account (EA), Billing Profile (MCA), Subscription ou Resource Group — ele retorna uma ou mais recomendações para o lookBackPeriod escolhido (Last7Days, Last30Days, Last60Days) e term (P1Y, P3Y).

As duas opções $expand são onde a mágica mora:

$expand=properties/allRecommendationDetails retorna um array de níveis alternativos de commitment (AllSavingsBenefitDetails). Cada entrada inclui commitmentAmount, coveragePercentage, benefitCost, overageCost, savingsAmount, savingsPercentage, wastageCost e averageUtilizationPercentage.
$expand=properties/usage retorna a série horária de cobrança PAYG (usage.charges) que o motor utilizou. Combinado com properties.firstConsumptionDate e properties.lastConsumptionDate, você obtém uma visão completa e alinhada no tempo da demanda.

Ambas as expansões são baratas e valem a pena serem solicitadas sempre. Elas transformam uma única recomendação em um produto de dados pequeno e completo.

Conheça o script: Export-BenefitRecommendations.ps1

Para tornar isso útil em cinco minutos em vez de uma tarde, existe um script PowerShell no GitHub que encapsula a chamada à API e produz artefatos prontos para uso. Ele é interativo, então não há nada para memorizar:

=== Azure Benefit Recommendations Export ===

Select billing scope kind:
  * [1] Billing Account (EA)
    [2] Billing Profile (MCA)
    [3] Subscription
    [4] Resource Group
Enter choice 1-4 (default 1): 1
Billing Account ID: <your-EA-billing-account-id>

Select lookback period:
    [1] Last7Days
  * [2] Last30Days
    [3] Last60Days
Enter choice 1-3 (default 2): 3

Select term:
  * [1] P1Y
    [2] P3Y
Enter choice 1-2 (default 1): 2
...
Retrieved 1 recommendation(s).

Ele autentica via o módulo Az.Accounts, sempre solicita ambas as opções $expand, segue a paginação nextLink, verifica o acesso à API antecipadamente (traduzindo 401/403/404 em dicas acionáveis) e escreve quatro arquivos usando um padrão de nome previsível:

yyyy-MM-dd-<scope>-<lookback>-<term>-AllRecommendationDetails.csv — uma linha por alternativa de commitment, pronta para tabelas dinâmicas.
yyyy-MM-dd-<scope>-<lookback>-<term>-TopRecommendation.md — um resumo em Markdown da recomendação principal, incluindo a linha de commitment recomendada e a tabela completa de alternativas.
yyyy-MM-dd-<scope>-<lookback>-<term>-HourlyUsage.csv — uso PAYG hora a hora para a recomendação principal, alinhado à janela de dados real da API (sem padding, sem espaços em branco no final).
yyyy-MM-dd-<scope>-<lookback>-<term>-Raw.json — dump opcional da resposta completa, para arquivamento ou ferramentas downstream.

A convenção de nomenclatura é intencional: cole uma pasta desses arquivos no Power BI e as datas, scopes e termos já estarão no nome do arquivo.

Quer ajuda para implementar FinOps na sua empresa? Conheça as soluções da Nuvem Online.

Exemplo prático

Aqui está uma forma real de uma exportação Last60Days / P3Y contra uma conta de faturamento EA. O CSV AllRecommendationDetails nos dá quatro alternativas de commitment:

averageUtilizationPercentage,coveragePercentage,commitmentAmount,overageCost,benefitCost,savingsAmount,savingsPercentage,totalCost,wastageCost
100.000,28.868,4.124,30914.280,5889.072,6656.889,15.317,36803.352,0.000 100.000,39.168,5.848,26437.791,8350.944,8671.506,19.953,34788.735,0.000
9.984,97.883,16.359,919.948,23360.652,19179.641,44.131,24280.600,3.767 98.684,98.900,16.806,477.956,23998.968,18983.317,43.680,24476.924,315.907

Leia essas linhas como uma alavanca interativa:

Comprometer $4.124/hora → 28,9% de cobertura, 15,3% de economia, zero wastage. Seguro, mas a maior parte do gasto ainda é PAYG.
Comprometer $5.848/hora → 39,2% de cobertura, 19,9% de economia. Ainda seguro, ainda conservador.
Comprometer $16.359/hora → 97,9% de cobertura, 44,1% de economia, ~$3,77 de wastage. Este é o ponto ideal que o motor sinaliza como recomendado.
Comprometer $16.806/hora → 98,9% de cobertura, 43,7% de economia, mas o wastage salta para $315,9 na janela. Você comprou mais cobertura e o motor te cobrou por isso.

O CSV horário é o que torna a recomendação defensível. Ele contém 1.428 linhas — uma por hora de 2026-04-11T00:00 até 2026-06-09T11:00 (o intervalo de dados reportado pela API, não "agora menos 60 dias"):

DateTime,HourlyPayGoUsage
2026-04-11T00:00,29.5350191832771
2026-04-11T01:00,29.566694701744
...
2026-06-09T11:00,32.7312920192344

Jogue isso no Excel ou Power BI, coloque uma linha horizontal no commitmentAmount recomendado ($16.359/hora), e você verá imediatamente com que frequência a demanda fica acima da linha (coberta por PAYG overage) versus abaixo dela (onde o commitment está tecnicamente ocioso, mas, dada a taxa de economia, ainda é líquido-positivo). Você também pode fatiar por hora do dia para identificar vales de fim de semana ou picos de jobs em lote que mudam a forma como você interpreta a "utilização média".

Como usar?

O script e a documentação completa estão em github.com/DirkBrinkmann/azure-savingsplan-insights. Início rápido:

git clone https://github.com/DirkBrinkmann/azure-savingsplan-insights.git 
cd azure-savingsplan-insights 
Install-Module Az.Accounts -Scope CurrentUser  # se você ainda não tem

#Conecte-se ao Azure
Connect-AzAccount
#Execute o script 
.\Export-BenefitRecommendations.ps1

Você precisará de permissão de leitura no scope alvo — Cost Management Reader em uma assinatura, ou Billing Reader no nível de billing account / billing profile, é suficiente.

Teste contra seu próprio scope e nos conte como foi. O repositório tem Issues e Discussions habilitados — relatórios de bug, casos extremos, ideias de funcionalidades e histórias de "plotei isso no Power BI e aprendi X" são todos bem-vindos. O script só vai melhorar com dados do mundo real, e os seus são os que queremos ouvir.

Considerações finais

Em termos de FinOps, esta é uma atividade da fase Inform: transformar uma recomendação de caixa-preta em um conjunto de dados transparente que seu time pode desafiar, gráficar e alinhar. A API sempre teve esses dados; o script apenas torna a extração algo rotineiro — que é exatamente o que você quer que uma ferramenta de FinOps seja.

Faça uma exportação Last60Days / P3Y para o seu scope de maior gasto, plote a linha horária e decida seu próximo Savings Plan com um número que você pode apontar. Seu eu do futuro (e seu parceiro de finanças) agradecerão.

Perguntas Frequentes

Por que o valor único de recomendação do portal não é suficiente?
O valor único é um otimizado para 'utilização razoável', mas não responde a perguntas críticas: como é a demanda horária real? O que acontece com cobertura e saving se eu comprometer um pouco menos ou mais? Haverá wastage em finais de semana? As séries horárias resolvem isso.
Quais dados a API Benefit Recommendations expõe que o portal não mostra?
A API, com os parâmetros $expand, retorna a série horária de uso PAYG (usage.charges) e uma tabela com níveis alternativos de commitment (AllSavingsBenefitDetails), incluindo commitmentAmount, coveragePercentage, savingsPercentage e wastageCost para cada alternativa.
O script Export-BenefitRecommendations.ps1 requer permissões especiais?
Sim. Você precisa de pelo menos 'Cost Management Reader' na assinatura ou 'Billing Reader' no billing account / billing profile. O script verifica o acesso e traduz erros 401/403/404 em dicas acionáveis.
Como o dado horário melhora a decisão de um Savings Plan?
Com a série horária em uma planilha, você pode traçar uma linha horizontal no valor recomendado e ver quantas horas o consumo fica acima (coberto por PAYG overage) ou abaixo (idle, mas ainda vantajoso). Permite também correlacionar com janelas de manutenção ou batch jobs.