Cloud-implementeringsmodeller: Public, Private, Hybrid & Multi-Cloud

Cloud-implementeringsmodeller definerer, hvor din infrastruktur befinder sig, hvem der driver den, og hvordan workloads bevæger sig mellem miljøer. De fire primære modeller — public, private, hybrid og multi-cloud — medfører hver især forskellige trade-offs inden for omkostninger, compliance, operationel kompleksitet og ydeevne. Det rette valg kræver analyse på workload-niveau, ikke en generel politik. Denne guide gennemgår hver model med de operationelle detaljer og EU/dansk compliance-kontekst, som generiske oversigter springer over.

Vigtigste pointer

• De fire cloud-implementeringsmodeller — public, private, hybrid og multi-cloud — indebærer hver især forskellige trade-offs inden for omkostninger, kontrol, compliance og operationel kompleksitet.
• Hybrid cloud er den mest udbredte model blandt virksomheder ifølge Flexeras State of the Cloud, fordi den giver organisationer mulighed for at placere workloads der, hvor de passer bedst.
• Danske og øvrige EU-organisationer skal vurdere cloud-implementeringsvalg i lyset af NIS2 og GDPR's krav til dataopbevaring; Datatilsynets vejledninger stiller yderligere krav til behandling af personoplysninger i cloud-miljøer.
• Multi-cloud er ikke det samme som hybrid cloud — at sammenblande de to fører til arkitekturspredning, duplikeret tooling og ukontrollerede omkostninger.
• Valg af implementeringsmodel er ikke en engangsbeslutning; workload-klassificering og periodisk revurdering forhindrer drift mod den forkerte model.

Hvad er en cloud-implementeringsmodel?

En cloud-implementeringsmodel beskriver ejerskab, adgangsomfang og fysisk placering af cloud-infrastruktur. Den besvarer tre spørgsmål: Hvem ejer hardwaren? Hvem har adgang til miljøet? Hvor befinder data sig fysisk?

Dette adskiller sig fra cloud-servicemodeller (IaaS, PaaS, SaaS), som beskriver abstraktionslaget — hvad udbyderen administrerer kontra hvad du administrerer. En implementeringsmodel handler om hvor og hvordan; en servicemodel handler om hvad. Du kan køre IaaS på en private cloud eller forbruge SaaS leveret gennem en hybrid-arkitektur. De to taksonomier er ortogonale.

NIST SP 800-145-definitionen identificerer fire implementeringsmodeller: public, private, hybrid og community. Branchen har siden tilføjet multi-cloud som en de facto femte model, fordi dens operationelle karakteristika adskiller sig væsentligt fra hybrid. Vi dækker alle fem herunder.

Public Cloud

Sådan fungerer det

Public cloud-infrastruktur ejes og drives af en tredjepartsudbyder — AWS, Microsoft Azure, Google Cloud Platform (GCP) eller andre — og deles på tværs af flere lejere (tenants). Du forbruger ressourcer on-demand, betaler pr. forbrug, og udbyderen håndterer hardware-anskaffelse, fysisk sikkerhed og basal platform-administration.

De store udbydere driver regioner globalt. AWS har regioner i Stockholm (eu-north-1), Frankfurt (eu-central-1) og Mumbai (ap-south-1). Azure opererer i Sweden Central, Germany West Central og West Europe. GCP tilbyder europe-north1 (Finland) og asia-south1 (Mumbai). For danske organisationer er eu-north-1 (Stockholm) og West Europe typisk de mest relevante regioner. Regionsvalg er kritisk for latenstid, dataopbevaring og prissætning — det er ikke en eftertanke.

Hvornår public cloud er det rigtige valg

• Variable eller uforudsigelige workloads: auto-scaling eliminerer gætterier ved kapacitetsplanlægning. Du betaler for det, du bruger, ikke for det, du måske får brug for.
• Startups og teams med hurtigt iterationstempo: nul CapEx på forhånd, øjeblikkelig provisionering. Ship først, optimér senere.
• Stateless eller cloud-native applikationer: containeriserede microservices, serverless-funktioner (AWS Lambda, Azure Functions, Cloud Run) og managed databaser (RDS, Cloud SQL) er bygget til public cloud-primitiver.
• Dev/test-miljøer: spin op, kør tests, riv ned. Reserveret kapacitet giver ingen mening her.

