Molnets driftmodeller: Publikt, privat, hybrid & multi-cloud

Molnets driftmodeller definierar var din infrastruktur finns, vem som driver den och hur arbetsbelastningar flyttas mellan miljöer. De fyra primära modellerna — publikt, privat, hybrid och multi-cloud — medför skilda avvägningar vad gäller kostnad, compliance, operativ komplexitet och prestanda. Att välja rätt kräver analys på arbetsbelastningsnivå, inte en generell policy. Den här guiden bryter ner varje modell med de operativa detaljer och det EU-/Sverige-specifika compliance-perspektiv som generiska översikter utelämnar.

Viktiga insikter

• De fyra molnets driftmodeller — publikt, privat, hybrid och multi-cloud — medför var och en distinkta avvägningar vad gäller kostnad, kontroll, compliance och operativ komplexitet.
• Hybrid cloud är den mest utbredda modellen bland storföretag enligt Flexeras State of the Cloud, eftersom den låter organisationer placera arbetsbelastningar där de passar bäst.
• Organisationer inom EU — och specifikt Sverige — måste utvärdera valet av driftmodell utifrån NIS2 och GDPR:s krav på dataresidency.
• Multi-cloud är inte samma sak som hybrid cloud — att sammanblanda de två leder till arkitekturutbredning, duplicerade verktyg och okontrollerade kostnader.
• Att välja driftmodell är inte ett engångsbeslut; arbetsbelastningsklassificering och regelbunden omprövning förhindrar att man glider mot fel modell.

Vad är en molndriftmodell?

En molndriftmodell beskriver ägande, åtkomstomfattning och fysisk placering av molninfrastruktur. Den svarar på tre frågor: Vem äger hårdvaran? Vem kan nå miljön? Var befinner sig data fysiskt?

Detta skiljer sig från molntjänstmodeller (IaaS, PaaS, SaaS), som beskriver abstraktionsnivån — vad leverantören hanterar kontra vad du hanterar. En driftmodell handlar om var och hur; en tjänstmodell handlar om vad. Du kan köra IaaS i ett privat moln eller konsumera SaaS som levereras genom en hybridarkitektur. De två taxonomierna är ortogonala.

NIST SP 800-145-definitionen identifierar fyra driftmodeller: publikt, privat, hybrid och community. Branschen har sedan dess lagt till multi-cloud som en de facto femte modell, eftersom dess operativa egenskaper skiljer sig väsentligt från hybrid. Vi täcker alla fem nedan.

Publikt moln

Hur det fungerar

Publik molninfrastruktur ägs och drivs av en tredjepartsleverantör — AWS, Microsoft Azure, Google Cloud Platform (GCP) eller andra — och delas mellan flera klienter. Du konsumerar resurser on-demand, betalar per användning och leverantören hanterar hårdvaruanskaffning, fysisk säkerhet och grundläggande plattformshantering.

De stora leverantörerna driver regioner globalt. AWS har regioner i Stockholm (eu-north-1), Frankfurt (eu-central-1) och Mumbai (ap-south-1). Azure driver Sweden Central, Germany West Central och Central India. GCP erbjuder europe-north1 (Finland) och asia-south1 (Mumbai). Regionval är avgörande för latens, dataresidency och prissättning — det är inte en eftertanke.

När publikt moln är rätt val

• Variabla eller oförutsägbara arbetsbelastningar: autoskalning eliminerar gissningar kring kapacitetsplanering. Du betalar för det du använder, inte det du eventuellt behöver.
• Startups och snabbt iterande team: ingen CapEx upp front, omedelbar provisionering. Leverera först, optimera sedan.
• Tillståndslösa eller molnbaserade applikationer: containeriserade mikrotjänster, serverlösa funktioner (AWS Lambda, Azure Functions, Cloud Run) och hanterade databaser (RDS, Cloud SQL) är byggda för publika molnprimitiver.
• Utvecklings-/testmiljöer: starta, kör tester, riv ner. Reserverad kapacitet är meningslöst här.

Där publikt moln brister

