Cloudflare Workers vs Azure AKS: 2ms mot 200ms [2026]

Skal du bygge en global API som svarer på millisekunder i Oslo, Stockholm og København, eller trenger du et fullverdig cluster som kjører hundrevis av mikrotjenester med tung tilstand og strenge compliance-krav? Det er akkurat det valget flere nordiske utviklerteam står i nå, og de to plattformene som stadig oftere havner mot hverandre i den samtalen er Cloudflare Workers og Azure Kubernetes Service (AKS). Den ene kjører koden din i tusenvis av små V8-isolater spredt over hele kloden. Den andre gir deg full kontroll over containere, noder og nettverk i et Azure-datasenter du selv velger.

Begge plattformene har hatt en tett august 2026. Cloudflare har rullet ut nativ TCP- og gRPC-støtte i Workers, kuttet kaldstart for isolater til rundt 2 ms, og hevet CPU-grensen for betalende kunder fra 30 til 50 sekunder per forespørsel. Microsoft har på sin side gjort Managed Prometheus generelt tilgjengelig i AKS og lagt til akselerert AI-inferens med NVIDIA Dynamo. De to plattformene løser i bunn og grunn ulike problemer, men grensen mellom dem blir stadig mer utydelig, og det gjør sammenligningen mer relevant enn noen gang for team som skal ta en arkitekturbeslutning i 2026.

Denne artikkelen går gjennom spesifikasjoner, priser, kaldstart- og ytelsestall fra flere uavhengige kilder, sikkerhet og compliance for nordiske team, fem konkrete bruksscenarier, en migreringsguide og en tallbasert anbefaling. Alle tall er hentet fra offisiell Cloudflare- og Microsoft-dokumentasjon per august 2026, med kildehenvisninger underveis. Vi ser også på utvikleropplevelsen, altså hvor mye tid teamet ditt faktisk bruker på verktøy og drift fremfor å skrive forretningslogikk, siden det ofte veier like tungt som selve prislappen når et team skal velge plattform for de neste tre til fem årene.

Cloudflare Workers og Azure Kubernetes Service: to arkitekturfilosofier

Kubernetes bygger på en idé fra tidlig 2010-tall: pakk applikasjonen i containere, la et orkestreringslag planlegge dem på tvers av noder, og gi driftsteamet full kontroll over ressurser, nettverk og skalering. Azure Kubernetes Service er Microsofts administrerte versjon av dette, der Azure drifter kontrollplanet mens du selv styrer arbeidsnodene. Det er den samme modellen som ligger bak Amazons EKS og Googles GKE, bare med Azures nettverk, identitetsstyring og prismodell rundt seg. For norske selskaper som allerede har mesteparten av infrastrukturen sin i Azure, gjennom Active Directory, Office 365 eller andre Microsoft-tjenester, er AKS ofte det naturlige valget rett og slett fordi identitetsstyring og fakturering allerede henger sammen med resten av miljøet.

Cloudflare Workers snur modellen på hodet. I stedet for containere som kjører på faste noder, kjører koden din i V8-isolater, de samme lettvekts sandkassene som isolerer faner i Chrome-nettleseren. En isolat starter på millisekunder, krever ikke et helt operativsystem, og kan spinnes opp og ned tusenvis av ganger i sekundet uten at brukeren merker noe. Cloudflare kaller dette edge compute, fordi koden kjører fysisk nærmest mulig sluttbrukeren, i et av over 300 byer der selskapet har infrastruktur, i stedet for i én sentral Azure-region.

Forskjellen handler ikke bare om hvor koden kjører, men om hva slags problemer plattformene er bygget for å løse. AKS gir deg et fullverdig operativsystem-nivå av kontroll: du velger VM-type, nettverkspolicyer, lagringsklasser og kan kjøre nesten hva som helst som lar seg pakke i en container, inkludert tunge databaser, GPU-arbeidslaster og langvarige batch-jobber. Cloudflare Workers er i stedet optimalisert for korte, hendelsesdrevne funksjoner, HTTP-forespørsler, API-endepunkter og enkel tilstand via Durable Objects, KV og D1, uten at du noensinne trenger å tenke på en node eller et cluster.

Begge plattformene har beveget seg mot hverandre de siste to årene. Cloudflare har lagt til `@cloudflare/computer`, en runtime som kan flytte tunge AI- og agentarbeidslaster fra lette V8-isolater over til fulle Linux-containere ved behov, samt nativ gRPC og TCP-støtte fra 3. august 2026. Microsoft har på sin side bygget AKS Automatic, en forhåndskonfigurert klyngetype som fjerner mye av den manuelle oppsettsjobben Kubernetes er kjent for. Likevel forblir de grunnleggende driftsmodellene ulike nok til at valget faktisk betyr noe for arkitekturen din.

