Räkna förbrukningsbaserade molnkostnader med en kalkylmall

Börja räkna på förbrukningsbaserade molnkostnader

CGI beskriver molnet som tillgång till datakraft, lagring och programvara över internet i stället för egna servrar, med betalning för faktisk användning. Kostnaden flyttas från inköpstillfället till löpande mätning. Bygg därför en kalkylmall där varje fakturerad resurs får enhet, debiterbar mängd, pris per enhet och radkostnad, och stäm sedan av månadssumman mot fakturan.

Skillnaden mot en egen server är vem som bär kapacitetsrisken. Vid lokal server stod företaget för inköp, installation, elförsörjning, kylning, underhåll, säkerhetsuppdateringar och hårdvarubyte när utrustningen blev gammal (CGI).

Amazon Web Services, Microsoft Azure och Google Cloud är tre ledande molnplattformar som erbjuder beräkning, lagring och datatjänster (opsiocloud.com). För allmänna webbapplikationer ligger prisskillnaden mellan dem typiskt på 5–15 procent (swivrr.se). Jämför därför samma användning och konfiguration, inte bara plattformarnas namn.

Avgränsa först vilka system och miljöer som ska ingå i kalkylen. Ta med de molntjänster som faktiskt används och skriv ned vad som ligger utanför, så jämförelsen får en tydlig gräns.

Inventera resurserna per tjänst i stället för per faktura. Hos AWS handlar det om beräkning i EC2 och Lambda samt databaser i RDS (swivrr.se). Google Cloud motsvarar det med Compute Engine, Cloud Storage, BigQuery och Cloud SQL (cloudpricecalculators.com).

Du betalar för det du faktiskt använder, och AWS debiterar per sekund eller per gigabyte (swivrr.se). Det gör mätenheten avgörande, för fel enhet ger fel summa hur rätt priset än är.

Skilj mellan en resurs som står på hela tiden och en som bara används vid behov. För kalkylen påverkar drifttiden antalet enheter, medan pris per enhet hämtas enligt den aktuella konfigurationen.

Lägg varje fakturerad post på en separat rad, även när flera poster hör till samma system. Då går det att se om exempelvis operationer eller trafik tillkommer utöver lagringen.

Spara antagandena bakom varje rad tillsammans med källan till mängden och priset. När prognosen avviker från fakturan går det då att kontrollera om förändringen gäller användning, pris eller klassificering.

Kalkylen måste byggas kring förbrukning per tidsperiod, inte kring en inköpskostnad. Den blir bara rättvisande om användningen faktiskt mäts och följs upp.

En förbrukningskostnad måste mätas, medan en licens per användare räknas per person. Posterna styrs av olika enheter och hör därför hemma på olika rader i kalkylen.

Leverantörerna säljer compute, storage och datatjänster i ett gemensamt ekosystem (opsiocloud.com). AWS, Azure och Google Cloud har egna prislistor, så kalkylen måste byggas rad för rad mot de tjänster du faktiskt använder.

En förbrukningsrad behöver enhet, antal enheter och pris per enhet, följt av den beräknade radkostnaden. Enheten bestäms av hur leverantören mäter resursen, antalet av användningsunderlaget och priset av tillämpliga prisvillkor. Kontrollera också vilken del av den uppmätta användningen som faktiskt är debiterbar innan du multiplicerar.

Mätperioden är månaden. Timmar, volymer och anrop ska avse samma intervall om de ska kunna summeras mot fakturan.

En komplett förbrukningskalkyl vilar på fyra delar: enheterna som visar vad som mäts, formeln som summerar raderna, kostnadsdrivarna som förklarar varför antalet enheter ändras och uppföljningen mot fakturan. Saknas någon av delarna går kalkylen inte att luta sig mot.