• Krav på datasuveränitet: GDPR Artikel 44 begränsar överföring av personuppgifter utanför EES om inte adekvata skyddsåtgärder finns. Att använda en USA-baserad leverantörs EU-region är generellt acceptabelt, men Schrems II-implikationerna och den pågående utvecklingen kring EU–US Data Privacy Framework kräver juridisk granskning — inte bara ett regionval. IMY (Integritetsskyddsmyndigheten) har varit aktiva i tillsynen av molnbaserade tjänster i Sverige, och deras vägledning bör beaktas.
• Stabila arbetsbelastningar med hög utnyttjandegrad: en VM som körs på 80 %+ dygnet runt i åratal är nästan alltid billigare lokalt eller i privat moln. Reserved Instances och Savings Plans (som typiskt erbjuder 30–60 % rabatt jämfört med on-demand-priser, enligt AWS egen dokumentation) minskar gapet men eliminerar det inte för verkligt statiska laster.
• Hårt reglerade miljöer: vissa finansiella tillsynsmyndigheter och försvarsmyndigheter kräver fysisk isolering som logisk klientseparation i publikt moln inte uppfyller.

Managerade molntjänster

Privat moln

Hur det fungerar

Privat moln dedikerar infrastruktur till en enskild organisation. Det kan köras lokalt i ditt eget datacenter eller hostas av en tredje part (hostat privat moln). Det definierande kännetecknet är enkel klientskap (single-tenancy) och direkt kontroll över hela infrastrukturstacken.

Moderna privata moln använder samma orkestreringsteknik som publika leverantörer. VMware Cloud Foundation, OpenStack, Nutanix och Azure Stack HCI tillhandahåller IaaS-liknande förbrukningsmodeller internt. Kubernetes-distributioner som Red Hat OpenShift eller Rancher lägger till containerorkestrering ovanpå.

När privat moln är motiverat

• Strikta compliance-regimer: finansiella institutioner under nationella bankregler (exempelvis Finansinspektionen i Sverige) ställer ibland krav som förutsätter verifierbar fysisk isolering. Vårdorganisationer som hanterar patientdata inom EU föredrar ofta privat infrastruktur för att förenkla GDPR:s ansvarskedjor.
• Förutsägbar, högdensitetsberäkning: HPC-arbetsbelastningar, storskalig batchbearbetning eller ML-träning på dedikerade GPU-kluster kan vara mer kostnadseffektivt på egen hårdvara när utnyttjandegraden förblir hög.
• Beroenden av äldre applikationer: arbetsbelastningar nära stordatorer eller applikationer med hårdkodade IP-beroenden, protokoll utanför TCP/IP eller licensiering knuten till fysiska kärnor kan ofta inte flyttas till publikt moln utan en omskrivning.

De verkliga kostnader som underskattas

Privat moln är inte "gratis för att vi redan äger servrarna." Opsios Cloud FinOps-uppdrag avslöjar konsekvent dolda kostnader: elkraft och kylning för anläggningen, hårdvaruförnyelsecykler (typiskt 3–5 år), personal för att hantera firmware, patchar och fysisk säkerhet, plus alternativkostnaden av att ingenjörer ägnar sig åt odifferentierat tungt arbete istället för att bygga produktfunktioner.

Den ärliga kalkylen: om din utnyttjandegrad i snitt ligger under 60 % betalar du sannolikt för mycket för privat moln. Om den konsekvent ligger över 75 % sparar du sannolikt pengar jämfört med publika molnets on-demand-prissättning — men du behöver räkna in agilitetskostnaden av upphandlingens ledtider.

Hybrid cloud

Hur det fungerar

Hybrid cloud kopplar samman privat infrastruktur (lokal eller hostad) med en eller flera publika molnmiljöer genom orkestrering, nätverk och ofta delade identitetslager. Den avgörande skillnaden mot att helt enkelt använda båda är integration: arbetsbelastningar, data och hanteringsplan opererar koordinerat över miljöerna.

Kärnteknologier som möjliggör hybrid cloud:

Varför hybrid dominerar bland storföretag

Enligt Flexeras State of the Cloud har hybrid konsekvent varit den dominerande företagsstrategin under flera år i rad. Orsakerna är praktiska, inte teoretiska:

1. Migrering sker gradvis: inget storföretag lyfter allt till publikt moln i ett steg. Hybrid är den naturliga övergångsarkitekturen under alla Molnmigrering-program.

2. Flexibilitet i arbetsbelastningsplacering: känslig data stannar på privat infrastruktur medan kundnära applikationer skalar i publikt moln. Ett svenskt e-handelsföretag kan exempelvis behålla personuppgifter i en Stockholmsbaserad privat miljö medan CDN- och beräkningslagret körs på AWS eu-north-1.

3. Burst-kapacitet: kör basberäkning lokalt och skala ut till publikt moln under belastningstoppar — Black Friday-trafik, bokslutsbearbetning, säsongsmässig efterfrågan.

4. DR och resiliens: använd publikt moln som katastrofåterställningsmål för lokala arbetsbelastningar. AWS Elastic Disaster Recovery, Azure Site Recovery och liknande tjänster gör detta operativt genomförbart.

