TL;DR
Oväntade molnkostnader och fakturachocker beror sällan på faktureringsfel. Mätaren rullade på och tog betalt för sånt du glömt bort, inte visste var avgiftsbelagt eller aldrig räknade med att behöva betala för. Ungefär 29 % av utgifterna för IaaS och PaaS beräknas vara rent slöseri. Åtgärderna är billiga: schemalagda kostnadskontroller, taggar, infrastruktur som kod, stäng av det som inte används och läs prislistan först. Ge varje vana en ansvarig ägare, och föredra leverantörer som inte bryter ner prissättningen i molekyler och som har en offentlig prislista som du faktiskt kan förstå.
Oväntade molnkostnader uppstår nästan alltid på samma sätt. Någon startade några molnresurser för ett test. Testet tog slut. Resurserna raderades inte. Säg till om du har hört den här förut. En månad senare kom en faktura som var tio eller hundra gånger större än väntat, och personen som berättar historien minns fortfarande den exakta summan. Oväntade molnkostnader av det här slaget är så vanliga att fenomenet har ett eget namn, ”cloud bill shock”, eller fakturachock i molnet på ren svenska. Det har till och med en egen genre av blogginlägg, i regel skrivna i stundens hetta medan författaren högtidligt lovar att påbörja någon form av migreringsresa.
Molnfakturor är oftast korrekta
Jag har personligen inte haft oturen att drabbas, men precis som många av er har jag hört historierna. Senast från en av våra partners som hjälpte ett stort företag att migrera till Cleura, just på grund av en fakturachock och ilskan som följde med den.
Den gemensamma nämnaren hamnar ofta i skuggan av de stora beloppen och det är att fakturan i nästan samtliga fall visade sig vara korrekt. Leverantören tog betalt för molnresurser som faktiskt kördes och kunden hade helt enkelt glömt att de var igång, inte vetat att de var avgiftsbelagda eller aldrig tänkt på att räkna med dem i kalkylen från första början.
Modern prissättning med en inbyggd asymmetri
Pay-as-you-go-prissättning är en av molnets stora fördelar. Du slipper göra stora investeringar i förväg, det behövs ingen kapacitetsplanering flera år i förväg och du kan enkelt skala upp eller ner i enlighet med dina behov.
Missförstå mig rätt. Det granulära sättet att betala för molnresurser är både rättvist och utmärkt i alla bemärkelser, men det har också en inbyggd asymmetri. Att skapa eller allokera en molnresurs kräver bara ett enkelt API-anrop och några sekunders uppmärksamhet. Att komma ihåg att resursen existerar och vad den gör, kanske till och med efter att kollegan som skapade den har bytt team eller slutat, är en helt annan sak.
Mätaren bryr sig inte och den glömmer aldrig. Det som har förbrukats har förbrukats.
Slöseriet som detta skapar är inte något litet avrundningsfel. Flexeras 2026 State of the Cloud-undersökning uppskattar att ungefär 29 % av utgifterna för IaaS och PaaS är slöseri. Separat forskning från CloudZero visade att bara ungefär en tredjedel av organisationerna har en korrekt bild av vart deras molnbudget tar vägen.
De dramatiska historierna som når oss på LinkedIn är uppenbarligen bara toppen av det ökända isberget.
Vad skulle hända om du behandlar varje molnresurs som en liten prenumeration som debiteras på ditt privata kort?
Om ingen i teamet kan säga vad en resurs är till för, utgå från att den bara bränner pengar.
Två sätt att mäta: per allokering och per användning
Här är en distinktion som gör oväntade molnkostnader, och resten av den här artikeln, lättare att resonera kring.
Pris per allokering
Vissa resurser prissätts baserat på vad som allokeras. Dvs. du betalar för de resurser du reserverar, oavsett om du använder dem eller inte. En VM med 4 vCPU:er och 16 GB RAM kostar lika mycket per timme vid 3 % last som vid 97 %, och en volym på 500 GB kostar lika mycket tom som full. Fördelen med modellen är att du oftast blir informerad och vet priset innan du driftsätter resurserna.
Pris per faktisk användning
Andra resurser prissätts per användning och du betalar för det som faktiskt händer. Det vill säga per: gigabyte utgående trafik, API-anrop, funktionsanrop, frågor. Givetvis är det helt omöjligt att specificera den kostnaden i förväg, eftersom allt beror på din framtida trafik, dina användare och, emellanåt, dina buggar.
Vardagliga vs. virala historier
De flesta stora plattformarna har en blandning av båda. De stora amerikanska molnen sveper in VM:ar som debiteras baserat på vad som allokeras i ett lager av dimensioner som debiteras baserat på användning. För jämförelse debiteras Cleura Cloud nästan uteslutande baserat på allokering. Håll distinktionen i minnet bara. De flesta vardagliga överraskningarna kommer från resurser som ingen kommer ihåg att de allokerat, men de mest högljudda och virala historierna tenderar att handla om användning som verkligen har svidit i plånboken.
Några kända exempel på användning som spårat ur
- We Burnt $72K testing Firebase + Cloud Run on Google Cloud (Milkie Way)
- How an empty S3 bucket can make your AWS bill explode (Maciej Pocwierz)
- Beware RunOnStartup in Azure Functions – a serverless horror story (Tom Wright)
- How we spent $30K in Firebase in less than 72 hours (Hacker News)
- Netlify sent me a $104K bill for a simple static site (Hacker News)
- Cara’s viral week led to ~$98K in Vercel Functions costs (InfoQ)
- Recursive serverless functions on AWS, Azure and Google Cloud (InfoQ)
- ServerlessHorrors: ett löpande arkiv med den här sortens historier
De vanligaste orsakerna till fakturachock i molnet
De oväntade molnkostnaderna som brukar överraska mest kommer från en kort och anmärkningsvärt stabil lista.
- Bortglömda VMar: Testservern som överlevde testet. Utvecklingsmiljöer som fortsätter köra klockan 03:00 för att ingen schemalagt en avstängning.
- Resurser utan kopplingar: Volymer eller snapshots som överlevde raderingen av servern de tillhörde. Reserverade publika IP-adresser som pekar på ingenting. Snapshots från 2023.
- Testperioder som löper ut: Testperioder tar oftast slut utan att göra mycket väsen av sig, och resurserna som skapades under gratisperioden fortsätter debiteras till fullt pris efteråt.
- Licensierad mjukvara: Kommersiell mjukvara som mäts per vCPU multipliceras lite smått oskyldigt när någon skalar upp en server. Windows Server och SQL Server är klassikerna; på de flesta prislistor, vår inräknad, debiteras de linjärt per 2 vCPU:er, så en dubblering av serverns kärnor dubblerar också licenskostnaden. Leverantörernas prisjusteringar kommer dessutom oavsett om du hade koll på licensen eller inte.
- Automatisering utan gränser: Autoskalning och serverless-funktioner tenderar att fungera som bäst när du minst vill det, i synnerhet när användningen skenar eller vid attacker. Skämt åsido, försök att bygga in skyddsräcken och gränser i dina automatiseringar så att de inte kan snurra upp resurser i all oändlighet.
Det finns en post till som kanske borde läggas till på listan, och det är kostnaderna för datatrafik. Djävulens påfund enligt vissa, rimligt och rättvist enligt andra. En sak som är säker är att den här posten sällan är medräknad när budgeten gissas fram. Det här ämnet täcker jag i ett separat inlägg och jag kommer att länka till det härifrån när det är publicerat.
Oväntade molnkostnader går att förebygga
Allt på den här listan går att förebygga, så varför fortsätter det hända? Min och mina kollegors erfarenhet är att uppgiften att upptäcka de här sakerna oftast är tilldelad Mållgan. Att gå igenom kostnaderna hamnar i glappet mellan utvecklarna (som ser resurserna men inte fakturan) och ekonomi (som ser fakturan men inte resurserna).
Skapa ett månatligt, eller varför inte veckovis, städschema:
Lista volymer som inte är kopplade till någon VM, IP-adresser som inte pekar på något och snapshots som är äldre än vad er lagringspolicy faktiskt kräver. Radera det som inte klarar granskningen. Trettio minuter i månaden är en mycket bättre investering än alternativet.
Vanor som kan förebygga en fakturachock
Oväntade molnkostnader och fakturachocker undviker du med en handfull ytterst tråkiga vanor. Ingen av dem kräver nya verktyg eller ny budget, bara en utsedd ägare. Jag slår vad om att din senaste och bästa AI-kompanjon kan sköta en del av det här åt dig.
Ett förbehåll innan jag går in på listan. De här vanorna fångar de långsamma läckorna. Den sortens slöseri som branschens 29-procentssiffra beskriver: overksamma resurser, överdimensionerade instanser, testmiljöer som ingen stängde av. Vanorna hjälper mindre, eller inte alls, mot katastrofscenarion där en skenande funktion eller en attack förvandlar en fyrsiffrig faktura till en femsiffrig innan någon varning hunnit gå fram. Det scenariot kräver andra verktyg, som spärrar som pausar i stället för att varna, gränser för vad som får skala och isolering mellan projekt. Det täcker vi i en egen artikel. Märk väl, tills vidare, att vanorna nedan löser de vanligaste problemen, inte de katastrofala.
Håll koll på kostnaderna från dag ett
Om din plattform erbjuder budgetvarningar, använd dem och sätt tröskeln under din smärtgräns i stället för på den. Där varningar saknas kan två andra vanor göra samma jobb: på vissa plattformar som Cleura Cloud visas tim- och uppskattad månadskostnad redan innan du driftsätter resurser (du minns kanske skillnaden på debitering per resurs och debitering per faktisk användning ovan). Anteckna kostnaden och jämför mot den faktureringsdata som finns att tillgå. Där sådan data finns tillgänglig via API är en schemalagd kostnadskontroll bara ett kort skript bort. Kom ihåg att varningar och kontroller bara rapporterar kostnader, de stoppar dem inte, och på vissa plattformar släpar faktureringsdatan de bygger på ett helt dygn efter verkligheten.
Tagga allt
En enkel taggning som följer en viss standard, varför inte projekt, miljö och ägare, förvandlar en oläslig faktura till en fråga som går att besvara. Otaggade resurser bör stå överst på din lista över kandidater att radera.
Använd mer infrastruktur som kod
Resurser som skapats utanför dina OpenTofu-, Ansible- eller Heat-definitioner är osynliga för din granskningsprocess, och osynliga resurser tenderar att bara ticka pengar.
Stäng av det som inte används
Icke-produktionsmiljöer behöver sällan vara igång utanför arbetstid. Att schemalägga avstängning eliminerar en stor kostnad utan att någon funktion går förlorad. Testmiljöer behövs i de allra flesta fall bara under ca 40 av veckans 168 timmar.
Läs prislistan (om du kan)
Tio minuter med prislistan, innan du driftsätter, besvarar de flesta av frågorna som nästa faktura riskerar att besvara till ett mycket högre pris.
Granska leverantörssidan noggrant
Allt jag har skrivit ovan ligger på kundens sida av det hela. Fakturachocker har också en leverantörssida, eftersom prismodeller skiljer sig enormt i hur många obehagliga överraskningar de har förmågan att skapa.
När du utvärderar en IaaS-leverantör är fem frågor värda att ställa när det gäller deras prislista:
- Finns det en offentlig prislista, eller kräver prissättningen ett säljsamtal?
- Vad kostar inkommande och utgående datatrafik, exakt, per GB?
- Finns det avgifter per användning (API-anrop, IOPS, hämtningar) som skalar lite försynt med användningen?
- Vad kostar publika IP-adresser?
- Finns det en kalkylator du kan använda innan du skapar ett konto?
Låt oss stanna där för att hålla listan professionell, men ärligt talat, och ur ett högst personligt perspektiv, borde det finnas en sjätte punkt: ”Går prislistan att läsa och förstå utan en doktorsexamen i molnprissättning?”
Cleura som exempel
Vi kan använda Cleura Cloud som exempel här, inte minst för att svaren är ganska korta.
- Prissättningen finns på en enda offentlig sida på https://cleura.com/sv/prislista/.
- Allokerade resurser mäts per sekund, beräknas per timme och faktureras månadsvis, utan bindningstider.
- Inkommande datatrafik är gratis i både Cleura Public Cloud och Cleura Compliant Cloud. I Cleura Compliant Cloud kostar även utgående trafik 0 € per GB. Endast i Cleura Public Cloud debiteras utgående trafik med, för närvarande, 0,2875kr per GB.
- IPv6-adresser är gratis, IOPS debiteras inte separat.
- En offentlig kostnadskalkylator låter dig räkna på dina konfigurationer även om du inte är kund.
För att vara riktigt tydlig: Det finns ingen prismodell som är snällare än någon annan mot rent slarv. En bortglömd VM kostar pengar överallt, även i vårt moln. Min poäng är att ju färre dimensioner en faktura har, och ju synligare var och en är i förväg, desto mindre utrymme för obehagliga överraskningar.
Du ska kunna hitta svaren på fem enkla frågor om prissättning med hjälp av publikt tillgänglig information.
Kan du inte det – toppen, då har du också fått ett svar.
Vidare läsning
- Cleura Clouds prissida och kostnadskalkylatorer
- AWS-dokumentationen: Understanding unexpected charges. Leverantörens egen katalog över sätt som fakturor överraskar på är lärorik läsning.
- The Register: 37signals completes its cloud exit.
Özgür Bal
Marknadsansvarig · Cleura AB
Özgür är marknadsansvarig på Cleura. Han arbetar med varumärke, kommunikation, innehåll och go-to-market-strategi, med särskilt fokus på molninfrastruktur och digital suveränitet.