Det finnes også et tredje alternativ mange team vurderer underveis: å kombinere begge plattformene i samme system fremfor å velge én. Cloudflare selv omtaler dette som en hybrid-modell, der Workers håndterer det ytterste laget mot brukeren mens tyngre, statefull logikk fortsatt kjører i et tradisjonelt cluster. Den tilnærmingen krever litt mer arkitekturarbeid i starten, men unngår at teamet må velge bort styrkene til den ene plattformen for å få fordelene til den andre.

Spesifikasjoner side om side

Tabellen under samler de viktigste tekniske egenskapene fra begge plattformene, hentet fra offisiell dokumentasjon fra Cloudflare og Microsoft per august 2026.

Egenskap	Cloudflare Workers	Azure Kubernetes Service
Kjøremodell	V8-isolater (serverløs, hendelsesdrevet)	Containere planlagt på VM-noder
Kaldstart	~1–10 ms, ned mot ~2 ms etter workerd 1.2026.08	~200 ms–2 s med varm node og cachet image
Skalering fra null	Praktisk talt umiddelbar, per forespørsel	10–60+ sekunder ved oppskalering av nye noder
Maks CPU-tid per forespørsel	10 ms (gratis), inntil 50 sek. for betalende (fra juli 2026)	Ingen plattformgrense, styres av arbeidslasten selv
Maks forespørselsvarighet	~30 sek. typisk for HTTP-svar	Ingen hard grense, styres av ingress/load balancer (ofte 30–240 sek.)
Global tilstedeværelse	300+ byer i 100+ land	60+ Azure-regioner globalt
Tilstand/database	Durable Objects, Workers KV, D1 (SQL)	Ingen innebygd, bruker Azure SQL, Cosmos DB, disker
Runtime-versjon (aug. 2026)	workerd 1.2026.08, V8 15.2	Kubernetes 1.30–1.35, Istio 1.28-støtte
Observability	Workers Analytics, Logpush	Azure Managed Prometheus (GA 13. aug. 2026)
AI/GPU-arbeidslaster	Workers AI, egne isolater for lette modeller	Full GPU-nodestøtte, NVIDIA Dynamo-akselerasjon
Nettverksprotokoller	HTTP, WebSockets, nativ TCP og gRPC (fra 3. aug. 2026)	Alt som kan kjøre i en container, inkl. egne protokoller
Driftsansvar	Ingen noder, ingen patching, ingen cluster å vedlikeholde	Du styrer node-oppgraderinger, nettverkspolicy, RBAC
Gratis nivå	Ja, 100 000 forespørsler/dag	Ja, kontrollplan uten kostnad, men du betaler for VM-noder

Noen av radene fortjener en presisering. Kaldstart-tallene er ikke direkte sammenlignbare i praksis, fordi en Worker starter på nytt for hver forespørsel som treffer en kald isolat, mens et AKS-cluster som regel holder poder varme og kjørende kontinuerlig. Det betyr at AKS sjelden opplever kaldstart i det hele tatt for et system i normal drift, mens kaldstart-tallet for Workers er relevant for absolutt hver eneste forespørsel som ikke allerede har en varm isolat tilgjengelig i nærheten.

Nettverksstøtten er også verdt å se nærmere på. Frem til august 2026 var Cloudflare Workers begrenset til HTTP og WebSockets, noe som utelukket en god del tradisjonelle backend-protokoller. Med nativ TCP- og gRPC-støtte fra 3. august kan Workers nå fungere som gRPC-servere eller klienter og rute rå TCP-sokler direkte til Durable Objects eller backend-containere, ifølge Cloudflares endringslogg. Det tetter et av de mest åpenbare hullene mellom edge-modellen og et fullverdig Kubernetes-cluster.

Verdt å nevne er også hvordan de to plattformene håndterer polyglot-arkitektur, altså systemer skrevet i flere programmeringsspråk. Cloudflare utvidet i august 2026 Workers RPC til å støtte deling av objekter på tvers av Python og JavaScript i sanntid, slik at metoder kan kalles direkte mellom språkene uten manuell serialisering til JSON eller Protobuf. AKS løser det samme problemet på en helt annen måte: siden alt kjører som containere, kan hver mikrotjeneste skrives i hvilket som helst språk og kommunisere via standard nettverksprotokoller, uten noen begrensning fra selve plattformen. Begge løsningene fungerer godt, men de krever ulik tankegang fra teamet som skal designe systemet.

Priser i 2026: hva koster de reelt?

Prismodellene er så ulike at en direkte sammenligning krever et konkret scenario. Cloudflare fakturerer per forespørsel og CPU-millisekund, mens Azure fakturerer per virtuell maskin og time, uavhengig av hvor mye trafikk den faktisk håndterer.