Enhet, formel och kalkylmall hänger ihop. Enheten bestämmer vad raden mäter, medan formeln multiplicerar den debiterbara mängden med motsvarande pris. Mallen håller sedan beräkning, lagring, operationer, trafik och övriga avgifter åtskilda tills radkostnaderna summeras.

Börja med en lista över de resurstyper du faktiskt använder och skriv leverantörens fakturerade enhet bredvid varje rad. Först när enheten står på raden är det meningsfullt att hämta priset per enhet.

Kontrollera att mätperioden i användningsrapporten matchar fakturaperioden. Om perioderna skiljer sig ska mängden jämföras på samma tidsgrund innan radkostnaderna summeras.

Om en resurs har skilda prisvillkor, låt varje villkor få en egen rad i kalkylen. Då syns vilket antagande som ändras mellan scenarierna.

Vad du faktiskt betalar för i molnet

Typiskt mäts och prissätts datakraft, lagring och programvara som levereras som tjänst över internet (CGI). Varje resurs har egen mätenhet: beräkning i tid resursen är igång, lagring i volym per tidsperiod och programvara per användare, per nyttjad funktion eller som del av underliggande förbrukning. Du måste veta vilken enhet varje post faktureras i för att kunna räkna kostnaden.

Varje tjänst mäts i sin egen enhet. AWS debiterar efter faktisk användning, per sekund eller per gigabyte, och för Lambda är både anrop och exekveringstid kostnadsdrivare (swivrr.se). Ge varje debiteringsgrund en egen rad, så att ett pris för anrop inte används för att beräkna exekveringskostnaden.

Molnplattformar kan innehålla infrastruktur, plattformstjänster och färdig programvara. Ta bara med tjänster som används och ge varje fakturerad resurstyp en egen rad, eftersom mätenhet och pris kan skilja sig.

För beräkning kan faktureringen utgå från aktiv tid, medan lagring kan redovisas som datamängd över en period. Kontrollera fakturans enhet i stället för att anta att samma mått gäller för varje resurs.

Programvara mäts per användare, per nyttjad funktion eller som del av underlaget för förbrukning. En licens per användare följer antalet personer, medan en användningsbaserad licens följer samma förbrukning som övriga rader. Båda kräver enhet, antal och pris per enhet.

Priset per enhet skiljer sig mellan resurstyper: beräkning prissätts per tidsenhet, lagring per mängd och period, operationer per anrop och utgående trafik per volym. Priset hämtar du färdigt; antalet enheter måste mätas fram.

Personbaserade licenser hör inte hemma bland resursmängder som mäts i timmar, datavolym eller anrop. Lägg dem på en egen rad med antal användare och pris per licens.

Räkna raden genom att multiplicera antalet licenser med priset per licens. Om avtalet tar betalt per funktion i stället, använd den fakturerade funktionen som enhet.

Håll personbaserad och användningsbaserad licensiering åtskilda i prognosen. Den första följer antalet licenser, medan den andra följer den mätning som anges för användningen.

En licens per användare följer antalet användare, medan en användningsbaserad licens följer den mätning som anges för användningen. I kalkylen hamnar de på olika rader med olika enheter.

Att prissätta användning per enhet bygger på virtualisering. CGI beskriver tekniken som att en kraftfull fysisk server delas upp i flera oberoende virtuella servrar. Varje virtuell server fungerar som en egen dator med eget operativsystem och egna resurser men delar kraften från samma fysiska hårdvara.

Samma källa jämför med en stor kontorslokal som delas i mindre, låsbara kontor: flera kunder kan arbeta privat och säkert i samma byggnad och dela gemensamma resurser. När hårdvaran utnyttjas effektivt sjunker kostnaden för alla. Den delade, mätbara kapaciteten 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 bli olika dyr beroende på användningen. En databas som ligger still och sällan läses belastar andra poster än en applikation med jämn och hög trafik. Användningsmönstret, inte tjänstenamnet, avgör vilka rader som dominerar fakturan.

