AWS Lambda vs Azure Functions: 2,3x Billigere [2026]

Norske og nordiske utviklerteam står stadig oftere overfor det samme valget: skal serverløs kode kjøre på AWS Lambda eller Azure Functions? Begge plattformene lover null serveradministrasjon og betaling kun for faktisk bruk, men prismodellene, kaldstartatferden og grensene skiller seg mer enn markedsføringen antyder. Denne sammenligningen går gjennom priser, ytelsestall, språkstøtte og reelle bruksmønstre for begge tjenestene i 2026, med et konkret regneeksempel som viser at valget kan bety en kostnadsforskjell på over 2x for identisk arbeidsmengde.

Hvorfor AWS Lambda vs Azure Functions er aktuelt akkurat nå

Serverløs databehandling har gått fra å være et nisjevalg til å bli standardarkitektur for API-er, hendelsesdrevet databehandling og bakgrunnsjobber. AWS Lambda har lengst historikk og fortsatt størst markedsandel innen FaaS (function-as-a-service), mens Azure Functions har hentet inn mye terreng, spesielt blant bedrifter som allerede er tungt investert i .NET og Microsofts skyøkosystem. I løpet av 2025 og 2026 har begge leverandørene gjort betydelige endringer i prisstrukturen sin: AWS begynte å fakturere for såkalt INIT-fase (oppstartskoden som kjører før selve håndteringsfunksjonen) fra august 2025, noe CloudZeros gjennomgang av Lambda-priser i 2026 beskriver som en endring som kan gi 10-50 prosent høyere kostnad for funksjoner med tung initialisering, som maskinlæringsmodeller eller store avhengighetstrær. Microsoft har på sin side lansert en ny prisplan kalt Flex Consumption, som skal løse kaldstartproblemer på Consumption-planen, men som koster mer per GB-sekund enn den klassiske modellen.

For nordiske selskaper som drifter arbeidslaster på tvers av landegrenser, med krav til datasuverenitet og kostnadskontroll, er dette ikke et akademisk spørsmål. Et team som flytter en arbeidsmengde fra Lambda til Azure Functions uten å regne på GB-sekunder og eksekveringer på nytt, kan fort ende opp med en overraskende høy sky-regning. Denne artikkelen bruker offisielle prislister fra AWS og Microsofts prisside for Azure Functions, samt uavhengige 2026-benchmarks, for å gi et datadrevet svar på hvilken plattform som passer til hvilket scenario.

Hva er AWS Lambda?

AWS Lambda er Amazons administrerte kjøretidsmiljø for funksjoner. Du laster opp kode (eller et konteinerbilde), definerer en utløser (HTTP-forespørsel via API Gateway, en melding i SQS, en hendelse i S3, og så videre), og Lambda tar seg av skalering, patching og infrastruktur. Betalingen skjer per forespørsel og per GB-sekund kjøretid, altså minnetildeling multiplisert med kjøretid. Lambda ble lansert i 2014 og regnes fortsatt som referansepunktet de fleste serverløs-sammenligninger måler seg mot, delvis fordi integrasjonen med resten av AWS-økosystemet (DynamoDB, EventBridge, Step Functions, S3) er dypere og mer moden enn konkurrentenes tilsvarende koblinger. AWS sin egen compute-blogg dokumenterer jevnlig hvordan tjenesten videreutvikles, fra nye kjøretidsversjoner til endringer i faktureringsmodellen.

Lambda støtter kjøring på både x86- og ARM-baserte Graviton-prosessorer, der ARM-alternativet er rundt 20 prosent billigere per GB-sekund. Funksjoner kan pakkes som zip-filer eller som Docker-konteinerbilder på opptil 10 GB, noe som gir stor fleksibilitet for team som vil bruke egne språk eller tunge avhengigheter uten å være bundet til AWS sine offisielle kjøretidsmiljøer.

Hva er Azure Functions?

Azure Functions er Microsofts motsvar, men med et vesentlig bredere utvalg av vertsplaner enn Lambda. I stedet for én modell tilbyr Azure fire hovedvarianter: Consumption (klassisk, ren pay-per-use), Flex Consumption (nyere, med bedre kaldstart-kontroll), Premium (forhåndsvarmede instanser, ingen kaldstart) og Dedicated/App Service (kjører på faste virtuelle maskiner du allerede betaler for). Denne fleksibiliteten er en styrke for bedrifter med varierende arbeidslaster, men gjør også prissammenligning mer komplisert enn med Lambdas enklere modell.

Azure Functions er spesielt sterk der bedriften allerede bruker Azure-tjenester som Event Grid, Service Bus, Cosmos DB eller Logic Apps, og for team med tung .NET-kompetanse som drar nytte av den isolerte prosessmodellen for C#. Microsoft har også bygget Durable Functions, en utvidelse for stateful orkestrering av flertrinns arbeidsflyter, noe Lambda løser separat gjennom AWS Step Functions.

Spesifikasjoner side om side

Tabellen under stiller opp de tekniske grensene og egenskapene som avgjør hva slags arbeidslaster som passer på hver plattform, hentet fra AWS sin offisielle dokumentasjon av Lambda-grenser og Microsofts tilsvarende dokumentasjon for Azure Functions.