Kostnadselement	Cloudflare Workers	Azure Kubernetes Service
Gratisnivå	100 000 forespørsler/dag, 10 ms CPU/forespørsel	Kontrollplan uten kostnad (Free-nivå), men noder koster
Minstebeløp betalt plan	$5/mnd (Workers Paid)	$0 (Free) eller ~$73/mnd (Standard kontrollplan)
Inkludert i grunnpris	10 mill. forespørsler + 30 mill. CPU-ms/mnd	Ingen forespørselskvote, betaling er per VM-time
Pris per ekstra 1 mill. forespørsler	$0,30	Ikke relevant (VM-basert, ikke forespørselsbasert)
Eksempel: 3 noder Standard_D2s_v5	Ikke relevant	~$210/mnd (Free kontrollplan) / ~$283/mnd (Standard)
Durable Objects (tilstand)	1 mill. forespørsler inkl., deretter $0,15/mill.	Ikke relevant, tilstand løses via Azure-tjenester
D1 (SQL-database)	25 mrd. rader lest/mnd inkl., deretter $0,001/mill.	Bruker Azure SQL eller Cosmos DB, separat fakturert
Workers KV (nøkkel-verdi)	10 mill. lesinger/mnd inkl., deretter $0,50/mill.	Ikke relevant
SLA på kontrollplanet	Ikke separat priset, del av plattformen	99,95 % med Standard-nivå og tilgjengelighetssoner
Skalering til null trafikk	Betaler kun for faktisk bruk, ned til $0	Nodene koster selv uten trafikk, med mindre du skalerer ned manuelt

Tallene for AKS-kostnaden er hentet fra Convox’ 2026-analyse av et typisk 3-node cluster med D2as_v5-instanser, samt Azures offisielle prisside for kontrollplanet. Et lite produksjonscluster med tre noder av typen Standard_D2s_v5, som gir 2 vCPU og 8 GB RAM per node, lander på rundt $210 i måneden med gratis kontrollplan, eller $283 hvis du velger Standard-nivået med 99,95 % SLA og støtte for tilgjengelighetssoner. Den kostnaden løper uansett hvor mye eller lite trafikk clusteret faktisk håndterer.

Cloudflare snur regnestykket. En Worker som håndterer noen tusen forespørsler i døgnet koster ingenting utover gratisnivået. En Worker som håndterer 10 millioner forespørsler i måneden koster $5, selv om trafikken kommer i ujevne støt gjennom hele døgnet. Det gjør Workers vesentlig billigere for arbeidslaster med lavt eller variabelt volum, mens AKS blir mer kostnadseffektivt jo høyere og jevnere trafikken er, fordi du da faktisk utnytter kapasiteten du allerede betaler for. Krysningspunktet ligger typisk et sted mellom 50 og 200 millioner forespørsler i måneden for en enkel API, avhengig av hvor CPU-tung hver forespørsel er.

For å gjøre regnestykket konkret er det nyttig å se på et par typiske trafikkscenarier. Tabellen under viser omtrentlig månedskostnad for en enkel API ved tre ulike trafikknivåer, basert på Cloudflares publiserte priser og et minimalt AKS-cluster med tre noder av typen Standard_D2s_v5.

Trafikknivå	Cloudflare Workers	AKS (3 noder, Standard kontrollplan)
1 million forespørsler/mnd	~$5/mnd (grunnpris dekker volumet)	~$283/mnd (fast kostnad uansett volum)
50 millioner forespørsler/mnd	~$17/mnd (10M inkl. + $0,30 per ekstra mill.)	~$283/mnd (samme fast kostnad)
500 millioner forespørsler/mnd	~$152/mnd (avhenger av CPU-tid per kall)	~$283–500+/mnd (kan kreve flere/større noder)

Tabellen forenkler et par ting. Cloudflare-kostnaden avhenger sterkt av hvor CPU-tung hver forespørsel er, ikke bare antallet, så en Worker som gjør tung databehandling per kall vil koste mer enn tabellen antyder. AKS-kostnaden ved 500 millioner forespørsler forutsetter at de tre opprinnelige nodene fortsatt har kapasitet, noe som sjelden stemmer i praksis, og de fleste team vil skalere opp til flere eller større noder lenge før man når det volumet. Poenget som likevel består: AKS-kostnaden er nesten flat uansett trafikk innenfor kapasiteten til clusteret, mens Workers-kostnaden vokser gradvis og forutsigbart med faktisk bruk.

Ytelse og kaldstart: hva sier benchmarkene

Kaldstart er der forskjellen mellom de to plattformene blir tydeligst i praksis. Cloudflares egen endringslogg viser at workerd-versjon 1.2026.08, sluppet 1. august 2026, kuttet oppstartstiden for en kald isolat fra rundt 6 millisekunder til omtrent 2 millisekunder, gjennom raskere deserialisering av V8-øyeblikksbilder. Det er en forbedring på over 60 prosent på et tall som allerede var svært lavt sammenlignet med tradisjonelle containere.