Skriv enheten först och hämta priset för rätt tjänst och konfiguration ur leverantörens prislista eller avtal. Hämta mängden från användningsunderlaget och kontrollera den mot fakturan. Kontrollera även att prisets valuta och tidsgrund motsvarar kalkylen; annars behöver underlagen räknas om innan de kan jämföras.

För molnkalkylen gäller tre uppgifter per rad: enhet, antal enheter och pris per enhet. Enheten kommer från leverantörens fakturering, antalet från din mätning och priset från prislistan.

Rad för rad: beräkning, lagring, operationer och utgående trafik. Varje resurstyp får egen enhet och eget pris per enhet.

Kostnadsdrivare att mäta

Beräkningstid är en central post. Den mäts som tiden en beräkningsresurs är aktiv och dimensioneras av antal instanser eller virtuella processorer, drifttid och tilldelat minne.

När en instans debiteras för tiden den är igång fortsätter tidskostnaden även om applikationen saknar trafik. En instans som startas vid behov får däremot en annan uppmätt drifttid. Skilj därför på kontinuerlig drift och resurser som kan stängas av, och beräkna tidsraden från faktisk drifttid i stället för från hur aktiv applikationen verkar vara.

Lagringsvolym mäts i regel som mängd data per månad. Den driver kostnad genom vad som lagras och 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 lagringsvolymen; 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.

Använd den minsta fakturerade enheten som kostnadsunderlaget faktiskt redovisar. Om kalkylens enhet avviker från fakturans behöver du omvandla mängden innan du multiplicerar med priset.

Varje drivare har sin egen enhet: beräkning i timmar, lagring i mängd per månad, operationer i antal anrop och utgående trafik i volym. Enheten avgör hur förbrukningen mäts och vad som ska stå i kalkylen.

Så mäts de fyra raderna: beräkning som antal instanser gånger antal timmar de varit igång, lagring som mängd under månaden, operationer som antal anrop och utgående trafik som volym som lämnat molnet. Varje rad multipliceras sedan med sitt pris per enhet.

Sätt enheten i radens rubrik. Då syns det direkt om en siffra är hämtad från fel mätning.

Fyra rader täcker de flesta kalkyler: beräkning, lagring, operationer och utgående trafik. Använder du databaser, köade meddelanden eller loggvolymer tillkommer en rad per resurs, var och en med sin egen enhet.

Priset per enhet är ingen konstant. Olika köpmodeller kan ge olika pris per enhet, och rabatter kan påverka kostnaden. Google Cloud tillämpar automatiskt sustained use-rabatt på upp till 30 procent på PAYG-användning över 25 procent av månaden (cloudpricecalculators.com). Räkna därför med ett pris per enhet per köpmodell.

Fyra grundrader är beräkning, lagring, operationer och utgående trafik. Kör du containrar tillkommer ECS/EKS som egna rader; skilj också AWS on-demand från Reserved Instances när du anger prisvillkor (swivrr.se). Spara köpmodellen bredvid priset, så att användning med olika prisvillkor inte räknas till samma pris.

Mät antalet enheter under en normalmånad. Priset per enhet hämtar du från leverantörens prislista.

Kalkylmall för förbrukningsbaserade molnkostnader

Månadskostnad = Σ (debiterbar förbrukning × pris per enhet) + övriga avgifter. Utgående trafik ingår som en förbrukningsrad, liksom beräkning, lagring, operationer, databaser, köade meddelanden och loggvolymer när de används. Övriga avgifter omfattar bara belopp som inte redan finns bland förbrukningsraderna, så att samma kostnad aldrig summeras igen.

Arbetsbladets beräkningskolumner är enhet, antal debiterbara enheter, pris per enhet och radkostnad. Lägg tjänst, konfiguration, prisvillkor och period bredvid dem, så att varje inmatning kan kopplas till rätt fakturapost. Radkostnaden är antal debiterbara enheter gånger pris per enhet, och månadskostnaden är summan av förbrukningsraderna och övriga avgiftsrader.