Egenskap	AWS Lambda	Azure Functions
Maks kjøretid per kall	15 minutter (900 sekunder)	5-10 minutter på Consumption; ingen praktisk øvre grense på Premium/Dedicated
Minnetildeling	128 MB – 10 240 MB, justerbar i små steg	Ca. 1,5-3,5 GB praktisk på Consumption; høyere på Premium avhengig av plantørrelse
Prosessorarkitektur	x86 og ARM/Graviton2 (ca. 20 % billigere)	x86 (ARM under utrulling på enkelte planer)
Konteinerstøtte	Ja, opptil 10 GB Docker-bilder	Ja, på Premium/Dedicated og via Azure Container Apps
Samtidighetsgrense (standard)	1000 samtidige kjøringer per region (kan økes)	Instansbasert skalering, ingen fast globalt tak, styrt av utløsertype og plan
Kaldstart-reduksjon	Provisioned Concurrency, SnapStart for Java	Always Ready (Flex), forhåndsvarmede instanser (Premium)
VPC/nettverksisolasjon	Native VPC-tilkobling via ENI, forbedret med Hyperplane	VNet-integrasjon krever Premium eller Dedicated for private endepunkter
Midlertidig diskplass	Konfigurerbar opptil 10 GB	Begrenset til underliggende instans/plan
Statlig orkestrering	Separat tjeneste: AWS Step Functions	Innebygd: Durable Functions
Konteinerorkestrering (Kubernetes-tilstøtende)	AWS Fargate/EKS som separat tjeneste	Azure Container Apps (KEDA + Dapr + Envoy under panseret)
Fakturering av oppstartskode	INIT-fase fakturert siden august 2025	Faktureres som del av kjøretiden på de fleste planer
Gratisnivå (kjøretid)	400 000 GB-sekunder/måned	400 000 GB-sekunder (Consumption) eller 100 000 GB-sekunder (Flex) per måned

Prismodeller i detalj: hva koster GB-sekundet

Begge leverandørene bruker samme grunnprinsipp: du betaler for antall forespørsler/kjøringer, pluss GB-sekunder (tildelt minne i GB multiplisert med kjøretid i sekunder). Men satsene, og hvor mange varianter av samme modell som finnes, er svært ulike.

Plan/komponent	Pris per forespørsel/kjøring	Pris per GB-sekund	Gratisnivå per måned
AWS Lambda x86 (standard)	$0,20 per million forespørsler	$0,0000166667	1 million forespørsler + 400 000 GB-sekunder
AWS Lambda ARM/Graviton2	$0,20 per million forespørsler	$0,0000133334 (ca. 20 % billigere)	Samme som over
AWS Lambda, volumtrinn 6-15 mrd GB-s	$0,20 per million forespørsler	$0,000015	Gjelder etter gratisnivå og trinn 1
AWS Lambda Provisioned Concurrency	Vanlig forespørselspris i tillegg	$0,0000041667 i beredskap + $0,0000097222 under aktiv kjøring	Ikke dekket av gratisnivå
Azure Functions Consumption (klassisk)	$0,20 per million kjøringer	Ca. $0,000016	1 million kjøringer + 400 000 GB-sekunder
Azure Functions Flex Consumption	$0,40 per million kjøringer	$0,000026	250 000 kjøringer + 100 000 GB-sekunder
Azure Functions Flex, Always Ready	$0,40 per million kjøringer	$0,000004 beredskap + $0,000016 under kjøring	100 000 GB-sekunder
Azure Functions Premium (alltid-varm)	Fakturert per vCPU-time, ikke per kjøring	Fra ca. $0,173 per vCPU-time	Ingen gratisnivå (fast forhåndskostnad)

Legg merke til at Lambdas grunnpris per GB-sekund ($0,0000166667) er lavere enn Azures Flex Consumption-pris ($0,000026), mens Azures klassiske Consumption-plan ligger tettere opp mot Lambda. Forskjellen skyldes at Flex-planen selger en bedre kaldstart-opplevelse som en del av prisen, ikke bare ren beregningskraft. Dette gjør det misvisende å sammenligne “Azure Functions” som én pris, siden valg av plan endrer regnestykket dramatisk.

Regnestykket: hva koster 10 millioner kjøringer i praksis

Tall uten kontekst sier lite, så la oss regne på et konkret scenario: 10 millioner kjøringer i måneden, 512 MB minne, gjennomsnittlig kjøretid på 200 millisekunder. Dette tilsvarer et typisk API-endepunkt med moderat trafikk, for eksempel en mellomstor nettbutikk eller et internt saksbehandlingssystem hos en nordisk offentlig etat.

GB-sekunder totalt: 0,5 GB x 0,2 sekunder x 10 000 000 kjøringer = 1 000 000 GB-sekunder.

AWS Lambda (x86), før gratisnivå: beregning $16,67 + forespørsler $2,00 = $18,67 totalt.
AWS Lambda (x86), etter gratisnivå trukket fra: (600 000 GB-s x $0,0000166667) + (9 millioner forespørsler x $0,0000002) = $10,00 + $1,80 = $11,80 totalt.
Azure Functions Flex Consumption, før gratisnivå: beregning $26,00 + kjøringer $4,00 = $30,00 totalt.
Azure Functions Flex Consumption, etter gratisnivå trukket fra: (900 000 GB-s x $0,000026) + (9 millioner kjøringer x $0,0000004) = $23,40 + $3,60 = $27,00 totalt.

