Når et nettsted eller en app skal svare på millisekunder uansett om brukeren sitter i Oslo, Tromsø eller Austin, flytter utviklere kode nærmere brukeren i stedet for å sende hver forespørsel til en sentral server. Tre plattformer dominerer denne kampen i 2026: Cloudflare Workers, AWS Lambda@Edge og AWS CloudFront Functions. Alle tre kjører kode i nettverkskanten, men de bygger på helt forskjellige arkitekturer, prismodeller og grenser. Valget påvirker alt fra regningen ved slutten av måneden til hvor mye logikk du faktisk kan kjøre per forespørsel.
Denne sammenligningen går gjennom spesifikasjonene, prisene, ytelsen og de praktiske grensene for alle tre tjenestene, med særlig vekt på hva som gjelder for norske og nordiske team som drifter trafikk mot brukere i Norden. Vi ser også på fem konkrete bruksmønstre, en migreringsguide og en klar anbefaling basert på tallene.
Hva er edge computing, og hvorfor velger norske team mellom disse tre
Edge computing betyr at kode kjører fysisk nær brukeren, i et av leverandørens edge-punkter, i stedet for i en sentral region. Fordelen er lavere nettverkslatens fordi forespørselen ikke trenger å reise til et datasenter på den andre siden av kontinentet. For en bruker i Bergen betyr dette at en forespørsel kan besvares av en nod i Stockholm eller Oslo i stedet for å krysse Atlanteren til et AWS-datasenter i Virginia.
Cloudflare Workers er bygget på V8-isolater, den samme motoren som driver Chrome-nettleseren. Hver isolat starter opp på under et sekund og deler infrastruktur med tusenvis av andre kunders kode, uten at de kan se hverandre. AWS løser samme problem på to måter: Lambda@Edge kjører fullverdige Lambda-funksjoner knyttet til CloudFront, mens CloudFront Functions bruker et lettvekts JavaScript-miljø designet for forespørsler som bare trenger å endre en header eller omdirigere en URL. De tre tilnærmingene ligner på overflaten, men de løser ulike problemer, og det er nettopp derfor sammenligningen er mer komplisert enn den ser ut som ved første øyekast.
Cloudflare Workers forklart: arkitektur og isolater
Cloudflare Workers kjører JavaScript, TypeScript og WebAssembly direkte i Cloudflares globale nettverk, uten at utvikleren trenger å velge en region. Du publiserer koden én gang, og Cloudflare distribuerer den til hele nettverket automatisk. Ifølge Cloudflares egen nettverksdokumentasjon dekker plattformen over 335 byer, inkludert både Oslo og Stockholm, noe som gjør Workers til den tjenesten med flest fysiske punkter nær norske brukere av de tre.
Arkitekturen bruker isolater i stedet for virtuelle maskiner eller containere. En isolat er en lett sandkasse inni V8-motoren, og flere isolater kan dele samme prosess. Det gjør oppstarten rask, men det setter også en hard grense på minnebruk per isolat. Cloudflare har i 2026 fjernet den gamle begrensningen på 1.000 subforespørsler per kjøring for betalende kunder. Standard er nå 10.000 subforespørsler, og det kan konfigureres opp til 10 millioner, ifølge Cloudflares egne platformgrenser. Det åpner for mer komplekse kjeder av API-kall direkte fra kanten.
Workers Builds, byggesystemet for Workers, tilbyr i 2026 inntil 6.000 byggeminutter per måned på betalte planer, seks samtidige bygg, 4 vCPU og 8 GB byggeminne, med en tidsgrense på 20 minutter per bygg. Dette er relevant for team som automatiserer utrulling via CI/CD mot et edge-miljø, noe som blir mer vanlig etter hvert som Workers tar over oppgaver som tidligere krevde en egen backend.
AWS Lambda@Edge forklart: CloudFront-integrasjon og regionkrav
Lambda@Edge er AWS sitt svar på samme problem, men løsningen er tettere koblet til CloudFront, AWS sitt CDN-produkt. En Lambda@Edge-funksjon må opprettes i regionen US East (N. Virginia), og AWS replikerer den deretter ut til CloudFront sine edge-lokasjoner globalt, ifølge AWS sin utviklerdokumentasjon for Lambda@Edge. Dette regionkravet er en praktisk forskjell fra Workers, hvor det ikke finnes noe tilsvarende opprinnelseskrav.
Lambda@Edge støtter fire typer hendelser i forespørselskjeden: viewer-request, viewer-response, origin-request og origin-response. De to siste kjører nærmere opprinnelsesserveren og gir funksjonen mer tid og flere ressurser å jobbe med. Minnet kan konfigureres fra 128 MB opp til 10.240 MB, altså over 10 GB, et helt annet nivå enn både Workers og CloudFront Functions. Kjøretiden er derimot strengt begrenset: 30 sekunder, både for viewer-hendelser og origin-hendelser. AWS tillater i dag Node.js og Python som kjøretidsmiljøer for Lambda@Edge, med de versjonsbegrensningene som gjelder for Lambda generelt.
En praktisk begrensning mange glemmer: AWS tillater kun 500 CloudFront-distribusjoner per konto som kan ha Lambda@Edge-funksjoner koblet til seg. For de fleste team er dette ikke et problem, men for større plattformer med mange merkevarer eller kundedomener kan det bli en reell kvote å planlegge rundt.
CloudFront Functions forklart: det lette alternativet
CloudFront Functions kom som AWS sitt svar på at Lambda@Edge var tregere og dyrere enn nødvendig for enkle oppgaver. Ifølge AWS sin dokumentasjon for CloudFront Functions er tjenesten bygget for forespørsler som kun trenger å lese eller endre URL-er, query-strenger, headere og cookies, altså metadata, ikke selve forespørselskroppen.
Grensene er strenge med vilje: 2 MB minne, 1 millisekund kjøretid og maks 10 KB kode per funksjon, skrevet i et eget JavaScript-kjøretidsmiljø kalt CloudFront Functions JavaScript runtime 2.0. Funksjonen kan kun kjøre ved viewer-request og viewer-response, aldri ved origin-stadiet, og den har ingen tilgang til hele forespørselskroppen. Dette gjør CloudFront Functions uegnet for applikasjonslogikk, men svært billig og forutsigbart for ting som URL-omskriving, A/B-ruting basert på cookies og enkle sikkerhetssjekker før forespørselen når origin.
Spesifikasjoner side ved side
Tabellen under samler de tekniske grensene fra Cloudflares og AWS sin offisielle dokumentasjon, slik de gjelder i 2026. Tallene er hentet direkte fra plattformenes egne spesifikasjonssider, ikke fra tredjeparts estimater.
| Egenskap | Cloudflare Workers | AWS Lambda@Edge | CloudFront Functions |
|---|---|---|---|
| Minne per kjøring | 128 MB per isolat | 128 MB til 10.240 MB | 2 MB |
| Maks kjøretid | 30 sek. standard, inntil 5 min CPU-tid | 30 sek. (viewer og origin) | 1 millisekund |
| Maks kodestørrelse | 64 MiB | Avhenger av Lambda-pakkegrenser (vesentlig større enn CF Functions) | 10 KB |
| Tilgang til forespørselskropp | Full tilgang, opptil 100-200 MB (5 GB på Enterprise) | Begrenset, avhenger av hendelsestype | Ingen tilgang til hele kroppen |
| Støttede språk | JavaScript, TypeScript, WebAssembly | Node.js, Python | JavaScript (runtime 2.0) |
| Hendelsestyper | Full HTTP-request/response, cron, køer, lagring | Viewer-request, viewer-response, origin-request, origin-response | Kun viewer-request og viewer-response |
| Oppstartsgrense (cold start) | Maks 1 sekund oppstart per isolat | Ingen offentlig garantert grense, varierer med pakkestørrelse | Ingen offentlig garantert grense, designet for svært lav startkostnad |
| Subforespørsler per kjøring | 10.000 standard, konfigurerbart til 10 millioner | Vanlig AWS-nettverksbegrensning, ingen Workers-lik kvote | Ingen generell utgående nettverksmodell |
| Driftssted for funksjonen | Publiseres direkte til hele nettverket | Må opprettes i US East (N. Virginia), replikeres ut | Publiseres direkte til CloudFront-distribusjonen |
| Antall distribusjoner/kontogrense | Ingen tilsvarende grense | 500 distribusjoner per konto med Lambda@Edge | Følger vanlige CloudFront-kvoter |
| Tilleggstjenester i plattformen | KV, Durable Objects, R2, D1, Queues, Workflows, Workers AI | Full tilgang til AWS-tjenester fra opprinnelsesregionen (med begrensninger ved selve edge-kjøringen) | Ingen tilleggstjenester, kun forespørselsmanipulasjon |
| Gratis kvote | 100.000 forespørsler/dag, 10 ms CPU-tid per kjøring | Følger generell Lambda-gratiskvote, med egne CloudFront-vilkår | Betaling fra første forespørsel, ingen separat gratiskvote for selve funksjonen |
Mønsteret er tydelig: Workers gir mest fleksibilitet og lengst kjøretid av de to lette alternativene, Lambda@Edge gir mest rå ressurser men krever mer arkitektonisk arbeid, og CloudFront Functions er strippet ned til det mest nødvendige for å holde prisen og latensen lav.
Priser i detalj: hva regningen faktisk ser ut som
Prisforskjellene mellom de tre er store, og de blir enda viktigere når trafikkvolumet skalerer opp mot millioner av forespørsler i måneden. Cloudflare Workers på en betalt plan inkluderer 10 millioner forespørsler i måneden for en fastpris, med en kontominimum på 5 dollar i måneden, ifølge Cloudflares prisside for Workers. Overforbruk koster 0,30 dollar per million forespørsler. AWS tar generelt rundt 0,60 dollar per million forespørsler for Lambda@Edge, pluss separat betaling for kjøretid og minnebruk, mens CloudFront Functions er desidert billigst i ren pris med 0,10 dollar per million kjøringer, ifølge AWS sin prisside for CloudFront.
| Prisparameter | Cloudflare Workers | AWS Lambda@Edge | CloudFront Functions |
|---|---|---|---|
| Pris per million forespørsler/kjøringer | Inkludert 10 mill./mnd, deretter $0,30/mill. | Ca. $0,60/mill. pluss kjøretid | $0,10/mill. |
| Fast minstebeløp | $5/mnd på betalt plan | Ingen felles minstebeløp, men CloudFront/Lambda-gebyrer tilkommer | Ingen separat minstebeløp |
| CPU/kjøretidsbetaling | 30 mill. CPU-ms inkludert, så $0,02 per ekstra mill. CPU-ms | Betaling etter kjøretid og tildelt minne, pluss replikeringsoverhead | Inkludert i invocation-prisen, ekstremt kort kjøretid per design |
| Gratisnivå | 100.000 forespørsler/dag | Følger generell Lambda-gratiskvote med CloudFront-vilkår | Ingen separat gratiskvote for funksjonen selv |
| Ekstra plattformtjenester | Workers AI fra $0,011 per 1.000 “neurons”, 10.000 gratis/dag | Vanlige AWS-tjenestepriser gjelder ved integrasjon | Ingen tilleggstjenester å prise inn |
| Typisk kost ved 50 mill. forespørsler/mnd | 10 mill. inkludert + 40 mill. x $0,30 = $12 i ren request-kost | 50 mill. x $0,60 = $30 i ren request-kost, pluss kjøretid | 50 mill. x $0,10 = $5 i ren invocation-kost |
Ved høyt volum blir forskjellen mellom Lambda@Edge og CloudFront Functions betydelig, rundt seks ganger billigere for CloudFront Functions på rene forespørselskostnader. Men det er en falsk sammenligning hvis oppgaven din faktisk krever mer enn 1 millisekund kjøretid eller tilgang til forespørselskroppen, fordi da er CloudFront Functions rett og slett ikke et alternativ uansett pris.
Ytelse og kaldstart: hva dataene faktisk viser
Kaldstart er ofte det første spørsmålet utviklere stiller, men her må man være ærlig om hva som faktisk er dokumentert. Ingen av de tre leverandørene publiserer et universelt, garantert millisekundtall for kaldstart, fordi tiden varierer med kodestørrelse, initialiseringsarbeid og hvilken node forespørselen treffer. Det som derimot er dokumentert, er strukturelle grenser som påvirker kaldstart indirekte.
Cloudflare setter en hard grense på 1 sekund oppstartstid per isolat, ifølge egen plattformdokumentasjon. Det betyr at Cloudflare selv kutter av funksjoner som bruker for lang tid på å starte, noe som i praksis tvinger utviklere til å skrive lett kode. AWS har ingen tilsvarende hard grense for Lambda@Edge, men arkitekturen med regional opprinnelse og replikering innebærer at en kald isolat et sted i nettverket kan oppleve lenger responstid enn en varm Cloudflare-isolat, spesielt ved origin-stadiet. Uavhengige kostnads- og arkitekturanalyser som sammenligner CloudFront og Cloudflare, inkludert gjennomganger fra teknologiblogger som dekker CDN-arkitektur i detalj, peker samstemt på at Workers sitt isolatmodell generelt gir jevnere og mer forutsigbar oppstart enn en tradisjonell funksjonsplattform som må “varme opp” en kjøretid.
For CloudFront Functions er situasjonen annerledes: fordi kjøretiden er begrenset til 1 millisekund og koden må være under 10 KB, er det strukturelt umulig å ha en tung kaldstart i utgangspunktet. Dette er den tredje kilden til ytelsesdata i denne sammenligningen, altså selve designbegrensningen som fungerer som en innebygd ytelsesgaranti. Konklusjonen basert på alle tre datapunktene (Cloudflares egen oppstartsgrense, AWS sin arkitekturbeskrivelse, og CloudFront Functions sin designgrense) er at CloudFront Functions vinner på ren kjøretidslatens for mikro-oppgaver, Workers vinner på konsistens for alt som krever mer enn millisekunder, og Lambda@Edge betaler en arkitektonisk kostnad for å tilby mest fleksibilitet. Du kan lese mer om hvordan AWS har jobbet med kaldstart-problemet på selve Lambda-plattformen i vår gjennomgang av Lambda SnapStart for containere, som angriper samme problem fra en annen vinkel enn Lambda@Edge gjør.
Hva tre uavhengige kilder sier om valget
For å unngå å basere konklusjonen på én leverandørs markedsføringstekst, er det verdt å se hva tre forskjellige typer kilder faktisk sier om disse plattformene. Den første kilden er Cloudflares egen tekniske dokumentasjon, som er uvanlig åpen om harde grenser som 128 MB minne og 1 sekunds oppstartstid, i stedet for å pakke dette inn i generelle markedsføringstall. Den andre kilden er AWS sin utviklerdokumentasjon, som på samme måte spesifiserer konkrete tall for Lambda@Edge og CloudFront Functions, selv om AWS er mer tilbakeholden med å publisere et samlet antall edge-lokasjoner enn Cloudflare er.
Den tredje kilden er uavhengige kostnads- og arkitekturgjennomganger fra teknologiblogger som sammenligner CDN- og edge-plattformer i detalj, uten å selge noen av dem. Flere slike gjennomganger konkluderer samstemt med at CloudFront Functions er den klart billigste tjenesten ved høyt volum av enkle operasjoner, at Lambda@Edge er den dyreste men mest kapable av AWS sine to alternativer, og at Cloudflare Workers ligger i en mellomposisjon på pris men leder på funksjonsbredde og antall fysiske lokasjoner. Dette mønsteret er konsistent nok over flere uavhengige kilder til at det er trygt å bruke som grunnlag for en arkitekturbeslutning, selv om de eksakte dollartallene kan variere noen prosent fra kilde til kilde avhengig av når de ble målt.
Tabellen under oppsummerer hvor de tre kildetypene er samstemte, og hvor de spriker nok til at du bør måle selv før du bygger en kapasitetsplan på tallene.
| Spørsmål | Cloudflares egen dokumentasjon | AWS sin dokumentasjon | Uavhengige kostnadsanalyser |
|---|---|---|---|
| Hvem er billigst ved høyt volum av enkle oppgaver | Oppgir egne faste priser, ikke en direkte sammenligning | Oppgir egne faste priser, ikke en direkte sammenligning | Samstemt: CloudFront Functions vinner på ren pris |
| Hvem har flest fysiske edge-punkter | Oppgir over 335 byer offentlig | Oppgir ikke et samlet, enkelt tall for CloudFront-nettverket | Samstemt: Cloudflare kommuniserer et klarere tall |
| Hvem er mest fleksibel for tung applikasjonslogikk | Beskriver Workers som en full applikasjonsplattform | Beskriver Lambda@Edge som mest kapabel av AWS-alternativene | Spriker noe: avhenger av om AWS-økosystemet allerede er i bruk |
| Hvem har mest forutsigbar kaldstart | Oppgir en hard 1-sekundsgrense | Publiserer ingen garantert kaldstarttid | Samstemt: isolatmodeller gir jevnere oppstart enn tradisjonelle funksjoner |
Observability og feilsøking i edge-laget
Når kode flyttes ut av en sentral region og inn i hundrevis av fysiske lokasjoner, blir feilsøking et eget fagfelt. Cloudflare gir tilgang til sanntidslogger gjennom wrangler tail, som strømmer logger direkte fra en kjørende Worker uten at du behøver å sette opp en separat loggingstjeneste først. Dette er nyttig i utviklingsfasen, men ved høyt trafikkvolum i produksjon bør loggene sendes videre til et eksternt system, siden sanntidsstrømming ikke er bygget for å holde historikk over tid.
AWS sin tilnærming for Lambda@Edge er tettere integrert med CloudWatch, der hver kjøring logges automatisk i den regionen som er nærmest edge-lokasjonen funksjonen kjørte i. Dette betyr i praksis at loggene for en global applikasjon kan ende opp spredt over mange CloudWatch-regioner samtidig, noe som krever et aggregeringsoppsett hvis du vil ha ett samlet dashbord for feil som skjer i Frankfurt i dag og i Tokyo i morgen. CloudFront Functions har en enda enklere loggingsmodell, men samtidig færre ting som kan feile, siden funksjonen ikke har tilgang til eksterne tjenester eller komplekse operasjoner som typisk krever dyp feilsøking.
Et praktisk råd uavhengig av plattform: bygg inn strukturert logging med et konsistent feltnavn for forespørsels-ID helt fra start. Når en feil oppstår i en edge-funksjon som kjører i et dusin forskjellige fysiske lokasjoner samtidig, er det denne ID-en som lar deg koble sammen en brukers klage med den eksakte kjøringen som feilet, i stedet for å gjette basert på tidspunkt og land. Dette gjelder spesielt for Workers og Lambda@Edge, der funksjonen ofte er en del av en lengre kjede av kall, mens CloudFront Functions sin enkle natur gjør dette mindre kritisk der.
Grenser som avgjør arkitekturen din
Minne og forespørselskropp
Minnegrensen avgjør hva du praktisk kan gjøre. Workers sine 128 MB per isolat er nok for de fleste API-mellomlag, autentiseringslogikk og personalisering, men for store bildebehandlingsjobber eller tunge maskinlæringsmodeller blir det stramt. Lambda@Edge sine opptil 10.240 MB gir rom for ting som bildetransformasjon i stor skala eller mer krevende serverrendrering direkte ved origin-stadiet. CloudFront Functions sine 2 MB er ikke engang i samme kategori. De tre tjenestene konkurrerer ikke om samme type oppgave her, de dekker tre forskjellige punkter på en skala fra “les en header” til “kjør en hel applikasjon”.
Tilgangen til forespørselskroppen følger samme logikk. Workers kan lese og behandle hele kroppen, med en øvre grense på 100-200 MB avhengig av plan og opp mot 5 GB på enkelte Enterprise-avtaler. Lambda@Edge har mer begrenset tilgang avhengig av hendelsestype, mens CloudFront Functions ikke har tilgang til hele kroppen overhodet, kun metadata som URL, headere og cookies.
Kjøretid og hendelsessteg
Workers kan kjøre opptil 5 minutter CPU-tid på betalte planer, langt mer enn Lambda@Edge sine 30 sekunder, som gjelder både ved origin-hendelser og viewer-hendelser. Dette gjør Workers til det eneste av de to seriøse alternativene som kan håndtere lengre bakgrunnsoppgaver direkte i kanten, mens Lambda@Edge er tenkt for kortere, mer presise operasjoner knyttet direkte til CloudFronts forespørselsflyt. CloudFront Functions sitt 1-millisekunds vindu er i en helt egen klasse, designet for operasjoner som fysisk ikke kan ta lenger tid enn det.
Norge og Norden: datasentre, latens og suverenitet
For norske og nordiske team handler valget også om hvor dataene faktisk behandles. Cloudflare oppgir egne lokasjoner i både Oslo og Stockholm som del av sitt globale nettverk, og vår tidligere dekning av Cloudflares Oslo-datasenter går gjennom hvordan dette punktet ble det 75. i nettverket og hva det betyr for lokal latens. AWS har sin egen Europa (Stockholm)-region, kjent som eu-north-1, med flere tilgjengelighetssoner, men det er viktig å skille mellom denne regionale infrastrukturen og selve CloudFront-nettverket som Lambda@Edge og CloudFront Functions kjører på. CloudFront-nettverket har egne edge-lokasjoner som betjener nordiske brukere, men AWS publiserer ikke et eget, enkelt tall for hvor mange av disse punktene som ligger i Norden spesifikt.
Praktisk betyr dette at Workers har en synlig, navngitt tilstedeværelse i både Oslo og Stockholm, mens AWS sin edge-tilstedeværelse i Norden er mer diffust dokumentert selv om den regionale Stockholm-infrastrukturen er godt kjent og mye brukt av norske virksomheter. For selskaper med krav til datalokalisering, typisk innen finans, helse og offentlig sektor, er dette ofte et samtaleemne i seg selv: hvor kjører koden fysisk, og hvilket lands lovverk gjelder for den behandlingen. Ingen av de tre tjenestene løser datasuverenitet automatisk bare fordi koden kjører nær brukeren. Det krever fortsatt en egen vurdering av hvilke edge-noder som faktisk brukes og hvilke avtaler som gjelder for dem.
Fem praktiske bruksmønstre fra virkelige arkitekturer
I stedet for abstrakte eksempler, her er fem konkrete mønstre som går igjen i produksjonsarkitekturer som bruker disse tre plattformene aktivt.
1. A/B-testing og personalisering ved viewer-request. En nettbutikk som vil vise forskjellige landingssider basert på en cookie, uten å endre selve origin-serveren, legger logikken i CloudFront Functions eller en enkel Worker. Her vinner CloudFront Functions på pris hvis logikken er triviell nok til å holde seg under 1 millisekund og 10 KB kode.
2. Bildetransformasjon og mediebehandling ved origin-request. Når en bildetjeneste skal endre størrelse eller format på bilder før de når CDN-cachen, trengs tilgang til mer minne og lengre kjøretid enn CloudFront Functions tillater. Lambda@Edge sine opptil 10.240 MB og 30 sekunder ved origin-hendelser gjør dette mulig direkte i edge-laget, uten en separat mikroservice.
3. Full API-logikk og autentisering direkte i kanten. Team som bygger hele backend-API-er på edge-plattformen, ikke bare enkle transformasjoner, trenger lengre kjøretid, tilgang til databaser og lagringstjenester. Dette er der Cloudflare Workers sammen med KV og Durable Objects skiller seg mest fra de to AWS-alternativene, fordi plattformen er bygget for full applikasjonslogikk fra start, ikke bare forespørselsmanipulasjon.
4. Botbeskyttelse og sikkerhetsheadere. Enkle regler som blokkerer kjente botmønstre basert på User-Agent eller headere kjøres billigst og raskest i CloudFront Functions, fordi oppgaven er ren metadata-sjekk uten behov for ekstern oppslag. Mer avanserte botbeskyttelsesregler som krever et kall til en ekstern tjeneste eller database må derimot opp til Workers eller Lambda@Edge, siden CloudFront Functions ikke har en generell utgående nettverksmodell.
5. Multi-region origin-failover. Når en applikasjon skal velge mellom flere opprinnelsesservere basert på helsesjekk eller geografisk nærhet, krever dette logikk som kjører ved origin-request-steget. Lambda@Edge er bygget nettopp for denne typen oppgave, med direkte tilgang til CloudFronts distribusjonskonfigurasjon, mens Workers kan oppnå lignende resultat gjennom egen ruting-logikk kombinert med Cloudflares lastbalanseringsfunksjoner.
Når bør du velge hva: fem konkrete anbefalinger
Velg Cloudflare Workers når du bygger applikasjonslogikk som skal kjøre globalt uten regional konfigurasjon, når du trenger mer enn noen få millisekunder kjøretid, eller når du vil ha tilgang til tilleggstjenester som nøkkelverdilagring og databaser direkte i kanten uten å sette opp separat infrastruktur.
Velg AWS Lambda@Edge når organisasjonen allerede er tungt investert i AWS, når oppgaven krever mer minne enn 128 MB, eller når du spesifikt trenger å kjøre kode ved origin-request- eller origin-response-steget, noe de to andre alternativene ikke støtter i samme grad.
Velg CloudFront Functions når oppgaven er triviell, prisen er avgjørende ved svært høyt volum, og du allerede bruker CloudFront som CDN. Dette er det riktige valget for URL-omskriving, enkel header-manipulasjon og cookie-basert ruting, men aldri for noe som krever mer enn metadata.
Kombiner CloudFront Functions og Lambda@Edge i samme CloudFront-distribusjon når du har en blanding av trivielle og tunge oppgaver. AWS tillater begge typer funksjoner på samme distribusjon, slik at du kan la CloudFront Functions håndtere de lette, høyvolum-oppgavene mens Lambda@Edge tar de tyngre, mer sjeldne operasjonene.
Vurder en multi-cloud-tilnærming hvis virksomheten allerede bruker både Cloudflare som CDN/sikkerhetslag og AWS som skyplattform. Mange team lar Cloudflare håndtere botbeskyttelse, WAF og enkel edge-logikk, mens tyngre applikasjonslogikk fortsatt kjører i AWS-regioner. Vår gjennomgang av Cloudflare Workers mot Azure AKS går mer i detalj på hvordan edge-kompute og tradisjonell containerdrift kan utfylle hverandre i en slik arkitektur.
Migreringsguide: fra Lambda@Edge til Cloudflare Workers
Mange team som opplever at Lambda@Edge blir for dyrt eller for rigid ved høyt volum, migrerer til Workers. Her er de praktiske stegene som går igjen i en slik migrering.
- Kartlegg hvilke hendelsessteg funksjonene dine bruker i dag (viewer-request, viewer-response, origin-request, origin-response), fordi Workers ikke skiller mellom disse på samme måte som CloudFront gjør.
- Identifiser funksjoner som kun leser eller endrer headere, cookies og URL-er. Disse er enklest å flytte først og gir raskest gevinst.
- Konverter Node.js- eller Python-koden til JavaScript eller TypeScript hvis den opprinnelige funksjonen var skrevet i Python, siden Workers ikke støtter Python-kjøretid direkte.
- Sett opp en ny Cloudflare-konto og definer rutene (routes) som skal trigge Workeren, tilsvarende hvordan Lambda@Edge var koblet til CloudFront-oppførsel.
- Flytt eventuell tilstand fra DynamoDB eller andre AWS-tjenester til Cloudflare KV eller Durable Objects, eller sett opp en bro som lar Workeren fortsatt kalle AWS-tjenester via API.
- Test kjøretidsgrensene nøye. En funksjon som brukte nær 30 sekunder ved origin-request i Lambda@Edge, må trimmes eller restruktureres for Workers sine kjøretidsmodeller.
- Kjør begge systemene parallelt med trafikksplitting (canary-utrulling) i minst én til to uker før full overgang, og overvåk feilrater og responstider i begge systemer samtidig.
- Oppdater DNS og eventuelle CDN-innstillinger til å peke mot Cloudflare når testperioden er bestått, og behold Lambda@Edge-funksjonene inaktive i en periode som sikkerhetsnett.
- Fjern de gamle Lambda@Edge-funksjonene og CloudFront-distribusjonen når overgangen er stabil, og dokumenter endringen for driftsteamet.
Den vanligste fellen i denne migreringen er å undervurdere forskjellen i minnemodell. Kode som er skrevet for Lambda@Edge sine opptil 10.240 MB må ofte omskrives for å passe innenfor Workers sine 128 MB per isolat, spesielt hvis koden holder store datastrukturer i minnet mellom kall.
Kodeeksempel: samme oppgave på to plattformer
For å illustrere forskjellen i programmeringsmodell, her er en enkel header-injeksjon skrevet for begge plattformene.
// Cloudflare Worker
export default {
async fetch(request) {
const response = await fetch(request);
const newResponse = new Response(response.body, response);
newResponse.headers.set("X-Edge-Platform", "Cloudflare-Workers");
return newResponse;
}
};// AWS Lambda@Edge (viewer-response)
exports.handler = async (event) => {
const response = event.Records[0].cf.response;
response.headers["x-edge-platform"] = [
{ key: "X-Edge-Platform", value: "Lambda-at-Edge" }
];
return response;
};Begge eksemplene gjør samme jobb, men syntaksen og hendelsesmodellen er forskjellig nok til at en direkte kopiering av kode aldri fungerer. Dette er en av grunnene til at migrering mellom plattformene krever faktisk omskriving, ikke bare en endring av konfigurasjon.
Fordeler og ulemper for hver plattform
Cloudflare Workers
- Fordeler: Bredest nettverk med over 335 byer, lengst kjøretid av de tre, rikt økosystem med KV, Durable Objects, R2 og D1, enkel utrulling uten regional konfigurasjon.
- Ulemper: Fast grense på 128 MB minne per isolat, kun JavaScript/TypeScript/WebAssembly, krever at team lærer et nytt isolat-basert tankesett i stedet for tradisjonelle funksjoner.
AWS Lambda@Edge
- Fordeler: Opptil 10.240 MB minne, støtte for origin-steg i forespørselsflyten, naturlig integrasjon med resten av AWS-økosystemet for team som allerede står der.
- Ulemper: Høyest pris per million forespørsler av de tre, krever opprettelse i US East (N. Virginia) og replikering, strengere kvoter som 500 distribusjoner per konto.
CloudFront Functions
- Fordeler: Lavest pris per million kjøringer, strukturelt umulig å ha tung kaldstart, enkel å skrive og revidere på grunn av 10 KB-grensen.
- Ulemper: Ingen tilgang til forespørselskroppen, kun viewer-steg, 1 millisekund kjøretid gjør den ubrukelig for alt utover enkel metadata-logikk.
Sikkerhet og isolasjon: isolater mot funksjoner
Isolasjonsmodellen har også en sikkerhetsside. Cloudflares V8-isolater deler prosessrom med andre kunders kode, med V8 sin egen sandkasse som skillevegg. AWS Lambda, inkludert Lambda@Edge, kjører hver funksjon i sin egen mikro-VM gjennom Firecracker-teknologien, et sterkere isolasjonsnivå på papiret fordi det er maskinvarevirtualisering i stedet for prosessnivå-isolasjon. Dette er ikke en ny diskusjon. Sikkerhetsforskere har tidligere pekt på at delt prosessrom i isolatmodeller generelt krever at motoren (i dette tilfellet V8) er fri for sidekanalsvakheter, mens VM-baserte modeller som Firecracker har en annen angrepsflate knyttet til hypervisoren selv.
For de fleste applikasjoner er dette ikke en avgjørende faktor, fordi begge leverandørene investerer tungt i å patche og overvåke sine respektive isolasjonslag. Men for virksomheter med spesielt høye krav til multi-tenant-sikkerhet, for eksempel når man kjører kode på vegne av egne kunder i en SaaS-plattform, er det verdt å forstå forskjellen før man velger arkitektur. CloudFront Functions sin ekstremt begrensede kjøretid og mangel på utgående nettverkstilgang gjør den i praksis til den tryggeste av de tre rent ved at angrepsflaten er minimal av design.
Utviklererfaring og økosystem
Utviklererfaringen skiller seg markant mellom plattformene. Cloudflare har bygget et eget kommandolinjeverktøy og lokalt utviklingsmiljø som lar deg teste Workers uten å publisere til produksjon for hver endring, og veksten i Workers-økosystemet har gjort at Python Workers nå er allment tilgjengelig som et alternativ for team som ikke vil skrive JavaScript, selv om kjerneplattformen fortsatt kjører JavaScript under skjermen. AWS sin utvikleropplevelse for Lambda@Edge er tettere integrert med resten av AWS-verktøykassen, inkludert CloudFormation og SAM, noe som er en fordel for team som allerede har investert i disse verktøyene, men samtidig en høyere inngangsbarriere for team som starter fra scratch.
CloudFront Functions har den enkleste utvikleropplevelsen av de tre, nettopp fordi omfanget er så begrenset. Det finnes ikke mye som kan gå feil når funksjonen er under 10 KB og kun kan røre ved headere og URL-er. For team som vurderer et bredere sett med edge- og compute-alternativer utenfor denne sammenligningen, går vår tidligere artikkel om AWS Fargate mot Google Cloud Run gjennom hvordan tradisjonell containerbasert kompute prises og presterer sammenlignet med de lettere edge-modellene vi diskuterer her, mens vår sammenligning av Cloudflare Workers mot Fastly Compute ser på den nærmeste direkte konkurrenten til Cloudflare utenfor AWS-familien.
Verdikt: hvem vinner i 2026
Det finnes ikke én vinner, fordi de tre tjenestene faktisk svarer på tre forskjellige spørsmål. Men basert på tallene i denne sammenligningen kan vi trekke klare konklusjoner for norske og nordiske team.
For generell applikasjonslogikk i kanten, med behov for lengre kjøretid og rikere tilleggstjenester, er Cloudflare Workers det mest komplette valget i 2026. Nettverket med over 335 byer, inkludert dedikerte punkter i både Oslo og Stockholm, gir den beste geografiske nærheten til norske brukere av de tre, og prismodellen med 10 millioner inkluderte forespørsler for 5 dollar i måneden er vanskelig å konkurrere med for de fleste arbeidsmengder under svært høyt volum.
For team som allerede er dypt investert i AWS og trenger mer minne eller origin-stegs-logikk, er Lambda@Edge fortsatt riktig verktøy, selv om det er det dyreste alternativet av de tre på rene forespørselskostnader og krever mer operasjonelt arbeid rundt regional opprinnelse og replikering.
For høyvolum, enkel forespørselsmanipulasjon der hver tiendedel av en cent betyr noe, er CloudFront Functions uslåelig på pris, med 0,10 dollar per million kjøringer og en arkitektur som gjør tunge kaldstarter strukturelt umulig. Svakheten er at den aldri kan vokse til å bli noe mer enn det den er i dag, en ren metadata-manipulator.
Det ærlige svaret for de fleste norske team i 2026 er derfor en kombinasjon: bruk CloudFront Functions eller Workers for de lette, høyvolum-oppgavene, og reserver Lambda@Edge eller Workers sine tyngre funksjoner for det som faktisk krever mer minne, mer kjøretid eller dypere integrasjon med eksisterende infrastruktur.
Den dypere lærdommen fra denne sammenligningen er at “edge computing” i 2026 ikke er ett produkt, men et spekter av verktøy med vidt forskjellige avveininger. Et team som velger plattform basert på prisark alene, uten å teste de faktiske grensene mot egen kode, ender ofte opp med en dyr omskriving noen måneder senere når en funksjon vokser forbi det den valgte tjenesten faktisk tåler. Start derfor alltid med å kartlegge hvilken type oppgave koden din faktisk løser, og la det, ikke prislappen, styre det første valget.
Ofte stilte spørsmål
Kan jeg bruke Cloudflare Workers sammen med AWS CloudFront?
Ja, men ikke i samme forespørsel samtidig. Mange team setter Cloudflare foran som et ekstra sikkerhets- og cachelag, mens AWS fortsatt håndterer selve CloudFront-distribusjonen og eventuell Lambda@Edge-logikk bak Cloudflare. Dette krever at DNS-oppsettet ruter trafikken gjennom Cloudflare først.
Hvorfor må Lambda@Edge opprettes i US East (N. Virginia)?
Dette er et designvalg fra AWS fordi CloudFront selv er en global tjeneste som historisk har vært administrert fra denne regionen. Funksjonen replikeres automatisk ut til edge-lokasjonene etter at den er publisert, men selve kildefunksjonen må alltid ligge der.
Er CloudFront Functions billigere enn Lambda@Edge i alle tilfeller?
På ren pris per kjøring, ja. Men hvis oppgaven din krever mer enn 1 millisekund kjøretid, mer enn 2 MB minne eller tilgang til forespørselskroppen, er CloudFront Functions rett og slett ikke teknisk mulig å bruke, uavhengig av pris.
Støtter Cloudflare Workers Python?
Ja, Python Workers er nå allment tilgjengelig, men koden kjører fortsatt gjennom et lag som til slutt eksekveres i V8-isolaten. Ren JavaScript og TypeScript gir fortsatt best ytelse og minst overhead på plattformen.
Hva skjer hvis en Cloudflare Worker bruker mer enn 128 MB minne?
Isolaten avsluttes med en feil. Det finnes ingen måte å kjøpe seg til mer minne per isolat i dagens modell, i motsetning til Lambda@Edge der du kan konfigurere opp til 10.240 MB. Løsningen er å dele arbeidet opp i mindre kall eller flytte den minnetunge delen til en annen tjeneste, som R2 eller en ekstern API.
Kan jeg bruke både Lambda@Edge og CloudFront Functions på samme distribusjon?
Ja. AWS tillater at samme CloudFront-distribusjon bruker CloudFront Functions for lette viewer-oppgaver og Lambda@Edge for tyngre origin-oppgaver samtidig. Dette er faktisk den mest kostnadseffektive måten å bruke AWS sine to edge-alternativer sammen.
Hvordan påvirker dette valget datasuverenitet for norske virksomheter?
Verken Workers, Lambda@Edge eller CloudFront Functions garanterer automatisk at data behandles innenfor Norge eller EU/EØS. Du må uttrykkelig undersøke hvilke noder som faktisk brukes og hvilke databehandleravtaler som gjelder, uavhengig av hvilken edge-plattform du velger.
Er det vanskelig å migrere fra én plattform til en annen senere?
Det krever faktisk omskriving av koden, ikke bare konfigurasjonsendringer, fordi programmeringsmodellene er forskjellige. Jo enklere funksjonen er, desto raskere går migreringen. En ren header-injeksjon tar minutter å flytte, mens en kompleks applikasjon med tilstand kan ta uker å migrere forsvarlig.