Fyll mallen genom att skriva faktureringsenheten, hämta mängden ur användningsunderlaget och välja priset för motsvarande tjänst och konfiguration. Om priset gäller ett paket av enheter behöver mängden uttryckas i samma paketstorlek innan du multiplicerar. Beräkna varje rad separat och summera förbrukningen. Lägg därefter till övriga avgifter som inte redan ingår i någon rad.

För Lambda är 1 miljon anrop per månad gratis, medan 500 miljoner anrop per månad med 256 MB minne kan landa på 5 000–10 000 kr per månad (swivrr.se). Lägg anrop och exekveringstid på skilda kalkylrader med sina respektive mängder och priser. Minnesinställningen ska följa konfigurationen som exekveringspriset gäller, och fri användning ska skiljas från debiterbar användning.

Ta antalet enheter från kostnadsrapporten och kontrollera det mot fakturan för samma period. Om underlagen visar olika mängder, reda ut vilken resurs eller tidsavgränsning som saknas innan du sätter ett pris.

Använd priset för den tjänst, enhet och konfiguration som raden gäller. Ett pris från en annan nivå eller resurstyp kan inte användas utan att först kontrollera att faktureringsvillkoren är desamma.

Om en fakturarad innehåller flera resurser, dela upp den med hjälp av användningsunderlaget i stället för att fördela totalsumman schablonmässigt. Behåll kopplingen mellan rad och enhet som leverantören fakturerar.

För ett litet företag med en enkel webbapp eller intern applikation brukar AWS-kostnaden landa på 1 000–8 000 kr per månad (swivrr.se). Det är summan av alla rader plus övriga avgifter, inte en enskild post.

Fyll i enheten i varje radrubrik: timmar, mängd per månad, antal anrop, volym. Då framgår det av kalkylen vilken mätning varje siffra kommer från.

För varje resurs behövs fakturerad enhet, debiterbar mängd under månaden och tillämpligt pris per enhet. Markera vilka uppgifter som är uppmätta och vilka som är antaganden, så att osäkerheten syns på rätt rad. Ändra mängderna när du bygger efterfrågescenarier, men ändra även priset om scenariot innebär en annan konfiguration eller andra prisvillkor.

Övriga avgifter får egna rader eftersom de inte alltid följer resursförbrukningens enheter. Kontrollera exempelvis stödavtal, hanterade tilläggstjänster, licenser per användare, backuper och loggarkivering mot fakturaunderlaget. Använd mängd gånger pris när avgiften är förbrukningsbaserad och det avtalade periodbeloppet när den är fast. Lägg bara beloppet i avgiftsdelen om det inte redan finns bland förbrukningsraderna.

Stäm av radbeloppet mot fakturans belopp för samma enhet och period. Om de inte stämmer, kontrollera först om raden omfattar andra avgifter eller ett annat prisvillkor innan du ändrar antalet.

Beräkning: fakturerad drifttid i timmar eller annan tidsenhet × pris per samma tidsenhet. Lagring: fakturerad mängd för månaden × pris per mängd och månad. Operationer: antal debiterbara anropsenheter × pris per anropsenhet. Utgående trafik: debiterbar volym × pris per volymenhet, uppdelad efter tillämpligt prisvillkor.

Kontrollera en rad baklänges genom att dela radbeloppet med den debiterbara mängden, om mängden inte är noll. Jämför kvoten med det pris som kalkylen använder för samma enhet. Om värdena skiljer sig kan orsaken vara mängden, enhetsomvandlingen, prisvillkoret eller att beloppet innehåller andra poster; kontrollera underlaget innan du ändrar en siffra.

Månadssumma = beräkningskostnad + lagringskostnad + operationskostnad + trafikkostnad + övriga radkostnader. Användningsrapporten ger mängd och enhet, medan prislistan eller avtalet ger priset för motsvarande tjänst och konfiguration. Fyll kategorierna med de beräknade radbeloppen, lägg till avgiftsraderna en gång och jämför både varje rad och totalsumman med fakturan för samma period.