Konklusjonen fra dette ene, men representative, regnestykket: Azure Functions Flex Consumption koster omtrent 2,3 ganger så mye som Lambda x86 for identisk arbeidsmengde. Velger man i stedet Azures klassiske Consumption-plan, som ligger nærmere Lambdas satser, krymper forskjellen kraftig, men da mister man samtidig Flex-planens fordeler med raskere skalering og bedre kaldstart-kontroll. Med Graviton2/ARM på Lambda-siden blir gapet enda større, siden compute-kostnaden der faller med ytterligere 20 prosent.

Kostnadsoptimalisering: fem konkrete tiltak

Regnestykket over viser et enkelt scenario, men i praksis kan begge plattformer optimaliseres betydelig utover standardoppsettet. Her er tiltak som faktisk flytter kostnadstallene, ikke bare teoretiske besparelser.

Riktig minnedimensjonering: Lambda-kostnad er en funksjon av minne multiplisert med kjøretid, så en funksjon som kjører raskere med mer minne (fordi den får mer CPU tildelt proporsjonalt) kan faktisk bli billigere totalt sett, ikke dyrere. Test flere minnenivåer og mål faktisk kjøretid før du antar at mindre minne alltid er billigere.
Bytt til ARM/Graviton2 der koden tillater det: for Lambda gir dette et umiddelbart kutt på rundt 20 prosent i kompute-kostnaden uten andre endringer, forutsatt at avhengighetene støtter ARM-arkitektur.
Reduser INIT-fasens varighet: siden AWS nå fakturerer oppstartskoden separat, bør tunge importer, modellinnlasting og tilkoblingsoppsett flyttes til lat initialisering der det er mulig, eller flyttes til konteinerbilder med forhåndsbygde lag.
Velg riktig Azure-plan for arbeidsmengden: ikke bruk Flex Consumption for jevn, forutsigbar trafikk der klassisk Consumption eller til og med Premium kan være billigere over tid. Flex gir mest verdi for ujevn, spikete trafikk der rask skalering er avgjørende.
Overvåk og rydd i ubrukte Provisioned Concurrency/Always Ready-instanser: begge disse funksjonene fakturerer kontinuerlig, uavhengig av faktisk trafikk, så glemte forhåndsvarmede instanser fra et tidligere prosjekt kan stille og rolig koste betydelige beløp over tid uten at noen merker det før fakturaen kommer.

Kaldstart og ytelse: hva sier benchmarkene

Kaldstart, altså forsinkelsen når en funksjon må initialiseres fra bunnen fordi ingen varm instans er tilgjengelig, er ofte den faktoren som avgjør brukeropplevelsen mer enn selve prisen. Uavhengige 2026-sammenligninger fra flere utviklerpublikasjoner (blant annet Tech Insider, Reintech og DevWharf) peker i samme retning: Lambda har historisk hatt tettere og mer forutsigbar kaldstart-fordeling for Node.js og Python, typisk under 200 millisekunder for enkle HTTP-handlere, med en p95-verdi som i flere tester lander mellom 1,2 og 2,8 sekunder for mer komplekse funksjoner. Azure Functions på klassisk Consumption-plan viser et bredere spenn, fra rundt 1 sekund opp til 10 sekunder, med enkelte målte utfall helt opp mot 30 sekunder i verste fall.

Begge leverandørene har verktøy for å eliminere kaldstart helt, men de koster ekstra og løser problemet forskjellig. Lambda tilbyr Provisioned Concurrency, som holder et gitt antall instanser varme mot en fast tilleggskostnad, samt SnapStart, som er spesifikt rettet mot Java og reduserer oppstartstid ved å ta et snapshot av en initialisert kjøretid. Azure sin løsning er Always Ready innenfor Flex-planen, eller å gå helt over til Premium-planen, der instanser holdes kontinuerlig varme mot en fast vCPU-time-kostnad uavhengig av trafikk. For team som kjører API-er med strenge responstidskrav, betyr dette i praksis at “gratis” kaldstart ikke finnes hos noen av de to. Man betaler enten i form av beredskapskostnad, eller i form av at brukeren opplever en treg første respons.

Språkstøtte og kjøretidsmiljøer

AWS Lambda støtter offisielt Node.js, Python, Java (med SnapStart-akselerasjon), Go, Ruby og .NET/C#, i tillegg til at Lambda Runtime API lar deg bygge egendefinerte kjøretidsmiljøer for språk som Rust, PHP eller Elixir. Kombinert med konteinerbilder på opptil 10 GB gir dette svært stor frihet for team som ikke vil være låst til AWS sine forhåndsbygde kjøretider.