Convox’ 2026-gjennomgang av Kubernetes-drift, publisert på convox.com, peker i en annen retning: et AKS-cluster i normal drift har i praksis ingen kaldstart, fordi podene holdes varme kontinuerlig. Kostnaden ved den modellen er at du betaler for kapasitet du kanskje ikke bruker, mens en Worker alltid starter fra et kaldt eller varmt utgangspunkt avhengig av trafikkmønsteret akkurat da. Når AKS derimot må skalere opp fra null noder, for eksempel etter en periode uten trafikk med aggressiv nedskalering aktivert, tar det typisk mellom 10 og 60 sekunder før den første nye poden er klar til å ta imot trafikk, ifølge samme analyse.

Den tredje kilden er Kubernetes’ egen dokumentasjon om utgivelsessyklusen, som viser at prosjektet nå leverer tre store versjoner i året med om lag 14 måneders støttevindu per versjon. Det er relevant for ytelsessammenligningen fordi det betyr at et AKS-cluster krever jevnlige, planlagte oppgraderinger for å holde seg innenfor support, noe som i seg selv påvirker driftskostnaden og risikoen for ytelsesregresjon ved hver oppgradering. En Worker har ingen tilsvarende oppgraderingssyklus for deg som utvikler, fordi Cloudflare drifter og oppdaterer runtime-laget kontinuerlig i bakgrunnen.

For gjennomstrømming, altså hvor mange forespørsler systemet klarer å håndtere samtidig, snur bildet seg. Et AKS-cluster med store noder og godt optimaliserte containere kan pakke langt mer CPU- og minnetung logikk per enhet enn en Worker, som er begrenset til 128 MB minne og en CPU-tidsgrense selv på betalt plan. For arbeidslaster som video-transkodering, tunge ML-inferenser med store modeller eller batch-databehandling er AKS fortsatt det klart mer kapable verktøyet, mens Workers vinner på responstid for korte, hyppige, globalt distribuerte kall.

Utvikleropplevelse: verktøy og arbeidsflyt

Ytelsestall forteller bare halve historien. Den andre halvparten handler om hvor mye tid teamet ditt faktisk bruker på å bygge, teste og drifte systemet dag til dag. Cloudflare Workers bruker Wrangler som kommandolinjeverktøy, og en ny utvikler kan skrive, teste lokalt med `wrangler dev` og deploye en fungerende funksjon på under en time uten å røre en eneste YAML-fil for infrastruktur. Konfigurasjonen ligger i én enkelt `wrangler.toml`-fil, versjonskontrollert sammen med koden, og selve utrullingen skjer med én kommando.

AKS krever et helt annet sett med ferdigheter. Du trenger `kubectl` for å kommunisere med clusteret, sannsynligvis Helm eller Kustomize for å pakke og versjonere manifester, og som regel et eget CI/CD-verktøy som ArgoCD eller Flux for å holde produksjonsclusteret synkronisert med det som ligger i Git. Det gir langt mer fleksibilitet, men også en brattere læringskurve. Et team uten tidligere Kubernetes-erfaring bør regne med flere uker, ikke timer, før de har et stabilt, sikkert oppsett i produksjon, selv med AKS Automatic som fjerner en del av den manuelle nodekonfigurasjonen.

Feilsøking skiller seg også markant. I Workers ser du logger og feilmeldinger direkte gjennom Cloudflares dashbord eller Logpush, uten å måtte tenke på hvilken node eller pod feilen oppsto i, fordi det konseptet ikke finnes for deg som utvikler. I AKS må du som regel korrelere logger på tvers av flere poder, noder og eventuelt en service mesh som Istio, noe som krever et modent observability-oppsett for å ikke bli en tidkrevende jakt hver gang noe går galt. Microsofts Managed Prometheus, som ble generelt tilgjengelig 13. august 2026, gjør denne jobben enklere, men fjerner ikke behovet for at noen i teamet forstår hvordan man leser Kubernetes-metrikker under press klokken tre om natten.

Global rekkevidde og ventetid for nordiske brukere

For team som betjener brukere i Norge, Sverige, Danmark og Finland betyr geografisk plassering ofte mer for opplevd hastighet enn selve kjøremodellen. Cloudflare har infrastruktur i over 300 byer globalt, ifølge Cloudflares egen produktside, med flere tilstedeværelser i og rundt Norden. Det betyr at en Worker som svarer på en forespørsel fra en bruker i Bergen, som regel gjør det fra et datasenter i regionen, uten at trafikken må krysse Atlanteren eller gå via en sentral europeisk region.

