How does departmental chargeback work in cost management?
One of the most common questions we hear is "how can I charge back the cost of AI workloads to the business units responsible for their consumption?" As your organization scales and your AI usage becomes more distributed, departmental chargeback becomes increasingly important for maintaining clear cost ownership and financial accountability. It gives each business unit visibility into the costs it incurs, supports more accurate budgeting, and helps the organization manage growing AI spend without relying on a single centralized budget. In this post, we’ll cover: What is chargeback? How is chargeback built-in to Agent 365 cost management in Microsoft 365 admin center? How will custom chargeback scenarios be supported? What is chargeback? Chargeback is not a new concept. Organizations have long used it to assign shared technology costs to the business units responsible for their consumption. But it is becoming more important as AI shifts from fixed per-user licenses to usage-based billing. Chargeback brings that same discipline to AI by assigning costs to the business units responsible for their AI usage, rather than leaving them in one central budget. As your organization become more mature in its AI adoption, they increasingly want this level of accountability—so each business unit owns the cost of its AI usage and becomes responsible for the value it generates. For example, IT builds an AI agent that helps the Sales Development team research prospects, personalize outreach, and write follow-up messages. IT tracks how much the team uses the agent and charges those costs to the sales department each month, instead of covering them through a central IT budget. This helps sales understand what it is spending and compare that cost with results such as qualified opportunities and pipeline generated. How is chargeback built-in to cost management? Agent 365 cost management in the Microsoft 365 admin center gives IT admins a one-stop shop to manage usage-based billed AI services. It’s already included in your existing Microsoft cloud subscriptions (i.e., it does not require separate Agent 365 or ME7 licensing to manage your Microsoft services). As we shared in our previous FinOps for AI post, cost management brings together the visibility and controls you need to understand usage, manage spend, and make more informed decisions as AI adoption grows. Spending policies are at the center of the experience. They let admins decide who can use supported AI services, set enforced spending limits, and receive alerts as usage approaches those limits. This helps you give teams room to use AI while keeping variable costs within clear guardrails. Departmental chargeback in cost management is built into the experience, and it is structured on Azure subscriptions and resource groups. We designed it this way because many organizations already align on an Azure subscription to each department, giving that department a clear boundary for managing and tracking its own costs. If a separate subscription for every department does not fit your setup, each department can instead use its own resource group within a shared subscription. Either approach lets AI usage follow the same financial structure as the rest of your cloud spend, so costs are assigned to the right team and fit into existing reporting and finance processes. Because usage is tied to the right subscription or resource group from the start, you can avoid the manual work of calculating each department’s bill and charging them at the end of the month. This gives you a practical way to introduce chargeback without adding another layer of manual tracking or reconciliation. For more details on organizing along Azure subscriptions and resource groups, check out this link for more details: Resource organization design area overview - Cloud Adoption Framework | Microsoft Learn. Configuring this in cost management is simple. When selecting the billing method for the spending policy, you can select the Azure subscription and resource group that should receive the charges, along with the region where billing-related tenant and usage data will be stored. This connects the department’s AI usage to the right Azure billing structure from the start. Built-in departmental chargeback is available for spending policies billed via pay-as-you-go and pre-purchase plans. You can also view this spend directly in the Azure Portal. Open the subscription connected to the spending policy, go to cost analysis, and filter the meter category to Microsoft Copilot Studio. From there, add a tag filter for policyname or servicename—for example, Cowork—to narrow the view and understand spend trends over time. (Note: Although the meter category currently appears as Microsoft Copilot Studio, it reflects all Copilot Credits usage; we are working to update the name so it better represents the services covered.) How will custom chargeback scenarios be supported? Built-in departmental chargeback works well when your organization already uses Azure subscriptions or resource groups to separate costs. But not every chargeback model follows that structure. And some organizations have established FinOps, reporting, or finance processes that require data to flow into their own systems. The Microsoft 365 Copilot Cost Management APIs in Microsoft Graph are available through the Microsoft Graph beta endpoint, giving you a programmatic way to manage cost controls at scale. With these APIs, you can view credit balances at the user, service, and tenant levels; create, read, update, and delete spending policies; manage the groups each policy applies to; configure service settings; and set limits and alerts. For example, you could use a single POST request to create a spending policy for a pilot group with a clear monthly cap and a per-user limit. In the same request, you can choose the billing method and enable the services the policy should cover—such as Cowork and Work IQ—so the right users, budget guardrails, and service access are configured together. You can get started today by reviewing the documentation available on Microsoft Learn. POST https://graph.microsoft.com/beta/copilot/costManagement/spendingPolicies Content-Type: application/json { "@odata.type": "#microsoft.graph.selectedGroupsSpendingPolicy", "displayName": "Pilot teams monthly cap", "periodLimit": { "@odata.type": "#microsoft.graph.limitedCostManagementQuantity", "value": 10000, "unit": "copilotCredit" }, "perUserLimit": { "@odata.type": "#microsoft.graph.limitedCostManagementQuantity", "value": 500, "unit": "copilotCredit" }, "billingMethods": "prepaidCredits", "serviceSettings": [ { "serviceId": "cowork", "state": "enabled" }, { "serviceId": "workIQ", "state": "enabled" } ] }@ We are building on this foundation to give you more flexibility in your custom chargeback processes. To support that flexibility, we are developing a data pipeline for detailed AI cost and usage data that you can bring into your business intelligence tools, data lakes, or chargeback systems of choice. From there, you can apply your own allocation rules, combine AI spend with other technology costs, and support the reporting and financial processes that already work for your business. We plan to share more updates next month. As AI becomes a bigger part of how work gets done, you need a practical way to understand who is using it, manage what they spend, and connect that investment to business value. Whether you use built-in departmental chargeback or extend it with Microsoft Graph and custom reporting, you have a flexible foundation that can grow with your organization.
FinOps for AI Workloads on Azure: Tokens, PTU and Pay-As-You-Go
Originally published on Substack: https://gisli78.substack.com/p/finops-for-ai-workloads-on-azure Part 3 of my Azure AI landing zone series is about FinOps for AI workloads. Tokens are the AI bill most teams actually get, so the post covers: Picking the deployment type first: Global Standard, Data Zone, Batch and Flex (preview) Why quota isn't billing, and why max_tokens eats your TPM PTU vs pay-as-you-go, and when hourly PTU actually pays off Sizing PTU with Microsoft's formula, and how prompt caching helps Spillover: PTU for the baseline, pay-per-token for the peaks Showback per team with llm-token-limit and llm-emit-token-metric in API Management Cost Management: group by meter, tag your deployments, and remember budgets only alert Read the full article on Substack: https://gisli78.substack.com/p/finops-for-ai-workloads-on-azure Bicep sample: https://github.com/gislig/azure-ai-landing-zone/tree/main/examples/ai-finopsHow to keep agentic workloads orchestrated, fast, and affordable
Getting AI to production is only half the battle. Once agentic workloads are live, organizations face compounding challenges: token costs that grow non-linearly, latency that degrades user trust, Retrieval-Augmented Generation (RAG) pipelines that return noise instead of signal, and orchestration overhead that multiplies with every agent added to the mesh. This is where the real engineering begins. Wrap up your Path to production Tech Accelerator experience with a practical optimization playbook for agentic AI, from model selection and inference routing to prompt compression, RAG tuning, and caching strategies. Learn how to manage orchestration complexity across multi-agent systems while improving signal quality and response times. Explore FinOps practices for AI, including capacity planning, batch processing, and intelligent model routing. Walk away with actionable techniques to reduce inference costs, cut latency, and scale reliably across regions. How do I participate? Select Add to Calendar to save the date, then click the Attend button to save your spot, receive event reminders, and participate in the Q&A. Not able to attend live? This session will be recorded and available on demand shortly after airing. Just announced! Live Q&A will also be available July 29 from 10:00-11:00 AM SGT (UTC+8) to support attendees in Asia and western Australia. Don't see Attend or Add to Calendar? Sign in to the Tech Community to join the conversation. Organizational policies preventing you from signing in to the Tech Community? Use a personal account or tune in on LinkedIn. This session is part of Path to production for agents: a Microsoft Azure AI Tech Accelerator. View the full agenda for more actionable strategies to help you deliver secure, compliant, and high-performing AI solutions across your organization.Detectando Anomalias de Custo no Azure com FinOps Hub + SRE Agent
Introdução Um dos maiores desafios em ambientes cloud é manter a visibilidade sobre os custos. Picos inesperados podem passar despercebidos por dias e quando chegam na fatura, já é tarde demais. Neste artigo, vou mostrar como configurei uma análise automática diária de anomalias de custo usando o Azure SRE Agent, conectado ao FinOps Hub (Azure Data Explorer), com notificação automática no Microsoft Teams quando algo fora do padrão é detectado. 🏗️ Arquitetura da Solução FinOps Hub (ADX) → SRE Agent (Scheduled Task) → KQL Anomaly Detection ↓ anomalia detectada? SIM → Adaptive Card → Teams Channel NÃO → Log: 'custos dentro do esperado' Pré-requisitos Requisito Detalhe ✅ FinOps Hub implantado Com dados de custo sendo ingeridos no Azure Data Explorer ✅ Azure SRE Agent configurado Com acesso à subscription onde o FinOps Hub está ✅ Canal no Microsoft Teams Onde as notificações serão postadas ✅ Permissões adequadas Managed Identity com Viewer no database Hub do ADX Passo a Passo ① Identificar o Cluster ADX do FinOps Hub O primeiro passo é localizar o cluster Azure Data Explorer onde o FinOps Hub armazena os dados de custo. No Azure SRE Agent, usamos o Azure Resource Graph: az graph query -q "Resources | where type =~ 'Microsoft.Kusto/clusters'" --first 10 --subscription <subscription-id> No meu caso como exemplo, o cluster retornado foi: Propriedade Valor Nome finopshubadx URI https://finopshubadx.northcentralus.kusto.windows.net Database Hub SKU Dev(No SLA)_Standard_D11_v2 Região North Central US ② Configurar Permissões (RBAC no ADX) A managed identity do SRE Agent precisa de acesso Viewer ao database Hub do ADX. Sem isso, a query KQL falhará com erro 403. Opção A — Azure CLI: az kusto database-principal-assignment create \ --cluster-name finopshubadx \ --database-name Hub \ --resource-group <resource-group> \ --subscription <subscription-id> \ --principal-assignment-name "sre-agent-viewer" \ --principal-id "<managed-identity-client-id>" \ --principal-type App --role Viewer Opção B — Portal: ADX → Cluster → Database Hub → Permissions → Add → Viewer → Selecionar managed identity Opção C — KQL (ADX Web UI): .add database Hub viewers ('aadapp=<client-id>') 'SRE Agent' ③ A Query KQL de Detecção de Anomalias Esta query utiliza series_decompose_anomalies do Kusto para detectar padrões anômalos nos custos diários ao longo dos últimos 12 meses: let numberOfMonths = 12; let start = startofmonth(ago(numberOfMonths * 30d)); let end = now(); let interval = 1d; Costs() | where ChargePeriodStart between (start .. end) | summarize DailyCost = sum(EffectiveCost) by bin(ChargePeriodStart, interval) | make-series CostSeries = sum(DailyCost) on ChargePeriodStart from start to end step interval | extend anomalies = series_decompose_anomalies(CostSeries) | project ChargePeriodStart, CostSeries, anomalies 💡 Como a query funciona Costs() → Função do FinOps Hub que retorna dados de custo consolidados make-series → Cria série temporal diária contínua (sem gaps) series_decompose_anomalies → Algoritmo ML nativo do Kusto que detecta spikes e drops usando decomposição sazonal + STL Score > 0 → custo acima do esperado | Score < 0 → abaixo do esperado Quanto maior o |score|, mais significativa a anomalia ④ Configurar Webhook no Microsoft Teams Para receber notificações no Teams, criamos um Incoming Webhook via Power Automate Workflows (método recomendado pela Microsoft): No canal do Teams, clique nos 3 pontos (...) → Workflows Pesquise "Post to a channel when a webhook request is received" Selecione o Team e Channel desejados → Add workflow Copie a URL gerada (formato: https://prod-xx...logic.azure.com/...) Ative o workflow no Power Automate (My flows → Turn on) ⚠️ Atenção: O workflow pode ser criado com status 'Suspended'. Ative em: Power Automate → My flows → Turn on. ⑤ Criar a Scheduled Task no SRE Agent Agora a parte principal: criar a tarefa agendada (Scheduled Task) no Azure SRE Agent. Basta pedir em linguagem natural: "Crie uma tarefa diária para analisar anomalias de custo no FinOps Hub e me notificar pelo Teams quando houver anomalias detectadas." O SRE Agent criará a task com os seguintes parâmetros: Parâmetro Valor Nome Daily FinOps Cost Anomaly Analysis Schedule 0 8 * * * (diariamente às 08:00 UTC) ADX Cluster https://finopshubadx.northcentralus.kusto.windows.net Database Hub Query KQL com series_decompose_anomalies (12 meses) Notificação Adaptive Card no Teams via webhook Escalação HIGH se anomalias por 3+ dias consecutivos Idempotência Sem anomalia = 'custos dentro do esperado' Task details: Obs: Modificar os campos na task para adequar seu ambiente Autonomous Scheduled Run - Daily FinOps Cost Anomaly Analysis ## Scope - Subscription: xxxxxxx-xxxxxxx-xxxxxx-xxxx-xxxxx - ADX Cluster: https://finopshub.northcentralus.kusto.windows.net - Database: Hub - Resource Group: finopshub-rg ## Goal Detect cost anomalies in Azure spending using the FinOps Hub data. Run the KQL query against the ADX cluster, analyze results, and notify via Teams if anomalies are found. ## Step 1: Execute KQL Query Use the KustoQuery subagent to run this query against the ADX cluster (https://finopshubadx.northcentralus.kusto.windows.net, database: Hub): ```kql let numberOfMonths = 12; let start = startofmonth(ago(numberOfMonths * 30d)); let end = now(); let interval = 1d; Costs() | where ChargePeriodStart between (start .. end) | summarize DailyCost = sum(EffectiveCost) by bin(ChargePeriodStart, interval) | make-series CostSeries = sum(DailyCost) on ChargePeriodStart from start to end step interval | extend anomalies = series_decompose_anomalies(CostSeries) | project ChargePeriodStart, CostSeries, anomalies ``` ## Step 2: Analyze Results - Parse the anomalies array from series_decompose_anomalies output - Identify days where anomaly score is significantly positive (cost spike) or negative (unusual drop) - For each anomaly found, calculate: the date, actual cost value, expected baseline, and percentage deviation - Focus on the last 7 days of data for actionable anomalies, but use the full 12-month history for context ## Step 3: Generate Report Create a summary with: - Total anomalies detected in the last 7 days - For each anomaly: date, cost value, deviation from expected, severity (high/medium/low) - Trend analysis: whether costs are trending up, down, or stable - Top recommendations (e.g., investigate specific resource groups, check for new deployments, review reserved instances) ## Step 4: Teams Notification (ONLY if anomalies detected in last 7 days) If anomalies are found, send a notification to Microsoft Teams using the executing_code skill (ExecutePythonCode) to POST to this webhook URL: https://839eace659ab424397eca5b8fcc104.e4.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/88ec6b6c43014d8f8cb13999714dddd8/triggers/manual/paths/invoke?api-version=1&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=br2rNi4x1zKjWp6CgKWcajvEUW_7EUBkHrkbnp6Hk2g Use Adaptive Card format for the Teams message with: - Title: "⚠️ Azure Cost Anomaly Detected" - Summary of anomalies (dates, values, deviations) - Severity indicator - Link back to this SRE Agent thread for details Python code example for the webhook POST: ```python import urllib.request import json webhook_url = "<colar-url-webhook-aqui>" card = { "type": "message", "attachments": [{ "contentType": "application/vnd.microsoft.card.adaptive", "content": { "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "type": "AdaptiveCard", "version": "1.4", "body": [ {"type": "TextBlock", "text": "⚠️ Azure Cost Anomaly Detected", "weight": "Bolder", "size": "Large"}, {"type": "TextBlock", "text": "<ANOMALY_SUMMARY_HERE>", "wrap": True}, {"type": "FactSet", "facts": [ {"title": "Date", "value": "<DATE>"}, {"title": "Actual Cost", "value": "<COST>"}, {"title": "Expected", "value": "<EXPECTED>"}, {"title": "Deviation", "value": "<DEVIATION>%"}, {"title": "Severity", "value": "<SEVERITY>"} ]} ], "actions": [{"type": "Action.OpenUrl", "title": "View in SRE Agent", "url": "https://sre.azure.com/agents/subscriptions/<sua-subscricao>/resourceGroups/finopshub-rg/providers/Microsoft.App/agents/finopshub/views/thread/7314d219-77d6-4e12-a3fb-f30606d13077"}] } }] } req = urllib.request.Request(webhook_url, data=json.dumps(card).encode('utf-8'), headers={'Content-Type': 'application/json'}, method='POST') response = urllib.request.urlopen(req) ``` ## Step 5: Report in Thread Always post a summary in this thread with: - Whether anomalies were found or not - Key metrics and trends - If no anomalies: "No material cost anomalies detected. Daily costs within expected range." ## Constraints - Read-only operations only against ADX - Max 5 KQL queries per execution - Do not modify any Azure resources ## Idempotence If no anomalies detected in the last 7 days and costs are within normal thresholds, output: "No material cost anomalies detected. Daily costs within expected range." ## Escalation If anomalies are detected for 3+ consecutive days, flag as HIGH severity in the Teams notification and recommend immediate investigation. ⑥ Notificação no Teams (Adaptive Card) Quando anomalias são detectadas, o SRE Agent envia um Adaptive Card rico para o Teams: ⚠️ AZURE COST ANOMALY DETECTED 🔴 HIGH — 2026-04-21 Custo Real $1,847.32 Custo Esperado $623.15 Desvio +196.5% (↑ $1,224.17) Score Anomalia 4.7 (threshold: 1.5) 🟡 MEDIUM — 2026-04-20 Custo Real $987.44 Desvio +59.5% (↑ $368.54) 📊 Trend (7d) $601 → $615 → $622 → $619 → $987 → $1,847 Exemplo de Adaptive Card enviado ao canal do Teams O card inclui botões: Ver Detalhes no SRE Agent e Abrir FinOps Hub (ADX) para investigação. ⑦ Testar a Integração (Simular Anomalia) Antes de confiar no agendamento, teste pedindo ao SRE Agent: "Simular uma anomalia de custo para eu receber no Teams" O agente enviará um Adaptive Card de teste com dados simulados para validar que o webhook está funcionando. Dica: Se o webhook retornar erro 400 - WorkflowTriggerIsNotEnabled, ative o flow em: Power Automate → My flows → Turn on. Como Funciona no Dia a Dia Horário Ação Resultado 08:00 UTC SRE Agent executa query KQL no ADX Dados de custo (12 meses) 08:01 UTC Análise de anomalias (últimos 7 dias) Identifica spikes e drops 08:02 UTC Se anomalia → Teams notification Adaptive Card no canal 08:02 UTC Se normal → log no thread "Custos dentro do esperado" Contínuo 3+ dias anomalia → escalação HIGH Investigação recomendada Gerenciamento da Task Após criada, a tarefa pode ser gerenciada pelo SRE Agent: Pausar: "Pausar a tarefa de anomalia de custo" Retomar: "Retomar a tarefa" Alterar horário: "Mudar para executar às 10h UTC" Ver histórico: "Mostrar histórico de execuções" Cancelar: "Cancelar a tarefa de anomalia" Conclusão Com essa configuração, você tem um sistema inteligente de vigilância de custos que: 🔍 Analisa 12 meses de histórico para detectar padrões sazonais 🤖 Usa ML nativo do Kusto — sem infraestrutura adicional 📱 Notifica proativamente no Teams — só quando há anomalia 📈 Escala automaticamente a severidade em anomalias persistentes 💬 Mantém histórico completo no thread do SRE Agent 🔧 É gerenciável por linguagem natural — sem YAML, sem pipelines A combinação FinOps Hub + Azure SRE Agent + Teams transforma a governança de custos de reativa (olhar dashboards) em proativa e automatizada. 🚀 Quer implementar na sua organização? Se você quer testar, o Azure SRE Agent está disponível como preview. Configure um agente na sua subscription e comece a conversar em linguagem natural. Já usa FinOps Hub? Conte nos comentários como você monitora anomalias de custo hoje! #FinOps #Azure #SREAgent #CostManagement #AzureDataExplorer #CloudGovernance #DevOps #MicrosoftTeams #AIOpsFinOps Hub Privado: Implementação Manual em Ambientes Corporativos
O que é o FinOps Hub? O FinOps Hub é uma solução open source da Microsoft, parte do FinOps Toolkit, que fornece uma base escalável e extensível para análise, governança e otimização de custos em nuvem. A solução centraliza dados de custos por meio de recursos de armazenamento e pipelines de dados, permitindo que as organizações padronizem a forma como analisam seus gastos na nuvem, adotando o modelo de dados FOCUS definido pela FinOps Foundation. Além de disponibilizar relatórios e dashboards prontos, o FinOps Hub expõe os dados de custos de forma estruturada por meio do Azure Data Explorer ou do Microsoft Fabric, possibilitando a criação de relatórios customizados no Power BI e o desenvolvimento de soluções internas sob medida, de acordo com as necessidades do negócio. Objetivo Esse artigo visa orientar a implementação manual do acesso privado ao FinOps Hub após uma implementação pública, sem usar diretamente a opção de implementação privada oferecida pelo template. Por que implementar o FinOps Hub com acesso privado de forma manual? O template disponibilizado para a implementação do FinOps Hub permite que selecionemos duas formas de implementação: Pública: forma de implementação mais simples e comum. Os recursos são provisionados com acesso público habilitado, sendo acessados por meio de seus endpoints públicos padrões do Azure. O controle de acesso é feito exclusivamente via permissões RBAC. Privada: forma de implementação mais segura. Os recursos são provisionados com acesso público desabilitado e expostos apenas por meio de private endpoints, ficando acessíveis somente através de redes privadas que possuem conectividade com a rede onde esses endpoints estão implementados. Embora a comunicação privada traga ganhos significativos de segurança, sua habilitação através do template do FinOps Hub introduz algumas implicações importantes no processo de implantação. O template, de forma automática, tenta: Criar uma rede virtual (/26); Provisionar Private DNS Zones; Criar os registros DNS associados aos private endpoints; Configurar os links entre as VNets e as zonas DNS. Em muitas organizações, esse tipo de configuração é restrito por políticas internas. A criação de redes, zonas DNS e seus respectivos vínculos costuma ser responsabilidade de times especializados, que garantem a padronização e a aderência às diretrizes arquiteturais definidas pela empresa. Em cenários onde a organização adota, por exemplo, uma topologia Hub & Spoke, com landing zones bem definidas para workloads e conectividade, é fundamental considerar alguns pontos adicionais: Garantir que a rede criada para os private endpoints não tenha sobreposição (overlap) com outras redes existentes; Assegurar que exista peering com a VNet de hub; Integrar os registros DNS dos novos private endpoints às Private DNS Zones centralizadas; Configurar corretamente os VNet links; Garantir que a resolução de nomes esteja funcional no ambiente on-premises, permitindo o acesso ao FinOps Hub por meio de VPN, ExpressRoute ou outras formas de conectividade híbrida. Esses fatores explicam por que, em muitos casos, o uso do template com configuração privada se torna inviável quando utilizado de forma isolada. Isso ocorre porque, frequentemente, o time de FinOps não é o mesmo time responsável por redes e DNS, possuindo permissão para implantar apenas parte dos recursos necessários. Nesses cenários, a implementação privada exige a orquestração entre diferentes times, cada um atuando dentro de suas responsabilidades. Como resultado, algumas etapas que o template tenta executar automaticamente precisam ser realizadas manualmente, conforme descrito nas próximas seções. Passo a Passo para Implementação Faça a implementação do template seguindo o tutorial documentado, com “Networking” em modo público. Assim que o template é implementado, alguns scripts de configuração são executados. Aguarde até que esses scripts sejam executados, ou seja, desapareçam do grupo de recursos onde o FinOps Hub foi implementado para seguir com os próximos passos. Exemplos dos “Deployment Scripts” que desaparecerão: Crie uma rede de tamanho mínimo /26 – valide com o time de infraestrutura o espaçamento que pode ser utilizado. Dentro dessa rede implemente uma subrede: private-endpoint-subnet (/28) – subrede para os private endpoints. Garanta a existência das Private DNS Zones: se seu ambiente possui zonas de DNS privadas centralizadas pré-configuradas. Garanta que as seguintes zonas já existam na subscription padrão para os seus recursos de rede: privatelink.blob.core.windows.net– para o Data Explorer e storage privatelink.dfs.core.windows.net– para o Data Explorer and o data lake hospedando os dados de FinOps data e configuração das pipelines privatelink.table.core.windows.net– para Data Explorer privatelink.queue.core.windows.net– para o Data Explorer privatelink.{location}.kusto.windows.net– para Data Explorer Configurando a Storage Account com Acesso Privado O primeiro recurso que a ser configurado será a Storage Account. A configuração a seguir deve ser realizada duas vezes uma para o target sub-resource “blob” e outra para o target sub-resource “dfs”. Acesse “Networking” e a aba “Private Endpoints” Na aba “Basics” defina: Subscription: mesma que o FinOps Hub foi implementado Resource Group: mesmo que o FinOps Hub foi implementado Name: use um nome que remeta ao recurso criado (private endpoint) e o sub recurso que ele fará exposição (blob/dfs). Exemplo: pe-storageaccount-blob/ pe-storageaccount-dfs Na aba “Resource” defina o target sub-resource para o qual a configuração está sendo feita. No caso, primeiro foi feito para “blob” e depois “dfs”. Na aba “Virtual Network”, deve-se selecionar a rede criada para os private endpoints bem como a subrede (private-endpoint-subnet). Na aba “DNS” selecione a private DNS zone na qual são realizados os registros do seus private endpoints. Quando estiver configurando o private endpoint para blob será privatelink.blob.core.windows.net e para dfs privatelink.dfs.core.windows.net. Adicione Tags caso seja necessário. Clique em “Review + create”. Ao final, dois private endpoints devem estar criados para a storage account: Agora será necessário configurar o private endpoint usado pelo Data Factory para acessar a Storage Account. Acesse o Data Factory e clique em "Launch Studio". No menu lateral, selecione a opção "Manage" -> "Linked services": Selecione o serviço correspondente ao Azure Data Lake Storage Gen2. Em “Connect via integration runtime” substitua “AutoResolveIntegrationRuntime” por New+: Em “Integration runtime setup” selecione “Azure” -> Botão “Continue”: Na aba “Settings”, apenas altere o campo “Name”. Use algo como “ManagedIntegrationRuntime”. Os demais campos, mantenha como estão: Na aba “Virtual Network”, configure conforme a imagem abaixo: Por fim, na aba “Data flow runtime”, use as configurações abaixo: Clique em “Create”. Agora, voltando a página “Edit linked Service”, adicione o “Managed Private Endpoint”. Ele ficará em estado “Pending”. Clique em “Save”. Além disso, use a managed identity fornecida na página “Edit linked Service”, e lhe dê os seguintes acessos na storage account: Reader Storage Account Contributor Storage Blob Data Contributor Por fim, acesse a seção “Networking” da Storage Account novamente, selecione o private endpoint criado pelo Data Factory e clique no botão “Approve”. Configurando o Linked Service ftkRepo no Data Factory Voltando na seção “Manage” do Azure Data Factory, será necessário editar o serviço “ftkRepo”. Nele, o único campo a ser alterado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account. Clique em “Save”. Configurando o Azure Data Explorer com Acesso Privado Acesse a seção “Networking” cluster do Data Explorer criado pelo script do FinOps Hub e acesse a aba “Private Endpoint Connections” Clique em “+ Private Endpoint”. Em “Basics” inclua um nome para o private endpoint e garanta que a região selecionada é a de implementação do seu FinOps Hub e da vnet criada para ele. Na aba “Virtual Network” selecione a rede e subrede criadas para os private endpoints. Na aba “DNS”, associar cada configuração a sua private DNS zone correspondente. Se essas zonas já existirem no ambiente e forem utilizadas de forma centralizada, usar as existentes. Caso contrário, a configuração poderá criar private DNS zones novas: Novamente será preciso configurar o private endpoint gerenciado pelo Data Factory. Para isso, acesse “Managed” -> “Linked Services” e selecione o serviço referente ao Azure Data Explorer. Nessa seção, o único campo a ser editado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account. Agora ainda em “Manage” no Data Factory, selecione a opção “Managed Private Endpoints”. Clique em “+New” -> “Azure Data Explorer (Kusto)” Forneça um nome para o private endpoint, marque a subscription na qual o Data Explorer foi implementado e em "Cluster" selecione o recurso implementado via template do FinOps Hub: Ao final, deve-se ter dois private endpoints configurados no Azure Data Explorer: Ajustes Finais e Validações de Conectividade Tanto para a Storage Account quanto para o Data Explorer, acesse as configurações de rede e altere o Public network access para “Disabled”. Por fim, no seu servidor local de DNS, crie o registro para o Data Explorer apontando para o forwarder correto no Azure seja ele uma máquina virtual ou o inbound endpoint do Azure Private Resolver. Não use o domínio com privatelink, mas sim o padrão, no caso do Data Explorer a forma geral é <localização>.kusto.windows.net conforme o exemplo abaixo: Ao configurar os apontamentos corretamente, será possível configurar os dashboards em máquinas locais/on-premises que tenham acesso privado ao ambiente Azure. Os dashboards precisam ser capazes de resolver a URL do cluster Data Explorer que é apontado como parâmetro do Dashboard em PowerBI. Se desejar validar a comunicação antes de configurar o dashboard de Power BI, teste da sua máquina local a resolução da URI do Data Explorer implementado para o FinOps Hub, usando nslookup conforme o exemplo abaixo.
Office hours: FinOps and the Microsoft marketplace
Want to unlock a faster time-to-value for your cloud and AI projects? Join us live, July 30, with your questions! Learn how the Microsoft marketplace can support your FinOps practitioners by sourcing thousands of pre-vetted solutions that accelerate AI transformation while better managing technology spend.
Mine your Azure backup data, it could save you 💰💡
Your data has a story to tell. Mine it, decipher it, and turn it into actionable outcomes. 📊🔍 Azure backups can become orphaned in several ways (I'll dive into that in a future post). But here’s a key point: orphaned doesn’t always mean useless, hence the word “Potential” in the title of my Power BI report. Each workload needs to be assessed individually. If a backup is no longer needed, you might be paying for it - unnecessarily and unknowingly. 🕵️♂️💸 To uncover these hidden costs, I combined data from the Azure Business Continuity Center with a PowerShell script I wrote to extract LastBackupTime and other metadata. This forms the foundation of my report, helping visualize and track backup usage over time. This approach helped me identify forgotten one-time backups, VMs deleted without stopping the backup, workloads excluded due to policy changes, and backups left behind after resource migrations. If you delete unneeded backups and have soft-delete enabled, the backup size drops to zero and Azure stops charging for it. ✅🧹 💡 Do your Azure backups have their own untold story to tell? 📸 Here's a snapshot of my report that helped me uncover these insights 👇Anyone managing Azure budgets? Would love to hear how you're doing it
Hi everyone - I’m a founder working on a tool to help engineering and infra teams plan and monitor Azure cloud costs more effectively (especially when it comes to budgeting and forecasting). I’m not selling anything - just trying to understand how teams currently handle: Planning Azure spend across teams or projects Staying within budget or tracking drift over time Forecasting costs based on changing usage If you're involved in this (or have strong opinions about what Azure does well/poorly here), I’d love to hear your thoughts. Even a few sentences would be super helpful. You can DM me here or just drop a quick comment. Happy to share what I’ve learned from others too. Thanks!PowerShell script to delete all Containers from a Storage Account
After move the BootDiag settings out of the Custom Storage Account, the original Storage Account used for are still consuming space for nothing. This is part of the standard Clean Up stream need to be consider into the FinOps Plan. This script will help you to clean these Storage Accounts quickly and avoid cost paid for nothing. Connect-AzAccount #Your Subscription $MySubscriptionToClean = "MyGuid-MyGuid-MyGuid-MyGuid-MyGuid" $MyStorageAccountName = "MyStorageAccountForbootdiags" $MyStorageAccountKey = "MySAKeyWithAllCodeProvidedByYourStorageAccountSetting+MZ3cUvdQ==" $ContainerStartName = "bootdiag*" #Set subscription ID Set-AzContext -Subscription $MySubscriptionToClean Get-AzContext $ctx = New-AzStorageContext -StorageAccountName $MyStorageAccountName -StorageAccountKey $MyStorageAccountKey $myContainers = Get-AzStorageContainer -Name $ContainerStartName -Context $ctx -MaxCount 1000 foreach($mycontainer in $myContainers) { Remove-AzStorageContainer -Name $mycontainer.Name -Force -Context $ctx } I used this script to remove millions of BootDiag Containers from several Storage Accounts. You can also use it for any other cleanup use case if you need it. Fab