Azure Functions dekker C#/.NET (både i prosess og i den nyere isolerte prosessmodellen), Node.js, Python, Java, PowerShell og TypeScript, samt egendefinerte handlere for andre språk. Der Azure historisk har hatt et fortrinn, er i dybden av .NET-integrasjonen. Den isolerte prosessmodellen gir bedre kontroll over avhengigheter og oppstartsatferd for C#-utviklere enn det som er tilgjengelig i eldre in-process-modellen. For team med tung Microsoft-stack, Active Directory-autentisering og eksisterende .NET-kodebaser, er dette ofte en vel så viktig faktor som ren pris.

Nettverk, VPC-integrasjon og sikkerhet

Begge tjenestene kan kjøre isolert i et privat nettverk, men modellene skiller seg. Lambda-funksjoner kan festes til en eller flere subnett i en VPC (Virtual Private Cloud) med tilhørende sikkerhetsgrupper, noe som gir tilgang til private ressurser som RDS-databaser eller interne tjenester. Historisk medførte VPC-tilkobling en ekstra kaldstart-kostnad på grunn av opprettelse av nettverksgrensesnitt (ENI), men AWS sin Hyperplane-arkitektur har redusert denne straffen kraftig de siste årene.

Azure Functions krever som regel Premium- eller Dedicated-planen for å koble til et virtuelt nettverk (VNet) med private endepunkter. Den klassiske Consumption-planen har mer begrenset nettverksisolasjon uten å oppgradere plan. Til gjengjeld er integrasjonen med Azure sine egne PaaS- og SaaS-tjenester, som Event Grid, Service Bus, Cosmos DB og Logic Apps, ofte tettere og krever mindre limkode enn tilsvarende AWS-oppsett. For sikkerhetsteam i regulerte bransjer som bank, forsikring og offentlig sektor i Norden, er identitetsstyring og nettverksisolasjon ofte det som avgjør valget mer enn kaldstarttall.

På compliance-siden har begge leverandørene et bredt sett med sertifiseringer som dekker de fleste krav norske og nordiske virksomheter møter, inkludert ISO 27001, SOC 2 og relevante bransjespesifikke standarder. Forskjellen ligger sjelden i om sertifiseringen finnes, men i hvor mye ekstra konfigurasjon som kreves for å oppnå samme sikkerhetsnivå. Lambda krever eksplisitt IAM-policyoppsett per funksjon, noe som gir finkornet kontroll, men også flere linjer konfigurasjon å vedlikeholde. Azure Functions kan i mange tilfeller arve tilgangsstyring direkte fra eksisterende Azure Active Directory-grupper, noe som reduserer duplisert konfigurasjonsarbeid for organisasjoner som allerede har en moden Azure-identitetsstruktur på plass.

Skalering og samtidighetsgrenser

Lambda har en eksplisitt, tallfestet samtidighetsgrense: som standard 1000 samtidige kjøringer per region per konto, som kan økes ved henvendelse til AWS support. Man kan også sette reservert samtidighet per funksjon for å garantere kapasitet, eller kombinere dette med Provisioned Concurrency for forhåndsvarmede instanser. Denne modellen er forutsigbar og lett å planlegge kapasitet rundt, men krever aktiv overvåking hvis trafikken vokser raskt, siden man kan treffe taket brått.

Azure Functions skalerer i stedet ut ved å legge til flere instanser av vertsapplikasjonen, styrt av utløsertype (HTTP, kø, Event Hub) og valgt plan. Det finnes ikke ett enkelt globalt samtidighetstall å forholde seg til slik som hos Lambda. I stedet styres skalering av instansgrenser, gjennomstrømningskvoter per abonnement og planens skaleringsregler. Dette kan oppleves som mer fleksibelt for varierende arbeidslaster, men også som mindre gjennomsiktig når man skal feilsøke hvorfor skalering ikke skjer raskt nok under en trafikktopp. Microsofts egen dokumentasjon om skalering anbefaler å teste skaleringsatferd med realistisk last før produksjonssetting, nettopp fordi grensene varierer mellom utløsertyper.

Markedsandel og adopsjon i 2026

Serverløs databehandling er ikke lenger en eksperimentell arkitektur, det er standard for hendelsesdrevne systemer i store deler av bransjen. Rapporter som Datadogs State of Serverless har fulgt utviklingen år for år og viser en klar trend: AWS Lambda forblir den mest brukte FaaS-tjenesten blant selskaper som allerede kjører produksjonslaster i skyen, mens Azure Functions har styrket sin posisjon særlig blant virksomheter med .NET-tunge kodebaser og eksisterende Microsoft-lisenser. Google Cloud Functions og Cloud Run utgjør en tredje retning, men faller utenfor denne artikkelens sammenligning siden fokuset her er de to plattformene flest norske og nordiske bedrifter faktisk velger mellom når de allerede har landet på enten AWS eller Azure som hovedleverandør.

Det er verdt å merke seg at adopsjonstallene ikke nødvendigvis reflekterer hvilken plattform som er teknisk best for et gitt problem, de reflekterer i stor grad hvilken sky bedriften allerede har forhandlet avtaler med, hvilke sertifiseringer utviklerteamet har, og hvor mye eksisterende infrastruktur som allerede er bygget. En bedrift med et etablert .NET-team og eksisterende Azure Active Directory-oppsett vil sjelden bytte til Lambda selv om kostnadstallene i denne artikkelen isolert sett taler for det, fordi kostnaden ved å bygge om identitetshåndtering og autentisering ofte overstiger besparelsen i kompute-kostnad.

