Molnfakturan avkodad – och sänkt

Av Weapp · Uppdaterad

Molnfakturan består i praktiken av fyra posttyper: beräkning (servrar som kör din kod), lagring (databaser och filer), datatrafik ut ur molnet och färdiga tjänster. Den växer sällan av ett dåligt beslut utan av glömda miljöer och överdimensionering. En kvartalsvis genomgång med rätt frågor håller den i schack.

En växande molnfaktura utan en tydlig orsak är en av de vanligaste källorna till obehag hos beställare. Hundratals rader med kryptiska tjänstenamn, en slutsumma som kryper uppåt, och ingen som riktigt kan förklara varför. Men bakom raderna finns bara en handfull poster. När du förstår dem kan du både budgetera driften och ifrågasätta den.

De fyra posterna du faktiskt betalar för

Nästan allt på fakturan går att sortera i fyra kategorier.

  • Beräkning. Servrar, containrar och funktioner som kör din kod. Nästan alltid den största posten. Priset styrs av hur mycket kapacitet du reserverar och hur många timmar den är igång – inte av hur mycket den faktiskt används.
  • Lagring. Databaser, filer och backuper. Billigt per gigabyte men växer stadigt, eftersom data sällan raderas. Data som läses ofta kostar mer än arkivdata som ligger orörd.
  • Datatrafik. Trafik in i molnet är i regel gratis, trafik ut prissätts per gigabyte. Det är den post som oftast förbryllar, särskilt för produkter som levererar filer, video eller stora API-svar.
  • Färdiga tjänster. Managerade databaser, köer, e-postutskick, AI-anrop, övervakning. Bekväma byggblock du slipper drifta själv – men var och en har sin egen prislapp, och de summerar sig.

Det mesta av det som känns obegripligt på fakturan är egentligen bara en av dessa fyra, uttryckt i leverantörens produktnamn.

Ett konkret exempel

Säg att du driftar en webbapplikation: ett par containrar bakom en lastbalanserare, en managerad databas, fillagring och övervakning. Beräkningen är din tyngsta post. Databasen kommer näst, som en färdig tjänst du betalar för att slippa sköta. Lagringen är liten men stadig. Så lanserar ni en exportfunktion som låter kunder ladda ner stora rapporter – och plötsligt syns datatrafiken tydligt, en post som knappt märktes förut. Ingen har gjort något fel. En ny funktion flyttade bara tyngdpunkten mellan posterna, och utan uppföljning märks det först på fakturan.

Var slöseriet nästan alltid göms

Molnkostnader ökar sällan för att någon fattat ett dåligt beslut, utan för att ingen fattat något beslut alls. De vanligaste läckorna ser likadana ut överallt:

  • Överdimensionering. Kapacitet som beställdes för en topp som aldrig kom och sedan aldrig krymptes.
  • Glömda miljöer. Testuppsättningar, gamla diskar och kopior som ingen stängt av. De fakturerar vidare varje månad, tyst.
  • Allt igång dygnet runt. Utvecklings- och testmiljöer som kör nätter och helger trots att ingen använder dem.
  • Överraskande trafik. En ny funktion som skickar mycket data ut, utan att någon räknat på vad det kostar.

Det fina är att inget av detta kräver en ombyggnad för att åtgärda. Det handlar om tillsyn, inte om arkitektur.

Frågorna att ställa vid kvartalsgenomgången

Gör en genomgång med leverantören varje kvartal och ha med de här frågorna. De flyttar samtalet från en obegriplig totalsumma till konkreta beslut.

  • Vilka är våra tre största poster den här månaden, och varför?
  • Vilka resurser är igång men i praktiken oanvända – kan de stängas eller krympas?
  • Kör alla miljöer dygnet runt, eller kan test och utveckling stängas utanför arbetstid?
  • Har vi förutsägbar baslast som skulle löna sig att reservera i stället för att betala per timme?
  • Vad drev den senaste ökningen, och var den väntad?
  • Finns glömda diskar, ögonblicksbilder eller gamla kopior vi kan gallra?

En leverantör som är mån om relationen svarar rakt på det här. Får du bara ett ryck på axlarna och ett “molnet är dyrt” är det i sig ett svar värt att notera.

Skilj driftgenomgång från arkitektur

En kvartalsgenomgång städar och trimmar det som redan finns. Den löser inte en uppsättning som är feldimensionerad från grunden – det är ett större arbete som hör hemma i arkitekturen, inte i månadsstädningen. Blandar man ihop de två väntar man sig ofta att en genomgång ska halvera en faktura som egentligen är hög av strukturella skäl. Vet du inte vilket fall som är ditt, är det just den frågan en genomgång ska besvara.

Vi på Weapp arbetar med cloud-arkitektur som en del av våra tjänster och hjälper gärna till att läsa av en faktura som stuckit iväg. Hör av dig så tittar vi på den tillsammans.

Vanliga frågor

Varför är datatrafik en egen post på molnfakturan?

Data in i molnet är nästan alltid gratis, men data ut prissätts per gigabyte. Det kallas egress och överraskar ofta, eftersom det inte syns i koden. En ny funktion som exporterar stora filer eller strömmar video kan därför dyka upp mer på fakturan än i utvecklingsarbetet.

Vad menas med överdimensionering i molnet?

Att du betalar för mer kapacitet än du använder. En server som beställdes för en trafiktopp som aldrig kom, och sedan aldrig krympte, kostar fullt pris dygnet runt. Molnet fakturerar reserverad kapacitet, inte faktisk användning, så outnyttjad kraft är ren förlust tills någon aktivt skalar ner den.

Hur ofta bör vi gå igenom molnkostnaderna?

Kvartalsvis är en rimlig takt för de flesta. Tillräckligt ofta för att fånga glömda miljöer och skenande trafik innan de hunnit kosta mycket, men inte så ofta att det blir en börda. Vid snabb tillväxt eller stora förändringar i produkten kan månadsvis uppföljning löna sig.

Vad är en rimlig molnkostnad för en mindre produkt?

En tidig produkt med måttlig trafik klarar sig ofta på några tusenlappar i månaden, ibland mindre med serverless. Det viktiga är inte en exakt siffra utan att kostnaden växer proportionerligt med användningen. En faktura som skenar utan att trafiken gör det är en varningssignal värd att gräva i.

Kan vi sänka fakturan utan att bygga om produkten?

Oftast, ja. Att krympa överdimensionerade servrar, stänga testmiljöer på natten, städa glömda resurser och reservera kapacitet för förutsägbar last kräver ingen omarkitektur. Den typen av åtgärder brukar kunna ta bort en betydande del av kostnaden utan att användarna märker något alls.