AKS kjører derimot i en spesifikk Azure-region du velger ved oppsett, for eksempel Norway East eller Sweden Central. Microsoft opererer over 60 regioner globalt, men et enkelt cluster er fysisk plassert i én av dem. Det gir deg full kontroll over hvor dataene ligger, noe som er nyttig for compliance, men det betyr også at brukere langt unna den valgte regionen får høyere ventetid enn de ville fått med en global edge-plattform. Løsningen mange velger er en hybrid: statiske ressurser og enkel API-logikk på Cloudflare, tunge tjenester og databaser i et AKS-cluster i en nordisk Azure-region, med Workers som et tynt lag foran.

Forskjellen er størst for trafikk med global spredning. Et nordisk SaaS-selskap med kunder i USA, Asia og Europa vil merke edge-modellens fordel direkte, fordi hver bruker treffer sitt nærmeste datasenter uavhengig av hvor selskapets AKS-cluster er plassert. For et rent nordisk publikum, der de fleste brukerne allerede er nær en Azure-region i Norden, blir latency-forskjellen mindre synlig, og andre faktorer som driftsmodell og kostnad veier tyngre i beslutningen.

Et konkret eksempel gjør forskjellen tydelig. Et norsk mediehus med lesere hovedsakelig i Norge vil merke lite til latency-forskjellen mellom de to plattformene for det meste av trafikken, fordi Azures region i Norway East uansett ligger fysisk nær leserne. Et nordisk fintech-selskap som ekspanderer til Sørøst-Asia eller Nord-Amerika vil derimot se en helt annen effekt, siden hver ny bruker der ute treffer et Cloudflare-datasenter i egen region umiddelbart, mens et rent AKS-basert system ville sendt hver forespørsel hele veien tilbake til Norden med tilhørende ventetid på flere hundre millisekunder.

Sikkerhet, drift og compliance for norske og nordiske team

Begge plattformene håndterer sikkerhet svært ulikt, og det påvirker hvilken som passer best avhengig av bransje. Cloudflare Workers kjører i en delt, multi-tenant infrastruktur der isolasjonen skjer på V8-isolatnivå i stedet for på VM- eller containernivå. Det gir svært rask oppstart, men betyr også at du har mindre direkte kontroll over det underliggende laget enn i et AKS-cluster du selv styrer nettverkspolicyer og RBAC-regler for.

AKS gir deg derimot full kontroll, og dermed også fullt ansvar, over patching av noder, nettverkssegmentering og identitetsstyring. Microsofts Managed Prometheus, som ble generelt tilgjengelig 13. august 2026 ifølge Azures dokumentasjon, gjør det enklere å overvåke kontrollplanet uten å drifte en egen Prometheus-installasjon, men selve sikkerhetsansvaret for arbeidsnodene ligger fortsatt hos deg som kunde.

For norske og nordiske virksomheter som er underlagt GDPR og det skjerpede NIS2-regelverket, er datalokasjon ofte det som avgjør valget mer enn selve sikkerhetsmodellen. AKS gir deg eksplisitt kontroll over hvilken Azure-region dataene lagres og behandles i, noe som gjør compliance-dokumentasjon enklere for revisorer som spør konkret hvor persondata befinner seg. Cloudflare tilbyr regionale kontroller for kunder med slike krav, men den globale, distribuerte naturen til edge-nettverket krever mer eksplisitt konfigurasjon for å garantere at data ikke forlater EU/EØS-området. Begge modellene kan møte kravene, men AKS gjør det med et enklere utgangspunkt for team som allerede er vant til å dokumentere infrastruktur i detalj for revisjon.

Hendelseshåndtering er også verdt å tenke gjennom før du velger. Med AKS eier du hele stabelen, fra operativsystem til applikasjon, noe som betyr at du selv må ha rutiner for å patche sårbarheter i noder og containere, følge med på CVE-varsler for både Kubernetes-versjonen og avhengighetene i bildene dine. Med Cloudflare Workers ligger runtime-laget helt utenfor ditt ansvar. Cloudflare patcher og oppdaterer isolat-miljøet kontinuerlig uten at du merker det, men det betyr samtidig at du har mindre innsyn i og kontroll over nøyaktig hvordan den underliggende infrastrukturen er sikret, noe enkelte revisorer og sikkerhetsteam i regulerte bransjer ønsker mer detaljert dokumentasjon på enn en delt, multi-tenant plattform naturlig gir.

Fem virkelige bruksscenarier

Teorien blir tydeligere med konkrete eksempler. Under følger fem realistiske arkitekturmønstre som viser hvor hver plattform faktisk gjør en forskjell i praksis. Alle fem er hentet fra vanlige arkitekturmønstre norske og nordiske team faktisk bygger i dag, ikke hypotetiske idealtilfeller.

