Kjell Tore Guttormsen
1c9af82daa
Ordren ba meg behandle sitt eget premiss som et premiss: «PM-ens 87/45 er korrigert
til 85/47 ved maaling ... Behandle ogsaa 85/47 som et premiss og re-maal det foer du
bygger.» Re-målt over de 389 ref-filene holder 85/47 heller ikke — og feilen ligger i
KLASSIFIKATOREN, ikke i tellingen. Summen 132 står; fordelingen er 62/70.
TRE FUNN, alle pinnet i test:
1. FJORTEN bold-etiketter er DIALOG-ATTRIBUSJONER, ikke etiketter. Dialog-bøtta
matchet bare kursivformen `*Cosmo:*`. Fetformen står foran sitert tale —
`**Naar kunden sier:** "..."` / `**Cosmo svarer:** "..."` — så å slette den
etterlater replikken uten taler. Redaksjonelt, ikke mekanisk.
2. TI tabellceller er PROVENIENSPÅSTANDER i kildekvalitets-kolonnen. Celleposisjon
deler de 26 tabellforekomstene i tre klasser, ikke én: 12 radetiketter (kolonne 0),
4 kolonneoverskrifter, 10 proveniensverdier (`Moenstre er Cosmo-design`,
`Raadgivende innhold basert paa Cosmo-persona`). Å skrive om en av dem er å avgi en
ny påstand om hvor innholdet kommer fra, og den siste har ikke noe slettemål i det
hele tatt. Seks av ordrens ni sammensetninger ligger helt inne i denne klassen —
ordrens egen advarsel traff, målingen lokaliserte den.
3. Lekkasje ANDRE veien, +1 mekanisk: `- **For arkitekten (Cosmo):** ...` i
reasoning-models-o1-o3-optimization.md:549 er nøyaktig målklassen, men et
linjestart-forankret nett ser den ikke bak `- ` og bokførte den som prosa.
Operatøren ratifiserte 2026-09-15 alt. A: kjør de 62, hold dialog og proveniens for
R14. Begge tilbakeholdte klasser henger på #R14-persona-ramme som aldri er besvart;
de 62 gjør ikke det, fordi R13 ALT har kjørt `For Cosmo` -> `For arkitekten` over 401
headinger — dette gjør bare etiketter og tabellrader konsistente med en beslutning
som allerede er utført.
UTFØRT: 62 forekomster i 50 filer (ordren sa 47) — 46 etiketter i 16 ratifiserte
varianter, 16 celler i 4. Diffen er 62 fjernet = 62 lagt til, ren in-place-erstatning;
hver endret linje klassifisert, ANNET = 0. Ingen måltekst innfører et ord kilden ikke
hadde, utover R13s sanksjonerte `arkitekten` (samme invariant-test, gjenbrukt).
GATEN, DEKOMPONERT I TRE KLAUSULER, hver validert BEGGE veier før den ble konsumert:
R1 REFERENT mekaniske sites 62 -> 0, produkt 451 uendret.
Kjent-pos: `**For Cosmo:**` OG `| Cosmos raad |` (genitiven er den
et bold-only nett mister) feller begge. Kjent-neg:
`**Cosmos DB-anbefaling:**` — ser ut som persona, er produkt —
og `| Azure Cosmos DB |` passerer urørt.
R2 REKKEVIDDE 0 umålte varianter, 0 utenfor rekkevidde. Kjent-pos: en ukjent
etikettform rapporteres som umålt OG transformen KASTER, den
hopper ikke stille over. Kjent-neg: dialog + proveniens bokføres
utenfor scope og er byte-identiske.
R3 HVA SOM STÅR 16 redaksjonelle etiketter + 10 celler uendret, heading/TOC
fortsatt 0 (R13 ikke regradert), prosa 132 -> 70. Kjent-pos: et
fjernet tegn i `Cosmos DB` feller produkt-differansen. Kjent-neg:
alle kun-produkt-filer byte-identiske gjennom transformen.
Gaten ble kjørt FØR transformen og felte R1 (exit 1) — et nullresultat som aldri er
tvunget til det andre svaret er ingen måling. R13b har egen baseline-fil;
cosmo-gate-baseline.json er et referansepunkt-artefakt (personaHeadings 401) og er
IKKE re-emittert. Ny .gitignore-negasjon (6 entries), aldri `git add -f`.
Målt underveis: 0 av de 62 målinjene ligger i en kodeblokk, så fence-agnostisk
transform er trygg her — samme konklusjon R13 nådde for headinger. Nøyaktig 1 linje
bærer begge klasser; dens `Cosmo-persona` står igjen, som den skal.
Suite 1134/1134 (1120 + 14 nye), validate-plugin 250/0/0, transform idempotent,
R13-driveren fortsatt no-op. RX-OPS1 adversarial-scan kjørt MANUELT på de 56 stagede
filene (OK, exit 0) — `core.hooksPath` skygger repoets pre-commit, fiksen eies av
`.claude`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
- 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
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 | 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 | Baseline + Best Practices | Syntetisert fra research + field experience |
Total sources: 8 unique Microsoft Learn URLs