Hvor public cloud kommer til kort

• Krav til datasuverænitet: GDPR artikel 44 begrænser overførsel af personoplysninger uden for EØS, medmindre tilstrækkelige beskyttelsesforanstaltninger er på plads. At bruge en amerikansk udbyders EU-region er generelt acceptabelt, men Schrems II-implikationerne og den løbende udvikling af EU–US Data Privacy Framework kræver juridisk vurdering — ikke blot et regionsvalg. Datatilsynet har udgivet specifik vejledning om brug af cloud-tjenester, som danske organisationer skal forholde sig til ved valg af implementeringsmodel.
• Stabile workloads med høj udnyttelsesgrad: en VM der kører med 80%+ udnyttelse 24/7 i årevis er næsten altid billigere on-premises eller i private cloud. Reserved Instances og Savings Plans (typisk 30–60% besparelse i forhold til on-demand-priser ifølge AWS' egen dokumentation) mindsker forskellen, men eliminerer den ikke for virkelig statiske belastninger.
• Stærkt regulerede miljøer: visse finanstilsynsmyndigheder og forsvarsmyndigheder kræver fysisk isolation, som logisk lejerseparation i public cloud ikke opfylder. Finanstilsynet i Danmark kan stille specifikke krav til outsourcing af IT-tjenester til cloud-udbydere.

Managed Cloud Services

Private Cloud

Sådan fungerer det

Private cloud dedikerer infrastruktur til en enkelt organisation. Den kan køre on-premises i dit eget datacenter eller hostes af en tredjepart (hosted private cloud). Det definerende kendetegn er single-tenancy og direkte kontrol over hele infrastrukturstakken.

Moderne private clouds bruger de samme orkestreringsteknologier som public cloud-udbydere. VMware Cloud Foundation, OpenStack, Nutanix og Azure Stack HCI leverer IaaS-lignende forbrugsmodeller internt. Kubernetes-distributioner som Red Hat OpenShift eller Rancher tilføjer containerorkestrering ovenpå.

Hvornår private cloud giver mening

• Strenge compliance-krav: finansielle institutioner under nationale bankregulativer (f.eks. Finanstilsynets vejledning om outsourcing af IT-tjenester, BaFins krav i Tyskland) møder undertiden krav om verificerbar fysisk isolation. Sundhedsorganisationer, der behandler danske patientdata, foretrækker ofte privat infrastruktur for at forenkle GDPR-ansvarskæden.
• Forudsigelig compute med høj densitet: HPC-workloads, storstilede batch-processer eller ML-træning på dedikerede GPU-klynger kan være mere omkostningseffektive på ejet hardware, når udnyttelsesgraden forbliver høj.
• Afhængigheder af legacy-applikationer: mainframe-nære workloads eller applikationer med hardcodede IP-afhængigheder, ikke-TCP/IP-protokoller eller licensering bundet til fysiske kerner kan ofte ikke flyttes til public cloud uden en omskrivning.

De reelle omkostninger, folk undervurderer

Private cloud er ikke "gratis, fordi vi allerede ejer serverne." Opsios Cloud FinOps-engagementer afdækker konsekvent skjulte omkostninger: strøm og køling til faciliteter, hardware-udskiftningscyklusser (typisk 3–5 år), personale til at håndtere firmware, patches og fysisk sikkerhed, plus alternativomkostningen ved at ingeniører udfører udifferentieret tungt løftearbejde i stedet for at bygge produktfeatures.

Den ærlige beregning: hvis din udnyttelsesgrad er under 60% i gennemsnit, betaler du sandsynligvis for meget for private cloud. Hvis den konsekvent ligger over 75%, sparer du sandsynligvis penge sammenlignet med public cloud on-demand-priser — men du skal medregne smiddighedsomkostningen ved indkøbsledetider.

Hybrid Cloud

Sådan fungerer det

Hybrid cloud forbinder privat infrastruktur (on-premises eller hostet) med et eller flere public cloud-miljøer gennem orkestrering, netværk og ofte delte identitetslag. Det afgørende, der adskiller det fra blot at bruge begge dele, er integration: workloads, data og management-planer opererer på tværs af miljøer på en koordineret måde.

Centrale muliggørende teknologier inkluderer:

Hvorfor hybrid dominerer enterprise-adoption

Ifølge Flexeras State of the Cloud har hybrid konsekvent været den dominerende enterprise-strategi i adskillige på hinanden følgende år. Årsagerne er praktiske, ikke teoretiske:

1. Migrering er gradvis: ingen virksomhed løfter alt til public cloud i ét skridt. Hybrid er den naturlige overgangsarkitektur under ethvert Cloud-migrering-program.

2. Fleksibilitet i workload-placering: følsomme data forbliver på privat infrastruktur, mens kundevendte applikationer skalerer på public cloud. En dansk e-handelsvirksomhed kan holde personoplysninger i et Stockholm-baseret privat miljø, mens CDN og compute-laget kører på AWS eu-north-1.

3. Burst-kapacitet: kør baseline-compute on-premises og burst til public cloud ved spidsbelastninger — Black Friday-trafik, kvartalsafslutningsbatch, sæsonbestemt efterspørgsel.

4. DR og resiliens: brug public cloud som disaster recovery-mål for on-premises workloads. AWS Elastic Disaster Recovery, Azure Site Recovery og lignende tjenester gør dette operationelt realistisk.

Operationelle udfordringer ved hybrid cloud

Hybrid er ikke "det bedste fra begge verdener" uden indsats. Fra Opsios 24/7 NOC-operationer med administration af hybridmiljøer er de tilbagevendende smertepunkter:

• Netværkskompleksitet: latens-følsomme workloads fordelt på tværs af miljøer skaber debugging-mareridt. Hvis din database er on-prem, og din applikation er i public cloud, traverserer hver forespørgsel interconnectet. Mål dette, før du arkitekterer det.
• Inkonsistent sikkerhedsposition: firewall-regler on-prem, security groups i AWS, NSG'er i Azure — tre forskellige policy-sprog, der beskriver samme intention. Drift er uundgåelig uden Infrastructure as Code (Terraform, Pulumi) og kontinuerlig policy-validering (OPA, Checkov).
• Monitorerings-fragmentering: en alarm udløses i CloudWatch, en anden i din on-prem Zabbix-instans og en tredje i Datadog. Uden et samlet observerbarhedslag spilder dit SOC-team tid på at korrelere på tværs af konsoller i stedet for at løse incidents.

Cloud-sikkerhed

Multi-Cloud

Multi-Cloud vs. Hybrid: En nødvendig skelnen

Disse begreber bruges ofte i flæng. Det bør de ikke. Hybrid betyder at blande privat og public infrastruktur. Multi-cloud betyder at bruge to eller flere public cloud-udbydere. En organisation, der bruger AWS og Azure, er multi-cloud. En organisation, der bruger AWS og en on-premises VMware-klynge, er hybrid. En organisation, der gør begge dele, er hybrid multi-cloud — og at administrere det er det mest operationelt komplekse scenarie inden for cloud-infrastruktur.

Bevidst vs. utilsigtet multi-cloud

Denne skelnen betyder mere end noget arkitekturdiagram. De fleste multi-cloud-miljøer er utilsigtede: produktteamet valgte AWS, data-teamet valgte GCP for BigQuery, og virksomheden opkøbte en firma, der kørte alt på Azure. Ingen planlagde det; det skete bare.

Bevidst multi-cloud har specifikke begrundelser:

• Regulatoriske krav: visse EU-finanstilsyn kræver koncentrationsrisikominimering — at man ikke er afhængig af en enkelt cloud-udbyder til kritiske tjenester. NIS2 artikel 21 kræver i visse fortolkninger "multi-vendor ICT-strategier" for væsentlige enheder. Finanstilsynet i Danmark har tilsvarende vejledning om outsourcing-risici for finansielle virksomheder.
• Best-of-breed-tjenester: GCP BigQuery til analytics, AWS til generel compute, Azure til Microsoft 365-integration og Active Directory. Dette er forsvarligt, når omkostningerne ved cross-cloud-netværk og operationelt overhead opvejes af fordelen på serviceniveau.
• Geografisk dækning: ingen enkelt udbyder har regioner overalt. En organisation, der har brug for lokal compute i et land, hvor kun én udbyder har en region, vil være multi-cloud af nødvendighed.

Den operationelle skat ved multi-cloud

Gennem Opsios Managed DevOps på tværs af multi-cloud-estates ser vi den operationelle skat tydeligt:

• IAM-divergens: AWS IAM, Azure Entra ID og GCP IAM bruger forskellige tilladelsesmodeller, forskellige tillidskædemekanismer og forskellige audit log-formater. At bygge et samlet adgangsstyringslag kræver betydelig investering i tooling.
• Fragmenteret omkostningssynlighed: AWS Cost Explorer, Azure Cost Management og GCP Billing Export udsender hver især data i forskellige skemaer. Uden en Cloud FinOps-platform (Apptio Cloudability, Vantage eller lignende) kan du ikke besvare "hvad koster denne applikation at køre pr. måned?" på tværs af udbydere.
• Kompetence-udvanding: hver cloud-udbyder har tusindvis af tjenester. Dyb ekspertise i alle tre er sjælden. Teams, der spredes tyndt på tværs af udbydere, mestrer ingen.

Den ærlige anbefaling: forfølg ikke multi-cloud som strategi. Forfølg det kun, når du har en specifik, forsvarlig grund for hver ekstra udbyder, og budgettér for det operationelle overhead, det skaber.

Community Cloud

Community cloud — delt infrastruktur blandt organisationer med fælles krav — er den mindst omtalte model, men forbliver relevant i specifikke sektorer. Eksempler inkluderer community clouds til det offentlige (AWS GovCloud, Azure Government), forskningssamfund (GÉANT i Europa, DeiC i Danmark) og branchekonsortier, der deler compliant infrastruktur.

I praksis er community cloud arkitektonisk lig en private cloud med delt tenancy blandt godkendte organisationer. Dens relevans er snæver, men reel: hvis du er en dansk kommune, der deler infrastruktur med andre kommuner gennem KL (Kommunernes Landsforening) eller en fælles KOMBIT-løsning, befinder du dig på community cloud.

Sammenligning af cloud-implementeringsmodeller

Sådan vælger du den rigtige cloud-implementeringsmodel

Valg af implementeringsmodel er en beslutning på workload-niveau, ikke på organisationsniveau. Forskellige applikationer inden for den samme virksomhed vil legitimt høre til i forskellige modeller. Her er det beslutningsframework, Opsio anvender:

Trin 1: Klassificér dine workloads

For hver workload vurderes:

• Datafølsomhed: behandler den personoplysninger under GDPR, finansielle data under bankregulativer eller sundhedsdata under nationale sundhedsdatalove? Under NIS2 skal væsentlige og vigtige enheder i 18 sektorer implementere risikostyringsforanstaltninger, der kan begrænse implementeringsmulighederne. Datatilsynets vejledning om cloud-tjenester bør inddrages specifikt for danske organisationer.
• Ydeevneprofil: latens-følsom (skal være tæt på brugere eller andre systemer), throughput-tung (kræver høj båndbredde) eller compute-intensiv (kræver specifik hardware som GPU'er)?
• Efterspørgselsvariabilitet: stabil belastning, sæsonmæssige spidsbelastninger eller uforudsigelige udsving?
• Integrationsafhængigheder: er denne workload afhængig af on-premises systemer (databaser, mainframes, legacy API'er)?

Trin 2: Kortlæg begrænsninger

• Regulatoriske: GDPR-krav til dataopbevaring, Datatilsynets vejledninger, sektorspecifikke regler (PSD2 for betalinger, MiFID II for handel), Finanstilsynets outsourcing-vejledning for finansielle virksomheder.
• Finansielle: CapEx-budgettilgængelighed, eksisterende hardware med resterende brugbar levetid, committede forbrugsaftaler med udbydere.
• Organisatoriske: teamkompetencer, eksisterende tooling, leverandørrelationer.

Trin 3: Vælg pr. workload, aggregér derefter

Når hver workload har en målmodel, bestemmer aggregatet din organisationsmodel. Hvis alle workloads retter sig mod public cloud, er du public-cloud-only. Hvis workloads spænder over privat og public, er du hybrid. Hvis de spænder over flere public cloud-udbydere, er du multi-cloud.

Trin 4: Revurdér periodisk

Cloud-implementering er ikke en beslutning, man træffer én gang og glemmer. Workload-karakteristika ændrer sig. Priser ændrer sig. Regulering ændrer sig. Opsio anbefaler en formel revurdering minimum årligt, tilpasset kontraktfornyelsescyklusser og compliance-auditplaner.

EU- og dansk compliance-kontekst

EU og Danmark

GDPR: Artikel 44 begrænser overførsel af personoplysninger uden for EØS. Valg af implementeringsmodel skal sikre, at kontroller for dataopbevaring er arkitektonisk håndhævet, ikke kun policy-baseret. AWS, Azure og GCP tilbyder alle forpligtelser til dataopbevaring i EU-regioner, men konfigurationer som cross-region replikering, CDN-caching og support-access-tooling kan utilsigtet overføre data uden for de tilsigtede grænser.

Datatilsynet: Som Danmarks databeskyttelsesmyndighed har Datatilsynet udgivet specifik vejledning om cloud-tjenester og behandling af personoplysninger. Danske organisationer skal dokumentere, at implementeringsmodellen understøtter de krav, Datatilsynet stiller — herunder risikovurdering af cloud-leverandøren, databehandleraftaler og sikring af de registreredes rettigheder.

NIS2-direktivet: gældende siden oktober 2024 og implementeret i dansk lov, kræver NIS2 at væsentlige og vigtige enheder implementerer passende tekniske og organisatoriske foranstaltninger til cybersikkerhedsrisikostyring. Dette inkluderer forsyningskædesikkerhed — din cloud-udbyder er en del af din forsyningskæde. Beslutninger om implementeringsmodel bør dokumentere, hvordan hver model opfylder NIS2 artikel 21-krav.

Cloud-suverænitet: Tysklands BSI C5-attestering og Frankrigs SecNumCloud-mærke stiller yderligere krav til cloud-udbydere. Organisationer i disse markeder kan have brug for udbydere med specifikke nationale certificeringer, hvilket kan begrænse valgmulighederne for implementeringsmodel. I en dansk kontekst bør man være opmærksom på tilsvarende krav fra Finanstilsynet og Center for Cybersikkerhed (CFCS).

Finanstilsynet: Danske finansielle virksomheder skal overholde Finanstilsynets vejledning om outsourcing af væsentlige aktivitetsområder, herunder IT-tjenester. Dette inkluderer specifikke krav til risikovurdering, exit-strategier og tilsynsmyndighedens adgang til cloud-udbyderens infrastruktur.

Cloud-sikkerhed

Hvad Opsio ser: Operationelle mønstre på tværs af implementeringsmodeller

Gennem 24/7 SOC- og NOC-operationer på tværs af kundemiljøer, der spænder over alle implementeringsmodeller, fremstår flere mønstre konsekvent:

Hybridmiljøer genererer flest incidents fra netværksgrænse-fejl. Interconnectet mellem on-premises og public cloud (Direct Connect, ExpressRoute) er et single point of failure, som teams undermonitorerer. Når det degraderer, viser symptomerne sig som applikationstræghed snarere end netværksfejl, hvilket fører til fejlrettet fejlsøgning.

Multi-cloud omkostningsattribuering er den største FinOps-udfordring. Organisationer, der kører workloads på tværs af to eller flere udbydere, kæmper konsekvent med at besvare grundlæggende spørgsmål som "hvad koster denne applikation pr. måned?" uden dedikeret tooling og tagging-disciplin.

Private cloud-miljøer driver hurtigst væk fra sikkerhedsbaselines. Public cloud-udbydere opdaterer løbende standardkonfigurationer (encryption-at-rest-defaults, TLS-minimumskrav, public-access-blokering). Privat cloud-infrastruktur fastholder den konfiguration, der blev sat ved implementeringen, medmindre den aktivt vedligeholdes.

Public-cloud-only-organisationer er hurtigst til at adoptere nye kapabiliteter, men akkumulerer også flest ubrugte ressourcer. Den nemme provisionering skaber sprawl. Flexeras State of the Cloud har konsekvent identificeret cloud-spild som en topbekymring, og rene public cloud-miljøer er der, hvor Opsios FinOps-praksis finder den største optimeringsmulighed.

Ofte stillede spørgsmål

Hvad er de 4 cloud-implementeringsmodeller?

De fire modeller defineret af NIST SP 800-145 er public cloud (delt infrastruktur drevet af en udbyder som AWS, Azure eller GCP), private cloud (dedikeret infrastruktur til en enkelt organisation), hybrid cloud (workloads fordelt på både public og private miljøer med orkestrering imellem) og community cloud (delt infrastruktur blandt organisationer med fælles krav, f.eks. offentlige myndigheder). Multi-cloud — brug af flere public cloud-udbydere — behandles ofte som en femte model i praksis.

Hvilken cloud-implementeringsmodel er mest anvendt?

Hybrid cloud er den mest udbredte model blandt virksomheder. Flexeras State of the Cloud-rapport har konsekvent vist, at et flertal af virksomheder forfølger en hybridstrategi, der kombinerer on-premises eller private cloud-ressourcer med en eller flere public clouds. Rene public-cloud-only-implementeringer er mere udbredte blandt startups og mindre organisationer, der ikke har legacy-infrastruktur med behov for on-premises integration.

Hvad er IaaS, PaaS og SaaS, og hvordan forholder de sig til implementeringsmodeller?

IaaS (Infrastructure as a Service), PaaS (Platform as a Service) og SaaS (Software as a Service) er cloud-servicemodeller — de beskriver abstraktionslaget, og hvad udbyderen administrerer kontra hvad du administrerer. Implementeringsmodeller beskriver hvor og hvordan infrastrukturen er hostet. De to er uafhængige: du kan køre IaaS på en private cloud, forbruge PaaS på en public cloud eller bruge SaaS leveret gennem en hybrid-arkitektur. Valg af implementeringsmodel låser dig ikke til en bestemt servicemodel.

Er AWS en public, private eller hybrid cloud?

AWS er primært en public cloud-udbyder, men understøtter alle implementeringsmodeller. AWS Outposts bringer AWS-administreret infrastruktur ind i dit on-premises datacenter til private eller hybride implementeringer. AWS GovCloud tilbyder isolerede regioner til amerikanske myndigheders workloads. AWS Local Zones udvider compute tættere på slutbrugere. De fleste organisationer bruger AWS som public cloud-komponenten i en bredere hybrid- eller multi-cloud-strategi.

Er hybrid cloud billigere end private cloud?

Omkostningerne afhænger helt af workload-profilen. Hybrid cloud reducerer typisk omkostningerne for variable workloads, fordi du kan burste til public cloud i stedet for at overprovisionere privat infrastruktur til spidsbelastning. Hybrid introducerer dog netværksomkostninger (interconnect-gebyrer, data transfer-afgifter), integrationskompleksitet og yderligere tooling-overhead. For stabile workloads med konsekvent høj udnyttelsesgrad kan private cloud være mere omkostningseffektiv pr. compute-enhed. Den grundige tilgang: modellér TCO for dine specifikke workloads på tværs af begge modeller, før du beslutter dig.