Global betalings-API for en nettbutikk: En norsk netthandelsplattform med kunder i hele Norden og videre ut i Europa legger valideringslogikk, rate-limiting og enkel autentisering i Cloudflare Workers foran opprinnelsesserveren. Responstiden holder seg lav uavhengig av hvor kunden befinner seg, mens selve ordrebehandlingen fortsatt kjører i et backend-system i Azure.
Sanntids flerspiller-backend: Et spillstudio bygger en chat- eller matchmaking-tjeneste med Durable Objects, som gir hver spilløkt en dedikert, stateful isolat plassert nær spillerne. Den innebygde konsistensmodellen gjør det unødvendig å drifte en egen WebSocket-server i et cluster.
Multi-tenant SaaS-kontrollplan: Et mellomstort SaaS-selskap kjører kjerneapplikasjonen, med tung forretningslogikk og en relasjonsdatabase, i et AKS-cluster i Sweden Central, mens de bruker Workers som et tynt API-gateway-lag for autentisering og caching foran clusteret.
Fintech-transaksjonsbehandling: En betalingsleverandør med strenge krav til revisjonsspor og datalokasjon kjører hele transaksjonsmotoren i AKS med dedikerte noder, nettverkspolicyer og fullstendig logging, der hvert steg i behandlingskjeden kan dokumenteres for en tilsynsmyndighet.
AI-inferens ved kanten kombinert med tung trening i skyen: Et selskap som bygger en kundeserviceassistent bruker Workers AI for lette, lavlatens-modeller som svarer direkte på enkle spørsmål, mens tyngre modelltrening og batch-inferens med NVIDIA Dynamo-akselerasjon kjører i et GPU-utstyrt AKS-cluster.

Et gjennomgående mønster i alle fem eksemplene er at Cloudflare Workers oftest fungerer best som det ytterste laget, tett på brukeren, mens AKS gjør jobben når arbeidslasten krever mer tilstand, kontroll eller ren regnekraft enn en isolat kan tilby. De fleste modne, nordiske teknologiselskaper ender opp med en kombinasjon av begge, ikke et enten-eller-valg. Det som ofte overrasker team som er nye i denne diskusjonen, er hvor lite ekstra kompleksitet en slik hybrid faktisk krever i praksis, siden Workers og AKS kommuniserer over vanlig HTTP eller den nye TCP-støtten uten behov for spesialtilpasset integrasjonskode mellom lagene.

Cloudflare Workers og AKS: fordeler og ulemper

Cloudflare Workers: fordeler og ulemper

Fordel: Ingen noder eller cluster å drifte, patche eller skalere manuelt.
Fordel: Kaldstart ned mot ~2 ms etter workerd 1.2026.08, langt raskere enn containeroppstart.
Fordel: Betal kun for faktisk bruk, ned til $0 ved lav trafikk.
Fordel: Global tilstedeværelse i 300+ byer uten ekstra konfigurasjon for hver region.
Ulempe: Begrenset minne (128 MB) og CPU-tid gjør tunge arbeidslaster upraktiske eller umulige.
Ulempe: Mindre direkte kontroll over den underliggende infrastrukturen, noe som kan komplisere enkelte compliance-krav.
Ulempe: Ingen innebygd relasjonsdatabase på nivå med en fullverdig SQL-tjeneste, du er avhengig av D1 eller eksterne tjenester.

Azure Kubernetes Service: fordeler og ulemper

Fordel: Full kontroll over ressurser, nettverk og sikkerhetspolicy for team med spesifikke krav.
Fordel: Kan kjøre praktisk talt hva som helst, inkludert GPU-tunge AI-arbeidslaster og langvarige batch-jobber.
Fordel: Eksplisitt datalokasjon i en valgt Azure-region, som forenkler GDPR- og NIS2-dokumentasjon.
Fordel: Managed Prometheus (GA aug. 2026) gir innebygd observability uten egen drift.
Ulempe: Node-kostnaden løper uansett trafikkmengde, med mindre du setter opp aggressiv autoskalering.
Ulempe: Krever et driftsteam med reell Kubernetes-kompetanse for sikker og stabil drift.
Ulempe: Oppskalering fra null noder tar 10–60+ sekunder, langt tregere enn en Workers-kaldstart.

Migreringsguide: bytte mellom edge og cluster

De færreste team bytter plattform fullstendig over natten. Den vanligste veien er å flytte enkeltkomponenter gradvis, og teste grundig underveis, slik at en feil i den nye arkitekturen aldri får lov til å ta ned hele produksjonssystemet på én gang. Under følger stegene for en gradvis migrering fra et rent AKS-oppsett til en hybrid med Cloudflare Workers foran, skrevet som en praktisk sjekkliste et driftsteam kan følge uke for uke.