Driftskostnader utover ren kompute: logging, overvåking og feilsøking

Prissammenligninger som kun ser på GB-sekunder og forespørsler, overser ofte en betydelig del av den reelle kostnaden: logging, sporing og feilsøking. Lambda-funksjoner logger som standard til CloudWatch Logs, og for team med høyt trafikkvolum kan lagringskostnaden for logger fort bli en vesentlig post i tillegg til selve kompute-kostnaden. Azure Functions logger tilsvarende til Application Insights, som har en egen prismodell basert på datavolum som må inn i det totale kostnadsbildet.

Feilsøking av en distribuert, hendelsesdrevet arkitektur er dessuten krevende uansett plattform. Lambda har fordelen av at AWS X-Ray gir sporing på tvers av tjenester i samme økosystem, mens Azure Functions drar nytte av at Application Insights er dypt integrert i resten av Azure Monitor-stacken. For team som allerede investerer tungt i én av skyene sine observability-verktøy, er dette ofte en usynlig, men reell, kostnadsfaktor som bør regnes inn før man sammenligner rene kompute-priser mellom de to plattformene.

Datasuverenitet: hva betyr valget for nordiske virksomheter

For norske og nordiske virksomheter i regulerte bransjer, som finans, helse og offentlig sektor, er valg av region minst like viktig som valg av plattform. Begge leverandørene har datasentre i Europa som kan tilfredsstille krav til lagring innenfor EU/EØS, men den faktiske regiontilgjengeligheten for Lambda og Azure Functions varierer fra land til land i Norden. Før man velger plattform basert på pris og ytelse alene, bør team sjekke om ønsket region faktisk støtter alle funksjonene som trengs, siden enkelte nyere funksjoner (som Flex Consumption-planen på Azure) historisk har rullet ut til nye regioner i etapper, ikke samtidig globalt.

Latens til nærmeste region påvirker også reell brukeropplevelse mer enn kaldstart-tallene i denne artikkelen isolert sett. En funksjon med perfekt kaldstart-tid i en region langt fra sluttbrukeren gir fortsatt dårlig opplevd ytelse. For nordiske team bør regionvalg og nettverkslatens til egne brukere alltid testes empirisk, ikke bare antas ut fra generelle benchmarks publisert av tredjeparter.

Utviklerverktøy, lokal testing og infrastruktur som kode

Utvikleropplevelsen rundt Lambda og Azure Functions har modnet betydelig de siste årene, men verktøykjedene er fortsatt forskjellige nok til å påvirke daglig produktivitet. AWS SAM (Serverless Application Model) og AWS CDK lar deg definere funksjoner, utløsere og tilhørende ressurser som kode, med lokal emulering via sam local invoke for å teste funksjoner uten å deploye til skyen for hver endring. Terraform har også modne moduler for Lambda, noe mange nordiske team allerede bruker på tvers av skyer.

Azure Functions Core Tools gir en tilsvarende lokal utviklingsopplevelse, med func start som kjører funksjonene lokalt mot en emulert vertsprosess. Visual Studio og Visual Studio Code har historisk hatt dypere, mer polert integrasjon mot Azure Functions enn mot Lambda, spesielt for C#-utviklere som får full feilsøkingsstøtte med brekkpunkter direkte i IDE-et. For team som allerede bruker Bicep eller ARM-maler til infrastruktur som kode, er det naturlig å definere Azure Functions-ressurser i samme verktøy som resten av Azure-miljøet, på samme måte som CDK eller Terraform gjør for et AWS-tungt miljø.

Et praktisk poeng mange team overser: lokal emulering fanger sjelden opp alle produksjonsforhold, spesielt kaldstart-atferd og nettverksisolasjon. Uansett hvilken plattform du velger, bør endelig ytelsestesting skje i et miljø som ligner produksjon så tett som mulig, ikke bare lokalt på utviklerens maskin.

Virkelige eksempler: hvem bruker hva

Begge plattformene har en lang liste offentlig kjente brukere, og mønsteret i hvem som velger hva følger ofte den eksisterende sky-investeringen til selskapet.

Netflix bruker AWS Lambda til operasjonell automatisering og deler av kodings- og transkoderingsarbeidsflyten sin, presentert flere ganger på AWS sine egne utviklerkonferanser.
Airbnb har brukt Lambda til sanntids strømbehandling og databehandlingspipeliner der hendelsesdrevet skalering er avgjørende.
Nordstrom, Coca-Cola og Autodesk er blant selskapene som gjentatte ganger har delt cases på AWS re:Invent om bruk av Lambda til hendelsesdrevet arkitektur, ETL-jobber og bakgrunnsbehandling.
BMW og Siemens er blant selskapene Microsoft har fremhevet i egne casestudier som brukere av Azure Functions til IoT-databehandling og sanntids hendelseshåndtering i industrielle miljøer.
Heathrow Airport er trukket frem av Microsoft som eksempel på bruk av Azure-tjenester, inkludert Functions, til hendelsesdrevet databehandling i flyplassdrift.
Offentlige og finansielle virksomheter i Microsoft-økosystemet bruker ofte Azure Functions som lim mellom Event Grid, Cosmos DB og Service Bus i hendelsesdrevne arkitekturer, spesielt der Active Directory-autentisering allerede er på plass.

