Så räknar du på förbrukningsbaserade molnkostnader

Varför förbrukningsbaserad molnkostnad är annorlunda

CGI liknar molnet vid elnätet, fast för IT: i stället för att äga och underhålla egna servrar får organisationen datakraft, lagring och programvara över internet och betalar bara för det som faktiskt används. Kostnaden flyttas därmed från ett inköpstillfälle till en löpande mätning av användning.

Skillnaden mot en egen server handlar om vem som bär kapacitetsrisken. Med lokal server ansvarade företaget för inköp, installation, elförsörjning, kylning, underhåll, säkerhetsuppdateringar och för att byta ut hårdvaran när den blev gammal (CGI). I molnet hyr man motsvarande funktion och beställer i stället den datorkraft och lagring som behövs. En felbedömning av kapacitetsbehovet slår då på månadskostnaden i stället för på en avskrivning över flera år.

Kommerskollegium konstaterar i en rapport från 2024 att svenska företag som använder molntjänster tenderar att vara mer internationaliserade och att exportera mer och till fler marknader – och att det är mindre företag som tar hem de största exportvinsterna. Rapporten pekar också på att molntjänster ger tillgång till ledande teknologi utan stora investeringar. Praktiskt innebär det att kalkylen måste byggas kring förbrukning per tidsperiod, inte kring en inköpskostnad, och att den bara blir rättvisande om användningen faktiskt mäts och följs upp.

Statistik över molnnyttan i svenska företag

Vad du faktiskt betalar för i molnet

De resurser som typiskt mäts och prissätts är datakraft, lagring och programvara som levereras som tjänst över internet (CGI). Var och en har sin egen mätenhet: beräkning mäts i den tid en resurs är igång, lagring i volym per tidsperiod och programvara per användare, per nyttjad funktion eller som en del av den underliggande förbrukningen. Vill du räkna på kostnaden måste du därför först veta vilken enhet varje post faktureras i.

Att användning alls går att prissätta per enhet bygger på virtualisering. CGI beskriver tekniken som att en kraftfull fysisk server delas upp i flera oberoende virtuella servrar, där varje virtuell server fungerar som en egen dator med eget operativsystem och egna resurser men i praktiken delar kraften från samma fysiska hårdvara. Jämförelsen i samma källa är en stor kontorslokal som delas i mindre, låsbara kontor: flera kunder kan arbeta privat och säkert i samma byggnad och dela på gemensamma resurser. När hårdvaran utnyttjas effektivt sjunker kostnaden för alla, och den delade, mätbara kapaciteten är just det som gör att en enskild kund kan debiteras för sin andel i stället för för hela servern.

Samma tjänst kan alltså bli olika dyr beroende på hur den används. En databas som ligger still och sällan läses belastar andra poster än en applikation med jämn och hög trafik. Det är användningsmönstret, inte tjänstenamnet, som avgör vilka rader som dominerar fakturan.

Kostnadsdrivare att mäta

Beräkningstid är en central post. Den mäts som den tid en beräkningsresurs är aktiv och dimensioneras av antal instanser eller virtuella processorer, hur länge de körs och hur mycket minne de tilldelas. En instans som kör dygnet runt kostar lika mycket oavsett om den används eller inte, medan en som startas vid behov bara belastar de timmar den är igång. I kalkylen behöver du därför skilja på resurser med kontinuerlig drift och resurser som kan stängas av.

Lagringsvolym mäts i regel som mängd data per månad och driver kostnad både genom vad som lagras och genom hur länge det ligger kvar. Till det kommer läs- och skrivoperationer, alltså hur många gånger data hämtas eller ändras. Ett system med många små transaktioner kan få högre kostnad för operationer än för själva lagringsvolymen, medan ett system med stora datamängder som sällan rörs får motsatt fördelning.

Datatrafik är den tredje återkommande drivaren. Den mäts i volym och beror på hur mycket data som skickas mellan system och till användare.

Kostnadsdrivare i moln: Beräkning, lagring och datatrafik

En enkel räkneformel för månaden

Månadskostnaden kan sammanfattas som summan av förbrukning gånger pris per enhet för varje resurs, plus utgående datatrafik och övriga avgifter: månadskostnad = Σ (förbrukning per resurs × pris per enhet) + utgående trafik + övriga avgifter. Summan löper över alla resurstyper du använder – beräkning, lagring, operationer, databas, köade meddelanden, loggvolymer och liknande – eftersom varje typ har sin egen enhet och sitt eget pris.

För varje resurs behöver du fylla i tre uppgifter: vilken enhet som faktureras, hur många enheter du förbrukar under en typisk månad och priset per enhet. Osäkerheten sitter nästan alltid i den andra uppgiften, inte i priset. Börja därför med att mäta förbrukningen under en normalmånad och behandla sedan antalet enheter som den variabel du justerar när du räknar scenarier.

Övriga avgifter läggs till utanför summan, eftersom de ofta inte följer samma enhet som resursförbrukningen. Det kan vara stödavtal, hanterade tilläggstjänster, licenser per användare eller avgifter för backuper och loggarkivering. Ge var och en en egen rad i stället för att försöka få in dem i förbrukningssumman – då syns det vad som är rörligt och vad som är ett fast åtagande.