Kartlegg hvilke endepunkter som er rene, statsløse funksjoner (autentisering, rate-limiting, enkel caching), og hvilke som krever tung tilstand eller lange kjøretider.
Sett opp et Cloudflare-domene og pek DNS mot Cloudflares nettverk, uten å endre noe i AKS ennå.
Skriv den første statsløse funksjonen som en Worker, og test den parallelt med den eksisterende AKS-tjenesten via en feature-flag eller vekting av trafikk.
Flytt tilstand som passer for Durable Objects eller D1, for eksempel sesjonsdata eller enkel konfigurasjon, ut av clusteret.
Behold tung forretningslogikk, relasjonsdatabaser og GPU-arbeidslaster i AKS, og la Workers fungere som gateway foran disse tjenestene.
Test ventetid og feilrater fra flere nordiske lokasjoner før du ruter all produksjonstrafikk gjennom det nye laget.
Overvåk CPU-tid per Worker nøye i starten, siden grensen på 10 ms (gratis) eller opptil 50 sek. (betalt) kan overraske team vant til ubegrensede containerressurser.

Et minimalt eksempel på en Worker som fungerer som en enkel gateway foran et AKS-endepunkt, med grunnleggende rate-limiting, kan se slik ut:

export default {
  async fetch(request, env) {
    const ip = request.headers.get("cf-connecting-ip");
    const key = `rl:${ip}`;
    const count = parseInt(await env.RATE_LIMIT_KV.get(key) || "0");

    if (count > 100) {
      return new Response("For mange forespørsler", { status: 429 });
    }

    await env.RATE_LIMIT_KV.put(key, String(count + 1), { expirationTtl: 60 });

    return fetch("https://backend.aks-cluster.example.com" + new URL(request.url).pathname, request);
  }
};

Motsatt retning, fra Workers til et rent AKS-oppsett, er sjeldnere i praksis, men skjer når en arbeidslast vokser forbi det en isolat kan håndtere, for eksempel når CPU-tiden konsekvent nærmer seg grensen eller minnebehovet overstiger 128 MB. Da handler migreringen mest om å pakke den eksisterende logikken i en container, sette opp et cluster med riktig node-type, og gradvis rute trafikk bort fra Workers-endepunktet mens du overvåker feilrater tett.

Hvem bør velge hva? Anbefalinger etter bruksområde

De fem scenarioene over dekker de vanligste mønstrene, men de fleste team vil finne det mer nyttig å gå ut fra egen situasjon fremfor å prøve å matche seg selv mot én av de fem kategoriene direkte. Listen under oppsummerer anbefalingen etter arbeidslast, teamstørrelse og krav, og kan brukes som en rask sjekkliste i et forprosjektnotat før dere setter i gang en større arkitekturbeslutning.

Liten startup eller solo-utvikler med global brukerbase: Velg Cloudflare Workers. Gratisnivået og fraværet av driftsansvar gjør at du kan fokusere på produkt fremfor infrastruktur.
Mellomstor SaaS-bedrift med relasjonsdatabase og tung forretningslogikk: Velg AKS som kjerne, med Workers som valgfritt gateway-lag foran for de statsløse endepunktene.
Fintech eller annen aktør med strenge revisjonskrav: Velg AKS. Eksplisitt datalokasjon og full kontroll over nettverkspolicy veier tyngre enn responstidsgevinsten fra edge.
Spillstudio eller sanntidsapplikasjon med sesjonsbasert tilstand: Velg Cloudflare Workers med Durable Objects, som er bygget spesifikt for denne typen arbeidslast.
Selskap med tunge AI-treningsjobber eller GPU-arbeidslaster: Velg AKS. GPU-nodestøtte og NVIDIA Dynamo-akselerasjon dekker et behov Workers rett og slett ikke er dimensjonert for ennå.
Team uten dedikert driftskompetanse på Kubernetes: Velg Cloudflare Workers, eller vurder AKS Automatic hvis dere likevel trenger cluster-modellen, siden den fjerner mye av den manuelle konfigurasjonsjobben.

Konklusjon: vår vurdering med tall

Det finnes ikke ett riktig svar her, men tallene peker på klare mønstre. Cloudflare Workers vinner på kaldstart (~2 ms mot 200 ms–2 s), på global rekkevidde (300+ byer mot 60+ Azure-regioner), og på kostnad for lav og variabel trafikk, der et gratisnivå på 100 000 forespørsler per dag dekker mange mindre og mellomstore arbeidslaster helt uten kostnad. AKS vinner på ren regnekraft, tilstandshåndtering for komplekse systemer, og eksplisitt kontroll over datalokasjon, noe som gjør plattformen til det tryggere valget for regulerte bransjer som fintech og offentlig sektor. Ingen av plattformene er objektivt bedre, de er bygget for ulike deler av det samme problemet.

For de fleste nordiske team, fra mindre nettbutikker til mellomstore SaaS-selskaper, gir en hybrid mest verdi: Workers som det ytterste, globalt distribuerte laget, og AKS som motoren for tung forretningslogikk og data. Rendyrkede valg gir mening i hver sin ende av spekteret, en enkel, global API passer Workers alene, mens et komplekst, GPU-tungt system med strenge revisjonskrav passer AKS alene. De fleste virkelige systemer havner et sted mellom disse to ytterpunktene.

