Kjell Tore Guttormsen
30d4340e94
Sju entries lukket, aatte linjer slettet (26l hadde linja som eget avsnitt og
mistet ogsaa blanklinja). Ingen erstatningstekst: formen sier slett, ikke rett.
idx-26r trengte aldri form-beslutningen den var bokfoert for. «Kall eller
runder?» handler om om TALLET er riktig; under en slette-form er riktighet ikke
i mulighetsrommet, og linja er uverifiserbar under begge lesninger. Sjekket, ikke
paastaatt: idx-26k baerer eksplisitt sperre, idx-26r baerer ingen. STATEs «ikke
mekanisk» bar videre entry-teksten skrevet 14:11 — ti minutter FOER da16608
(14:21) oppløste den. Spoersmaal #15 er moot for slettingen.
Tre av sju BEHOLDTE linjer feilet verifiseringen. Formen sier «behold og
verifiser» og forutsatte at de ville passere. Bokfoert, ikke reparert:
- idx-26t: «10 unike URLer» er sann som kilder (10 entries), usann som URL-er
(11; entry 8 baerer to). Avviket gaar samme vei som alle aatte.
- idx-26u: «File size: ~14 KB» er FALSIFISERBAR, ikke bare uverifiserbar — git
ER artefaktet. 17388 -> 17963 -> 17965 -> 18554 byte, og linja staar ordrett i
den ELDSTE versjonen. Aldri sann paa noe punkt repoet kan observere.
- idx-26v: 80/20 uten nevner. 26j-presedensen «lukk i samme edit» ble TESTET mot
forutsetningen, ikke kopiert: 26j hadde en partisjon (12/5), denne fila har
ingen (8/8 Verified, seksjoner 3/3). Aa re-uttrykke ville krevd aa finne paa
en nevner — defektklassen den skulle lukke.
- idx-26w: 7/7 stemmer som aritmetikk, men 2 av 7 URL-er er ikke Learn, saa «fra
MCP-research» overklager. Proveniens, ikke telling.
TYNGSTE FUNN — korpusmaalingen som grunnla ratifiseringen var en underteljing.
«23 linjer i 23 filer, fire dialekter» er engelsk-spraaklig maalt. Dialekt-bred
sveip: 47 kandidater, 2 haandluket falske positive (kilde-tellinger), 1 ekte
under feil etikett => 45 EKTE LINJER I 45 FILER, minst 16 feltnavn-dialekter.
Norske former (MCP-kall, MCP-kall utfoert, Totalt antall MCP-kall), MCP call
summary, listeform og overskriftsform falt alle utenfor.
Dette ugyldiggjoer INGEN av de ni editene — slettegrunnen er uverifiserbarhet og
gjelder uansett populasjon. Det ugyldiggjoer REKKEVIDDEN: spoersmaal #17 gjaldt
«14 ubokfoerte filer»; reell populasjon er 45. Boettene er bevisst IKKE oppgitt —
et maskinforsoek i oekten reproduserte nøyaktig artefaktet haanden maatte rette
sist (leser «3 (search) + 2 (fetch) = 5 total» som «oppgitt 3»).
Alle 11 ankere (7 eksisterende + 4 nye) unikhetssjekket med grep -cF, ikke med
gatens text.includes. Koe: 11 aapne / 20 resolved. Suite: 1047/1047.
Docs: §9.15.
18 KiB
Azure Cost Management and Budget Monitoring for AI
Last updated: 2026-06-19 Status: GA Category: Cost Optimization & FinOps for AI Type: reference Source: https://learn.microsoft.com/azure/cost-management-billing/costs/tutorial-acm-create-budgets
Innhold
- Introduksjon
- Kjernekomponenter
- Arkitekturmønstre
- Beslutningsveiledning
- Integrasjon med Microsoft-stakken
- Offentlig sektor (Norge)
- Kostnad og lisensiering
- For arkitekten (Cosmo)
- Kilder og verifisering
Introduksjon
Azure Cost Management er Microsofts innebygde plattform for kostnadsovervåking, budsjettering og optimalisering på tvers av alle Azure-ressurser. For AI-workloads er økonomisk styring spesielt kritisk fordi token-baserte modeller, GPU-compute og storage-intensive RAG-løsninger kan generere uforutsigbare kostnader hvis de ikke overvåkes systematisk.
Azure Cost Management tilbyr tre primære mekanismer for kostnadsovervåking: budget alerts (faktiske kostnader mot budsjett), forecast alerts (prediktive varsler basert på trender) og anomaly detection (automatisk identifisering av uventede kostnadsmønstre). Sammen gir disse verktøyene en robust FinOps-tilnærming som balanserer innovasjon med økonomisk ansvar.
Plattformen er gratis for alle Azure-kunder og integreres sømløst med Azure Portal, Power BI, Azure Monitor, Logic Apps og Action Groups for automatiserte responser. For offentlig sektor i Norge er dette et viktig styringsverktøy for å etterleve krav til årsbudsjett, etatsstyring og statsregnskapets periodisering.
Kjernekomponenter
| Komponent | Beskrivelse | Bruksområde AI-workloads |
|---|---|---|
| Budget Alerts | Varsler når faktiske kostnader overstiger forhåndsdefinerte terskelverdier (% av budsjett) | Overvåk Azure OpenAI token-forbruk, Azure AI Search query volume, Cosmos DB RU/s |
| Forecast Alerts | Prediktive varsler basert på kostnadstrender (36-timers forecast-algoritme) | Identifiser økende inference-kostnader før månedsbudsjettet sprekkes |
| Anomaly Detection | Automatisk ML-basert identifisering av avvik fra historiske mønstre (60 dagers baseline) | Fang opp plutselige økninger i token-forbruk eller uventet storage-vekst i RAG-pipelines |
| Cost Analysis Views | Interaktiv kostnadsanalyse med grouping, filtering og custom views | Spor kostnader per AI-tjeneste, miljø (dev/test/prod), eller tag (prosjekt, kostnadssted) |
| Action Groups | Integrasjon med Azure Logic Apps, Webhooks, Azure Functions for automatiserte responser | Automatisk skalering ned av dev-miljøer, notifikasjoner til Teams/Slack, ITSM ticket-opprettelse |
| Exports | Automatisk eksport av kostnadsdata til Storage Account for analyse i Power BI eller Fabric | FinOps-dashboards, executive reporting, historisk trendanalyse |
| Budgets API | REST API for programmatisk budsjettering og alert-konfigurasjon | IaC (Bicep/Terraform), automatisk budsjettgenerering for nye subscriptions/resource groups |
Alert-typer og terskler
| Alert-type | Evalueringsfrekvens | Anbefalt terskelverdi | Notifikasjonstid |
|---|---|---|---|
| Budget Alert (Actual) | 1x per dag (etter at all usage data er tilgjengelig) | 90%, 100%, 110% | Innen 1 time etter evaluering |
| Forecast Alert | 1x per dag | 110% av budsjett | Innen 1 time etter evaluering |
| Anomaly Alert | 1x per dag (36 timer etter dag slutt UTC) | Auto-tuned (confidence interval basert på 60 dagers historikk) | Umiddelbart ved deteksjon |
Viktig: Budget alerts evaluerer faktiske påløpte kostnader, ikke forbruk som ennå ikke er fakturert. Data er normalt tilgjengelig innen 8-24 timer. Anomaly detection bruker normalisert usage (ikke kostnader) for å unngå prissvingninger.
Arkitekturmønstre
Pattern 1: Centralized Governance with Delegated Accountability
Beskrivelse: FinOps-team setter opp budsjetter, alerts og policies sentralt på subscription/management group-nivå, men delegerer kostnadseierskap til produktteam via tags og resource group-filtre.
Implementering:
- Management group-budsjetter for totale kostnadsrammer
- Subscription-budsjetter per produktområde
- Resource group-budsjetter per team/prosjekt
- Tag-baserte filtre (
costCenter,environment,project) for granulær allokering - Action Groups sender varsler til team-spesifikke kanaler (Teams, Slack, e-post)
Bruksområde: Store organisasjoner med mange AI-initiativer, hvor sentralisert kontroll kombineres med team-autonomi.
Eksempel AI-scenario: Microsoft Foundry-prosjekter tagges med project: customer-support-bot. Budget opprettes med filter på denne taggen, og varsler sendes til produkteier for chatbot-teamet.
Pattern 2: Decentralized with FinOps Guardrails
Beskrivelse: Team oppretter og forvalter egne budsjetter, men FinOps-team enforcer policies via Azure Policy og gir verktøy/opplæring for selvbetjening.
Implementering:
- Azure Policy krever at alle subscriptions/resource groups har et aktivt budsjett
- Standardiserte ARM/Bicep-templates for budsjett-konfigurasjon
- Sentralisert dashboard (Power BI/Fabric) aggregerer kostnader på tvers
- FinOps-team tilbyr "budget-as-code" templates i intern developer portal
Bruksområde: DevOps-modne organisasjoner med sterkt eierskap per team, men behov for minimumsgarantier.
Eksempel AI-scenario: Hvert Azure AI Search-miljø får automatisk et budsjett på 50 000 NOK/måned via IaC-pipeline. Overskridelser eskaleres til teamlead.
Pattern 3: FinOps Team with Real-Time Remediation
Beskrivelse: Automatiserte responser på budsjett-/anomali-varsler via Logic Apps eller Azure Functions for å begrense kostnadsvekst før budsjett sprekker.
Implementering:
- Budget alerts trigge Action Groups med Logic App workflows
- Logic Apps evaluerer kontext (environment, time of day, severity)
- Automatiske remediation-steg:
- Dev/test: Shutdown VM-er, scale down til F0/Free tier
- Prod: Send eskalert varsel til on-call team
- Logging til ITSM-system (ServiceNow, Jira)
Bruksområde: AI-dev-miljøer hvor "glemte" ressurser (langvarige fine-tuning jobs, ukontrollerte inference-tester) er en vanlig kostnadsdriverside.
Eksempel AI-scenario: Anomaly detection fanger opp 300% økning i Azure OpenAI token-forbruk i test-miljø kl 02:00. Logic App stopper deployment slot og sender varsel til team i Slack.
Beslutningsveiledning
Når bruke hvilken alert-type?
| Scenario | Alert-type | Begrunnelse |
|---|---|---|
| Månedlig budsjett for Microsoft Foundry-prosjekt | Budget Alert (90%, 100%, 110%) | Proaktiv overvåking mot kjente rammer |
| POC-miljø med ukjent forbruksmønster | Anomaly Alert | Identifiser uventet vekst før budsjett overskrides |
| Produksjon med stabil baseline, men risiko for sesongsvingninger | Forecast Alert (110%) | Early warning før månedslutt |
| Dev/test-miljø med ad-hoc eksperimenter | Anomaly Alert + Budget Alert | Både reaktiv (anomaly) og proaktiv (budget) kontroll |
Vanlige feil og røde flagg
| Feil | Konsekvens | Korrekt tilnærming |
|---|---|---|
| Kun ett budsjett på subscription-nivå | Manglende granularitet, team kan ikke isolere sine kostnader | Opprett budsjetter per resource group eller med tag-filtre |
| For høye terskelverdier (>100%) | Budsjett overskrides før varsel sendes | Bruk 90% (proaktiv), 100% (target), 110% (kritisk) |
| Ignorere forecast alerts | Budsjettoverskridelser oppdages for sent til korrektiv handling | Automatiser respons (scale down, notifications) |
| Ikke filtrere ut purchase charges i budsjetter | Reservations/Savings Plans fordreier faktisk forbruk | Legg til filter: ChargeType != Purchase |
| Manglende Action Groups | Varsler blir ikke handlet på, eksisterer kun som e-post | Integrer med Teams, Logic Apps, Azure Functions |
| Ikke tune anomaly detection | For mange falske positiver (støy) | Evaluer 60-dagers baseline, juster ved behov via API |
Integrasjon med Microsoft-stakken
Azure Portal
- Cost Management + Billing: Native UI for budsjett-oppretting, alert-oversikt, cost analysis
- Cost Analysis Views: Lagre custom views per team/prosjekt, subscribed alerts for ukentlig rapport
- Budgets: Opprett budsjetter med filtre (subscription, resource group, tags, services)
Power BI & Microsoft Fabric
- Cost Management Connector: Direkte integrasjon med Power BI Desktop/Service for executive dashboards
- FinOps Hub: Open-source accelerator fra Microsoft (Data Factory + Fabric) for advanced analytics
- Azure Data Explorer (ADX): Query cost data med KQL for AI-powered insights (Copilot integration)
FOCUS + moderne eksport-pipeline (MCP 2026-06): Microsoft anbefaler nå FOCUS (FinOps Open Cost and Usage Specification) — et leverandør-agnostisk skjema — som eksport-template i Cost Management. Den skalerbare analyse-pipelinen er Cost Management exports → ADLS Gen2 → Fabric Lakehouse → Power BI (FOCUS-formatert, daglig schedule). For høyvolum-loggkostnader: bruk ingestion-time transformation i Azure Monitor for å filtrere før lagring. Cost Management beholder data i 13 måneder; eksporter til storage (cool/archive) for lengre historikk.
Azure Monitor & Log Analytics
- Activity Log: Spor budsjett-opprettelse, endringer, alert-triggering
- Metrics Explorer: Visualiser kostnadstrender side-om-side med tekniske metrics (TPM, requests/sec)
- Alerts: Kombiner cost alerts med teknisk monitoring (f.eks. "hvis cost > 80% OG latency > 2s, escalate")
Tags for kostnadstildeling
| Tag | Formål | Eksempel verdi |
|---|---|---|
costCenter |
Finans-allokering til kostnadssenter | "1234-AI-Innovasjon" |
environment |
Skille dev/test/prod-kostnader | "production", "development" |
project |
Prosjekt-spesifikk kostnadsrapportering | "customer-chatbot-v2" |
owner |
Ansvarlig team/person | "ai-platform-team" |
ai-workload |
AI-spesifikk kategorisering | "rag-pipeline", "fine-tuning", "inference" |
Viktig: Aktiver tag inheritance i Cost Management for å propagere tags fra subscription/resource group til individuelle ressurser i kostnadsrapporter.
Management Groups
Hierarkisk budsjett-struktur for multi-subscription-organisasjoner:
Root Management Group (total AI-budsjett 5M NOK/år)
├── Production MG (3M NOK/år)
│ ├── Subscription: Customer-facing AI (2M)
│ └── Subscription: Internal AI Tools (1M)
└── Non-Production MG (2M NOK/år)
├── Subscription: Dev/Test (1.5M)
└── Subscription: Sandboxes (0.5M)
Offentlig sektor (Norge)
Budsjettprosesser og årshjul
| Periode | Aktivitet | Cost Management-anvendelse |
|---|---|---|
| Q4 (sept-nov) | Budsjettforberedelse for neste år | Eksporter historiske kostnader, generer 12-måneders forecast, input til statsbudsjett |
| Jan | Budsjettvedtak i Stortinget | Opprett budsjetter i Cost Management basert på vedtatt ramme |
| Kvartalsvis | Tertialrapportering til departement | Power BI-rapport med actual vs. budsjett, forklaring på avvik |
| Løpende | Disponeringsfullmakt per måned | Forecast alerts varsler hvis prognoser overstiger 1/12 av årsbudsjett |
Anskaffelsesregler og DFØ-føringer
- Anskaffelsesreglene del III: For AI-tjenester over terskelverdier, dokumenter estimerte årskostnader basert på Cost Management forecast
- DFØ (Direktoratet for forvaltning og økonomistyring): Kostnadsrapporter eksporteres til økonomi-/regnskapssystem for periodisering i statsregnskapet
- KSK (Kostra-rapportering): Kommunal sektor bruker tag
function: "KOSTRA-220"(digitale tjenester) for kostnadstildeling
Statsregnskapet og periodisering
Azure Cost Management aggregerer kostnader per dag, men fakturering skjer månedlig. For statlige virksomheter som følger periodiseringsprinsippet:
- Bruk Cost Analysis amortized view for å fordele reservation-/savings plan-kostnader over perioden
- Eksporter daglige kostnader via Exports for akkurat periodisering i regnskapssystem
- Sammenstill med faktura via Invoice Reconciliation for å sikre samsvar
Kostnad og lisensiering
Prising
| Komponent | Kostnad | Merknad |
|---|---|---|
| Azure Cost Management | Gratis | Alle features for Azure-kunder |
| Budgets & Alerts | Gratis | Ubegrenset antall budsjetter og alerts |
| Cost Analysis | Gratis | Historiske data lagres i 13 måneder |
| Exports | Storage-kostnad | Standard Azure Storage rates (blob storage) |
| Power BI Integration | Lisenskrav | Power BI Pro/Premium for deling av rapporter |
| FinOps Hub (optional) | ~$120-300/mnd + $10 per $1M overvåket | Azure Data Explorer eller Fabric capacity + storage |
Optimaliseringstips
- Bruk forecast alerts proaktivt: Unngå overskridelser ved å handle på 110%-varsel
- Automatiser eksporter til billig storage: Lagre kostnadshistorikk i Cool/Archive tier for compliance
- Konsolider alerts: Bruk Action Groups med Logic Apps for å redusere e-post-støy
- Tag-hygiene: Påkrev tags via Azure Policy for nøyaktig kostnadstildeling
- FinOps dashboards: Invester i Power BI/Fabric for å redusere tid brukt i Portal
For arkitekten (Cosmo)
Spørsmål å stille kunden
- Budsjettmodell: "Har dere et årlig AI-budsjett som skal fordeles per måned, eller varierer behovet sesongmessig?"
- Kostnadseierskap: "Hvem eier budsjettet – sentralt FinOps-team, eller dedikerte produktteam?"
- Alerting-strategi: "Skal varsler sendes til e-post, Teams, eller integreres i eksisterende ITSM-system?"
- Automatisering: "Aksepterer dere automatiske tiltak (f.eks. scale down ved budsjettoverskridelse), eller kun notifikasjoner?"
- Tagging-standard: "Har dere en etablert tagging-policy, eller trenger dere hjelp til å definere kostnadsallokeringsdimensjoner?"
- Rapporteringskrav: "Skal kostnadsrapporter integreres med eksisterende økonomi-/BI-verktøy, eller holder Azure Portal?"
- Anomaly tolerance: "Hvor sensitiv ønsker dere anomaly detection – streng (fanger alle avvik) eller liberal (kun store endringer)?"
- Forecast vs. actual: "Foretrekker dere forecast alerts (early warning) eller budget alerts (faktisk forbruk)?"
Fallgruver per modenhetsnivå
| Modenhetsnivå | Typisk fallgruve | Cosmo-anbefaling |
|---|---|---|
| Beginner | Oppretter kun ét budsjett for hele subscriptionen, mangler granularitet | Start med resource group-budsjetter per team, bruk templates for konsistens |
| Intermediate | Ignorerer forecast alerts, reagerer kun på 100%-overskridelse | Implementer forecast alerts (110%) med eskalert respons |
| Advanced | Over-automatiserer remediation uten safeguards (f.eks. stopper prod-ressurser ved anomali) | Bruk miljø-baserte policies: auto-shutdown kun i dev/test, eskalering i prod |
| Expert | Bygger custom FinOps-plattform uten å utnytte native Cost Management-features | Evaluer FinOps Hub + Power BI før custom-bygg, unngå reinventing the wheel |
Anbefalinger per organisasjonsstørrelse
| Størrelse | Anbefalt mønster | Rationale |
|---|---|---|
| Liten (<10 subscriptions) | Pattern 2: Decentralized med templates | Minimalt overhead, team-autonomi |
| Middels (10-50 subs) | Pattern 1: Centralized governance | Balanse mellom kontroll og delegering |
| Stor (>50 subs) | Pattern 3: FinOps team + automation | Skaler med Logic Apps, FinOps Hub, AI-powered anomaly tuning |
Kilder og verifisering
Microsoft Learn-ressurser (MCP-verified)
Konfidensgradering per seksjon
| Seksjon | Confidence | Kilde |
|---|---|---|
| Kjernekomponenter | Verified | Microsoft Learn docs fetch (tutorial, cost-mgt-alerts) |
| Arkitekturmønstre | Baseline + Domain Expertise | FinOps Framework + Azure Well-Architected |
| Beslutningsveiledning | Verified | Cost optimization best practices (Well-Architected) |
| Integrasjon med Microsoft-stakken | Verified | Official docs (tags, Power BI, Azure Monitor) |
| Offentlig sektor (Norge) | Domain Expertise | KTG/DDT-kontekst, ikke Microsoft-spesifikk |
| For arkitekten (Cosmo) | Baseline + Best Practices | Syntetisert fra research + field experience |
Total sources: 8 unique Microsoft Learn URLs File size: ~14 KB Verification status: 80% Microsoft-verified, 20% domain-specific (Norwegian public sector)