Krocení cloudů: Jak ve velkém zkrotit zásady fakturace Pay-As-You-Go v Power Platform

Bolest (v rozpočtu) odezní, až Vás to doučí… vydržte, možná je to poslední lekce….

Tak jo. Nasadili jste Pay-As-You-Go (PAYG) pro Power Platform a Copilot Studio. Gratulujeme — teď máte tu příjemnou volnost spotřebního účtování, kdy si každý maker ve Vaší organizaci může rozjet AI flow a agenty bez toho, aby se nejdřív schvalovala objednávka licence přes tři komise a notáře.

A pak dorazila faktura.

Ne nutně katastrofální. Ale dost velká na to, abyste se narovnali v židli, přimhouřili oči na dashboard v Azure Cost Management a procedili něco nepublikovatelného….

Tenhle článek je pro Vás.

Projdeme spolu dvě hodně praktické věci:

1. Hromadné přiřazení environments k billing policies podle názvu — protože proklikávat se Power Platform Admin Center u 47 environments není dlouhodobě udržitelná strategie.
2. Automatické odpojení environments od billing policies ve chvíli, kdy překročíte rozpočtový limit — protože automatické guardrails jsou spolehlivější než doufat, že si někdo všimne alert e-mailu ještě před víkendem.

Jdeme na to.

Rychlé připomenutí: Co jsou Billing Policies?

Billing policy si představte jako „finanční pas“ pro Vaše Power Platform environments. Propojí environment s Azure subscription — a právě přes ni se účtuje PAYG spotřeba, jako jsou Copilot Studio message packs, AI Builder credits a podobně. Když billing policy připojená není, environment buď spadne na seeded capacity, nebo se k premium funkcím vůbec nedostane.

Ruční správa je v pohodě, když máte tři environments. Když jich máte třicet? Nebo tři sta? To je přesně ten moment, kdy začnete psát PowerShell v 23:00 a přehodnocovat životní volby.

Část 1: Hromadné přiřazení Billing Policies (a nezbláznit se z toho)

Problém

Billing policies propojují Vaše environments s Azure subscription pro PAYG spotřebu. Admin Center UI je naprosto v pohodě, když řešíte tři environments. Jakmile ale jako enterprise admin koukáte na CSV s 50+ environments, které je potřeba přiřadit — a klidně i k různým billing policies — ruční postup přestává být správa a začíná to připomínat trest.

Co budete potřebovat

• Azure CLI nainstalované a přihlášené (az login)
• Uživatelský účet s rolí Power Platform Admin, Global Admin nebo Dynamics 365 Admin
• Seznam environments v CSV souboru
• Tento šikovný skript: bulk-assign-billing-policy.ps1

Formát CSV

Skript očekává jednoduché CSV se čtyřmi sloupci:

1
2
3
4
5
6

EnvironmentName,EnvironmentID,BillingPolicyName,Status
Sales-Production,,ProductionBillingPolicy,
Marketing-Sandbox,a1b2c3d4-...,DevBillingPolicy,
HR-Production,,ProductionBillingPolicy,
Finance-Sandbox,,Finance-BillingPolicy,
Legal-Production,b2c3d4e5-...,Sales-BillingPolicy,

Pár věcí, které je dobré vědět:

• EnvironmentID je volitelné. Když ho necháte prázdné, skript si ho dohledá automaticky podle zobrazovaného názvu (display name) dotazem do Vašeho tenantu. Hodí se to hlavně ve chvíli, kdy pracujete se seznamem názvů prostředí, a ne s GUIDy.
• BillingPolicyName se musí shodovat přesně s tím, co máte v tenantu. Skript si všechny názvy policy ověří hned na začátku a pokud některý neexistuje, skončí chybou ještě dřív, než cokoliv změní.
• Sloupec Status je na začátku prázdný; skript ho po každém běhu doplní na Succeeded nebo Failed: <reason>.

Spuštění skriptu

Nejdřív si dejte náhled (váš krevní tlak Vám poděkuje):

1

.\bulk-assign-billing-policy.ps1 -InputFile ".\environments.csv" -DryRun

Přepínač -DryRun Vám ukáže, co přesně by se provedlo, aniž by proběhlo jediné volání API:

1
2

Řádek 1 [Sales-Production]: Propojilo by se abc123... -> ProductionBillingPolicy (def456...)
Řádek 2 [Marketing-Sandbox]: Propojilo by se xyz789... -> DevBillingPolicy (ghi012...)

Pak to spusťte „naostro“:

1

.\bulk-assign-billing-policy.ps1 -InputFile ".\environments.csv"

Co skript ve skutečnosti dělá

Skript běží v šesti krocích. V konzoli jsou přehledně očíslované a barevně odlišené, abyste nemuseli hádat, kde se to pokazilo:

Step 1 — Verify Azure CLI login. Vypíše, pod jakým účtem jste přihlášení, abyste ho omylem nespustili pod špatným účtem. To se stává.

Step 2 — Load and validate the CSV. Ověří, že CSV obsahuje všechny čtyři povinné sloupce. Chybí sloupec? Skript se hned zastaví s jasnou chybou. Žádné tiché „něco se nepovedlo“.

Step 3 — Resolve billing policies. Stáhne kompletní seznam z https://api.powerplatform.com/licensing/billingPolicies jen jednou a vytvoří mapování název → ID. V CSV pak odkazujete na policies podle čitelných názvů — žádné kopírování GUIDů jako v roce 2008. Zároveň Vás upozorní, pokud některá z použitých policies není ve stavu Enabled:

1
2

Found: ProductionBillingPolicy -> b1234567-... (Enabled)
Found: DevBillingPolicy        -> c2345678-... (Enabled)

Step 4 — Resolve environment IDs. U řádků bez EnvironmentID si skript načte všechny environments ve Vašem tenantovi (včetně správného stránkování pro velké tenancy) a spáruje je podle display name. U řádků, kde už ID vyplněné je, ověří jednotlivě maximálně 20; nad tento limit už Vám věří a případné chyby se projeví až při samotném linkování. Rate limity nejsou teorie.

Step 5 — Link environments to billing policies. Pro každý validní řádek pošle POST na Power Platform API a přiřadí environment k příslušné billing policy. Ke každému řádku se hned zapíše stav Succeeded nebo Failed: <reason>.

Step 6 — Write results back to the CSV. CSV soubor teď obsahuje vyplněný sloupec Status — doplněná ID a výsledek pro každý řádek. Máte auditní stopu. Vaše budoucí já to ocení.

Závěrečné shrnutí Vám přesně řekne, jak to dopadlo:

1
2
3
4
5
6
7

════════════════════════════════════════════════════
  SUMMARY
════════════════════════════════════════════════════
  Total rows:   5
  Succeeded:    4
  Failed:       1
  Skipped:      0

K PAYG billing policies lze připojit pouze environments typu Production a Sandbox. Developer, Trial a Default environments nejsou podporované. Jde o omezení platformy, ne o limit skriptu. Pokud skript narazí na nepodporovaný typ environmentu, označí řádek jako Failed: EnvironmentType <type> not supported a pokračuje dál, aniž by zastavil celý běh. Tomu přizpůsobte i Vaše CSV.

Část 2: Automatické odpojení prostředí ve chvíli, kdy narazíte na rozpočet

Problém (tentokrát s ještě větší dávkou existenční úzkosti)

Přiřadit prostředí k billing policies je ta jednodušší část. Složitější otázka zní: co se stane, když útrata překročí Váš rozpočet? Chcete, aby Copilot Studio konverzace běžely dál i poté, co jste přestřelili měsíční limit?

Upřímná odpověď bez automatizace je: někomu přijde e-mail. A ten e-mail se klidně může (ale také nemusí) přečíst až v pondělí.

Osvědčený přístup je zapojit automatické odpojení — jakmile dojde k překročení rozpočtového prahu, systém prostředí z billing policy automaticky odebere a zastaví další PAYG spotřebu. Bez čekání na lidskou reakci.

Microsoft připravil hotový ukázkový příklad, který přesně tohle řeší: Azure Budgets funguje jako spouštěč, Azure Automation Account jako „most“ a Power Automate udělá samotnou práci v Power Platform. Zbytek této části vysvětluje, jak ukázka funguje a jak ji nastavit.

Architektura

Tady je přehled hlavních „postav“:

Každá komponenta dělá přesně jednu věc. Celý řetězec je event-driven — žádné polling, žádné plánované úlohy, žádné „snad to vyjde“.

Krok 1: Azure Budget Alert

V Azure Cost Management vytvořte Budget s rozsahem (scope) na subscription a resource group, které odpovídají Vaší billing policy. Nastavte práh – například 80 % měsíčního rozpočtu – a nakonfigurujte Action Group, která se na tomto prahu spustí. Action Group je to, co z „byl překročen práh“ udělá „něco se opravdu stane“. Přidejte do ní webhook action a nasměrujte ji na webhook URL Vašeho Azure Automation runbooku.

Když se Budget spustí, Azure odešle webhook payload ve formátu Azure Monitor Common Alert Schema:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