Et gjennomgående mønster: selskaper med AWS som strategisk skyplattform velger nesten alltid Lambda for nye serverløse arbeidslaster, mens organisasjoner bygget rundt Microsoft 365, Power Platform eller tung .NET-arv trekker mot Azure Functions selv om ren beregningskostnad isolert sett taler for Lambda.

Migrasjonsguide: å flytte en funksjon mellom plattformene

Å flytte en funksjon fra Lambda til Azure Functions (eller omvendt) er sjelden en ren copy-paste-jobb, men handlersignaturen er konseptuelt lik nok til at logikken kan gjenbrukes med moderate justeringer. Under følger et forenklet eksempel som viser strukturforskjellen mellom de to for en enkel HTTP-utløst funksjon i Node.js.

// AWS Lambda - Node.js handler
exports.handler = async (event) => {
  const navn = event.queryStringParameters?.navn || "verden";
  return {
    statusCode: 200,
    body: JSON.stringify({ melding: `Hei, ${navn}!` }),
  };
};

// Azure Functions - Node.js handler (v4-modell)
app.http('hilsen', {
  methods: ['GET'],
  authLevel: 'anonymous',
  handler: async (request, context) => {
    const navn = request.query.get('navn') || 'verden';
    return { jsonBody: { melding: `Hei, ${navn}!` } };
  }
});

Praktiske steg for en trygg migrering:

Kartlegg alle utløsere (HTTP, kø, tidsstyrt, hendelsesbasert) og finn den nærmeste ekvivalenten på målplattformen, siden triggermodellene ikke er identiske en-til-en.
Regn om minne- og kjøretidsprofilen til GB-sekunder på begge plattformer før migrering, slik at du unngår kostnadsoverraskelser som i regnestykket over.
Flytt hemmeligheter og konfigurasjon til plattformens eget hvelv (AWS Secrets Manager eller Azure Key Vault) i stedet for å hardkode dem inn i miljøvariabler.
Test kaldstart-atferd under realistisk last før du går i produksjon, spesielt hvis funksjonen har tunge avhengigheter som lastes ved oppstart.
Sett opp overvåking på ny plattform (CloudWatch eller Azure Monitor) parallelt med gammel plattform i en overgangsperiode, slik at du kan sammenligne feilrater og responstider direkte.
Planlegg en gradvis utrulling med trafikkdeling (feature flag eller vektet DNS-ruting) i stedet for en brå full migrering av alle funksjoner samtidig.

Fem-pluss bruksområder og anbefalinger

Valget mellom Lambda og Azure Functions bør styres av arbeidslasten og den eksisterende sky-strategien, ikke bare av rå pris. Her er konkrete anbefalinger for vanlige scenarioer:

API-backend for en oppstartsbedrift allerede på AWS: velg Lambda med ARM/Graviton2 for lavest mulig kostnad per GB-sekund og dyp integrasjon mot DynamoDB og API Gateway. For en tidlig oppstartsbedrift med begrenset driftsbudsjett er dette kombinasjonen som gir lavest kostnad per forespørsel uten å måtte ansette dedikert driftspersonell.
Bedriftsintern automatisering i en organisasjon med Microsoft 365 og Power Platform: velg Azure Functions for tett kobling mot Office-økosystemet og enklere autentisering via Azure Active Directory. Dette sparer ofte flere ukers integrasjonsarbeid sammenlignet med å bygge tilsvarende autentiseringsflyt mot Lambda fra bunnen.
Sanntids IoT-databehandling i industri: Azure Functions kombinert med Event Grid og Durable Functions gir en mer helhetlig orkestreringsmodell enn å sette sammen Lambda med separate AWS-tjenester. Dette er spesielt relevant for norske industribedrifter med sensorbaserte produksjonslinjer som allerede rapporterer til Azure-baserte dashband.
Latenskritiske API-er med strenge SLA-krav: invester i Provisioned Concurrency på Lambda eller Premium-planen på Azure. Ren Consumption/på-forespørsel-prising passer dårlig når hver kaldstart koster brukertillit, for eksempel i betalingsflyter eller innloggingssider der brukeren forventer svar på under ett sekund.
Batch- og ETL-jobber med tunge avhengigheter (maskinlæringsmodeller, store biblioteker): vurder om Lambdas nye fakturering av INIT-fasen fra august 2025 endrer kostnadsbildet, og test om konteinerbasert utrulling reduserer kaldstart-kostnaden. For svært tunge modeller kan det også lønne seg å vurdere en dedikert compute-tjeneste fremfor ren FaaS.
Flerspråklige team med blandet Node.js, Python og Java: begge plattformer dekker dette, men Lambdas SnapStart for Java gir et konkret ytelsesløft som Azure foreløpig ikke har en direkte parallell til. Team som står fritt til å velge språk bør la kaldstart-krav for det tyngste språket i porteføljen styre plattformvalget.
Offentlig sektor med krav til norsk/europeisk datalagring: sjekk hvilke regioner begge leverandørene faktisk har i Norden før valg av plattform, siden regionvalg påvirker både kaldstart-nærhet og hvilke compliance-krav som dekkes. Dette bør avklares med egen sikkerhetsavdeling før arkitekturvalg, ikke etter at koden allerede er skrevet.

