Offentlig sky
Hvordan det fungerer
Offentlig skyinfrastruktur eies og driftes av en tredjepartsleverandør — AWS, Microsoft Azure, Google Cloud Platform (GCP) eller andre — og deles mellom flere leietakere. Du bruker ressurser etter behov, betaler per forbruk, og leverandøren håndterer maskinvareanskaffelse, fysisk sikkerhet og plattformadministrasjon på basisnivå.
De store leverandørene opererer regioner globalt. AWS har regioner i Stockholm (eu-north-1), Frankfurt (eu-central-1) og Irland (eu-west-1). Azure opererer i Sweden Central og Germany West Central. GCP tilbyr europe-north1 (Finland). For nordiske arbeidsbelastninger er eu-north-1 (Stockholm) og eu-west-1 (Irland) de mest relevante AWS-regionene. Valg av region er avgjørende for latens, datalagring og pris — det er ikke en ettertanke.
Når offentlig sky er riktig valg
- Variable eller uforutsigbare arbeidsbelastninger: automatisk skalering eliminerer gjetning i kapasitetsplanlegging. Du betaler for det du bruker, ikke det du kanskje trenger.
- Oppstartsbedrifter og team med rask iterasjon: null CapEx på forhånd, umiddelbar klargjøring. Lever først, optimaliser etterpå.
- Tilstandsløse eller sky-native applikasjoner: containeriserte mikrotjenester, serverless-funksjoner (AWS Lambda, Azure Functions, Cloud Run) og administrerte databaser (RDS, Cloud SQL) er bygget for offentlig sky.
- Utviklings-/testmiljøer: sett opp, kjør tester, riv ned. Reservert kapasitet gir ingen mening her.
Hvor offentlig sky kommer til kort
- Krav til datasuverenitet: GDPR artikkel 44 begrenser overføring av personopplysninger utenfor EØS med mindre tilstrekkelige beskyttelsestiltak finnes. Å bruke en US-basert leverandørs EU-region er generelt akseptabelt, men implikasjonene av Schrems II-dommen og den pågående utviklingen av EU-US Data Privacy Framework krever juridisk vurdering, ikke bare valg av region. Datatilsynet har publisert veiledning om bruk av skytjenester som understreker behovet for risikovurderinger og databehandleravtaler.
- Stabile arbeidsbelastninger med høy utnyttelse: en VM som kjører på 80 %+ utnyttelse døgnet rundt i årevis er nesten alltid billigere lokalt eller i privat sky. Reserved Instances og Savings Plans (som typisk gir 30–60 % besparelser sammenlignet med on-demand-priser, ifølge AWS' egen dokumentasjon) reduserer gapet men fjerner det ikke for virkelig statiske laster.
- Sterkt regulerte miljøer: noen finanstilsyn og forsvarsetater krever fysisk isolasjon som logisk leietakerseparasjon i offentlig sky ikke tilfredsstiller. Finanstilsynet i Norge har klare forventninger til finansforetaks bruk av skytjenester og IKT-utsetting.
Privat sky
Hvordan det fungerer
Privat sky dedikerer infrastruktur til én enkelt organisasjon. Den kan driftes lokalt i ditt eget datasenter eller hostes av en tredjepart (hostet privat sky). Det definerende kjennetegnet er enkelt leietakerskap og direkte kontroll over infrastrukturstabelen.
Moderne private skyer bruker de samme orkestreringsteknologiene som offentlige leverandører. VMware Cloud Foundation, OpenStack, Nutanix og Azure Stack HCI tilbyr IaaS-lignende forbruksmodeller internt. Kubernetes-distribusjoner som Red Hat OpenShift eller Rancher legger til containerorkestrering på toppen.
Når privat sky gir mening
- Strenge etterlevelseregimer: finansinstitusjoner under Finanstilsynets IKT-forskrift, eller organisasjoner underlagt sikkerhetsloven, kan stå overfor krav som forutsetter verifiserbar fysisk isolasjon. Helseorganisasjoner som håndterer pasientdata under norsk personvernlovgivning foretrekker ofte privat infrastruktur for å forenkle ansvarskjedene under GDPR.
- Forutsigbar, høytetthet beregning: HPC-arbeidsbelastninger, storskala batchbehandling eller ML-trening på dedikerte GPU-klynger kan være mer kostnadseffektivt på eid maskinvare når utnyttelsen holder seg høy.
- Avhengigheter til eldre applikasjoner: stormaskin-tilknyttede arbeidsbelastninger eller applikasjoner med hardkodede IP-avhengigheter, ikke-TCP/IP-protokoller eller lisensering knyttet til fysiske kjerner kan ofte ikke flyttes til offentlig sky uten en omskriving.
De reelle kostnadene folk undervurderer
Privat sky er ikke «gratis fordi vi allerede eier serverne». Opsios Cloud FinOps-engasjementer avdekker konsekvent skjulte kostnader: strøm og kjøling for datasenter, maskinvare-oppdateringssykluser (typisk 3–5 år), personale for firmware-administrasjon, oppdateringer og fysisk sikkerhet, pluss alternativkostnaden ved at ingeniører gjør udifferensiert tungt arbeid i stedet for å bygge produktfunksjoner.
Den ærlige regnestykket: hvis utnyttelsen din i snitt er under 60 %, betaler du sannsynligvis for mye for privat sky. Hvis den konsekvent er over 75 %, sparer du trolig penger sammenlignet med on-demand-priser i offentlig sky — men du må medregne smidighets-kostnaden ved anskaffelses-ledetider.
Hybrid sky
Hvordan det fungerer
Hybrid sky kobler privat infrastruktur (lokal eller hostet) med ett eller flere offentlige skymiljøer gjennom orkestrering, nettverksintegrasjon og ofte delte identitetslag. Den vesentlige forskjellen fra å bare bruke begge deler er integrasjon: arbeidsbelastninger, data og administrasjonsflater opererer på tvers av miljøer på en koordinert måte.
Sentrale muliggjørende teknologier inkluderer:
| Teknologi | Formål | Eksempler |
|---|---|---|
| Hybridtilkobling | Private nettverksforbindelser mellom lokalt og sky | AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect |
| Hybridberegning | Kjør skytjenester lokalt | AWS Outposts, Azure Arc, Google Anthos |
| Identitetsfederering | Felles identitet på tvers av miljøer | Azure AD (Entra ID), Okta, AWS IAM Identity Center |
| Containerorkestrering | Portabilitet for arbeidsbelastninger | Kubernetes (EKS, AKS, GKE) med konsistente manifester |
| Overvåking og observerbarhet | Samlet synlighet | Datadog, Dynatrace, Grafana Cloud |
Hvorfor hybrid dominerer blant virksomheter
Ifølge Flexeras State of the Cloud har hybrid konsekvent vært den dominerende virksomhetsstrategien flere år på rad. Årsakene er praktiske, ikke teoretiske:
1. Migrering skjer gradvis: ingen virksomhet løfter alt til offentlig sky i ett steg. Hybrid er den naturlige overgangsarkitekturen under ethvert skymigrering-program.
2. Fleksibilitet i plassering av arbeidsbelastninger: sensitive data forblir på privat infrastruktur mens kundevendte applikasjoner skalerer i offentlig sky. En norsk netthandelsvirksomhet kan holde personopplysninger i et norsk- eller Norden-basert privat miljø mens den kjører CDN og beregningslaget på AWS eu-north-1 (Stockholm).
3. Burstkapasitet: kjør basisberegning lokalt og skaler ut til offentlig sky ved topper — Black Friday-trafikk, kvartalsvis batchbehandling, sesongbasert etterspørsel.
4. DR og resiliens: bruk offentlig sky som katastrofegjenopprettingsmål for lokale arbeidsbelastninger. AWS Elastic Disaster Recovery, Azure Site Recovery og lignende tjenester gjør dette operasjonelt gjennomførbart.
Operasjonelle utfordringer med hybrid sky
Hybrid er ikke «det beste fra begge verdener» uten innsats. Fra Opsios 24/7 NOC-drift som administrerer hybridmiljøer, er de tilbakevendende smertepunktene:
- Nettverkskompleksitet: latenssensitive arbeidsbelastninger som er delt mellom miljøer skaper feilsøkingsmareritt. Hvis databasen din er lokal og applikasjonen kjører i offentlig sky, traverserer hvert spørring sammenkoblingen. Mål dette før du arkitekterer det.
- Inkonsistent sikkerhetsstilling: brannmurregler lokalt, security groups i AWS, NSG-er i Azure — tre ulike policysyntakser som beskriver samme intensjon. Drift er uunngåelig uten Infrastructure as Code (Terraform, Pulumi) og kontinuerlig policyvalidering (OPA, Checkov).
- Fragmentert overvåking: et varsel utløses i CloudWatch, et annet i din lokale Zabbix-instans, og et tredje i Datadog. Uten et samlet observerbarhetslag kaster SOC-teamet bort tid på å korrelere på tvers av konsoller i stedet for å løse hendelser.
Multi-sky
Multi-sky vs. hybrid: en nødvendig distinksjon
Disse begrepene brukes ofte om hverandre. Det bør de ikke. Hybrid betyr å blande privat og offentlig infrastruktur. Multi-sky betyr å bruke to eller flere offentlige skyleverandører. En organisasjon som bruker AWS og Azure er multi-sky. En organisasjon som bruker AWS og en lokal VMware-klynge er hybrid. En organisasjon som gjør begge deler er hybrid multi-sky — og å administrere dette er det mest operasjonelt komplekse scenariet innen skyinfrastruktur.
Bevisst vs. tilfeldig multi-sky
Denne distinksjonen betyr mer enn noe arkitekturdiagram. De fleste multi-sky-miljøer er tilfeldige: produktteamet valgte AWS, datateamet valgte GCP for BigQuery, og selskapet kjøpte opp et firma som kjørte alt på Azure. Ingen planla det; det bare skjedde.
Bevisst multi-sky har spesifikke begrunnelser:
- Regulatoriske krav: enkelte EU-finanstilsyn krever konsentrasjonsrisikodempning — at man ikke er avhengig av én enkelt skyleverandør for kritiske tjenester. NIS2 artikkel 21 krever «flerleverandør-IKT-strategier» i visse tolkninger for vesentlige enheter. Finanstilsynet i Norge følger disse tolkningene tett.
- Best-of-breed-tjenester: GCP BigQuery for analyse, AWS for generell beregning, Azure for Microsoft 365-integrasjon og Active Directory. Dette er forsvarlig når kostnaden ved nettverksintegrasjon på tvers av skyer og operasjonelt merarbeid er verdt fordelen på tjenestenivå.
- Geografisk dekning: ingen enkelt leverandør har regioner overalt. En organisasjon som trenger lokal beregning i et land der bare én leverandør har en region, vil være multi-sky av nødvendighet.
Den operasjonelle skattebyrden ved multi-sky
Gjennom Opsios Administrert DevOps på tvers av multi-sky-miljøer ser vi den operasjonelle skattebyrden tydelig:
- IAM-divergens: AWS IAM, Azure Entra ID og GCP IAM bruker ulike tilgangsmodeller, ulike tillitskjedemekanismer og ulike revisjonsloggformater. Å bygge et samlet tilgangsstyringslag krever betydelige verktøyinvesteringer.
- Fragmentert kostnadssynlighet: AWS Cost Explorer, Azure Cost Management og GCP Billing Export eksporterer data i ulike skjemaer. Uten en Cloud FinOps-plattform (Apptio Cloudability, Vantage eller lignende) kan du ikke svare på «hva koster denne applikasjonen per måned?» på tvers av leverandører.
- Kompetanseutvanning: hver skyleverandør har tusenvis av tjenester. Dyp kompetanse i alle tre er sjelden. Team som spres tynt over leverandører mestrer ingen av dem.
Den ærlige anbefalingen: ikke forfølg multi-sky som en strategi. Forfølg det bare når du har en spesifikk, forsvarlig begrunnelse for hver ekstra leverandør, og budsjetter for det operasjonelle merarbeidet det medfører.
Fellesskapssky
Fellesskapssky — delt infrastruktur mellom organisasjoner med felles krav — er den minst diskuterte modellen, men forblir relevant i spesifikke sektorer. Eksempler inkluderer statlige fellesskapsskyer (AWS GovCloud, Azure Government), forskningsfellesskap (NORDUnet, GÉANT i Europa) og bransjekonsortier som deler kompatibel infrastruktur.
I praksis er fellesskapssky arkitektonisk lik en privat sky med delt leietakerskap mellom godkjente organisasjoner. Relevansen er smal men reell: hvis du er en norsk kommune som deler infrastruktur med andre kommuner gjennom KS (Kommunesektorens organisasjon) eller benytter Digitaliseringsdirektoratets felleskomponenter, er du på en form for fellesskapssky.
Sammenligning av skyutrullingsmodeller
| Dimensjon | Offentlig sky | Privat sky | Hybrid sky | Multi-sky |
|---|---|---|---|---|
| Eierskap | Leverandøreid, delt | Organisasjonseid eller hostet | Blandet | Flere leverandører |
| CapEx | Ingen (kun OpEx) | Høy (maskinvare, fasiliteter) | Blandet | Ingen per leverandør, høy samlet |
| Skalerbarhet | Tilnærmet uendelig | Begrenset av kapasitet | Burst til offentlig sky | Tilnærmet uendelig per leverandør |
| Kontroll | Begrenset (leverandørens API-er) | Full | Delt | Begrenset per leverandør |
| Etterlevelsesforenkling | Moderat (delt ansvar) | Høy (du eier stabelen) | Kompleks (flere omfang) | Mest kompleks |
| Operasjonell kompleksitet | Lav til moderat | Moderat til høy | Høy | Høyest |
| Best egnet for | Variable arbeidsbelastninger, oppstartsbedrifter | Regulerte, stabile arbeidsbelastninger | De fleste virksomheter | Spesifikke best-of-breed-behov |
| Leverandørlåsing-risiko | Høy (én leverandør) | Lav (du eier det) | Moderat | Lav (designmessig) |
Hvordan velge riktig skyutrullingsmodell
Valg av utrullingsmodell er en beslutning på arbeidslastnivå, ikke på organisasjonsnivå. Ulike applikasjoner innen samme virksomhet vil legitimt tilhøre ulike modeller. Her er beslutningsrammeverket Opsio anvender:
Steg 1: Klassifiser arbeidsbelastningene dine
For hver arbeidsbelastning, vurder:
- Dataskjermingsnivå: behandler den personopplysninger under GDPR (personvernforordningen, gjennomført i norsk lov), finansdata under Finanstilsynets regelverk, eller helsedata under helseregisterloven og pasientjournalloven? Under NIS2 må vesentlige og viktige enheter i 18 sektorer implementere risikostyringstiltak som kan begrense utrullingsalternativer.
- Ytelsesprofil: latenssensitiv (må være nær brukere eller andre systemer), gjennomstrømningstung (trenger høy båndbredde) eller beregningsintensiv (trenger spesifikk maskinvare som GPU-er)?
- Etterspørselsvariasjon: stabil, sesongmessige topper eller uforutsigbare spisser?
- Integrasjonsavhengigheter: er denne arbeidsbelastningen avhengig av lokale systemer (databaser, stormaskiner, eldre API-er)?
Steg 2: Kartlegg begrensninger
- Regulatoriske: GDPRs krav til datalagring (EØS-relevant), Datatilsynets veiledninger, NIS2-direktivets krav (implementert i norsk lov), sektorspesifikke regler (PSD2 for betalinger, IKT-forskriften for finansforetak).
- Finansielle: CapEx-budsjett tilgjengelig, eksisterende maskinvare med gjenstående levetid, forpliktede forbruksavtaler med leverandører.
- Organisatoriske: teamkompetanse, eksisterende verktøy, leverandørrelasjoner.
Steg 3: Velg per arbeidsbelastning, deretter aggreger
Når hver arbeidsbelastning har en målmodell, bestemmer aggregeringen din organisatoriske modell. Hvis alle arbeidsbelastninger peker mot offentlig sky, er du offentlig-sky-ren. Hvis arbeidsbelastninger spenner over privat og offentlig, er du hybrid. Hvis de spenner over flere offentlige leverandører, er du multi-sky.
Steg 4: Revurder periodisk
Skyutrulling er ikke en sett-og-glem-beslutning. Arbeidslastegenskaper endrer seg. Priser endrer seg. Regelverk endrer seg. Opsio anbefaler en formell revurdering minimum årlig, tilpasset kontraktsfornyelsessykluser og tidsplaner for etterlevelses-revisjoner.
Norske og europeiske etterlevelses-hensyn
Norge og EU/EØS
GDPR (personvernforordningen): Artikkel 44 begrenser overføring av personopplysninger utenfor EØS. Valg av utrullingsmodell må sikre at datalagrings-kontroller håndheves arkitektonisk, ikke bare gjennom retningslinjer. AWS, Azure og GCP tilbyr alle EU-regionbaserte datalagring-forpliktelser, men konfigurasjoner som replisering på tvers av regioner, CDN-caching og support-tilgangsverktøy kan utilsiktet overføre data utenfor tiltenkte grenser. Datatilsynet har vært tydelig på at norske virksomheter må gjennomføre grundige risikovurderinger ved bruk av skytjenester.
NIS2-direktivet: gjeldende fra oktober 2024 og under implementering i norsk rett, krever NIS2 at vesentlige og viktige enheter implementerer passende tekniske og organisatoriske tiltak for cybersikkerhets-risikostyring. Dette inkluderer leverandørkjedesikkerhet — din skyleverandør er del av leverandørkjeden din. Beslutninger om utrullingsmodell bør dokumentere hvordan hver modell tilfredsstiller NIS2 artikkel 21-kravene. Nasjonal sikkerhetsmyndighet (NSM) og Digitaliseringsdirektoratet gir veiledning om implementeringen i norsk kontekst.
Skysuverenitet: Gaia-X-initiativet og nasjonale sertifiseringsordninger som Tysklands BSI C5-attestering og Frankrikes SecNumCloud-merke pålegger ytterligere krav til skyleverandører. Norske organisasjoner med pan-europeiske kunder kan møte krav om leverandører med spesifikke nasjonale sertifiseringer, noe som kan begrense valgmulighetene for utrullingsmodell.
Norsk kontekst spesifikt: Sikkerhetsloven og IKT-forskriften for finansforetak stiller krav som kan påvirke valg av skymodell. Digitaliseringsdirektoratets skystrategiforankring anbefaler «sky først»-prinsippet for offentlig sektor, men med tydelige krav til risikovurdering og etterlevelse.
Hva Opsio ser: Operasjonelle mønstre på tvers av utrullingsmodeller
Gjennom 24/7 SOC- og NOC-drift på tvers av kundemiljøer som spenner over alle utrullingsmodeller, ser vi flere konsistente mønstre:
Hybridmiljøer genererer flest hendelser fra nettverksgrensefeil. Sammenkoblingen mellom lokalt og offentlig sky (Direct Connect, ExpressRoute) er et enkelt feilpunkt som team underovervåker. Når den degraderer, manifesterer symptomene seg som applikasjonstrehet snarere enn nettverksfeil, noe som fører til feilrettet feilsøking.
Multi-sky-kostnadsallokering er den største FinOps-utfordringen. Organisasjoner som kjører arbeidsbelastninger på tvers av to eller flere leverandører sliter konsekvent med å svare på grunnleggende spørsmål som «hva koster denne applikasjonen per måned?» uten dedikert verktøy og tagging-disiplin.
Private skymiljøer drifter raskest fra sikkerhetsgrunnlinjer. Offentlige skyleverandører oppdaterer kontinuerlig standardkonfigurasjoner (kryptering-i-ro som standard, TLS-minimumskrav, blokkering av offentlig tilgang). Privat skyinfrastruktur beholder den konfigurasjonen som ble satt ved utrulling med mindre den aktivt vedlikeholdes.
Organisasjoner med kun offentlig sky er raskest til å ta i bruk nye funksjoner, men akkumulerer også flest ubrukte ressurser. Enkelheten ved klargjøring skaper spredning. Flexeras State of the Cloud har konsekvent identifisert skysvinn som en topp-bekymring, og rene offentlige skymiljøer er der Opsios FinOps-praksis finner mest optimaliseringspotensial.
Ofte stilte spørsmål
Hva er de fire skyutrullingsmodellene?
De fire modellene definert av NIST SP 800-145 er offentlig sky (delt infrastruktur driftet av en leverandør som AWS, Azure eller GCP), privat sky (dedikert infrastruktur for én enkelt organisasjon), hybrid sky (arbeidsbelastninger som spenner over både offentlige og private miljøer med orkestrering mellom dem) og fellesskapssky (delt infrastruktur mellom organisasjoner med felles krav, som offentlige etater). Multi-sky — bruk av flere offentlige leverandører — behandles ofte som en femte modell i praksis.
Hvilken skyutrullingsmodell er mest brukt?
Hybrid sky er den mest adopterte modellen blant virksomheter. Flexeras State of the Cloud-rapport har konsekvent funnet at et flertall av virksomheter forfølger en hybridstrategi, der de kombinerer lokal infrastruktur eller private skyressurser med én eller flere offentlige skyer. Rent offentlig-sky-baserte utrullinger er mer vanlig blant oppstartsbedrifter og mindre organisasjoner som mangler eldre infrastruktur som krever lokal integrasjon.
Hva er IaaS, PaaS og SaaS, og hvordan henger de sammen med utrullingsmodeller?
IaaS (Infrastructure as a Service), PaaS (Platform as a Service) og SaaS (Software as a Service) er sky-tjenesteleveringsmodeller — de beskriver abstraksjonslaget og hva leverandøren administrerer kontra hva du administrerer. Utrullingsmodeller beskriver hvor og hvordan infrastrukturen er driftet. De to er uavhengige: du kan kjøre IaaS på en privat sky, konsumere PaaS på en offentlig sky, eller bruke SaaS levert gjennom en hybridarkitektur. Valg av utrullingsmodell låser deg ikke til en spesifikk tjenestemodell.
Er AWS en offentlig, privat eller hybrid sky?
AWS er primært en offentlig skyleverandør, men støtter alle utrullingsmodeller. AWS Outposts bringer AWS-administrert infrastruktur inn i ditt lokale datasenter for private eller hybride utrullinger. AWS GovCloud tilbyr isolerte regioner for regulerte arbeidsbelastninger. AWS Local Zones utvider beregningskapasitet nærmere sluttbrukere. De fleste organisasjoner bruker AWS som den offentlige skykomponenten i en bredere hybrid- eller multi-sky-strategi.
Er hybrid sky billigere enn privat sky?
Kostnaden avhenger helt av arbeidslastprofilen. Hybrid sky reduserer typisk kostnader for variable arbeidsbelastninger fordi du kan skalere ut til offentlig sky i stedet for å overdimensjonere privat infrastruktur for toppbelastning. Hybrid introduserer imidlertid nettverkskostnader (sammenkoblingsavgifter, dataoverføringsgebyrer), integrasjonskompleksitet og ekstra verktøy-overhead. For stabile arbeidsbelastninger med konsekvent høy utnyttelse kan privat sky være mer kostnadseffektivt per beregningsenhet. Den grundige tilnærmingen: modeller TCO for dine spesifikke arbeidsbelastninger på tvers av begge modeller før du beslutter.
