How 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. Don't see Attend or Add to Calendar? Sign in to the Tech Community to join the conversation. 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. FabPasso 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.