Operativa utmaningar med hybrid cloud

Hybrid är inte "det bästa av två världar" utan ansträngning. Utifrån Opsios dygnet-runt-NOC-verksamhet som hanterar hybridmiljöer är de återkommande smärtpunkterna:

• Nätverkskomplexitet: latensberoende arbetsbelastningar uppdelade över miljöer skapar felsökningsmardrömmar. Om din databas är lokal och din applikation i publikt moln traverserar varje fråga sammankopplingen. Mät detta innan du arkitekturerar det.
• Inkonsekvent säkerhetsstatus: brandväggsregler lokalt, security groups i AWS, NSG:er i Azure — tre olika policyspråk som beskriver samma avsikt. Avdrift är oundviklig utan Infrastructure as Code (Terraform, Pulumi) och kontinuerlig policyvalidering (OPA, Checkov).
• Fragmenterad övervakning: en alert utlöses i CloudWatch, en annan i ditt lokala Zabbix, och en tredje i Datadog. Utan ett enhetligt observerbarhetslager slösar ditt SOC-team tid på att korrelera mellan konsoler istället för att lösa incidenter.

Molnsäkerhet

Multi-cloud

Multi-cloud kontra hybrid: en nödvändig distinktion

Dessa begrepp används ofta omväxlande. Det bör de inte. Hybrid innebär att man blandar privat och publik infrastruktur. Multi-cloud innebär att man använder två eller flera publika molnleverantörer. En organisation som använder AWS och Azure är multi-cloud. En organisation som använder AWS och ett lokalt VMware-kluster är hybrid. En organisation som gör båda är hybrid multi-cloud — och att hantera det är det operativt mest komplexa scenariot inom molninfrastruktur.

Medveten kontra oavsiktlig multi-cloud

Denna distinktion är viktigare än något arkitekturdiagram. De flesta multi-cloud-miljöer är oavsiktliga: produktteamet valde AWS, datateamet valde GCP för BigQuery, och företaget förvärvade ett bolag som kör allt på Azure. Ingen planerade det; det bara hände.

Medveten multi-cloud har specifika motiveringar:

• Regulatoriska krav: vissa EU-finansiella tillsynsmyndigheter kräver koncentrationsriskreducering — att man inte är beroende av en enda molnleverantör för kritiska tjänster. NIS2 Artikel 21 kräver "multi-vendor ICT-strategier" i vissa tolkningar för väsentliga entiteter.
• Best-of-breed-tjänster: GCP BigQuery för analys, AWS för generell beräkning, Azure för Microsoft 365-integration och Active Directory. Detta är försvarbart när kostnaden för korsmoln-nätverk och operativ overhead motiveras av tjänstefördelen.
• Geografisk täckning: ingen enskild leverantör har regioner överallt. En organisation som behöver lokal beräkning i ett land där bara en leverantör har en region blir multi-cloud av nödvändighet.

Den operativa skatten av multi-cloud

Genom Opsios Managerad DevOps-verksamhet över multi-cloud-miljöer ser vi den operativa skatten tydligt:

• IAM-divergens: AWS IAM, Azure Entra ID och GCP IAM använder olika behörighetsmodeller, olika förtroendekedjesmekanismer och olika granskningsloggformat. Att bygga ett enhetligt åtkomststyrningslager kräver betydande verktygsinvestering.
• Fragmenterad kostnadssynlighet: AWS Cost Explorer, Azure Cost Management och GCP Billing Export levererar var och en data i olika scheman. Utan en Cloud FinOps-plattform (Apptio Cloudability, Vantage eller liknande) kan du inte besvara "vad kostar det att köra den här produkten per månad?" tvärs leverantörerna.
• Kompetensspridning: varje molnleverantör har tusentals tjänster. Djup expertis i alla tre är sällsynt. Team som sprids tunt över leverantörer bemästrar ingen.

Den ärliga rekommendationen: eftersträva inte multi-cloud som strategi i sig. Eftersträva det bara när du har en specifik, försvarbar anledning för varje ytterligare leverantör, och budgeterar för den operativa overhead det skapar.

Community cloud

Community cloud — delad infrastruktur bland organisationer med gemensamma krav — är den minst diskuterade modellen men förblir relevant i specifika sektorer. Exempel inkluderar statliga community-moln (AWS GovCloud, Azure Government), forskningsgemenskaper (GÉANT i Europa, SUNET i Sverige) och branschkonsortier som delar regelefterlevande infrastruktur.