Fordeler og ulemper

AWS Lambda – fordeler: lavere grunnpris per GB-sekund, dypere og mer moden integrasjon med resten av AWS-tjenestene, tydeligere og mer forutsigbar samtidighetsmodell, SnapStart gir rask oppstart for Java, ARM/Graviton2 gir videre 20 prosent kostnadskutt.

AWS Lambda – ulemper: fakturering av INIT-fasen siden august 2025 øker kostnaden for tunge oppstartsjobber, maks 15 minutters kjøretid begrenser enkelte batch-scenarioer, ingen innebygd stateful orkestrering uten å legge til Step Functions som egen tjeneste.

Azure Functions – fordeler: fire fleksible vertsplaner å velge mellom, innebygd stateful orkestrering via Durable Functions, sterk integrasjon med Azure PaaS-tjenester og Microsoft 365, isolert prosessmodell gir god kontroll for .NET-team.

Azure Functions – ulemper: Flex Consumption koster vesentlig mer per GB-sekund enn Lambda i vårt regneeksempel, bredere og mindre forutsigbart kaldstart-spenn på klassisk Consumption-plan, privat nettverkstilgang krever oppgradering til Premium eller Dedicated.

Beslutningsfaktor	Vinner	Begrunnelse
Ren kompute-kostnad	AWS Lambda	2,3x billigere enn Azure Flex Consumption i regneeksempelet over
Kaldstart-forutsigbarhet	AWS Lambda	Tettere p95-spenn i uavhengige 2026-benchmarks
Stateful orkestrering	Azure Functions	Durable Functions er innebygd, Lambda krever egen Step Functions-tjeneste
.NET/C#-utvikleropplevelse	Azure Functions	Isolert prosessmodell og dypere IDE-integrasjon
Maks kjøretid per kall	AWS Lambda	15 minutter mot 5-10 minutter på Azure Consumption
Enterprise-integrasjon mot Microsoft 365	Azure Functions	Tettere kobling mot Power Platform og Active Directory

Verdikt: hvem vinner på hvilke tall

Basert på tallene i denne sammenligningen er det ikke ett entydig svar, men et klart mønster. På ren kostnad for et representativt API-scenario med 10 millioner kjøringer i måneden, er AWS Lambda om lag 2,3 ganger billigere enn Azure Functions Flex Consumption, og enda billigere med ARM/Graviton2. Lambda vinner også på kaldstart-forutsigbarhet for Node.js og Python i de fleste uavhengige 2026-testene, samt på klarhet i samtidighetsmodellen.

Azure Functions vinner derimot tydelig når organisasjonen allerede er investert i Microsoft-økosystemet, når stateful orkestrering (Durable Functions) sparer betydelig utviklingstid sammenlignet med å sette opp Step Functions separat, eller når IoT- og bedriftsintegrasjon mot Azure PaaS-tjenester er kjernebehovet. For team som ikke har en eksisterende skyplattform å forholde seg til, og der ren kostnadseffektivitet for HTTP-API-er er hovedkriteriet, peker tallene i denne artikkelen mot AWS Lambda som det billigste og mest forutsigbare valget i 2026. For team dypt forankret i Azure, med behov for tett integrasjon mot Microsoft-tjenester, er merkostnaden for Azure Functions ofte verdt det i redusert integrasjonsarbeid.

Det viktigste rådet fra denne gjennomgangen er likevel at ingen av plattformene bør velges ut fra én enkelt beslutningsfaktor. Et team som velger Lambda utelukkende fordi GB-sekund-prisen er lavere, men som deretter må bygge egen stateful orkestrering fra bunnen, kan fort tape tilbake hele kostnadsgevinsten i ekstra utviklingstid. Omvendt kan et team som velger Azure Functions utelukkende for Durable Functions, men som ikke trenger stateful orkestrering i det hele tatt, ende opp med å betale Flex Consumption-prisen for en funksjon som fint kunne kjørt billigere andre steder. Regn på den faktiske arbeidsmengden, inkludert logging, overvåking og utviklertid, før dere låser arkitekturen til én av de to plattformene.

Leverandørlåsing: hvor bærbar er koden egentlig?

Et spørsmål som ofte kommer opp for sent i prosessen: hvor vanskelig er det å bytte plattform senere hvis behovene endrer seg? Verken Lambda eller Azure Functions er fullstendig portable ut av boksen. Selve handlerfunksjonen, altså logikken som mottar en hendelse og returnerer et svar, er relativt enkel å flytte, som migrasjonseksempelet i denne artikkelen viser. Det som binder deg tettere til én plattform er alt rundt handleren: IAM-roller og ressurspolicyer på AWS-siden, eller Azure Active Directory-integrasjon og Bicep/ARM-maler på Azure-siden.