Dataskikt och egressavgifter

Dataskikt prissätter efter hur snabbt data behöver vara tillgänglig. Varmt skikt är för data som läses och skrivs ofta, kallt för data som sällan används men måste kunna hämtas, och arkiverat för data som i praktiken ligger stilla och bara plockas fram undantagsvis.

Lagringsnivåer kan flyttas automatiskt eller enligt livscykelregler, så att data hamnar i billigare nivåer efter en period av inaktivitet. Kontrollera vilka funktioner och villkor som gäller hos din leverantör.

Utgående trafik mäts i volym, inte i tid eller i lagringsmängd. Den behöver därför hanteras som en separat post i kalkylen.

I månadskalkylen får varje lagringsskikt en egen volymrad med tillhörande lagringspris. Lägg läs- och skrivoperationer på separata rader med sina egna mängder och priser. Utgående trafik får också en egen rad, eftersom trafikvolymen inte är samma sak som den lagrade datamängden.

Om åtkomstmönstret ändras, se över vilken lagringsnivå som passar och uppdatera volymen på respektive rad. Håll kostnaden för att flytta data åtskild från den löpande lagringsposten.

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

Utgående datatrafik, egress, mäts i volym och måste räknas separat.

Dela trafikraderna efter destination och tjänst, eftersom egressprissättningen kan variera. Koppla varje uppmätt volym till rätt prisvillkor i stället för att använda ett gemensamt trafikpris. Om villkoret omfattar fri trafik, skilj den från den debiterbara mängden innan radkostnaden räknas fram.

Kontrollera kostnaden för att flytta data mellan skikten när ett dataset ändrar karaktär. Data som blivit sällan använd men ligger kvar i varmt skikt är en vanlig felkälla.

Prognos, skalning och uppföljning

Efterfrågan kan variera, så bygg kalkylen med låg-, normal- och högscenario. Ange vilka mängder som ändras i varje scenario och håll övriga antaganden tydliga.

Utgå från fakturor och användningsrapporter när du följer kostnaderna. Fördela varje resurs till det system eller team som använder den och jämför prognosen med utfallet per rad.

Använd AWS Cost Explorer och Cost Anomaly Detection för kostnadsuppföljning (swivrr.se). För Azure Virtual Desktop kan Microsoft Cost Management gruppera kostnader med Azure-taggar; funktionen är i förhandsversion (learn.microsoft.com). Google Cloud Pricing Calculator beräknar en månadsprognos utifrån tjänster, regioner och användningsvolymer, med listpriser i USD och uppdelning per tjänst (cloudpricecalculators.com). Samla fakturaunderlaget tillsammans med resursinventeringen.

Verktyg för right-sizing kan analysera faktisk resursanvändning och föreslå dimensionering. Jämför först kostnaden för en resurs med dess fakturerade mängd och prisvillkor.

Kontrollera att resurser i inventeringen fortfarande har en ägare och ett syfte. Ta bort poster ur prognosen först när de inte längre ingår i den faktiska användningen eller faktureringen.

Arbetssättet har 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. Då kan förbrukningen räknas om när efterfrågan ändras i stället för att gissas.

När pris och övriga villkor är oförändrade räknas scenarioraden som nytt antal debiterbara enheter gånger samma pris per enhet. Förbrukningsavvikelsen är då skillnaden mellan fakturerad och prognostiserad mängd, multiplicerad med priset. Om pris, konfiguration eller andra avgifter också har ändrats behöver de skillnaderna redovisas separat för att förklara hela kostnadsavvikelsen.

Rapportera avvikelsen rad för rad. Använd den enhet raden faktureras i, inte en klumpsumma för hela fakturan.