{
  "schemaId": "azureMonitorCommonAlertSchema",
  "data": {
    "essentials": {
      "monitoringService": "CostAlerts",
      "alertId": "/subscriptions/8be5abeb-.../resourceGroups/MyResourceGroup/...",
      "firedDateTime": "2026-04-24T15:44:27Z",
      "description": "Your spend for budget prodbilling is now $4.00 exceeding your specified threshold $1.60."
    },
    "alertContext": {
      "AlertData": {
        "BudgetName": "prodbilling",
        "BudgetThreshold": "$2.00",
        "NotificationThresholdAmount": "$1.60",
        "SpentAmount": "$4.00"
      }
    }
  }
}

Pole alertId má v cestě zakódované subscription ID a resource group – a právě toho runbook využije, když si z řetězce „vyřízne“ potřebné části.

Krok 2: Azure Automation Runbook

Váš Azure Automation Account hostuje PowerShell runbook. Dělá čtyři věci:

1. Zpracuje payload z webhooku

1
2
3

$alertId           = $WebhookData.data.essentials.alertId
$subscriptionId    = ($alertId -split '/')[2]
$resourceGroupName = ($alertId -split '/')[4]

Z alert ID si vytáhne subscription ID a resource group přímo z cesty — jen split a indexování v poli, bez potřeby regexů.

2. Ověří se přes Managed Identity

1

Connect-AzAccount -Identity

Tady je to nejčistší. Automation Account má System-Assigned Managed Identity s právy Power Platform Admin. Žádná hesla. Žádné tajné klíče service principalu v konfiguračním souboru. A žádné nepříjemné debaty se security týmem. Identitu spravuje Azure, automaticky ji rotuje a rozsah oprávnění je nastavený přesně na to, co je potřeba.

3. Získá Entra token pro Power Automate

1
2
3

$aud = "https://service.flow.microsoft.com/"
$EntraToken = Get-AzAccessToken -ResourceUrl $aud
$Token = $EntraToken.Token | ConvertTo-SecureString -AsPlainText

4. Zavolá Power Automate HTTP flow

1
2
3
4
5
6
7

$payload = [pscustomobject]@{
    resourceGroupName = $resourceGroupName
    subscriptionid    = $subscriptionId
} | ConvertTo-Json -Compress