I praktiken är community cloud arkitektoniskt likt ett privat moln med delad klientskap bland granskade organisationer. Dess relevans är smal men reell: om du är en svensk kommun som delar infrastruktur med andra kommuner genom SKR (Sveriges Kommuner och Regioner), befinner du dig i community cloud.

Jämförelse av molndriftmodeller

Hur du väljer rätt molndriftmodell

Att välja driftmodell är ett beslut på arbetsbelastningsnivå, inte på organisationsnivå. Olika applikationer inom samma företag kan legitimt tillhöra olika modeller. Här är det beslutsramverk som Opsio tillämpar:

Steg 1: Klassificera dina arbetsbelastningar

För varje arbetsbelastning, bedöm:

• Datakänslighet: behandlar den personuppgifter under GDPR, finansiell data under bankregler, eller hälsodata under nationella hälsolagstiftningar (exempelvis Patientdatalagen)? Under NIS2 måste väsentliga och viktiga entiteter i 18 sektorer implementera riskhanteringsåtgärder som kan begränsa driftsättningsalternativ.
• Prestandaprofil: latensberoende (behöver vara nära användare eller andra system), genomströmningsintensiv (behöver hög bandbredd) eller beräkningsintensiv (behöver specifik hårdvara som GPU:er)?
• Efterfrågevariabilitet: stabil, säsongsbetonade toppar eller oförutsägbara spikar?
• Integrationsberoenden: är arbetsbelastningen beroende av lokala system (databaser, stordatorer, äldre API:er)?

Steg 2: Kartlägg begränsningar

• Regulatoriska: GDPR:s dataresidency-krav, Schrems II-bedömningar, sektorspecifika regler (PSD2 för betalningar, MiFID II för handel). Finansinspektionens vägledning om molntjänster inom finanssektorn. NIS2-direktivets krav som implementerats i svensk lag.
• Finansiella: CapEx-budgettillgänglighet, befintlig hårdvara med kvarvarande nyttjandeperiod, avtalade åtaganden med leverantörer.
• Organisatoriska: teamets kompetens, befintliga verktyg, leverantörsrelationer.

Steg 3: Välj per arbetsbelastning, aggregera sedan

När varje arbetsbelastning har en målmodell bestämmer aggregatet din organisationsmodell. Om varje arbetsbelastning riktar sig mot publikt moln är du publikt-moln-enbart. Om arbetsbelastningar spänner över privat och publikt är du hybrid. Om de spänner över flera publika leverantörer är du multi-cloud.

Steg 4: Ompröva regelbundet

Val av molndriftmodell är inte ett engångsbeslut. Arbetsbelastningarnas karaktär förändras. Prissättning förändras. Regulatoriska förutsättningar förändras. Opsio rekommenderar en formell omprövning minst årligen, i linje med avtalsförnyelsecykler och compliance-revisionsscheman.

Compliance-överväganden för EU och Sverige

Europeiska unionen och Sverige

GDPR: Artikel 44 begränsar överföring av personuppgifter utanför EES. Val av driftmodell måste säkerställa att dataresidency-kontroller är arkitekturellt förankrade, inte bara policybaserade. AWS, Azure och GCP erbjuder samtliga åtaganden om dataresidency i EU-regioner, men konfigurationer som cross-region-replikering, CDN-caching och supportåtkomstverktyg kan oavsiktligt överföra data utanför avsedda gränser. IMY har genomfört tillsynsinsatser kring just detta — bland annat gällande användning av molnbaserade verktyg som överför data till tredjeland.

NIS2-direktivet: tillämpligt sedan oktober 2024, NIS2 kräver att väsentliga och viktiga entiteter implementerar lämpliga tekniska och organisatoriska åtgärder för cybersäkerhetsriskhantering. Detta omfattar försörjningskedjesäkerhet — din molnleverantör är en del av din försörjningskedja. Val av driftmodell bör dokumentera hur varje modell uppfyller NIS2 Artikel 21:s krav. I Sverige implementeras direktivet genom MSB:s (Myndigheten för samhällsskydd och beredskap) föreskrifter.

Molnsuveränitet: Sveriges ställning kring suveräna molntjänster utvecklas. Initiativ som "Swedish Government Cloud" diskuteras, och svenska myndigheter utvärderar i allt högre grad om publika molnleverantörer kan uppfylla kraven för hantering av känslig offentlig information. Tysklands BSI C5-attestering och Frankrikes SecNumCloud-märkning ställer ytterligare krav på molnleverantörer. Organisationer som verkar i dessa marknader kan behöva leverantörer med specifika nationella certifieringar, vilket kan begränsa alternativen för driftmodell.

Molnsäkerhet