Därefter bygger du scenarier genom att skala drivarna upp och ner. Sist jämför du varje månad prognosen mot faktisk förbrukning på fakturan och justerar antaganden som inte höll.

Spara låg-, normal- och högscenario som separata beräkningar med samma faktureringsenheter och tidsperiod. Ange vilken efterfrågedrivare som ändrar mängden på varje rad och vilka prisvillkor som hålls oförändrade. När utfallet kommer, jämför både debiterbara mängder och radbelopp med respektive scenario. Då syns om skillnaden beror på efterfrågan, priset eller en kostnadspost som saknades i prognosen.

Lägg licensposten på rätt drivare. En användningsbaserad licens följer förbrukningen, medan en licens per användare följer antalet personer och inte rör sig när trafiken ökar.

Uppföljningen blir 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 vilken del av organisationen som driver kostnaden, och avvikelser upptäcks i tid. Sätt ett tröskelvärde per märkning där du vill bli varnad, så att oväntade ökningar upptäcks innan de blir en vana.

Uppföljningen kan också användas för ansvar. När fakturorna samlas och tilldelas rätt team syns det vilka som driver kostnad, och de som håller nere sitt resursutnyttjande kan i stället belönas. Då blir mätningen en del av arbetssättet och inte bara en rapport.

Bestäm vem som granskar varje kostnadsrad och vem som får agera på avvikelser. När ansvar kopplas till system, team eller projekt blir det lättare att följa upp vad som driver användningen.

Följ upp rad för rad mot fakturan. Jämför prognostiserat antal enheter med fakturerat antal enheter per rad, inte som klumpsumma.

Förbrukningsavvikelsen per rad är skillnaden mellan fakturerad och prognostiserad debiterbar mängd gånger samma pris per enhet. Den totala kostnadsavvikelsen är däremot fakturerat radbelopp minus prognostiserat radbelopp och kan också omfatta ändrade priser eller avgifter.

Fallgropar, licenser och extrakostnader

CGI konstaterar att molntjänster ofta prissätts efter användning. Förstå vad som ingår i priset och se upp för extra kostnader. Grundförbrukningen från räkneformeln är sällan hela fakturan. Extrakostnader uppstår typiskt för tilläggstjänster vid sidan av grundutförandet, stöd och hanterade tillägg samt trafik och lagring utanför det du först dimensionerade.

Små enhetskostnader kan bli betydande när mängden förbrukning ökar. Följ därför både priset per enhet och antalet fakturerade enheter, och använd fakturaunderlaget för att hitta den rad som driver förändringen.

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

En tredje källa till oväntade kostnader är kvarlämnade resurser: instanser som körs utan trafik, volymer utan koppling till system, gamla kopior och loggar som samlas utan gallring. Eftersom debiteringen följer faktisk användning kostar sådant 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 används.

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

Priset per enhet kan bero på prisvillkor och konfiguration, medan mängden ändras med användningen. Stäm av båda mot fakturan varje månad i stället för att utgå från att bara en av dem varierar.

Kör du Windows Server eller Oracle Database på EC2 tillkommer licenskostnader ovanpå instanspriset och kan ofta dubbla kostnaden (swivrr.se). Azure Hybrid Benefit låter dig återanvända befintliga Windows Server-licenser med Software Assurance eller Windows Server-prenumerationer (microsoft.com). För varje sådan licens täcker Azure kostnaden för operativsystemet, och du betalar bara för VM-beräkningskostnaderna.

Kontrollera varje månad att varje rad har enhet, antal enheter och pris per enhet. Då syns fel enhet innan den blir en felaktig prognos.

Radkostnaden är debiterbar mängd gånger tillämpligt pris per enhet. Skillnaden i mängd gånger samma pris förklarar förbrukningsavvikelsen bara när pris och övriga villkor är oförändrade. Kontrollera därför även prisändringar och avgiftsrader innan du använder mängdskillnaden som förklaring till hela skillnaden mot fakturan.