Skal du kjøre Kubernetes i produksjon i 2026, må du velge en administrert tjeneste før du velger noe annet. Amazon EKS, Microsoft Azure AKS og Google GKE dekker til sammen mesteparten av verdens Kubernetes-klynger, men prismodellene, oppgraderingsreglene og autoskaleringsverktøyene deres skiller seg mye mer enn de fleste team er klar over før regningen kommer. Denne artikkelen går gjennom kontrollplan-priser, SLA-nivåer, nodegrenser, sikkerhetsmodeller og reell driftskostnad for alle tre, med tall hentet fra offisiell AWS-, Microsoft- og Google-dokumentasjon oppdatert i august og september 2026.
Kort oppsummert: AKS Standard har gratis kontrollplan, EKS koster 0,10 dollar i timen (rundt 73 dollar i måneden) per klynge, og GKE ligger et sted mellom de to avhengig av om du velger Standard eller Autopilot. Men kontrollplan-prisen er bare toppen av isfjellet. Nodekostnader, dataoverføring, støttevinduer for Kubernetes-versjoner og hvor mye tid teamet ditt bruker på manuell drift, avgjør som regel den reelle totalkostnaden.
Hva er EKS, AKS og GKE?
Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) og Google Kubernetes Engine (GKE) er de tre store skyleverandørenes administrerte Kubernetes-tilbud. Alle tre gjør samme grunnjobb: de drifter kontrollplanet (API-server, etcd, scheduler) slik at teamet ditt slipper å administrere det selv, og lar deg kjøre arbeidsnoder som enten er egendefinerte virtuelle maskiner eller fullt administrerte compute-ressurser.
Forskjellen ligger i hvor mye av driftsarbeidet som faktisk er automatisert, hvor raskt hver leverandør ruller ut nye Kubernetes-versjoner, og hvordan de fakturerer deg. GKE var først ute med et administrert Kubernetes-produkt tilbake i 2015 og har historisk ledet an på funksjoner som Autopilot, der Google styrer nodene fullstendig og du kun betaler for pods. EKS har i stedet bygget en bred økosystem-tilnærming med sterk AWS-integrasjon og verktøy som Karpenter for nodeprovisjonering. AKS skiller seg ut ved at kontrollplanet i Standard-tier er helt gratis, noe som gjør det til det billigste utgangspunktet for team med lite trafikk.
Dette skjer parallelt med at Kubernetes-prosjektet selv har rullet ut versjon 1.37 med flere brytende endringer som alle tre skyleverandørene må tilpasse seg. Ifølge Mordor Intelligence sin 2026-rapport om Kubernetes-markedet står EKS alene for rundt 30 prosent av alle administrerte Kubernetes-klynger globalt, med over 2 millioner aktive kunder. Andre kilder, som ReleaseRun sin februar 2026-undersøkelse, anslår EKS til rundt 42 prosent og GKE til rundt 27 prosent av det administrerte segmentet, mens 79 prosent av spurte team sier de foretrekker en administrert tjeneste fremfor å drifte Kubernetes selv. Tallene varierer mellom kilder, men retningen er tydelig: administrert Kubernetes har blitt normen, ikke unntaket, for produksjonsmiljøer i 2026.
Kontrollplan-priser: hva koster hver tjeneste egentlig?
Prisen på selve kontrollplanet er der de tre tjenestene skiller seg mest fra hverandre på papiret. Amazon EKS tar 0,10 dollar per klynge-time for standard support, som blir omtrent 73 dollar i måneden ved 730 timer, ifølge AWS sin egen prisside. Denne prisen er lik for enhver klyngestørrelse, og gjelder uansett hvor mange noder du kjører bak kontrollplanet.
Azure AKS snur modellen på hodet: Standard-tier har ikke noe eget kontrollplan-gebyr i det hele tatt, så du betaler kun for de underliggende Azure-VM-ene dine. Vil du ha en formell SLA på kontrollplanet, må du oppgradere til AKS Premium-tier, som ifølge Microsofts prisdokumentasjon koster rundt 0,10 dollar i timen, altså på linje med EKS. Dette gjør AKS Standard til det billigste alternativet for team som kjører mange små klynger, for eksempel per-team eller per-miljø-oppsett, siden du slipper å betale kontrollplan-avgift for hver enkelt klynge.
Google GKE har en lignende todeling. Standard-modus har i utgangspunktet et kontrollplan-gebyr på 0,10 dollar i timen per klynge etter den første gratis klyngen per faktureringskonto, mens Autopilot-modus flytter kostnadsberegningen over til faktisk pod-ressursbruk i stedet for en fast klyngeavgift. Det betyr at et lite testmiljø på GKE Autopilot kan bli billigere enn både EKS og AKS Premium, mens en stor produksjonsklynge med høy og jevn utnyttelse ofte havner nærmere Standard-prisingen. Sjekk alltid gjeldende tall på Google Cloud sin offisielle prisside før du budsjetterer, siden GKE har justert modellen flere ganger de siste årene.
| Kategori | Amazon EKS | Azure AKS | Google GKE |
|---|---|---|---|
| Kontrollplan (Standard) | 0,10 USD/time (~73 USD/mnd) | Gratis | 0,10 USD/time etter første gratis klynge |
| Kontrollplan (Premium/Autopilot) | Ikke separat nivå | 0,10 USD/time (~73 USD/mnd) | Betaling etter pod-forbruk |
| SLA (betalt tier) | 99,95 % | 99,95 % (Premium) | 99,95 % |
| SLA (gratis tier) | Ikke tilgjengelig | Uten formell SLA i Standard | Regionale klynger har SLA, single-zone har ikke |
| Nyeste K8s-versjon (sep. 2026) | 1.36 (platform-oppdatert 17. aug. 2026) | 1.37 forhåndsvisning, 1.36.3 patch | 1.37 i Rapid-kanal fra 18. sep. 2026 |
| Standard autoskalering | Karpenter / Cluster Autoscaler | Cluster Autoscaler | GKE Autopilot / Cluster Autoscaler |
| Identitetsmodell | EKS Pod Identity | AKS Workload Identity | Workload Identity Federation |
| Versjonsstøtte (standard) | 14 måneder, deretter utvidet support | Opptil 2 år LTS på Premium | Inntil 24 måneder på Extended-kanal |
| Nodealternativer | EC2, Fargate, EKS Auto Mode | Azure VM-nodepools | Standard nodepools eller Autopilot |
| Markedsandel (administrert K8s) | ~30-42 % (kilde-avhengig) | Vokser raskt, ingen fast tall | ~25-27 % |
| Gratis klynge inkludert | Nei | Ja, i Standard-tier | Ja, én zonal klynge per faktureringskonto |
Nodepriser og skjulte kostnader
Kontrollplan-avgiften er sjelden det som avgjør den totale regningen din. Nodene, altså virtuelle maskiner som faktisk kjører applikasjonene dine, dominerer kostnadsbildet i de fleste produksjonsmiljøer. Alle tre leverandørene fakturerer noder separat fra kontrollplanet, basert på den underliggende compute-prisingen deres.
EKS lar deg velge mellom EC2-instanser du administrerer selv, AWS Fargate for serverløs pod-kjøring uten å styre noder, eller det nyere EKS Auto Mode, der AWS automatisk velger og skalerer infrastruktur og legger til et administrasjonsgebyr på toppen av EC2-prisen. AKS fakturerer rett og slett standard Azure VM-priser for nodene i nodepoolene dine, uten noe ekstra påslag utover selve compute-ressursen. GKE har et lignende oppsett med Standard-nodepools som følger vanlig Compute Engine-prising, mens Autopilot slår sammen node- og pod-fakturering til én sats per vCPU, minne og lagring som faktisk forbrukes av arbeidslastene dine.
Et praktisk eksempel: en typisk produksjonsklynge med tre noder av middels størrelse (fire vCPU, 16 GB minne hver) vil typisk koste et sted mellom 300 og 450 dollar i måneden bare i node-compute, avhengig av region og om du bruker spot- eller reserverte instanser. Legg til kontrollplan-avgiften, lastbalansering, utgående dataoverføring og eventuell administrasjonsavgift for automatiserte modus som EKS Auto Mode eller GKE Autopilot, og totalsummen kan variere med 20 til 40 prosent mellom leverandørene selv for identiske arbeidslaster. Dette er grunnen til at FinOps-team i økende grad kjører parallelle kostnadssimuleringer før de committer til én skyleverandør for en ny klynge.
Ytelsesbenchmark: klargjøringstid og oppetid
Hvor raskt en ny klynge er klar til bruk, påvirker både utviklerproduktivitet og evnen til å reagere raskt på skalering eller feilsituasjoner. Basert på dokumentasjon og driftsrapporter fra 2026 tar en frisk EKS-klynge typisk mellom 10 og 15 minutter å provisjonere fra API-kall til et fullt operativt kontrollplan, mens tillegg av arbeidsnoder via managed node groups legger til noen minutter ekstra avhengig av instansstørrelse og region.
AKS har generelt vært ansett som raskest til å spinne opp et nytt kontrollplan, ofte under 10 minutter i standardkonfigurasjon, delvis fordi Microsoft har investert tungt i å redusere klargjøringstiden som en konkurransefortrinn mot AWS og Google. GKE ligger typisk mellom de to andre for Standard-modus, mens Autopilot-klynger kan ta noe lengre tid å klargjøre fullt ut siden Google også setter opp sikkerhets- og nettverkspolicyer automatisk i bakgrunnen.
På oppetidssiden viser alle tre leverandørene 99,95 prosent SLA på sine betalte kontrollplan-tilbud, ifølge både AWS, Microsoft og Google sine egne SLA-sider. Det tilsvarer i praksis rundt 4,4 timer nedetid tillatt per år før du kvalifiserer for kompensasjon. Ingen av de tre har offentlig dokumentert store, isolerte 2026-hendelser som bare rammet deres administrerte Kubernetes-kontrollplan spesifikt, men generelle skyavbrudd hos alle tre leverandørene har fra tid til annen påvirket tilstøtende tjenester som IAM, DNS eller nettverkskomponenter som klyngene er avhengige av. Dette understreker et poeng som ofte glemmes: SLA-en dekker kontrollplanet, ikke nødvendigvis alle avhengighetene rundt det.
Autoskalering: Karpenter mot Cluster Autoscaler mot Autopilot
Autoskalering er kanskje det området der de tre plattformene har utviklet seg mest forskjellig de siste par årene. AWS har satset tungt på Karpenter, et open source-prosjekt som nå er standardanbefalingen for nodeprovisjonering på EKS. Karpenter analyserer ventende pods i sanntid og velger den mest kostnadseffektive instanstypen som passer arbeidslasten, i stedet for å skalere forhåndsdefinerte nodegrupper i faste trinn slik den eldre Cluster Autoscaler gjør. Dette gir ofte raskere skalering og bedre pakking av arbeidslaster, som igjen reduserer bortkastet compute-kapasitet.
Azure AKS støtter i hovedsak den standard Kubernetes Cluster Autoscaler, sammen med Azures egne node-provisjoneringsforbedringer. AKS har historisk vært litt bak EKS og GKE på avansert autoskaleringstooling, men Microsofts september 2026-utgivelsesnotater viser aktiv utvikling med Kubernetes 1.37-forhåndsvisning og patch-versjonene 1.36.3, 1.35.7 og 1.34.10 tilgjengelig, ifølge Azure AKS sine offisielle utgivelsesnotater på GitHub, noe som tyder på at selskapet prioriterer å holde tritt med kjerneøkosystemet.
Google GKE Autopilot forblir det mest hands-off alternativet av de tre. Med Autopilot trenger du ikke å tenke på nodepools i det hele tatt: Google velger, klargjør og skalerer den underliggende infrastrukturen basert på pod-spesifikasjonene dine, og fakturerer deg per forbrukt ressurs. Dette reduserer operasjonell kompleksitet betraktelig, men gir deg samtidig mindre kontroll over ting som nøyaktig instanstype, spot-rabatter eller spesialisert maskinvare, noe som kan være en ulempe for team med svært spesifikke ytelseskrav.
Kubernetes-versjonsstøtte og oppgraderingssykluser
Kubernetes selv rullet ut versjon 1.37 som generelt tilgjengelig 26. august 2026, ifølge det offisielle Kubernetes-prosjektets utgivelsesoversikt, med endringer som avvikling av IPVS-modus, SELinuxMount satt som standard, og fjerning av statiske pod-hemmeligheter. Hvor raskt hver skyleverandør adopterer en ny hovedversjon, sier mye om hvor mye vedlikeholdsarbeid teamet ditt må gjøre selv.
Google GKE var raskest ute denne runden: ifølge Googles egne utgivelsesnotater ble 1.37 tilgjengelig i Rapid-kanalen allerede 18. september 2026, bare tre uker etter at Kubernetes selv ga ut versjonen. AKS fulgte tett bak med en 1.37-forhåndsvisning i sine GitHub-utgivelsesnotater i samme periode. EKS var mer konservativ og viste ifølge AWS sin dokumentasjon fortsatt aktiv støtte for 1.36.2 og 1.34.9, med platform-oppdateringer datert 17. august 2026, uten offentlig bekreftet 1.37-støtte på publiseringstidspunktet for denne artikkelen.
Selve supportvinduet varierer også betydelig mellom leverandørene. Ifølge endoflife.date sin oversikt over EKS-versjoner gir EKS standard support i 14 måneder etter at en versjon slippes, deretter går klyngen automatisk over i utvidet support, som ifølge flere bransjekilder koster betydelig mer, opp mot 0,60 dollar per klynge-time. Ifølge GKEs offisielle utgivelsesplan tilbyr Google opptil 24 måneders støtte på sin Extended-kanal for team som ikke kan oppgradere ofte. AKS Premium-tier skiller seg ut med en toårig LTS-mulighet (Long Term Support), som er attraktivt for regulerte bransjer og virksomheter med strenge endringskontrollprosesser, som mange norske finans- og offentlige aktører opererer under.
Sikkerhet: Pod Identity, Workload Identity og Autopilot-policyer
Identitetshåndtering for arbeidslaster er et av de områdene der en feilkonfigurasjon lettest fører til alvorlige sikkerhetshendelser i Kubernetes-miljøer. Alle tre leverandørene har beveget seg bort fra langlivede hemmeligheter og over til føderert, kortlivet identitet de siste årene.
EKS Pod Identity lar pods hente midlertidige AWS-legitimasjoner direkte, uten å måtte konfigurere OIDC-tillitsforhold og tvungen CA-rotasjon manuelt slik den eldre IRSA-metoden (IAM Roles for Service Accounts) krevde. Dette forenkler oppsettet betydelig og reduserer risikoen for feilkonfigurerte tillitspolicyer. Azure AKS Workload Identity følger samme grunnprinsipp, der Kubernetes-service accounts føderer med Microsoft Entra ID for å hente Azure-ressurstilgang uten lagrede nøkler i klyngen. Google sin tilsvarende løsning, Workload Identity Federation for GKE, kobler Kubernetes-service accounts direkte til Google Cloud IAM.
GKE Autopilot skiller seg ut på sikkerhetssiden ved at Google håndhever en rekke sikkerhetsinnstillinger som standard, inkludert begrensninger på privilegerte containere, obligatorisk bruk av Shielded Nodes, og automatisk patching av den underliggende node-infrastrukturen. Dette gir Autopilot et sterkere “sikker som standard”-utgangspunkt enn Standard-modus på alle tre plattformer, der teamet selv må konfigurere tilsvarende beskyttelse manuelt. For team med begrenset sikkerhetskompetanse internt kan dette være en avgjørende faktor, spesielt gitt hvor mange Kubernetes-relaterte CVE-er som har blitt avdekket i 2026, inkludert containerd-sårbarheter som direkte rammer både EKS og GKE og en kritisk AKS-sårbarhet med CVSS-score på 9,4 som Microsoft måtte patche i stor skala.
Nodegrenser og skalerbarhet
For store organisasjoner er det tekniske taket på klyngestørrelse ofte relevant, selv om de færreste team i Norden noensinne kommer i nærheten av grensene. Standard Kubernetes-arkitektur støtter offisielt opptil 5000 noder og 110 pods per node som anbefalt maksimum, et tall som gjelder som utgangspunkt for både EKS, AKS og GKE siden alle tre bygger på samme underliggende Kubernetes-kjerne.
I praksis er det sjelden selve node-taket som setter grensen, men heller etcd-ytelse, API-server-kapasitet og nettverksadressering (CIDR-størrelse) som avgjør hvor stort en klynge realistisk kan bli før den trenger å deles opp i flere klynger. GKE har historisk vært mest åpen om disse praktiske grensene i sin dokumentasjon, med detaljerte kvoter for antall noder per nodepool og antall nodepools per klynge. EKS og AKS publiserer lignende kvoter, men disse kan ofte økes ved å kontakte support dersom virksomheten har et legitimt behov for større skala.
| Grense | Amazon EKS | Azure AKS | Google GKE |
|---|---|---|---|
| Maks noder per klynge (standard kvote) | Opptil 450 uten support-forespørsel | Opptil 5000 (Standard-tier) | Opptil 15 000 på Standard-modus |
| Maks pods per node | Avhenger av instanstype/CNI | 250 med overlay-nettverk | 110 som standard |
| Maks nodepools per klynge | Ubegrenset praktisk sett | 100 | Opptil 100 (kvote-avhengig) |
| Kan økes via support? | Ja | Ja | Ja |
Disse tallene er praktiske øvre grenser dokumentert av leverandørene selv, og de færreste organisasjoner i Norden nærmer seg dem. Et typisk mellomstort norsk teknologiselskap kjører sjelden mer enn 20-50 noder totalt på tvers av alle miljøer, noe som betyr at alle tre plattformene har mer enn nok hodeplass til å vokse i mange år uten å måtte tenke på disse taket i det hele tatt.
Nettverk og CNI: hvordan pod-trafikk faktisk flyter
Nettverksarkitekturen under panseret påvirker både ytelse og hvor mange pods du kan kjøre per node, noe som ofte overraskes team som planlegger store klynger. Amazon EKS bruker som standard AWS VPC CNI, som tildeler hver pod en ekte IP-adresse fra VPC-en din. Det gir sømløs integrasjon med sikkerhetsgrupper og andre AWS-nettverksressurser, men det betyr også at antall pods per node begrenses av hvor mange nettverksgrensesnitt og sekundære IP-adresser instanstypen støtter, ikke bare av CPU og minne. Store instanser som m5.xlarge støtter typisk rundt 58 pods, mens mindre instanser kan være begrenset til under 20.
Azure AKS lar deg velge mellom kubenet, som er enklere men gir mindre fleksibilitet på IP-adressering, og Azure CNI, som ligner AWS-modellen ved å gi pods egne IP-er fra det virtuelle nettverket. Nyere AKS-klynger anbefales som regel å kjøre Azure CNI Overlay, som reduserer IP-adresseforbruket betraktelig sammenlignet med tradisjonell Azure CNI, siden pod-IP-er da hentes fra et eget overlay-nettverk i stedet for å spise opp adresser fra hovednettverket ditt.
Google GKE bruker en VPC-native arkitektur som standard, der pods får IP-adresser fra sekundære IP-områder (alias IP ranges) i VPC-en. Dette er konseptuelt likt AWS-modellen, men GKE har historisk vært mer fleksibel på hvor mange pods du kan pakke per node, med et standardtak på 110 pods per node uavhengig av instansstørrelse, så lenge du har planlagt IP-området stort nok på forhånd. For lastbalansering tilbyr alle tre native integrasjon: AWS Load Balancer Controller for EKS, Azure Application Gateway Ingress Controller for AKS, og GKE Ingress-kontrolleren som er innebygd i plattformen.
| Nettverksegenskap | Amazon EKS | Azure AKS | Google GKE |
|---|---|---|---|
| Standard CNI | AWS VPC CNI | Azure CNI Overlay / kubenet | VPC-native (alias IP ranges) |
| Maks pods per node (typisk) | ~17-58, avhenger av instanstype | Opptil 250 med overlay | Opptil 110 som standard |
| Pod-IP-modell | Ekte VPC-IP per pod | Overlay-nettverk eller ekte VPC-IP | Alias-IP fra sekundært CIDR |
| Innebygd ingress-kontroller | AWS Load Balancer Controller | Application Gateway Ingress Controller | GKE Ingress |
| Nettverkspolicy-støtte | Calico eller VPC CNI network policy | Azure Network Policy / Calico | Innebygd Dataplane V2 (Cilium-basert) |
Observability: overvåking, logging og feilsøking
Ingen administrert Kubernetes-tjeneste er komplett uten gode verktøy for å se hva som faktisk skjer inne i klyngen når noe går galt. Amazon EKS integrerer nativt med Amazon CloudWatch Container Insights, som samler metrikker og logger fra både kontrollplan og arbeidsnoder, samt AWS X-Ray for distribuert sporing på tvers av mikrotjenester. Mange team velger likevel å legge til Prometheus og Grafana på toppen for mer detaljert, Kubernetes-native metrikkinnsamling, siden CloudWatch alene kan bli kostbart ved høyt metrikkvolum.
Azure AKS kobler seg til Azure Monitor og Container Insights, som gir lignende funksjonalitet med logganalyse via Log Analytics-arbeidsområder. AKS har også god native støtte for Managed Prometheus og Managed Grafana som Azure-tjenester, noe som reduserer behovet for å drifte disse selv. Google GKE har trolig det tettest integrerte observability-oppsettet av de tre, med Google Cloud Operations (tidligere Stackdriver) som samler logger og metrikker automatisk fra alle klynger uten ekstra konfigurasjon, pluss innebygd støtte for Managed Service for Prometheus.
Et praktisk poeng verdt å nevne: uansett hvilken plattform du velger, øker kostnaden for logger og metrikker raskt med klyngestørrelse dersom du ikke aktivt filtrerer hva som samles inn. Team som kjører store klynger bør sette opp samplingsregler og retensjonspolicyer tidlig, i stedet for å samle alt som standard og oppdage en overraskende observability-regning måneden etter.
Prissammenligning: reelle månedskostnader for en produksjonsklynge
For å gjøre kostnadsbildet konkret har vi satt opp et scenario med en middels produksjonsklynge: tre arbeidsnoder med fire vCPU og 16 GB minne hver, kjørt kontinuerlig gjennom en hel måned, pluss standard kontrollplan-avgift der det gjelder.
| Kostnadspost | EKS (Standard) | AKS (Standard) | GKE (Standard) | GKE (Autopilot) |
|---|---|---|---|---|
| Kontrollplan/mnd | ~73 USD | 0 USD | ~73 USD (etter gratis klynge) | 0 USD (fakturert via pods) |
| Node-compute (3 noder)/mnd | ~300-360 USD | ~290-350 USD | ~280-340 USD | Inkludert i pod-fakturering |
| Estimert totalsum/mnd | ~373-433 USD | ~290-350 USD | ~353-413 USD | Varierer med faktisk pod-forbruk |
| SLA inkludert i denne prisen | Ja, 99,95 % | Nei, krever Premium | Ja, 99,95 % | Ja, 99,95 % |
Legg merke til at AKS Standard fremstår billigst i dette scenarioet nettopp fordi kontrollplanet er gratis, men uten en formell SLA på selve kontrollplanet i det nivået. Skal du ha SLA-dekning tilsvarende EKS og GKE, må du legge til rundt 73 dollar i måneden for AKS Premium, noe som gjør de tre nesten identiske i pris når du sammenligner like tjenestenivåer. GKE Autopilot kan bli billigere enn alle de andre for arbeidslaster med lav og ujevn utnyttelse, siden du kun betaler for faktisk forbrukte ressurser i stedet for hele noder, men det kan også bli dyrere for jevnt høyt belastede klynger sammenlignet med reserverte eller spot-baserte noder på Standard-modus.
FinOps og kostnadsstyring på tvers av de tre plattformene
FinOps-praksisen, formalisert av FinOps Foundation, handler om å samle finans, utvikling og drift rundt en felles forståelse av skykostnader i sanntid, i stedet for å oppdage overforbruk først når regningen kommer. Alle tre skyleverandørene har innebygde kostnadsverktøy: AWS Cost Explorer og Cost and Usage Reports for EKS, Azure Cost Management for AKS, og Google Cloud Billing-rapporter for GKE. I tillegg finnes åpen kildekode-verktøy som OpenCost, som kan settes opp på under 30 prosent av tiden det tar å bygge egne kostnadsrapporter, og som gir en leverandøruavhengig visning av Kubernetes-kostnader ned til namespace- og pod-nivå, noe som gjør det enklere å sammenligne reell forbrukskostnad mellom EKS, AKS og GKE-klynger i et multisky-oppsett.
For nordiske virksomheter som opererer under strenge kostnadsbudsjetter og ofte har flere skykontoer på tvers av avdelinger, er evnen til å tagge ressurser konsekvent og eksportere kostnadsdata til et sentralt dashbord ofte viktigere enn selve listeprisen på kontrollplanet. Her har alle tre leverandørene forbedret seg betydelig i 2026, med bedre native integrasjon mot tredjeparts FinOps-plattformer og mer detaljert kostnadsallokering per Kubernetes-namespace.
Fordeler og ulemper: EKS
Amazon EKS passer best for organisasjoner som allerede har mesteparten av infrastrukturen sin i AWS og ønsker tett integrasjon med tjenester som IAM, VPC-nettverk og et bredt utvalg av instanstyper, inkludert Graviton-baserte ARM-noder for lavere kostnad.
- Fordeler: Modent økosystem med Karpenter for rask og kostnadseffektiv autoskalering, bred instansutvalg inkludert Graviton, sterk IAM-integrasjon via Pod Identity, stort community og mange tredjepartsverktøy.
- Ulemper: Kontrollplanet koster alltid noe (ingen gratis tier), historisk noe tregere til å adoptere de aller nyeste Kubernetes-versjonene sammenlignet med GKE, og oppsett kan oppleves mer komplekst for team uten AWS-erfaring fra før.
Fordeler og ulemper: AKS
Azure AKS er det naturlige valget for virksomheter som allerede er tungt investert i Microsoft-økosystemet, spesielt de som bruker Entra ID, Azure DevOps eller andre Microsoft 365-relaterte tjenester i daglig drift.
- Fordeler: Gratis kontrollplan i Standard-tier gjør det billigst for mange små og mellomstore klynger, sterk integrasjon med Microsoft Entra ID via Workload Identity, toårig LTS-opsjon på Premium for regulerte bransjer, og ofte raskest klargjøringstid.
- Ulemper: Ingen formell SLA på kontrollplanet uten å oppgradere til Premium, autoskaleringsverktøyene har historisk vært mindre avanserte enn Karpenter, og enkelte avanserte funksjoner ruller ofte ut noe senere enn hos AWS og Google.
Fordeler og ulemper: GKE
Google GKE er ofte førstevalget for team som prioriterer rask adopsjon av nye Kubernetes-funksjoner, siden Google selv er en av de største bidragsyterne til Kubernetes-prosjektet og gjerne ruller ut nye versjoner raskest av de tre.
- Fordeler: Raskest til å tilby nye Kubernetes-versjoner (1.37 i Rapid-kanal etter bare tre uker), Autopilot-modus reduserer driftsbyrde og sikrer strengere standardinnstillinger, sterk BigQuery- og dataintegrasjon for analytiske arbeidslaster.
- Ulemper: Autopilot gir mindre kontroll over spesifikk maskinvare og instansvalg, prismodellen kan være vanskeligere å forutsi for ujevne arbeidslaster, og mindre markedsandel i Norden enn AWS og Azure kan bety færre lokale konsulenter med dyp GKE-erfaring.
Fem konkrete bruksområder: hvilken tjeneste passer når?
I stedet for å lete etter én universell vinner, er det mer nyttig å matche valget mot konkrete scenarioer team faktisk står i.
- Startup med begrenset budsjett og flere miljøer: AKS Standard er ofte billigst siden du slipper kontrollplan-avgift for hvert test-, staging- og produksjonsmiljø.
- Finansaktør med strenge compliance-krav: AKS Premium med toårig LTS gir lengst mulig tid mellom tvungne versjonsoppgraderinger, noe som passer godt for norske banker og forsikringsselskaper under strenge endringsregimer.
- AI/ML-arbeidslaster med behov for GPU og rask iterasjon: GKE har historisk hatt sterk støtte for TPU/GPU-orkestrering og rask tilgang til nye Kubernetes-funksjoner som gagner ML-pipeliner.
- E-handelsplattform med svingende trafikk (kampanjer, sesongtopper): EKS med Karpenter gir rask, kostnadseffektiv autoskalering som reagerer på trafikktopper i sanntid uten manuell inngripen.
- Team uten dedikert plattformingeniør: GKE Autopilot krever minst Kubernetes-ekspertise internt siden Google håndterer node-drift og standard sikkerhetsherding automatisk.
Disse fem scenarioene overlapper naturligvis i praksis. En norsk fintech-startup kan for eksempel starte på AKS Standard for å holde kostnadene lave i tidlig fase, for så å vurdere en oppgradering til Premium-tier når selskapet blir underlagt strengere finanstilsyn og trenger dokumentert SLA-dekning. Tilsvarende ser man ofte at team som starter med GKE Autopilot for enkelhets skyld, etter hvert migrerer utvalgte arbeidslaster til Standard-modus når de trenger finkornet kontroll over spesifikke GPU-typer for tyngre ML-treningsjobber.
Det viktigste rådet på tvers av alle scenarioene er å teste den faktiske arbeidslasten din på minst to av plattformene før du bestemmer deg, i stedet for å basere valget kun på prislister. Kjør en representativ del av produksjonstrafikken i en pilotklynge over et par uker, mål faktisk kostnad, latency og operasjonell overhead, og la de tallene, ikke bare de offisielle prisarkene, styre den endelige beslutningen.
Multisky-strategi: kan du kombinere EKS, AKS og GKE?
Flere store nordiske virksomheter kjører i praksis mer enn én av disse tjenestene samtidig, ofte som følge av oppkjøp, avdelinger som har tatt egne skyvalg, eller bevisste strategier for å unngå å bli for avhengig av én enkelt leverandør. Verktøy som Terraform, Crossplane og Cluster API gjør det mulig å definere og administrere klynger på tvers av EKS, AKS og GKE med samme kodebase, selv om hver plattform fortsatt krever leverandørspesifikke moduler for ting som identitet og lastbalansering.
Federasjonsverktøy som Karmada eller Google sin Multi Cluster Ingress lar deg rute trafikk på tvers av klynger i forskjellige skyer, noe som er nyttig for katastrofegjenoppretting eller for å plassere arbeidslaster nærmere sluttbrukere i ulike geografiske regioner. Men kompleksiteten ved å drifte ekte multisky-Kubernetes bør ikke undervurderes: du dobler eller tripler antall systemer å patche, overvåke og feilsøke, og de fleste team bør ha en solid grunn, som regulatoriske krav om leverandøruavhengighet eller spesifikke ytelsesbehov, før de velger denne veien fremfor å konsolidere på én plattform.
For virksomheter som vurderer multisky primært av kostnadshensyn, er rådet som regel å heller optimalisere bruken innenfor én plattform først. Gevinsten ved å forhandle bedre volumrabatter eller reserverte instanser hos én leverandør overgår ofte besparelsen man håper å hente ved å flytte deler av arbeidslasten til en billigere konkurrent, når man tar med driftskostnaden ved å vedlikeholde flere parallelle Kubernetes-oppsett.
Migreringsguide: fra selvhostet Kubernetes eller mellom skyer
Å migrere en eksisterende Kubernetes-arbeidslast til en administrert tjeneste, eller mellom EKS, AKS og GKE, følger som regel de samme grunnleggende trinnene, selv om detaljene i verktøy varierer.
- Kartlegg alle avhengigheter i eksisterende klynge: ConfigMaps, Secrets, PersistentVolumes, CRD-er og eventuelle skyspesifikke annotasjoner i manifestene.
- Sett opp den nye klyngen med tilsvarende Kubernetes-versjon som kildeklyngen for å unngå API-inkompatibilitet under overgangen.
- Konfigurer identitetsføderasjon på nytt (Pod Identity, Workload Identity eller Workload Identity Federation) siden disse er leverandørspesifikke og ikke overføres automatisk.
- Bruk et verktøy som Velero for å ta sikkerhetskopi av klyngetilstand og persistente volumer, og gjenopprett dem i målklyngen.
- Oppdater DNS og lastbalansering gradvis, for eksempel med vektet DNS-ruting, slik at trafikk flyttes over i kontrollerte trinn i stedet for en brå full cutover.
- Kjør begge klyngene parallelt i en observasjonsperiode (typisk en til to uker) og overvåk feilrater, latency og kostnad før du avvikler den gamle klyngen.
- Oppdater CI/CD-pipeliner, Terraform- eller Pulumi-konfigurasjon, og eventuelle hardkodede referanser til den gamle klyngens API-endepunkt.
- Dobbeltsjekk autoskaleringskonfigurasjon på nytt, siden Karpenter, Cluster Autoscaler og Autopilot har ulik syntaks og oppførsel som ikke overføres direkte fra én plattform til en annen.
Den vanligste fellen team går i under en slik migrering, er å undervurdere hvor mye tid identitets- og nettverksoppsettet tar. Selve pod-manifestene flytter seg som regel greit siden Kubernetes-API-et er standardisert, men IAM-roller, sikkerhetsgrupper, nettverkspolicyer og lastbalanserings-annotasjoner er nesten alltid skyspesifikke og må skrives om fra bunnen.
Vanlige feil ved valg av administrert Kubernetes-tjeneste
Mange team gjør valget mellom EKS, AKS og GKE basert på hvilken skyleverandør de allerede kjenner best, uten å faktisk regne på total driftskostnad over tid, et mønster som ligner det vi har sett i den bredere sky- og Kubernetes-dekningen på tvers av leverandører de siste årene. Det er en forståelig snarvei, men den overser ofte at forskjellen i autoskaleringsmodenhet eller versjonsstøtte kan koste mer i ingeniørtimer enn det du sparer på selve kontrollplan-prisen.
En annen vanlig feil er å sammenligne kun listepriser uten å ta høyde for utgående dataoverføring, som kan variere kraftig mellom leverandørene avhengig av hvor mye trafikk som går ut av skyen versus internt mellom tjenester. Team bør også unngå å anta at nyeste Kubernetes-versjon automatisk er tilgjengelig samtidig på alle tre plattformer, siden vi ser klare forskjeller i utrullingstakt, som demonstrert av GKEs tre uker raskere 1.37-adopsjon sammenlignet med EKS i september 2026.
Verdikt: hvilken administrert Kubernetes-tjeneste vinner i 2026?
Det finnes ikke ett riktig svar, men dataene peker mot klare anbefalinger avhengig av prioritet. Velger du basert på ren kostnad for mange små klynger, vinner AKS Standard på grunn av det gratis kontrollplanet. Velger du basert på modenhet i autoskalering og bredest instansutvalg, vinner EKS med Karpenter. Velger du basert på raskest tilgang til nye Kubernetes-funksjoner og lavest driftsbyrde, vinner GKE, spesielt med Autopilot-modus.
For de fleste nordiske mellomstore og store virksomheter, som ofte allerede har en etablert skyleverandør-relasjon fra andre deler av virksomheten, er det beste rådet å velge tjenesten som matcher eksisterende sky-fotavtrykk fremfor å optimalisere isolert for Kubernetes-prising. Kostnadsforskjellen mellom de tre, når du sammenligner like tjenestenivåer med SLA, er som vist i tabellene over sjelden mer enn 15-20 prosent, mens kostnaden ved å drifte to separate skyøkosystemer parallelt som regel er langt høyere enn det du sparer på selve Kubernetes-regningen.
Ser vi fremover mot resten av 2026 og inn i 2027, er det verdt å følge med på tre ting spesielt. For det første hvor raskt EKS lukker gapet til GKE på ny versjonsstøtte, siden tre ukers forsprang i september 2026 kan vokse eller krympe avhengig av hvordan AWS prioriterer ressurser fremover. For det andre hvordan AKS sin gratis kontrollplan-modell påvirker de to andre leverandørenes prisstrategi, siden konkurransepress historisk har ført til at prismodeller i skybransjen justeres når én aktør skiller seg vesentlig ut. For det tredje hvordan Autopilot-lignende, hands-off driftsmodeller sprer seg til EKS og AKS, siden EKS Auto Mode allerede er et tegn på at AWS beveger seg i samme retning som Google har ledet an på i flere år.
Ofte stilte spørsmål om EKS, AKS og GKE
Er GKE virkelig gratis for én klynge?
Google gir historisk bort kontrollplan-avgiften for én zonal klynge per faktureringskonto, men dette gjelder ikke automatisk for alle kontotyper og kan endres, så sjekk alltid gjeldende vilkår på Google Cloud sin offisielle prisside før du planlegger budsjettet rundt det.
Kan jeg bytte fra EKS til AKS eller GKE uten å skrive om applikasjonene?
Selve applikasjonskoden og standard Kubernetes-manifester flytter seg som regel uten endringer siden Kubernetes-API-et er standardisert på tvers av leverandører, men identitetshåndtering, lastbalansering og lagringsklasser er skyspesifikke og må konfigureres på nytt.
Hvilken av de tre har best støtte for GPU-arbeidslaster?
Alle tre støtter GPU-noder for AI/ML-arbeidslaster, men GKE har historisk hatt tettest integrasjon med Googles egen TPU-maskinvare i tillegg til standard GPU-støtte, noe som gjør den attraktiv for team som allerede bruker Google sin AI-stack.
Trenger jeg AKS Premium hvis jeg bare kjører ett produksjonsmiljø?
Hvis du trenger en formell, kompensasjonsberettiget SLA på kontrollplanet, bør du oppgradere til Premium. Kjører du en mindre kritisk arbeidslast der noen minutters nedetid ikke er katastrofalt, kan Standard-tier være tilstrekkelig og billigere.
Hvor lang tid tar det å sette opp en produksjonsklar klynge fra bunnen?
Selve klyngeprovisjoneringen tar typisk 10 til 15 minutter på tvers av alle tre, men et fullt produksjonsklart oppsett med nettverk, identitet, overvåking og CI/CD-integrasjon tar som regel flere dager til et par uker avhengig av kompleksiteten i arbeidslastene.
Er Karpenter tilgjengelig på AKS og GKE, eller bare EKS?
Karpenter er utviklet av AWS og er tettest integrert med EKS, men det finnes eksperimentelle eller community-drevne tilpasninger for andre plattformer. Standard-anbefalingen for AKS er Cluster Autoscaler, og for GKE er det enten Cluster Autoscaler i Standard-modus eller den innebygde Autopilot-skaleringen.
Hvilken tjeneste er mest brukt globalt i 2026?
Ifølge Mordor Intelligence sin 2026-markedsrapport har Amazon EKS størst andel av det administrerte Kubernetes-markedet med rundt 30 prosent og over 2 millioner aktive kunder, men andre analyser anslår EKS-andelen enda høyere, opp mot 42 prosent, avhengig av metodikk og hvilket segment som måles.
Må jeg oppgradere Kubernetes-versjonen manuelt, eller skjer det automatisk?
Alle tre leverandørene tilbyr automatiske oppgraderingskanaler du kan aktivere, men mange produksjonsteam velger manuell eller planlagt oppgradering for å teste kompatibilitet først, spesielt siden versjon 1.37 introduserte flere brytende endringer som avviklet IPVS-modus og fjernet statiske pod-hemmeligheter.
