Molntjänster: så beräknar du kostnad för lagring och datauttag

Kostnadsbilden för molnlagring och datauttag i Sverige

Över 90 procent av svenska företag använder molntjänster i någon form, enligt Techgruppens jämförelse från januari 2025. Samma genomgång anger marknadsandelarna till AWS 32 procent, Microsoft Azure 23 procent och Google Cloud 10 procent. Further beskriver AWS som störst, följt av Azure och därefter Google Cloud. Geografin skiljer sig: Azure har datacenter i Stockholm (Sweden Central, sedan 2021), AWS har haft tre tillgänglighetszoner i Stockholm sedan 2018, och Google Cloud nås från en Finland-region med cirka 5 ms latens till Sverige enligt Techgruppen. Regionvalet är därför både en prestanda- och kostnadsfråga.

Lagrings- och datauttagskostnader är ingen fast prislista utan en funktion av volym, åtkomstmönster och varifrån data hämtas. Techgruppen sammanfattar det som att faktiska kostnader varierar kraftigt beroende på användningsmönster, region och rabattavtal. Kalkylen har därför fyra rattar: val av leverantör, val av region, hur data klassificeras och vilka rabattmodeller ni binder er till.

Så beräknar du lagringskostnaden steg för steg

Steg 1 är inventering: hur många TB data finns i dag, vilka system äger dem och hur snabbt volymen växer. Steg 2 är klassificering. Techgruppens migreringsguide delar in data i känslig, affärskritisk och arkiv, och indelningen styr vilken lagringsnivå varje dataset ska ligga i. Steg 3 är att matcha nivå mot åtkomstmönster: data som läses dagligen hör hemma i varm lagring, medan arkivlagring enligt Further är avsedd för stora mängder vilande data som inte behöver vara direkt åtkomliga. Exemplet som nämns är patientjournaler som enligt lag måste sparas i flera år. Further noterar också att Azures arkivlagring krypterar vilande data automatiskt, och att Amazon S3 beskrivs som en branschstandard som används för allt från små datamängder till applikationer, webbplatser, IoT-enheter, mobilappar och backuper.

Steg 4 är själva uträkningen. Bygg den som summan av fyra poster: kapacitet × pris per GB och månad för respektive nivå, tillgänglighets- eller redundansnivå (hur många kopior och i hur många zoner data lagras), antal transaktioner (läsningar och skrivningar) och backup som egen post. Utgå från er egen volym – i Techgruppens exempelmiljö för 10 användare antas 1 TB lagring, vilket ger en rimlig storleksordning att skala från. Bestäm också var backupen hamnar: i samma nivå och region som primärdata blir den billigare men skyddar sämre; i en annan region eller nivå påverkar den både lagrings- och uttagskostnaden.

Lägg till komponenter som ofta glöms: serverlös eller betal-per-körning-debitering för funktioner som körs mot lagringen (Further beskriver Azures modell där man debiteras när funktioner körs), samt kostnaden för den dagliga driften kring lagringen – behörigheter, nyckelhantering och uppföljning. Dessa syns sällan som en rad i prislistan men är en del av den faktiska månadskostnaden.

Datauttag och nätverksprestanda: det du behöver mäta

Datautgående trafik – data som lämnar molnmiljön – prissätts normalt per volym, medan inkommande trafik vanligen är avgiftsfri. Det är alltså flödet ut ur miljön du behöver mäta och prissätta, inte mängden data du lagrar. Destinationen avgör priset: trafik mellan zoner eller regioner hos samma leverantör, trafik till en annan leverantör och trafik ut till internet hanteras som separata flöden med egna villkor. Kontrollera därför leverantörens villkor för datautgående trafik per destination innan du lägger in posten i kalkylen.

Mät tre saker: volym (GB per månad), frekvens (hur ofta flödet sker) och mönster (kontinuerlig replikering eller enstaka återläsning). Ett backupjobb som kopierar hela datasetet varje natt ger en helt annan uttagsvolym än en arkivpost som läses ut en gång per år. Sätt taggar på resurserna per tjänst eller avdelning och logga utgående trafik per källa och destination, så att volymerna går att följa upp mot prognosen i stället för att bli en överraskning på fakturan.

Nätverksprestanda hänger ihop med regionvalet: data nära dem som använder den minskar latensen och gör uttagsmönstret mer förutsägbart. Multi-cloud ökar samtidigt antalet flöden att hålla reda på – fler miljöer betyder fler gränssnitt där data rör sig och därmed fler rader i uttagskalkylen.

Pay-as-you-go, reservationer och rabatter – så räknar du hem kalkylen

Grundmodellen är pay-as-you-go: ni betalar för faktisk förbrukning utan bindning. Opsio beskriver pay-as-you-go, reservationer och FinOps som centrala delar av TCO. Techgruppen listar de vanligaste rabattmöjligheterna per leverantör: Microsofts Hybrid Benefit ger 40 procent rabatt med befintliga licenser, AWS Spot Instances upp till 90 procent rabatt och Google Clouds Committed Use Discounts 57 procent rabatt.