Dataskikt och utgående trafik

Dataskikt är ett sätt att sätta pris efter hur snabbt data behöver vara tillgänglig. Ett varmt skikt är avsett för data som läses och skrivs ofta, ett kallt för data som sällan används men måste kunna hämtas, och ett arkiverat för data som i praktiken ligger stilla och bara plockas fram undantagsvis. Oracle beskriver i sin genomgång av kostnader för utgående molntrafik att ju varmare skiktet är, desto lägre blir kostnaden för läs- och skrivoperationer. Lägre operationskostnad i det varma skiktet motsvaras därför normalt av en högre kostnad för att lagra samma mängd data där, vilket gör placeringen till en avvägning mellan volym och åtkomstmönster.

För kalkylen betyder det att ett enda lagringspris för hela datamängden inte håller. Dela upp lagringen efter hur ofta varje dataset faktiskt läses, räkna operationer och volym för varje del för sig, och kontrollera kostnaden för att flytta data mellan skikten om ett dataset ändrar karaktär. En vanlig felkälla är data som blivit sällan använd men ligger kvar i ett varmt skikt.

Utgående datatrafik, egress, måste räknas in separat eftersom den inte följer beräknings- eller lagringsenheterna. Du behöver alltså veta hur mycket data som flödar ut till användare, kunder eller andra system varje månad – och den volymen ökar när tjänsten får fler användare, även om själva beräkningen ligger still. Notera också att trafik mellan olika delar av en arkitektur kan prissättas olika beroende på om den stannar inom molnet eller passerar ut ur det.

Prognos, skalning och uppföljning

Molntjänster ger skalbarhet för att hantera variationer i efterfrågan, vilket Kommerskollegium lyfter som en av faktorerna bakom att företag snabbt kan skala upp eller ner och experimentera med nya produkter och funktioner. Bygg in den egenskapen i kalkylen från början: räkna på ett lågscenario, ett normalscenario och ett högscenario, och ange vilken förbrukning som förändras i varje.

Arbetssättet kan delas in i fyra steg. Först fastställer du en baslinje genom att mäta förbrukning per resurstyp under minst en hel månad. Sedan kopplar du varje resurstyp till den efterfrågedrivare som styr den – antal aktiva användare, antal transaktioner, datamängd, antal samtidiga sessioner – så att du kan räkna om förbrukningen när efterfrågan ändras i stället för att gissa. Därefter bygger du scenarierna genom att skala drivarna upp och ner. Sist jämför du varje månad prognosen mot den faktiska förbrukningen på fakturan och justerar de antaganden som inte höll.

Uppföljningen blir mycket enklare om resurserna märks upp så att förbrukning kan hänföras till rätt system, kund, avdelning eller projekt redan i faktureringsunderlaget. Då syns det vilken del av organisationen som driver kostnaden, och avvikelser upptäcks i tid. Sätt gärna ett tröskelvärde per märkning där du vill bli varnad, så att en oväntad ökning upptäcks innan den hunnit bli en vana.

Se därför genomgången av prognos mot utfall som en återkommande rutin, inte som en engångsinsats när tjänsten införs.

Steg för korrekt prognos och uppföljning av molnkostnader

Vanliga fallgropar och extrakostnader

CGI konstaterar att molntjänster ofta prissätts efter användning, och att det därför är viktigt att förstå vad som ingår i priset och att se upp för extra kostnader. Den grundförbrukning du räknar fram med räkneformeln är sällan hela fakturan. Extrakostnader uppstår typiskt för tjänster som lagts till vid sidan av grundutförandet, för stöd och hanterade tillägg samt för trafik och lagring utanför det du först dimensionerade.

Dataskiktet är en annan återkommande fallgrop. Anta inte att hela datamängden ligger i ett och samma skikt – data med olika åtkomstmönster hör hemma i olika skikt, och då blir kostnaden fel. Data som en gång placerats för hög åtkomstfrekvens och sedan sällan rörs fortsätter dessutom att belasta volymkostnaden.

En tredje källa till oväntade kostnader är resurser som lämnats kvar: instanser som körs utan trafik, volymer som inte längre är kopplade till något system, gamla kopior och loggar som samlas utan gallring. Eftersom debiteringen följer faktisk användning fortsätter sådant att kosta varje månad utan att någon använder det. Kontrollera därför varje månad att instanser, volymer, kopior och loggar har en ägare och ett dokumenterat syfte, och avveckla eller arkivera det som inte längre används.

Själva mätningen kan också bli fel om du räknar på fel enhet. Mäts förbrukningen per timme men kalkylen antar heldagsdrift, eller räknas operationer per anrop medan kalkylen räknar per användare, blir prognosen systematiskt fel hur noggrant priset än är satt. Utgå därför alltid från hur leverantören faktiskt mäter varje resurs innan du bygger scenarierna.

Vanliga fallgropar i molnkostnader – prioriterade efter risk