Husk at begge plattformene fortsatt utvikler seg raskt. Cloudflare har levert flere store oppdateringer bare i august 2026, og Microsoft fortsetter å bygge ut AKS Automatic for å lukke gapet på driftskompleksitet. Sett en påminnelse om å revurdere arkitekturvalget hver 12. måned, og bruk migreringsguiden over som utgangspunkt hvis arbeidslasten din har vokst forbi det opprinnelige valget.

Den viktigste lærdommen fra denne sammenligningen er kanskje at spørsmålet “Cloudflare Workers eller AKS” sjelden er det riktige spørsmålet å stille i utgangspunktet. Det riktigere spørsmålet er hvilke deler av systemet ditt som trenger global, lav-latency respons uten tilstand, og hvilke deler som trenger tung regnekraft, kompleks tilstand eller streng kontroll over datalokasjon. Når du har svart på det, følger plattformvalget nesten av seg selv for hver enkelt komponent.

Ofte stilte spørsmål

Er Cloudflare Workers billigere enn AKS?
For lav til middels trafikk, ja. Workers har et reelt gratisnivå og koster fra $5 i måneden for 10 millioner forespørsler, mens et minimalt AKS-cluster med tre noder koster rundt $210–283 i måneden uansett trafikkmengde.

Kan jeg kjøre en hel applikasjon i Cloudflare Workers uten AKS eller annen backend?
For enkle applikasjoner med Durable Objects, KV og D1 som datalag, ja. For applikasjoner med tunge relasjonsdatabaser, store filer eller GPU-arbeidslaster trenger du fortsatt en tradisjonell backend som AKS.

Hvor lang tid tar en migrering fra AKS til en hybrid med Workers?
Regn med to til fire uker for å flytte de første statsløse endepunktene, og flere måneder for en full evaluering av hvilke tjenester som egner seg for edge-modellen i et større system.

Er Cloudflare Workers og AKS kompatible med hverandre?
Ja, i praksis brukes de ofte sammen. Workers kan rute trafikk direkte til et AKS-endepunkt via nativ TCP- eller HTTP-støtte, noe som gjør hybrid-arkitektur til det vanligste mønsteret, ikke unntaket.

Hvilken plattform passer best for norske banker og offentlig sektor?
AKS er ofte tryggere for denne typen aktør, fordi eksplisitt datalokasjon i en valgt Azure-region forenkler dokumentasjon for GDPR og NIS2, selv om Cloudflare også tilbyr regionale kontroller for kunder med slike krav.

Hva er CPU-grensen for en betalende Cloudflare Workers-kunde i 2026?
Grensen ble hevet fra 30 til 50 sekunder CPU-tid per forespørsel i juli 2026, i tillegg til en aggregert pott på 30 millioner CPU-millisekunder inkludert i Workers Paid-planen på $5 per måned.

Trenger jeg Kubernetes-kompetanse for å bruke AKS?
Ja, i noen grad, selv med AKS Automatic. Du bør forstå containere, poder og grunnleggende nettverkskonsepter for å drifte et cluster trygt over tid, selv om Automatic-nivået fjerner mye av den manuelle konfigurasjonsjobben.

Hva skjer med en Worker som overskrider minnegrensen på 128 MB?
Forespørselen feiler med en kjøretidsfeil. Det er et absolutt tak, ikke en myk grense, så arbeidslaster med stort minnebehov må enten optimaliseres kraftig eller flyttes til en plattform som AKS.

Kan jeg bruke AKS Automatic for å slippe det meste av manuell konfigurasjon?
Ja. AKS Automatic gir deg en forhåndskonfigurert, sikkerhetsherdet klynge med fornuftige standardverdier for nettverk og skalering, men du trenger fortsatt grunnleggende forståelse av containere og poder for å drifte den trygt over tid.

Er Cloudflare Workers egnet for GPU-tunge AI-arbeidslaster?
Delvis. Workers AI kan kjøre lette, lavlatens-modeller direkte ved kanten, men tung modelltrening og store batch-inferenser krever fortsatt en plattform med reell GPU-tilgang, som et AKS-cluster med NVIDIA Dynamo-akselerasjon.

Relatert dekning

Les mer om skytjenester i vår samlekategori for skytjenester.

Kilder: Cloudflare Workers-grenser og priser, Cloudflares endringslogg, Cloudflare Workers produktside, Microsofts AKS-dokumentasjon, Azures AKS-prisside, Convox’ analyse av Kubernetes-kostnader, Kubernetes’ utgivelsessyklus og CNCF-rapporter.

Cloudflare Workers vs Azure AKS: 2ms mot 200ms Kaldstart [2026]