AWS satte en ny standard for hvor lenge en serverløs funksjon kan kjøre. Den 9. september 2026 kunngjorde Amazon at AWS Lambda Managed Instances nå støtter en kjøretid på opptil 90 minutter for asynkrone kall og event source mapping (ESM), opp fra den mangeårige grensen på 15 minutter. Det er en seksdobling, og den fjerner et av de eldste irritasjonsmomentene ved Lambda: at utviklere måtte bygge om arkitekturen sin så snart en jobb tok lengre tid enn et kaffemøte.
Endringen kommer fra AWS-ingeniørene Tarun Rai Madan, Dan Slusariuc og Snehil Ameta, og ble publisert direkte på AWS sin Compute-blogg. For nordiske utviklingsteam som har bygget rundt Lambdas 15-minuttersgrense i årevis, med Step Functions, SQS-kjeder og separate Fargate-oppgaver som lapper på symptomet, er dette den største praktiske endringen i Lambda siden SnapStart senket kaldstarttiden for containere.
Hva som faktisk endret seg 9. september 2026
Kjernen i kunngjøringen er enkel: funksjoner som kjører på Lambda Managed Instances (LMI) kan nå konfigureres med en timeout på opptil 5 400 sekunder, altså 90 minutter, for asynkrone påkallinger og event source mappings. Synkrone kall beholder den gamle grensen på 15 minutter, og initialiseringsfasen (Init phase) er fortsatt begrenset til 15 minutter uansett invokasjonstype. Det er ingen ny kode å skrive og ingen ny kjøretid å lære seg. Samme handler, samme IAM-rolle, samme VPC-oppsett som før. Den eneste forskjellen er tallet i konfigurasjonsfeltet.
For team som kjører AWS Lambda i konkurranse med Azure Functions, endrer dette maktbalansen litt. Azure sin Consumption-plan er fortsatt låst til 10 minutter som standard maksgrense, mens Lambda nå strekker seg til ni ganger så lenge på det billigste sporet AWS tilbyr for denne typen arbeidsmengder.
Fra 5 til 90 minutter: en tolv år lang historie
Lambda lanserte i 2014 med en timeout på fem minutter. I 2018 økte AWS grensen til 15 minutter, og der har den stått i åtte år. I mellomtiden har arbeidsmengdene endret seg dramatisk. Video-transkoding, tale-til-tekst, Monte Carlo-simuleringer for obligasjonsprising, ETL-jobber på datasett i flere gigabyte og AI-inferens er alle eksempler AWS selv trekker frem som jobber som rutinemessig sprengte 15-minuttersgrensen. Utviklere likte enkelheten i Lambda, men måtte stadig bygge om til Fargate eller Step Functions så snart en jobb ble litt for stor.
Tabellen under viser hvordan grensen har flyttet seg siden lanseringen.
| År | Maks kjøretid | Endring |
|---|---|---|
| 2014 | 5 minutter | Lambda lanseres |
| 2018 | 15 minutter | 3x økning |
| 2026 (før 9. sep) | 15 minutter | Uendret i 8 år |
| 2026 (fra 9. sep) | 90 minutter (async/ESM på LMI) | 6x økning |
| 2026 (durable execution) | Opptil 1 år | Krever durable functions |
Slik fungerer Lambda Managed Instances
Lambda Managed Instances er en kapasitetsmodell AWS bygde for å gi Lambda samme prisfordeler som EC2 uten at kunden må drifte infrastruktur selv. I praksis lar LMI Lambda kjøre flere samtidige forespørsler per instans og gi tilgang til mer spesialiserte maskinkonfigurasjoner enn den klassiske on-demand-modellen. AWS beskriver Lambda i 2026 som et produkt med to formfaktorer: tradisjonelle funksjoner (hendelsesdrevet, 15-minutters grense) og MicroVM-er for AI-generert kode (HTTP-drevet, med varighet på opptil åtte timer). Managed Instances utvider den første formfaktoren uten å bryte med Lambdas kjente programmeringsmodell.
Dette er samme retning AWS har tatt med SnapStart for containere, som kuttet kaldstarttid til under ett sekund. Mønsteret er tydelig: AWS prøver å fjerne grunnene til at team forlater Lambda for tyngre containerbaserte løsninger, uten å kreve at de gir opp den serverløse driftsmodellen.
Durable functions: kontroll i opptil ett år
Den mest interessante detaljen i kunngjøringen gjelder Lambda durable functions, som AWS lanserte tidligere i 2026 som en del av sitt durable execution SDK. En durable funksjon lagrer fremdrift gjennom sjekkpunkter (checkpoints) med step()- og wait()-operasjoner, og gjenoppretter automatisk fra siste sjekkpunkt om infrastrukturen feiler, i stedet for å starte helt på nytt. Før 9. september var hvert enkelt steg i en durable execution begrenset til 15 minutter, selv om selve den samlede kjøringen kunne vare i opptil ett år.
Nå kan hvert asynkront steg i en durable funksjon som kjører på Managed Instances vare i opptil 90 minutter, mens den totale kjøringen fortsatt kan strekke seg over et helt år. For jobber der gjenkjøring er dyrt, for eksempel en 40-minutters AI-inferensjobb som allerede er 30 minutter inn, anbefaler AWS å kombinere den lengre timeouten med periodiske sjekkpunkter. Da fortsetter en feil ved minutt 35 fra siste lagrede tilstand i stedet for fra null.
Hvilke invokasjonstyper får 90 minutter
Ikke alle kalltyper er like. AWS har delt opp reglene etter hvordan funksjonen trigges, og det er verdt å lese nøye før man planlegger en migrering.
| Invokasjonstype | Ny maksgrense | Merknad |
|---|---|---|
| Asynkron | 90 minutter | Standard retry-policy og dead-letter queue gjelder ved feil |
| Event source mapping (SQS, Kinesis, DynamoDB Streams, MSK) | 90 minutter | Køens synlighetstimeout må settes til minst 6x funksjonens timeout |
| Event source mapping (Amazon MQ, DocumentDB) | 15 minutter | Ikke omfattet av utvidelsen |
| Synkron | 15 minutter | Uendret, selv om funksjonen er satt til lengre timeout |
| Init-fase (kaldstart) | 15 minutter | Gjelder alle invokasjonstyper |
For SQS-basert arkitektur er dette spesielt viktig: Lambda validerer forholdet mellom køens synlighetstimeout og funksjonens timeout når event source mappingen opprettes, men systemet stopper deg ikke fra å endre en av innstillingene senere slik at de kommer i utakt. Det er fortsatt utviklerens ansvar å holde dem synkronisert.
Slik aktiverer du 90-minutters timeout
Aktivering krever ingen kodeendring, kun en konfigurasjonsoppdatering. Via AWS CLI ser kommandoen slik ut:
aws lambda update-function-configuration \
--function-name min-databehandler \
--timeout 5400 \
--region eu-north-1Eller via AWS SAM/CloudFormation, som mange norske team bruker sammen med Kubernetes og andre serverløse tjenester i samme miljø:
MinFunksjon:
Type: AWS::Serverless::Function
Properties:
FunctionName: min-databehandler
Runtime: python3.12
Handler: app.handler
Timeout: 5400
MemorySize: 10240Endringen trer i kraft fra neste invokasjon etter at konfigurasjonen er oppdatert. For event source mappings kan det ta noen minutter før den nye innstillingen forplanter seg gjennom systemet. Eksisterende overvåking i CloudWatch, CloudTrail og X-Ray fungerer som før, uten justeringer.
Hvem drar nytte: bruksområder i praksis
AWS peker på fem konkrete kategorier der 15-minuttersgrensen tidligere tvang team til å velge bort Lambda: mediebehandling som tale-til-tekst og video-transkoding, finansielle beregninger som Monte Carlo-simuleringer og porteføljerisiko, ETL-pipelines som prosesserer flerdelte datasett, AI-inferens for tyngre resonneringsoppgaver, og web-skraping mot trege eksterne kilder. Fellesnevneren er jobber som passer Lambdas minne- og CPU-profil godt, men som rett og slett tok for lang tid.
Et konkret eksempel er et team som kjører en 40 minutter lang AI-inferensjobb per forespørsel. Før september måtte dette enten deles opp i flere Lambda-kall koordinert av Step Functions, eller flyttes til Fargate med tilhørende container-drift. Nå kan hele jobben kjøre i én enkelt Lambda-invokasjon, med samme enkle deploy-modell som resten av applikasjonen.
Kostnad: ingen ekstra avgift, men sjekk regnestykket
AWS er tydelige på at det ikke koster noe ekstra å bruke den lengre timeouten. Standard Lambda Managed Instances-priser gjelder som før. Lambdas offisielle prisside oppgir 0,20 dollar per million forespørsler etter gratis-tier, og compute prises per GB-sekund. En funksjon som bruker 1 GB minne i ett sekund koster om lag 0,0000167 dollar, eksklusive forespørselskostnad. Multipliser det med 90 minutter i stedet for noen få sekunder, og regnestykket endrer seg fort.
Det er her nordiske FinOps-team bør være nøye. En jobb som tidligere måtte splittes over Step Functions og flere Lambda-kall hadde ofte en overhead i orkestrering som nå forsvinner, men selve compute-kostnaden for en 90-minutters jobb kan fortsatt bli høyere enn en tilsvarende Fargate-oppgave, avhengig av minnekonfigurasjon. Det lønner seg å regne på begge alternativene før man migrerer en lang batch-jobb over til Managed Instances.
Konkurrentbildet: AWS mot Azure, Google og Cloudflare
Ingen av de andre store skyleverandørene tilbyr noe tilsvarende på sitt billigste serverløse spor. Google Cloud Run functions (2. generasjon) tillater opptil 60 minutter for HTTP-triggede funksjoner, men bare 9 minutter (540 sekunder) for hendelsesdrevne funksjoner opprettet via Cloud Functions v2-API, ifølge Google Cloud sin egen dokumentasjon. Azure Functions på Consumption-planen er fortsatt begrenset til 10 minutter som maks, med 5 minutter som standard, dokumentert på Microsoft Learn. Cloudflare Workers opererer med et helt annet mål: 5 minutters CPU-tid per kall på Standard-planen, ifølge Cloudflares prisdokumentasjon, men det måler prosessortid, ikke ventetid, så tallene er ikke direkte sammenlignbare.
| Plattform | Maks kjøretid (billigste spor) | Maks kjøretid (dyrere spor) |
|---|---|---|
| AWS Lambda Managed Instances | 90 minutter (async/ESM) | Opptil 1 år (durable execution) |
| AWS Lambda (on-demand, synkron) | 15 minutter | Uendret |
| Azure Functions Consumption | 10 minutter | Ubegrenset på Premium/Dedicated |
| Google Cloud Run functions (event) | 9 minutter | 60 minutter for HTTP-triggede |
| Cloudflare Workers Standard | 5 min CPU-tid | 15 min for Cron/Queue Consumers |
Azure og Microsoft har riktignok ubegrenset kjøretid på sine Premium- og Dedicated-planer, men det krever at man forlater den rene forbruksbaserte prismodellen. AWS sitt grep er annerledes: de flytter grensen på et spor som fortsatt er tett koblet til serverløs prising, ikke bare på de dyreste, mest hands-on driftsmodellene.
Prismodell versus tidsgrense: hvorfor det ikke er en ren sammenligning
Det er fristende å rangere leverandørene bare etter maksimal kjøretid, men modellene måler forskjellige ting. Cloudflare prissetter CPU-tid, ikke vegg-klokke-tid, så en Worker som venter på et nettverkskall kan i praksis løpe mye lenger enn fem minutter uten å bruke opp kvoten sin. Google skiller mellom HTTP- og hendelsesdrevne triggere med to ulike grenser i samme produkt, noe som gjør Cloud Run functions vanskelig å sette i én tabellrad. Azure sitt hopp fra 10 minutter til ubegrenset er også et hopp i driftsansvar, fra ren “server-mindre” prising til noe som ligner mer på tradisjonell app-hosting. AWS sin løsning er den mest lineære av de fire: samme prismodell, samme driftsansvar, bare en høyere øvre grense for hvor lenge klokken får løpe.
Hva dette betyr for Fargate og Step Functions
AWS Step Functions Standard Workflows kan allerede kjøre i opptil ett år, og Fargate har aldri hatt noen kjøretidsgrense i det hele tatt fordi det kjører containere som ECS- eller EKS-oppgaver. Det betyr ikke at Managed Instances gjør disse tjenestene overflødige. For jobber som varer lenger enn 90 minutter, eller som krever finkornet orkestrering med parallelle grener, tilstander og godkjenningstrinn, er Step Functions fortsatt riktig verktøy. Det samme gjelder for arbeidsmengder som trenger vedvarende tilkoblinger, spesialisert maskinvare eller svært lang kjøretid i én sammenhengende prosess.
Det som endrer seg, er sonen midt imellom: jobber på 15 til 90 minutter som tidligere tvang team til å velge Fargate eller bygge kompleks orkestrering rundt Lambda, bare for å komme rundt en kunstig grense. Den sonen tilhører nå Lambda direkte, uten mellomledd.
Historisk kontekst: serverless-grensenes utvikling
Da Lambda lanserte i 2014, var tanken at funksjoner skulle være korte, hendelsesdrevne og stateless. Åtte år senere, i 2018, doblet AWS grensen fra 5 til 15 minutter, og den grensen har stått urørt gjennom en periode der serverløs databehandling gikk fra å være et nisjeverktøy for webhooks til å bli ryggraden i mange produksjonssystemer. AWS sin egen tjeneste AgentCore Runtime viste tidligere i 2026 at selskapet er villig til å bryte gamle antakelser om hvordan serverløse kjøretider bør se ut, spesielt når AI-arbeidsmengder krever noe annet enn den klassiske webhook-modellen.
Det som skiller 2026-endringen fra tidligere justeringer, er at den kommer sammen med en helt ny kapasitetsmodell (Managed Instances) og et helt nytt utførelsesparadigme (durable functions). AWS bygger ikke lenger bare videre på den opprinnelige Lambda-modellen, de legger til nye lag som gradvis visker ut grensen mellom “funksjon” og “arbeidsflyt”.
Det er også et tegn i tiden. AI-inferens er den arbeidsmengden AWS nevner oftest når de forklarer hvorfor 15 minutter ikke lenger holder. Resonnerende språkmodeller kan bruke flere minutter bare på ett enkelt svar, og batch-inferens mot store datasett kan lett vare en time eller mer. Da Lambda ble designet i 2014, fantes ikke denne typen arbeidsmengde i det hele tatt. Grensen på 90 minutter er dermed ikke bare en teknisk justering, den er et forsøk på å gjøre en tolv år gammel tjeneste relevant for en helt ny generasjon arbeidsmengder uten å måtte bygge en ny tjeneste fra bunnen.
Markedseffekt for nordiske utviklere og bedrifter
For norske og nordiske selskaper som allerede har store deler av infrastrukturen sin i AWS-regionen eu-north-1 i Stockholm, senker denne endringen terskelen for å holde flere arbeidsmengder serverløse i stedet for å flytte dem til Fargate eller EKS bare fordi de tar for lang tid. Det er spesielt relevant for finanssektoren, der batch-beregninger som porteføljerisiko og likviditetsanalyser ofte havner nettopp i sonen mellom 15 og 90 minutter, og for mediebedrifter som prosesserer video- og lydfiler.
Samtidig er det verdt å merke seg at endringen foreløpig kun gjelder Managed Instances, ikke den klassiske on-demand-modellen for synkrone kall. Team som bygger API-er med synkrone HTTP-svar til sluttbrukere, vil altså ikke merke noen forskjell før AWS eventuelt utvider grensen videre. Kunngjøringen inneholder da også en direkte oppfordring fra AWS om at kunder som trenger lengre timeout for synkrone kall eller on-demand-modellen bør melde fra via Lambda sin offentlige roadmap på GitHub.
Hvorfor eu-north-1 og datasuverenitet spiller inn
Mange norske virksomheter i finans og offentlig sektor har allerede lagt vekt på å holde arbeidsmengder i den svenske AWS-regionen for å tilfredsstille interne krav til datalokasjon i Norden. Når en tjeneste som Lambda blir mer kapabel innenfor akkurat den regionen, betyr det i praksis at flere tunge batch-jobber kan bli værende der uten at teamet må vurdere å flytte dem til en annen region eller en helt annen skyleverandør bare for å få nok kjøretid. Det samme gjelder team som bruker Google Cloud Run som sekundærplattform for enkelte tjenester, der 9-minuttersgrensen for hendelsesdrevne funksjoner ofte er den reelle årsaken til at en jobb havner på AWS i stedet.
Fallgruver og beste praksis
En lengre kjøretid flytter også ansvar over på utvikleren. AWS peker selv på tre områder som krever ekstra oppmerksomhet når funksjoner kjører betydelig lenger enn før.
- Nettverk: Sjekk at inaktivitetstimeout på nedstrøms tjenester som RDS, ElastiCache og eksterne API-er tåler hele funksjonens varighet. Går trafikken gjennom en NAT Gateway, bør du sende keep-alive-pakker for å unngå at inaktive tilkoblinger droppes etter 350 sekunder.
- Credentials: Midlertidige tilgangsnøkler og tokens må enten gjelde for hele kjøretiden eller fornyes i bakgrunnen underveis.
- Idempotens: Lambda garanterer ikke nøyaktig én kjøring per hendelse. Med lengre funksjoner øker vinduet for gjenforsøk og duplikate leveranser. AWS anbefaler Powertools for AWS Lambda for å sikre at operasjoner som betalinger eller databaseskriving gir samme resultat selv om de kjøres flere ganger.
For team som bruker durable functions gjelder i tillegg at steg har “at-least-once”-semantikk som standard. SDK-en hopper over fullførte steg ved gjenavspilling, men steg som feiler før de rekker å sjekkpunktes kan kjøre på nytt. Bruk kjøringsnavn som idempotens-nøkler for å unngå duplikater der det er kritisk.
Fremtidsutsikter: hva skjer videre med Lambda
Basert på retningen AWS har tatt gjennom 2026, tegner det seg noen sannsynlige utviklingslinjer for de neste 12 til 18 månedene.
- AWS vil trolig utvide 90-minuttersgrensen til flere invokasjonstyper, inkludert synkrone kall, dersom etterspørselen på Lambda-roadmapen fortsetter å peke i den retningen.
- Konkurrentene vil svare. Google og Microsoft har historisk fulgt etter når AWS flytter grenser på serverløs kjøretid, og det er sannsynlig at minst én av dem justerer sine egne grenser innen 2027.
- Durable functions vil trolig bli standardanbefalingen for lange batch-jobber i AWS sin egen dokumentasjon, fremfor manuell orkestrering med Step Functions, for arbeidsmengder som ikke krever kompleks forgrening.
- Flere norske og nordiske fintech- og mediebedrifter vil sannsynligvis migrere batch-arbeidsmengder fra Fargate tilbake til Lambda i løpet av 2027, ettersom kostnadskalkylen for 15–90-minutters jobber blir gunstigere.
- Skillet mellom “serverløs funksjon” og “container” vil fortsette å viskes ut, drevet av AI-arbeidsmengder som verken passer den klassiske webhook-modellen eller krever full container-drift.
Slik kommer du i gang uten å bryte noe
Den enkleste måten å teste endringen på er å identifisere funksjoner som i dag orkestreres av Step Functions utelukkende fordi de overskrider 15 minutter, og vurdere om de kan samles til én enkelt Lambda-invokasjon med den nye timeouten. Start med en ikke-kritisk batch-jobb, mål faktisk kjøretid og kostnad, og sammenlign med den gamle løsningen før du migrerer noe som er kundevendt. Husk at synkrone kall ikke er omfattet, så eventuelle API-er må fortsatt holde seg innenfor 15 minutter eller bygges om til asynkron flyt med polling.
Ofte stilte spørsmål
Gjelder 90-minuttersgrensen alle Lambda-funksjoner?
Nei. Den gjelder kun asynkrone kall og event source mappings som kjører på Lambda Managed Instances. Synkrone kall og funksjoner på den klassiske on-demand-modellen er fortsatt begrenset til 15 minutter.
Må jeg endre kode for å bruke den nye timeouten?
Nei. Det er en ren konfigurasjonsendring, enten via AWS CLI, CloudFormation, SAM eller konsollen. Runtime, handler og IAM-rolle forblir uendret.
Koster det mer å bruke 90 minutters timeout?
Det er ingen egen avgift for selve funksjonen, men du betaler fortsatt for faktisk brukt compute-tid per GB-sekund. En jobb som kjører i 90 minutter koster naturlig nok mer enn en som kjører i 15, så det lønner seg å sammenligne med Fargate for lange, jevnt belastende jobber.
Hva skjer med Amazon MQ og DocumentDB event source mappings?
De er ikke omfattet av utvidelsen og beholder 15-minuttersgrensen, i motsetning til SQS, Kinesis, DynamoDB Streams og MSK.
Kan en durable funksjon fortsatt kjøre i et helt år?
Ja. Den totale durable execution-en kan vare i opptil ett år når den påkalles asynkront, mens hvert enkelt steg (invokasjon) innenfor den nå kan vare opptil 90 minutter på Managed Instances, mot 15 minutter tidligere.
Bør jeg flytte lange batch-jobber fra Fargate til Lambda nå?
Ikke automatisk. For jobber mellom 15 og 90 minutter kan det gi enklere drift og lavere kompleksitet. For jobber som varer lenger, eller som krever spesialisert maskinvare og vedvarende tilkoblinger, er Fargate fortsatt riktig valg.
Hvordan sammenligner dette seg med Azure og Google Cloud?
AWS sitt nye tak på 90 minutter for async/ESM-kall er lengre enn Azure Functions Consumption (10 minutter) og Google Cloud Run functions for hendelsesdrevne kall (9 minutter), men kortere enn Azure og Google sine ubegrensede eller time-lange topptilbud på dyrere driftsmodeller.
Må jeg endre SQS-oppsettet mitt?
Ja, hvis du bruker SQS som kilde. Køens synlighetstimeout bør settes til minst seks ganger funksjonens nye timeout, slik at Lambda får nok tid til å forsøke på nytt dersom en funksjon strupes mens den behandler en tidligere batch.