FinOps 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.Passo a Passo para Criar um Filtro de Tag no FinOps Hub
Recentemente, publiquei um blog sobre implementação e gerenciamento de custos do Azure usando FinOps Hub no formato FOCUS. Confira aqui. Agora, vou explicar como criar um filtro de Tag no FinOps Hub para otimizar a gestão de custos. 1. Acesse o Dashboard CostSummary do FinOps Hub Primeiro, abra o seu dashboard CostSummary do FinOps Hub. Esta versão que estamos trabalhando seria a V0.4. Em seguida, clique na aba de Resources. Você vai notar na tabela que existe uma coluna de Tag, porém ela não está formatada e não possui um filtro. O objetivo é corrigir a coluna e adicionar um filtro de tag para centro de custo. As Tags são referentes ao meu ambiente. De acordo com a figura abaixo, selecione a opção para transformar dados e adicionaremos o filtro de tag. 2. Navegue até a Seção de Filtragem No painel principal, localize e clique em CostDetails. Em seguida, encontre a coluna x_TagsDictionary, clique no item ao lado do nome e selecione a Tag centro_de_custo. No meu exemplo, também adicionei a Tag Environment. Antes de clicar em OK, desmarque a opção "Use original column name as prefix." E em seguida clique em OK 3. Selecione "Criar Novo Filtro" Ao clicar em OK, serão adicionadas mais duas colunas, centro_de_custo e Environment, conforme ilustrado no exemplo abaixo. Em seguida clique em Close & Apply 4. Criação do Fitro de Tag Na View de Resources, copie e cole o filtro de subscription com Ctrl+C e Ctrl+V e arraste-o para perto da view de Total Savings. 5. Alterar o Filtro Subscription para Filtro de Tag Selecione o filtro Subscription e, em Data, localize a tag centro_de_custo. Arraste o item centro_de_custo para field e depois exclua o Field Subscription. 6. Nova View para o Filtro Centro de Custo A visualização será parecida com o exemplo a seguir 7. Alterar a Tabela para fitrar por Tag Centro De Custo Precisamos agora modificar a tabela para aplicar o filtro ao centro de custo. Selecione a tabela e encontre no campo Data a tag centro_de_custo. Arraste o item centro_de_custo nas Colunas, como mostrado abaixo, e remova Tags da coluna. Com essas etapas concluídas, você deve ter uma nova visualização que reflete o filtro aplicado ao centro de custo. Essa configuração permitirá uma análise mais detalhada e específica, facilitando a identificação de gastos associados a cada centro de custo. Finalmente, salve as alterações feitas e atualize o dashboard para garantir que todas as modificações foram aplicadas corretamente. Agora, ao utilizar o filtro de centro de custo, você poderá visualizar apenas os dados relevantes conforme sua necessidade, tornando a análise financeira mais eficiente e direcionada.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.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 #AIOps
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.