Vad Opsio ser: operativa mönster över driftmodeller

Genom att driva dygnet-runt-SOC och NOC-verksamhet över kundmiljöer som spänner över alla driftmodeller ser vi flera återkommande mönster:

Hybridmiljöer genererar flest incidenter från nätverksgränsfel. Sammankopplingen mellan lokalt och publikt moln (Direct Connect, ExpressRoute) är en enskild felkälla som team underövervakar. När den försämras uppstår symtom som applikationslångsamhet snarare än nätverksfel, vilket leder till felriktad felsökning.

Kostnadsfördelning i multi-cloud är den främsta FinOps-utmaningen. Organisationer som kör arbetsbelastningar över två eller fler leverantörer har konsekvent svårt att besvara grundläggande frågor som "vad kostar den här applikationen per månad?" utan dedikerade verktyg och taggningsdisciplin.

Privata molnmiljöer avviker snabbast från säkerhetsbaslinjer. Publika molnleverantörer uppdaterar kontinuerligt standardkonfigurationer (kryptering-i-vila som standard, TLS-minimikrav, blockering av publik åtkomst). Privat molninfrastruktur behåller den konfiguration som sattes vid driftsättning om den inte aktivt underhålls.

Organisationer som enbart kör publikt moln är snabbast på att ta till sig nya funktioner men ackumulerar även mest oanvända resurser. Lättheten att provisionera skapar spridning. Flexeras State of the Cloud har konsekvent identifierat molnslöseri som ett toppproblem, och renodlade publika molnmiljöer är där Opsios FinOps-praktik hittar störst optimeringspotential.

Vanliga frågor

Vilka är de fyra molndriftmodellerna?

De fyra modellerna definierade av NIST SP 800-145 är publikt moln (delad infrastruktur som drivs av en leverantör som AWS, Azure eller GCP), privat moln (dedikerad infrastruktur för en enskild organisation), hybrid cloud (arbetsbelastningar som spänner över både publika och privata miljöer med orkestrering mellan dem) samt community cloud (delad infrastruktur bland organisationer med gemensamma krav, exempelvis myndigheter). Multi-cloud — att använda flera publika molnleverantörer — behandlas ofta som en femte modell i praktiken.

Vilken molndriftmodell är vanligast?

Hybrid cloud är den vanligaste modellen bland storföretag. Flexeras State of the Cloud-rapport har konsekvent visat att en majoritet av företagen eftersträvar en hybridstrategi, där man kombinerar lokala resurser eller privat moln med en eller flera publika moln. Renodlade publika molndriftsättningar är vanligare bland startups och mindre organisationer som saknar äldre infrastruktur som kräver lokal integration.

Vad är IaaS, PaaS och SaaS och hur förhåller de sig till driftmodeller?

IaaS (Infrastructure as a Service), PaaS (Platform as a Service) och SaaS (Software as a Service) är molntjänstmodeller — de beskriver abstraktionsnivån och vad leverantören hanterar kontra vad du hanterar. Driftmodeller beskriver var och hur infrastrukturen hostas. De två är oberoende av varandra: du kan köra IaaS i ett privat moln, konsumera PaaS i ett publikt moln, eller använda SaaS som levereras genom en hybridarkitektur. Att välja driftmodell låser dig inte till en specifik tjänstmodell.

Är AWS ett publikt, privat eller hybrid moln?

AWS är primärt en publik molnleverantör, men stöder alla driftmodeller. AWS Outposts placerar AWS-hanterad infrastruktur i ditt lokala datacenter för privata eller hybrida driftsättningar. AWS GovCloud erbjuder isolerade regioner för reglerade arbetsbelastningar. AWS Local Zones utökar beräkningskapacitet närmare slutanvändare. De flesta organisationer använder AWS som den publika molnkomponenten i en bredare hybrid- eller multi-cloud-strategi.

Är hybrid cloud billigare än privat moln?

Kostnaden beror helt på arbetsbelastningsprofilen. Hybrid cloud minskar vanligtvis kostnaderna för variabla arbetsbelastningar eftersom du kan skala ut till publikt moln istället för att överdimensionera privat infrastruktur för toppbelastning. Hybrid medför dock nätverkskostnader (sammankopplingsavgifter, dataöverföringsavgifter), integrationskomplexitet och ytterligare verktygsoverhead. För stabila arbetsbelastningar med konsekvent hög utnyttjandegrad kan privat moln vara mer kostnadseffektivt per beräkningsenhet. Det rigorösa tillvägagångssättet: modellera TCO för dina specifika arbetsbelastningar i båda modellerna innan du beslutar.