Avvägningen står mellan förutsägbarhet och pris. Reservationer och åtaganden ger lägre styckpris men binder kapacitet under avtalstiden, vilket blir fel om arbetslasten flyttar, arkitekturen ändras eller verksamheten växer i en annan region än den ni reserverade. Pay-as-you-go passar varierande eller ännu okända arbetslaster men saknar rabatten som ett åtagande ger. Spot-kapacitet är en rabattmodell enligt Techgruppen – kontrollera villkoren för er arbetslast innan ni räknar in den i kalkylen.

Räkna så här: ställ upp månadskostnaden med och utan rabatt över hela avtalstiden, inklusive risken att behovet ändras under perioden. Jämför besparingen mot vad flexibiliteten är värd för er. Kan ni förutse arbetslasten ett år framåt är ett åtagande en ren besparing; kan ni inte det är pay-as-you-go ett skydd mot att betala för kapacitet ni inte använder.

Rabattmodeller hos stora molnleverantörer (2025)

Från månadskostnad till TCO med FinOps

En TCO-modell ska innehålla fler poster än lagring och uttag: compute, nätverk, säkerhet och åtkomst (IAM och kryptering), löpande drift samt engångskostnaden för migreringen. Opsio sammanfattar att pay-as-you-go, reservationer och FinOps är centrala för TCO, att säkerhet och åtkomst är grundläggande och att prestanda för compute, lagring och nätverk avgör användarupplevelsen. Det är samma fyra områden som ska ha en rad var i kalkylen.

Migreringen är en projektkostnad som går att storleksbestämma. Techgruppens steg-för-steg-guide delar in arbetet i fas 1 planering (2–4 veckor: inventera infrastruktur och applikationer, identifiera beroenden mellan system, klassificera data som känslig, affärskritisk eller arkiv, välja lift-and-shift eller re-platforming, ta fram tidplan och ansvarsfördelning), fas 2 pilot (2–4 veckor: migrera icke-kritisk arbetslast först, validera prestanda, säkerhet och kostnader, dokumentera lärdomar och justera planen) och fas 3 produktion (4–12 veckor). Lägg in dessa veckor som intern kostnad, inte som en fotnot.

FinOps handlar om löpande uppföljning snarare än ett engångsprojekt: faktisk förbrukning ställs mot prognos varje månad, varje post har en tagg och en ägare, och avvikelser åtgärdas innan de blir en vana. Koppla uppföljningen till säkerhetsarbetet – felkonfigurerad lagringsnivå, glömda resurser eller data i fel region är samtidigt kostnads- och säkerhetsproblem, så samma genomgång kan täcka båda.

Exempel: kostnad för en svensk företagsmiljö

Techgruppens jämförelse räknar på en exempelmiljö med 10 användare, 1 TB lagring, 2 servrar och backup. Månadskostnaden anges till 8 000–12 000 kr för Azure, 7 000–11 000 kr för AWS och 6 500–10 000 kr för Google Cloud. Intervallen är ett spann att kalibrera mot, inte ett pris.

Det som flyttar slutsumman mest är region, hur stor andel av 1 TB som kan flyttas till arkivnivå i stället för varm lagring och hur mycket data som lämnar miljön varje månad. Bygg kalkylen som en rad per post – compute, lagring per nivå, backup, datauttag, nätverk, säkerhet och drift – med ett uttalat antagande om volym och frekvens bakom varje rad. Kör sedan en känslighetsanalys på de två eller tre största posterna: ändras antagandet om uttagsvolym eller arkivandel, hur mycket rör sig månadskostnaden?

Exempel på månadskostnader för en svensk företagsmiljö (10 användare, 1 TB lagring)

Vanliga fallgropar och så undviker du dem

Arkivlagring är enligt Further avsedd för stora mängder vilande data som inte behöver vara direkt åtkomliga. Data som läses ofta hör därför inte hemma i arkivnivån. Kontrollera alltid villkoren för återläsning och hur länge data måste ligga kvar i nivån innan du flyttar stora volymer dit för att sänka GB-priset – en felplacerad arkivpost kan bli dyrare än varm lagring.

Säkerhet och kostnad styrs i hög grad av er egen konfiguration. Computer Sweden citerar Andy Ellis med att kundens konfiguration av molntjänsten är kritisk för applikationssäkerheten, och beskriver samtidigt att fler moln gör den delade ansvarsmodellen "exponentiellt svårare" att hantera. Har ni flera leverantörer behöver ansvarsfördelningen för behörigheter, kryptering och nätverk vara dokumenterad per miljö, annars blir både risken och fakturan svår att förklara.

För svenska myndigheter och kommuner lyfter Techgruppen fram CLOUD Act-problematiken, specifika svenska sekretessregler och Schrems II-domens implikationer, och noterar att Azure eller svenska moln som Safespring och Binero ofta rekommenderas. Alla tre stora leverantörer erbjuder enligt samma källa datahemvist inom EU, databehandlingsavtal som standard, standardavtalsklausuler för tredjelandsöverföringar samt kryptering i vila och transit – men det är er dataplacering och era avtal som avgör om kraven är uppfyllda.

Tre praktiska råd: bygg kalkylen på uppmätta uttagsvolymer och verklig arkivandel i stället för på prislistor, sätt taggar per tjänst och kostnadsställe från dag ett så att månadsuppföljningen går att göra, och pilotera icke-kritisk arbetslast i 2–4 veckor enligt Techgruppens fasmodell och validera prestanda, säkerhet och kostnader innan produktionsmiljön migreras.