Rammeverk som Serverless Framework og enkelte varianter av Terraform-moduler forsøker å abstrahere bort noe av denne forskjellen, slik at samme kodebase i teorien kan deployeres til flere skyer med minimale endringer. I praksis bruker de fleste team disse verktøyene til å strukturere ett enkelt skyoppsett bedre, ikke til faktisk å kjøre produksjon på flere skyer samtidig, siden den operasjonelle kompleksiteten ved ekte multi-cloud drift sjelden er verdt besparelsen for en gitt arbeidsmengde. For de fleste nordiske team er det mer realistisk å planlegge for at et plattformbytte, om det skjer, vil kreve en dedikert migreringsperiode, ikke en switch man slår om på en ettermiddag.

Den praktiske konsekvensen er at valget mellom Lambda og Azure Functions bør behandles som en langsiktig arkitekturbeslutning, ikke en midlertidig konfigurasjon. Invester tid i å dokumentere hvilke plattformspesifikke tjenester (EventBridge, Step Functions, Durable Functions, Event Grid) funksjonene deres avhenger av, slik at en eventuell fremtidig migrering blir en planlagt prosess og ikke en brannslukningsøvelse.

Ofte stilte spørsmål

Er AWS Lambda billigere enn Azure Functions?
I det representative regneeksempelet i denne artikkelen (10 millioner kjøringer, 512 MB, 200 ms), kommer Lambda x86 ut på rundt $11,80 etter gratisnivå, mot rundt $27,00 for Azure Functions Flex Consumption, altså omtrent 2,3 ganger billigere. Bruker du Azures klassiske Consumption-plan i stedet for Flex, blir forskjellen mindre.

Hvilken plattform har raskest kaldstart?
Uavhengige 2026-sammenligninger peker på at Lambda generelt har tettere og mer forutsigbar kaldstart-fordeling for Node.js og Python enn Azures klassiske Consumption-plan, som har vist et bredere spenn med enkelte lange utfall.

Kan jeg eliminere kaldstart helt på begge plattformer?
Ja, men det koster ekstra på begge. Lambda tilbyr Provisioned Concurrency og SnapStart (for Java), mens Azure tilbyr Always Ready på Flex-planen eller full oppgradering til Premium-planen med alltid-varme instanser.

Hva er forskjellen på Azure Functions Consumption og Flex Consumption?
Consumption er den klassiske, rimeligere modellen med priser som ligger nærmere Lambda, men med mindre kontroll over kaldstart. Flex Consumption koster mer per GB-sekund og per kjøring, men gir bedre skalerings- og kaldstartkontroll, inkludert muligheten for forhåndsvarme instanser via Always Ready.

Hvilken plattform passer best for .NET-utviklere?
Azure Functions har historisk hatt et fortrinn her, spesielt med den isolerte prosessmodellen for C#, som gir bedre kontroll over avhengigheter og oppstartsatferd enn eldre in-process-modeller. Lambda støtter også .NET/C#, men den dypeste plattformintegrasjonen for .NET-team finnes fortsatt på Azure.

Hva betyr faktureringen av Lambdas INIT-fase for min kostnad?
Siden august 2025 fakturerer AWS for koden som kjører før selve håndteringsfunksjonen starter, altså initialisering av moduler, tilkoblinger og eventuelt store maskinlæringsmodeller. For funksjoner med tung oppstartslogikk kan dette gi en kostnadsøkning på 10-50 prosent sammenlignet med tidligere, så det lønner seg å måle og eventuelt optimalisere oppstartskoden.

Kan jeg bruke Kubernetes-lignende containerorkestrering i stedet for ren FaaS?
Ja. På AWS-siden er det nærmeste alternativet AWS Fargate eller EKS for containerbaserte mikrotjenester. På Azure-siden er Azure Container Apps det mest direkte alternativet, bygget på Kubernetes med KEDA for hendelsesbasert skalering og Dapr for tjenestekommunikasjon.

Er det vanskelig å migrere funksjoner mellom Lambda og Azure Functions?
Handlersignaturen er konseptuelt lik, så forretningslogikken kan ofte gjenbrukes med moderate endringer, men utløsermodellen, konfigurasjon av hemmeligheter og nettverksoppsett må tilpasses målplattformen. Følg migrasjonsstegene i denne artikkelen for en trygg overgang uten kostnadsoverraskelser.

Passer AWS Lambda eller Azure Functions best for en liten nordisk oppstartsbedrift?
Hvis bedriften ikke allerede har en etablert sky-strategi, taler ren kostnad og forutsigbar kaldstart-atferd for AWS Lambda, spesielt kombinert med ARM/Graviton2. Har teamet derimot allerede Microsoft 365 og Azure-lisenser gjennom en eksisterende avtale, kan Azure Functions redusere integrasjonsarbeidet nok til at merkostnaden er verdt det.

Hvordan påvirker logging og overvåking den totale kostnaden?
Begge plattformer fakturerer separat for logging og sporing, gjennom henholdsvis CloudWatch Logs og Application Insights. For arbeidslaster med høyt volum kan denne kostnaden bli en vesentlig andel av totalregningen, så den bør alltid regnes inn i budsjettet ved siden av selve kompute-kostnaden.