Ljus
Mörk
Författare
Jorge Mieres
Teamleader Azure Consulting
Read time
6 min
26 maj 2026
Du har produktionsystem i Azure. Tjänsterna fungerar, kostnaderna är inte alarmerande, ingen incident är akut. Allt ser bra ut, åtminstone på ytan. Det är just i det lugnet som problemen brukar gro. Azure-miljöer slits, men de slits tystare än on-prem-miljöer gjorde. Det märks inte i en serverlampa som blinkar fel, det märks i en samling småsaker som tillsammans gör att miljön gradvis glider bort från den arkitektur ni en gång designade.
Vi ser regelbundet Azure-miljöer som tekniskt sett fungerar, men där tre eller fyra år av små förändringar har gjort att den ursprungliga avsikten har tappats. En tillfällig undantagspolicy som glömts bort. En rolltilldelning till en konsult som slutade 2024 finns fortfarande kvar. En Azure Policy-konfiguration som inte uppdaterats sedan en ny PaaS-tjänst togs i bruk. Var och en av förändringarna kan vara små. Tillsammans bestämmer de hur exponerad organisationen faktiskt är.
Det här är inget Azure-problem i sig. Det är ett driftsproblem som blir tydligare i molnet eftersom plattformen inte ger samma fysiska påminnelser som ett serverrum gör. När du inte längre ser hårdvaran, ser du inte heller försiktigt vad som ackumuleras runt den.
För att illustrera vad vi pratar om kan det vara värt att titta på några konkreta mönster vi ofta möter när vi tar över eller granskar svenska Azure-miljöer.
RBAC-ackumulation. Identiteter som fått brett mandat för ett enskilt projekt ligger kvar med samma rättigheter tre år senare. Konsulter som inte längre arbetar med kunden har fortfarande Owner-rollen på prenumerationer. Service principals utan tydlig ägare har långa hemligheter som aldrig roterats. Det här är förmodligen den vanligaste typen av exponering vi ser.
Azure Policy-drift. Policyer som sattes vid initial design uppdateras sällan när nya tjänster införs. Resultatet blir att nya resurser hamnar utanför styrningen utan att något larm går. En policy för storage-konton som skrevs innan Storage Account v2 blev standard, eller en namngivningskonvention som ingen längre följer, är symptom på samma sak.
Tagg-erosion. Cost Management bygger på taggar för att kunna spåra vad som kostar vad. När taggningsdisciplinen glider, glider också insynen i kostnader. Ett halvår av otaggade resurser räcker för att månadsrapportens "övrigt"-kategori ska bli den största posten.
Säkerhetsposture-regression. Defender for Cloud Secure Score sjunker långsamt över tid när nya rekommendationer tillkommer och ingen i teamet har tid att hantera dem. Ingen incident inträffar. Scoren bara blir lägre, månad för månad. Tjänster och data utan Backup eller med backuppolicy som aldrig validerats genom restore-test. Automatiska uppdateringar nyttjas inte — patchning sker manuellt eller inte alls.
Kostnadskontroller. Utan aktiv uppföljning tappar man greppet om kostnaderna. Inga budgets, inga alerts, inga optimeringar. Orphaned-resurser ackumuleras: disks utan VM, NICs, public IPs, snapshots från 2022. Dev/test-VMs igång 24/7, Premium SSD v2 där Standard SSD räcker, Application Gateway WAF v2 i en miljö med 3 requests/dag. Små läckor blir snabbt stora: oanvända resurser, testmiljöer som går dygnet runt, överdimensionerade tjänster. Det märks sällan direkt – bara i fakturan. Kostnader driver inte sig själva nedåt. Utan ägarskap driver de bara åt ett håll.
IaC-drift. Resurser som ursprungligen deployades via Bicep eller Terraform har ändrats manuellt i Azure-portalen. Nästa pipeline-körning rullar tillbaka ändringen, eller ännu värre, bryter den. Pipelinen "fungerar inte längre" och börjar köras manuellt. Inom ett år är miljön delvis IaC-styrd och delvis klick-styrd.
Om plattformen i praktiken bara förvaltas, och förändring främst sker när något redan blivit ett problem, har driftmodellen ofta nått sin kapacitetsgräns. Nya tjänster och funktioner i Azure utvärderas inte längre systematiskt. Tekniska skulder ligger kvar. Förbättringsinitiativ skjuts upp.
Inget av detta orsakar en kris. Tillsammans skapar de en miljö där ingen längre vet säkert vad som körs, vem som har tillgång, eller vad som faktiskt kostar pengar.
Det finns inget hemligt med vad en mogen Azure-drift behöver göra. Microsoft har själva beskrivit det i Cloud Adoption Framework, som pekar ut fem governance-discipliner: Cost Management, Security Baseline, Identity Baseline, Resource Consistency och Deployment Acceleration. Ramverket är gratis, väl dokumenterat och uppdateras kontinuerligt. Få organisationer vi möter har inte hört talas om det.
Färre har implementerat det fullt ut.
Det är inte en kritik. Cloud Adoption Framework är ambitiöst och kräver löpande arbete för att förbli aktuellt. Att en intern IT-organisation som också ska bygga nya tjänster, hantera applikationsteam och svara på verksamhetens önskemål inte hinner fördjupa sig i alla fem discipliner är inte slarv. Det är en realistisk konsekvens av att kapacitet är begränsad.
Den fråga ramverket ändå tvingar fram är följande: hur ofta granskas faktiskt er governance-baseline mot CAF? Om svaret är "vid initial migrering, sedan ad hoc", då är det rimligt att anta att verkligheten har glidit från designen.
En av anledningarna till att Azure-drift är svårare än det ser ut är att plattformen kräver bredd som är ovanlig att samla i ett internt team.
För att sköta en mogen Azure-miljö väl behövs djup inom åtminstone följande områden:
Få interna IT-team kan ha samtliga av dessa områden representerade på djup nivå. De flesta har två eller tre starka områden och täcker övriga med god intention och ytlig kunskap. Det fungerar i normaldrift. Det märks när något gått snett, eller när Microsoft släpper en uppdatering som ändrar förutsättningarna för flera områden samtidigt, vilket händer ofta.
Bredden är inte ett kompetensproblem hos den enskilde. Det är en strukturfråga om hur kapacitet fördelas i teamet.
Det finns inget magiskt antal Azure-resurser där intern drift slutar fungera. Däremot finns det signaler som vi ofta ser föregå beslutet att antingen växa det interna teamet kraftigt eller paketera bort drift till en partner.
Den första är on-call som inte är hållbar. Om samma två personer alltid är de som löser nattincidenter, och de börjar prata om att byta jobb, är driften ekonomiskt sårbar oavsett hur välfungerande den ser ut.
Den andra är kontextväxling som äter utvecklingstid. Om utvecklarteamet i praktiken är driftspersonal halva tiden, eftersom inget annat team finns, då bär ni en kostnad som inte syns i någon faktura, men som syns i hur länge ny utveckling tar.
Den tredje är otestad disaster recovery. Om ingen vet exakt hur lång tid det tar att återställa er affärskritiska Azure-tjänst, eftersom det aldrig testats end-to-end, då vet ni heller inte om det löfte ni gett verksamheten är realistiskt.
Ingen av dessa signaler är ett absolut tecken på att något måste ändras. Tillsammans pekar de på att den nuvarande modellen kan vara på väg att bli sin egen flaskhals.
När en organisation når den punkten finns det i praktiken två vägar att överväga.
Den ena är att bygga ut intern kapacitet. Det innebär att rekrytera in den breddkompetens som saknas, etablera en formell drift-funktion, dokumentera processer och sannolikt köpa in kompletterande verktyg. Det är en investering som tar tid att betala tillbaka, men för organisationer som vill ha drift som kärnkompetens och har volymen att försvara den, är det rätt val.
Den andra är att paketera bort delar av driften till en specialiserad partner. Det innebär att en extern leverantör tar löpande ansvar för plattformen, medan det interna teamet fokuserar på utveckling, integration och arkitektur. Det är den modell Asurgents managerade tjänst CloudOps Azure är byggd för. Mer om vad som ingår, och var gränserna går, finns på tjänstesidan för CloudOps Azure.
Vilken väg som passar er beror på storlek, mognad, geografi, säkerhetskrav och vilken roll IT spelar i affärsmodellen. Det enda som inte fungerar bra över tid är att låta nuvarande tillstånd fortgå utan att fatta beslutet aktivt.
Azure är inte en plattform man köper. Det är en plattform man förvaltar. Den observationen är inte särskilt djup, men den hanteras ändå sällan strukturerat. Det enklaste sättet att börja är att ställa en konkret fråga till sig själv: när granskades vår Azure-governance senast mot CAF, och av vem? Om svaret är vagt, är det förmodligen där arbetet bör börja.