Invoke-RestMethod -Method Post -Authentication Bearer -Token $Token `
    -Uri $FlowHttpUrl -Body $payload -ContentType 'application/json'

Skript pošle (POST) informace o resource group a kontext subscription do Power Automate flow, který běží za HTTP triggerem. Další kroky už si flow vyřeší samo.

Krok 3: Řešení v Power Automate

Tady to začíná být opravdu zajímavé. Část v Power Automate je připravená jako importovatelná solution — BillingPolicyManagement.zip — kterou jednoduše nahrajete do svého environmentu. Obsahuje:

• custom connector pro Power Platform Licensing API (kvůli výpisu billing policies podle názvu — v Admin V2 connectoru tohle nativně není)
• HTTP endpoint flow, který slouží jako vstupní bod z runbooku
• child flow, který provádí samotné odpojování

The HTTP Endpoint Flow

Tento flow převezme z runbooku název resource group a subscription ID a hned je předá do child flow. Oddělený child flow dává smysl: můžete ho spustit i ručně, což se hodí pro testování nebo ve chvíli, kdy chcete billing policy odpojit bez celé cesty přes Azure alerting.

The UnlinkAllEnvironmentsFromBillingPolicy Flow

Tady se odvádí hlavní práce. Konkrétně flow udělá následující:

1. Načte všechny billing policies přes custom connector (GET /licensing/billingPolicies)
2. Najde policy, která odpovídá zadanému názvu — podle „friendly name“, ne podle GUID
3. Získá všechny environmenty napojené na danou policy přes Power Platform Admin V2 connector
4. Pro každý environment zavolá RemoveBillingPolicyEnvironment a odpojí ho
5. Sestaví audit log, kde zaznamená všechny provedené kroky
6. Vrátí HTTP 200 a do response body pošle kompletní audit log

Výsledek vypadá například takto:

1
2
3
4

Found Policy with name: prodbilling (Guid: abc-123...).
Retrieving list of linked environments.
Unlinked Environment: env-abc-123 from prodbilling (GUID: abc-123...)
Unlinked Environment: env-def-456 from prodbilling (GUID: abc-123...)

Od překročení budget threshold až po odpojení všech environmentů — plně automatizovaně a s kompletní auditní stopou v historii běhu flow.

Celý end-to-end přehled

flowchart LR
    A["🔔 Budget Alert"] --> B["Action Group"]
    B --> C["Automation Runbook<br/><i>zpracuje alert, získá token</i>"]
    C --> D["Power Automate<br/><i>dohledá policy, odpojí envs</i>"]
    D --> E["✅ Environments odpojené"]

Celý řetězec od alertu až po odpojení trvá méně než minutu.

Testování bez čekání na reálné překročení rozpočtu

Na otestování nemusíte skutečně „přestřelit“ rozpočet. Repo obsahuje soubor Webhooktestdata.json — realistický payload ve formátu Azure Monitor Common Alert Schema, předvyplněný simulovaným scénářem překročení (budget: $2.00, threshold: $1.60, spent: $4.00) — a také script pro vyvolání alertu.

Runbook proti tomu můžete spustit ručně:

1
2
3
4
5

az automation runbook start `
    --name UnlinkBillingPolicies `
    --resource-group Azurevnetforpowerplatform `
    --automation-account-name RRANJITBillingPolicy `
    --parameters webhookData='@./Webhooktestdata.json'

Tím ověříte celý řetězec end-to-end — runbook zpracuje payload, zavolá Power Automate a flow odpojí environments — bez nutnosti reálně překročit rozpočet. Vaše finanční oddělení to ocení.

Výhody a nevýhody tohoto přístupu

Buďme upřímní v tom, do čeho tímto řešením jdete.

Výhody

• Žádné uložené přihlašovací údaje. Managed Identity znamená nulové „secrety“, které byste museli spravovat, rotovat nebo omylem commitnout do gitu.
• Event-driven. Nic se neptá dokola. Jakmile se spustí budget alert, navazující řetězec se provede a je hotovo.
• Jasné rozdělení zodpovědností. Azure hlídá rozpočet; Power Platform řeší správu environmentů.
• Podle názvů, ne podle GUID. Jak skript pro přiřazení, tak flow pro odpojení pracují s čitelnými názvy policy.
• Auditovatelné na každé vrstvě. CSV je Váš doklad o propojení; historie běhů v Power Automate je Váš doklad o odpojení.
• Testovatelné bez reálného rizika. -DryRun pro hromadné přiřazení, Webhooktestdata.json pro otestování řetězce alertů.
• Ověřená infrastruktura. Azure Budgets, Automation Accounts a Action Groups jsou vyzrálé služby se SLA a vestavěným monitoringem.

Nevýhody

• Je potřeba znalost Azure. Automation Accounts, Managed Identities, Action Groups — není to složité, ale potřebujete někoho, kdo se v Azure portálu pohybuje jistě.
• Více služeb na správu. Automation Account, runbook, Action Group, Budget alert a Power Automate solution — každá část má svůj vlastní lifecycle.
• Dvě hranice oprávnění. Managed Identity řeší autentizaci na straně Azure; přihlašovací údaje v Power Automate connection řeší Power Platform. Na první pohled to nemusí být zřejmé.
• Náklady v Azure. Spouštění jobů v Automation Account při větším měřítku není zdarma. U nízké frekvence alertů je to zanedbatelné, ale pořád je to další položka v rozpočtu.
• PowerShell pro hromadné přiřazení. Část 1 vyžaduje spustit skript lokálně. Ne každý Power Platform admin se cítí komfortně v terminálu.
• Bez self-service. Makers ani vlastníci environmentů si to sami nenastaví. Je to čistě admin konfigurace.

Budget alerty nejsou v reálném čase. Data v Azure Cost Management mají zpoždění 8–24 hodin a vyhodnocování budget alertů probíhá periodicky, ne kontinuálně. Pokud Vám „utržený“ flow rychle pálí Copilot Studio messages nebo AI Builder credits, systém to nemusí zachytit dřív, než dojde k výrazným škodám. Je to známý limit tohoto přístupu, ne chyba — jen je dobré vědět, kde je jeho strop.

Co teď máte k dispozici

Pojďme si to shrnout:

• PowerShell script, který v jednom běhu hromadně přiřadí libovolný počet environments k billing policies. Používá čitelné názvy místo GUIDů, umí dry-run náhled a generuje CSV výstup pro audit.
• Řetězec Azure Budget + Automation Account + Power Automate, který automaticky odpojí environments ve chvíli, kdy se překročí nastavený budget threshold — bez ručního zásahu a bez nepříjemných pondělních překvapení.

Výsledkem je robustní, produkčně použitelný governance setup pro PAYG billing v Power Platform. Řeší dvě největší provozní bolesti: jak environments efektivně napojit na policies a jak je automaticky odpojovat, když se výdaje začnou nebezpečně zvyšovat.

Co bude dál

Téměř všechny nevýhody z předchozího seznamu mají stejnou příčinu: do problému v Power Platform jsme zatáhli Azure infrastrukturu. V příštím článku Microsoft ukáže, jak postavit stejný proces čistě uvnitř Power Platform. Bez Automation Accounts, bez runbooks, bez PowerShellu. Berte to jako malou odvetu citizen developerů za provozní složitost. Pokračování příště.