AWS rullet ut en ny måte å kjøre kode på serverløs infrastruktur 12. oktober 2026. Tjenesten heter Lambda Web Functions, og den endrer hvordan utviklere bygger API-er og nettjenester på Amazons skyplattform. Istedenfor at koden venter på én hendelse og returnerer ett svar, lytter funksjonen nå på en port og tar imot HTTP-forespørsler på samme måte som en vanlig webserver.
Endringen kommer midt i en bølge av AI-drevne arbeidsmengder som strømmer svar over tid, blant annet chatboter som bygger opp teksten ord for ord. Den klassiske Lambda-modellen var ikke bygget for denne typen trafikk, og AWS har nå laget en egen kjøremodell og en egen prisstruktur for nettopp dette bruksområdet. Tre dager senere, 15. oktober, fulgte AWS opp med en annen nyhet: Durable Execution SDK for Go ble allment tilgjengelig, slik at Go-utviklere kan bygge arbeidsflyter som varer i måneder uten at serverløs-modellen setter en stopper for det.
Begge lanseringene skjedde uten den store fanfaren AWS vanligvis sparer til re:Invent-konferansen i Las Vegas, som dette året går over fem dager fra 30. november til 4. desember. Likevel er Lambda Web Functions en av de mest konkrete endringene i hvordan Lambda fungerer siden tjenesten først ble lansert i 2014. For norske og nordiske team som drifter API-er, kundeportaler eller KI-tjenester på AWS, er dette en lansering verdt å forstå i detalj, ikke minst fordi en av de fem første regionene er Europa (Irland).
Gå ikke glipp av nye tech-saker på Google
Legg til Shattered én gang i Google-appen, så dukker artiklene våre opp i forslagene dine.
Hva er AWS Lambda Web Functions?
Lambda Web Functions snur om på hele grunnideen i tradisjonell Lambda. I den gamle modellen, som AWS nå kaller Event Functions, sender en trigger inn et hendelsesobjekt, koden kjører en handler-funksjon, og svaret går tilbake gjennom den samme kanalen. Alt er bygget rundt ett kall og ett svar.
I den nye modellen skriver utvikleren i stedet en vanlig HTTP-server som lytter på en port, akkurat som man ville gjort på en virtuell maskin eller i en container. AWS pakker den koden inn i en kjøreomgivelse som fremdeles skalerer automatisk og fremdeles fakturerer per bruk, men uten at utvikleren må tenke i hendelser og handlere. Det gjør det enklere å ta eksisterende webrammeverk og kjøre dem direkte på Lambda uten omskriving.
En viktig detalj er samtidighet. Et enkelt varmt kjøremiljø i Lambda Web Functions kan håndtere opptil 128 samtidige forespørsler, ifølge en grundig gjennomgang fra det japanske teknologimiljøet DevelopersIO, som testet funksjonen rett etter lansering i Tokyo-regionen. Det står i kontrast til den klassiske modellen, der hvert kjøremiljø typisk behandler én forespørsel om gangen før det blir ledig for neste kall. For arbeidsmengder med mye venting, som kall til databaser eller eksterne API-er, betyr det langt bedre ressursutnyttelse per instans.
Ved lansering støtter tjenesten kjøretiden Node.js 24 (nodejs24.x), ifølge samme gjennomgang fra DevelopersIO. Det er ikke overraskende at AWS starter med Node.js, siden mange av rammeverkene som brukes til å bygge strømmende API-er og chat-grensesnitt, som Express og lignende biblioteker, allerede lever i det økosystemet.
Lanseringsdato og hvilke regioner som får tilgang først
Lambda Web Functions ble generelt tilgjengelig 12. oktober 2026 i fem regioner: US East (Nord-Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) og Europa (Irland). Det er verdt å merke seg at AWS valgte å ta med en europeisk region allerede ved lansering, noe som ikke er en selvfølge for nye AWS-tjenester. Mange funksjoner starter i to eller tre amerikanske regioner før Europa får tilgang måneder senere.
For norske bedrifter som allerede kjører arbeidslaster i AWS sin Irland-region av hensyn til datalagring innenfor EU/EØS, betyr det at Lambda Web Functions er tilgjengelig fra første dag uten å måtte flytte data til USA eller Asia. Det samme gjelder virksomheter i Sverige, Danmark og Finland som bruker Irland som sin primære EU-region fordi Stockholm-regionen historisk har hatt færre tjenester tilgjengelig ved lansering av nye funksjoner.
Lanseringen er del av en lengre rekke forhåndskunngjøringer AWS har gjort i oktober i forkant av re:Invent. Ifølge researchen som ligger til grunn for denne artikkelen er det registrert 22 kunngjøringer knyttet til re:Invent-perioden 2026, der Lambda Web Functions og Durable Execution SDK for Go er to av de mest konkrete for utviklere som jobber med serverløs arkitektur. Reservert sitteplass til selve konferansen i Las Vegas åpnet 6. oktober.
Den nye kjøremodellen: fra hendelse til HTTP-server
For å forstå hvorfor dette er en stor endring, er det nyttig å se på hvordan Lambda fungerte frem til nå. En handler-funksjon tok inn et hendelsesobjekt, kjørte ferdig, og miljøet enten ble gjenbrukt til neste kall eller frosset ned. Modellen fungerte godt for korte, avgrensede oppgaver, som å behandle en melding fra en kø eller svare på et enkelt API-kall.
Problemet dukket opp når utviklere begynte å bygge tjenester som strømmer svar over flere sekunder, slik mange KI-assistenter gjør i dag. Da måtte man bruke omveier som Lambda Function URLs med responsstrømming eller legge en separat proxy foran funksjonen. Med Lambda Web Functions kan koden i stedet åpne en vanlig HTTP-lytter, skrive ut data gradvis, og la klienten lese svaret etter hvert som det blir produsert, uten noen omvei.
Samtidighet per miljø endrer kapasitetsplanlegging
Når et enkelt kjøremiljø kan ta 128 samtidige forespørsler i stedet for én, endres også måten team bør tenke på skalering. Et team som tidligere satte en høy samtidighetsgrense på Lambda-kontoen for å unngå kø under trafikktopper, kan i prinsippet dekke samme last med langt færre aktive miljøer. Det reduserer antall kaldstarter totalt sett, siden færre nye miljøer må spinnes opp når trafikken stiger.
Samtidig flytter dette noe av ansvaret tilbake til utvikleren. En webserver som håndterer 128 parallelle forespørsler må være skrevet på en måte som ikke blokkerer tråden ved lange databasekall, noe som er vanlig praksis i Node.js, men som krever at eksisterende kode faktisk er asynkron gjennomgående. Team som bare flytter en eksisterende Express-applikasjon over uendret, bør teste samtidighetsoppførselen grundig før de setter tjenesten i produksjon.
Ny prismodell: aktiv CPU-tid i stedet for total ventetid
Den andre store endringen ligger i fakturering. Tradisjonell Lambda betaler for hvert millisekund funksjonen kjører, uavhengig av om prosessoren faktisk jobber eller bare venter på at en database eller en ekstern tjeneste skal svare. For KI-arbeidsmengder som venter lenge på en modell et annet sted i kjeden, har det historisk vært en kostbar modell.
Lambda Web Functions fakturerer i stedet på fire dimensjoner: antall forespørsler, aktiv CPU-tid, minne som brukes mens miljøet kjører, og vanlig AWS-datatrafikk. Aktiv CPU-tid måles med en granularitet på 1 millisekund, og tiden koden bruker på å vente på databaser, nedstrøms-API-er eller andre I/O-operasjoner telles ikke som aktiv CPU-tid og faktureres derfor ikke på samme måte, ifølge AWS sin egen beskrivelse av tjenesten i AWS Builder Center.
Hva skjer med ventetiden på eksterne kall?
Dette er poenget AWS selv fremhever mest i lanseringsmaterialet, oppsummert med at kunden ikke betaler for ventingen. For en tjeneste som kaller en språkmodell og så strømmer svaret videre til brukeren i tre sekunder, men der prosessoren egentlig bare jobber aktivt i 200 millisekunder av de tre sekundene, er forskjellen i praksis stor. Tidligere ble hele varigheten fakturert. Nå er det i hovedsak den aktive databehandlingen som koster.
Prisen på selve forespørselen er satt til 0,30 dollar per million forespørsler, uavhengig av region. CPU- og minnepriser varierer derimot mellom regioner. I US East (Nord-Virginia) ligger aktiv CPU-tid på 0,0000276944 dollar per vCPU-sekund, og minne på 0,0000036667 dollar per GB-sekund. I Asia Pacific (Tokyo) er prisene høyere: 0,0000322421 dollar per vCPU-sekund og 0,0000042688 dollar per GB-sekund.
Regnestykket: hva betyr dette i praksis for en nordisk bedrift
AWS har selv lagt frem et regneeksempel som gir et konkret bilde av kostnadene. Scenarioet er en tjeneste som mottar 5 millioner forespørsler i måneden, bruker 200 millisekunder aktiv CPU-tid per forespørsel, og kjører i et miljø på 0,5 GB minne. Tabellen under samler tallene fra dette eksempelet, sammen med listepris per enhet i de to prisgruppene AWS har publisert.
| Element | US East (Nord-Virginia) | Asia Pacific (Tokyo) |
|---|---|---|
| Pris per million forespørsler | 0,30 dollar | 0,30 dollar |
| Aktiv CPU, pris per vCPU-sekund | 0,0000276944 dollar | 0,0000322421 dollar |
| Minne, pris per GB-sekund | 0,0000036667 dollar | 0,0000042688 dollar |
| Kostnad for aktiv CPU (5 mill. forespørsler, 200 ms) | 27,69 dollar | Ikke publisert av AWS |
| Kostnad for minne (0,5 GB-miljø, én måned) | 4,75 dollar | Ikke publisert av AWS |
| Kostnad for forespørsler (5 mill.) | 1,50 dollar | 1,50 dollar |
| Totalkostnad i eksempelet | 33,94 dollar | Ikke publisert av AWS |
Det mest oppsiktsvekkende tallet kommer når AWS sammenligner dette med den gamle modellen for nøyaktig samme arbeidsmengde. Ved å simulere en strømmende KI-tjeneste med 5 millioner forespørsler, der hver forespørsel varer 3 sekunder totalt men bare bruker 200 millisekunder aktiv CPU-tid, lander AWS på 33,94 dollar for Lambda Web Functions mot 101,00 dollar for en tradisjonell Event Function som løser samme oppgave. Det er en kostnadsreduksjon på nesten 66 prosent for denne typen strømmende arbeidsmengde, riktignok i et eksempel AWS selv har valgt for å vise tjenesten i best lys.
Durable Execution SDK for Go: arbeidsflyter som lever i måneder
Tre dager etter Web Functions-lanseringen, 15. oktober 2026, gjorde AWS Durable Execution SDK for Go allment tilgjengelig. Dette er en annen type problem enn web-trafikk: det handler om arbeidsflyter som må kjøre over lang tid, overleve omstarter, og huske nøyaktig hvor de var dersom noe feiler underveis, for eksempel en ordrebehandlingsprosess som venter på godkjenning fra et annet system i flere dager.
Go-utviklere kan nå pakke en durable-funksjon som en enkelt statisk binærfil og kjøre den på kjøretiden provided.al2023. SDK-et bruker et konsept kalt DurableContext, som lager sjekkpunkter underveis i kjøringen. Hvert sjekkpunkt lagrer fremdriften, slik at funksjonen kan fortsette nøyaktig der den slapp dersom den blir avbrutt, i stedet for å starte helt på nytt, ifølge AWS sin egen dokumentasjon og kildekoden til SDK-et på GitHub.
Det mest oppsiktsvekkende tallet her er varigheten. Fordi en durable-orkestrering strekker seg over flere Lambda-kall og ikke forbruker beregningskraft mens den venter, kan en hel arbeidsflyt vare i opptil ett år, ifølge AWS sin egen GitHub-dokumentasjon for Go SDK-et. Det er en stor kontrast til en vanlig synkron Lambda-invokering, som fortsatt er begrenset til maksimalt 15 minutter.
Hvilke språk og grenser gjelder for durable execution
Go er langt fra det eneste språket AWS støtter. Ifølge AWS sin dokumentasjon dekker Durable Execution SDK nå seks språk, og Go-lanseringen fullfører en rekke som startet tidligere i 2026 med de mer populære språkene i serverløs-verdenen. Tabellen under oppsummerer status per 18. oktober 2026.
| Egenskap | Detalj |
|---|---|
| Støttede SDK-språk | JavaScript, TypeScript, Python, Java, Go, C# (.NET) |
| Kjøretid for Go-funksjoner | provided.al2023 (statisk binærfil) |
| GA-dato for Go SDK | 15. oktober 2026 |
| Maks varighet for synkron invokering | 15 minutter |
| Maks varighet for hele orkestreringen | Opptil 1 år |
| Sjekkpunkt-mekanisme | DurableContext med trinnvis tilstandslagring |
Et viktig forbehold: durable-operasjoner og sjekkpunktdata faktureres separat fra vanlig Lambda-kjøring, og lagring og oppbevaring av sjekkpunkter kan bidra til egne kostnader. AWS har ikke publisert fullstendige prisdetaljer for denne målingen i materialet som ligger til grunn for denne artikkelen, og team bør derfor regne med egen testing før de flytter kritiske langvarige prosesser over på dette mønsteret.
Hvorfor AWS lanserer dette nå: AI-strømming driver endringen
Tidspunktet er ikke tilfeldig. Gjennom 2025 og 2026 har stadig flere selskaper bygget egne grensesnitt mot språkmodeller, enten via egne modeller eller via tredjeparts-API-er. Disse tjenestene strømmer typisk svar tilbake til brukeren mens modellen fortsatt genererer tekst, og det skaper nettopp den typen lange, men lavintensive, kall som den gamle Lambda-prisingen straffet hardest.
AWS sitt eget regneeksempel, med et LLM-strømmingsendepunkt som referanse, er et tydelig signal om hvilken kundegruppe denne lanseringen er myntet på. Selskaper som allerede bygger KI-agent-infrastruktur på AWS, inkludert de som bruker AgentCore Runtime til å drifte agenter med kortere kaldstarttider, får nå et billigere alternativ for selve API-laget som sitter mellom brukeren og modellen.
Samtidig løser Durable Execution SDK et helt annet problem i samme KI-bølge: agentiske arbeidsflyter som tar beslutninger over flere trinn, venter på menneskelig godkjenning, eller kaller flere eksterne tjenester i sekvens, krever nettopp den typen langvarige, tilstandsbevisste kjøring som durable execution er bygget for. De to lanseringene utfyller hverandre mer enn de konkurrerer om samme bruksområde.
Historisk bakgrunn: fra hendelsesdrevet Lambda i 2014 til webserver i 2026
AWS Lambda ble lansert på re:Invent i 2014 som en av de første brede kommersielle implementasjonene av det som senere ble kalt «functions as a service». Grunnideen var radikal for sin tid: utviklere skulle slippe å tenke på servere helt og holdent, og bare betale for de millisekundene koden faktisk kjørte.
Siden den gang har AWS lagt til lag etter lag rundt denne kjernen. Lambda Function URLs ga funksjoner en direkte HTTP-adresse uten å måtte sette opp API Gateway. SnapStart reduserte kaldstarttid for Java-funksjoner ved å ta et øyeblikksbilde av et initialisert miljø. Lambda Managed Instances ga team mer kontroll over hvor lenge instanser holdes varme. Hver av disse endringene har løst et konkret problem, men ingen av dem har endret selve grunnmodellen med hendelse inn og svar ut.
Lambda Web Functions er første gang AWS beveger seg bort fra selve hendelsesmodellen for en stor del av plattformen. Det er en erkjennelse av at verden har endret seg: moderne nettapplikasjoner, spesielt de som involverer strømmende KI-svar, passer bedre med en vedvarende server-prosess enn med korte, isolerte hendelser. På samme måte er Durable Execution SDK et svar på at serverløs lenge har vært dårlig egnet til prosesser som varer lenger enn minutter, et problem andre leverandører løste tidligere med egne verktøy for arbeidsflyt-orkestrering.
Konkurransebildet: hvor passer dette inn mot Fargate og andre plattformer
Lambda Web Functions kommer ikke inn i et tomt marked. Flere edge- og serverløs-plattformer har i flere år latt utviklere kjøre kode som lytter på nettverkskall direkte, uten å tvinge koden inn i et hendelsesformat. AWS sitt eget svar på denne trenden har tidligere vært Fargate, som kjører fullverdige containere uten at kunden må administrere underliggende servere, men Fargate er fortsatt priset og driftet som en container-tjeneste, ikke som en funksjon-tjeneste.
Det AWS nå gjør er å hente noe av fleksibiliteten fra containermodellen, port-lytting og vanlig HTTP, og kombinere det med faktureringsgranulariteten og den automatiske skaleringen fra den klassiske Lambda-modellen. For team som i dag velger mellom Fargate og Lambda fordi de ønsker en vanlig serverarkitektur, men samtidig vil ha funksjon-aktig fakturering, er Lambda Web Functions et nytt tredje alternativ å vurdere.
For virksomheter som allerede sammenligner skyleverandører på serverløs-pris og -ytelse, føyer dette seg inn i et mønster: hver stor leverandør prøver å fjerne friksjonen mellom å skrive vanlig serverkode og å betale bare for faktisk bruk. AWS sin versjon skiller seg ut ved å telle aktiv CPU-tid i stedet for total varighet, noe som i AWS sitt eget eksempel gir en vesentlig lavere regning for arbeidsmengder med mye venting, som nettopp KI-strømming er et typisk eksempel på.
Hva betyr dette for norske og nordiske utviklerteam
For team i Norge, Sverige, Danmark og Finland som allerede kjører produksjonstrafikk gjennom AWS sin Irland-region, er den mest konkrete nyheten at de ikke må vente på en europeisk utrulling. Det er ikke alltid tilfellet med nye AWS-tjenester, og det senker risikoen for team som vil teste Lambda Web Functions på faktiske kundevendte tjenester relativt tidlig.
For nordiske selskaper som bygger kundeservice-chatboter, interne KI-assistenter eller API-lag mot egne eller tredjeparts språkmodeller, er kostnadsbildet AWS selv legger frem verdt å teste opp mot egen trafikk. En reduksjon fra 101 dollar til 33,94 dollar i AWS sitt eksempel er stort nok til at det bør vekke interesse hos ethvert FinOps-team som allerede følger med på skykostnader, men det er fortsatt AWS sitt eget valgte eksempel, og faktisk besparelse vil variere med hvor mye av hver forespørsel som faktisk er aktiv databehandling versus venting.
Go-utviklere i nordiske fintech- og telekombedrifter, som ofte bruker Go til bakenforliggende tjenester med krav til ytelse og pålitelighet, får samtidig et nytt verktøy for prosesser som i dag løses med egne kø- og tilstandsløsninger. En ordrebehandling, en KYC-prosess i en bank, eller en flertrinns godkjenningsflyt i en forsikringsapplikasjon er alle eksempler på arbeidsflyter som kan dra nytte av en orkestrering som kan vare i måneder uten at man selv må bygge tilstandslagring fra grunnen.
Veien mot AWS re:Invent 2026: hva kommer etter dette
Både Lambda Web Functions og Durable Execution SDK for Go er forhåndskunngjøringer i egentlig forstand. AWS har en lang tradisjon med å dryppe mindre, men betydningsfulle, produktnyheter gjennom oktober og november, for så å samle de aller største annonseringene til selve keynotene i Las Vegas. Med rundt 22 kunngjøringer allerede registrert i denne perioden før konferansen starter, er det grunn til å tro at flere serverløs-relaterte nyheter kommer før 30. november.
Et naturlig spørsmål er om flere kjøretider får Web Functions-støtte utover Node.js 24, og om flere regioner, inkludert nordiske AWS-regioner som Stockholm, kommer til i løpet av de neste månedene. AWS har historisk brukt re:Invent-keynotene til å kunngjøre nettopp denne typen regionsutvidelser for tjenester som nylig ble lansert i et mindre antall regioner.
Fem spådommer for hvordan dette påvirker serverløs-markedet
Basert på tallene og mønstrene AWS selv har lagt frem, er det mulig å trekke noen linjer fremover. Spådommene under er redaksjonelle vurderinger, ikke bekreftede AWS-planer.
- Flere kjøretider følger etter Node.js. Gitt at AWS sitt eget eksempel handler om KI-strømming, er Python, som er dominerende i KI-verktøykjeder, en naturlig kandidat for neste kjøretid som får Web Functions-støtte.
- Flere regioner kommer rundt re:Invent. Fem regioner ved lansering er bredt for en helt ny kjøremodell, og historikken til AWS tilsier at flere regioner, inkludert i Europa, legges til i løpet av vinteren 2026 og 2027.
- Konkurrentene svarer med egne CPU-baserte prismodeller. Når en så stor leverandør som AWS flytter fakturering fra total varighet til aktiv CPU-tid for en ny produktkategori, legger det press på andre serverløs- og edge-plattformer til å vurdere lignende modeller for å ikke virke dyrere for ventetunge KI-arbeidsmengder.
- Durable execution blir en standardkomponent i agent-arkitektur. Ettersom flere selskaper bygger KI-agenter som tar flertrinns beslutninger, vil evnen til å pause, vente og gjenoppta en arbeidsflyt uten å betale for ventetiden sannsynligvis bli en forventet funksjon, ikke et nisjeverktøy.
- FinOps-team må lære en ny regnemodell. Overgangen fra varighet ganger minne til aktiv CPU-tid pluss minne pluss forespørsler krever nye dashboards og nye tommelfingerregler for kostnadsestimering, noe som trolig blir et eget tema i interne AWS-opplæringer i nordiske virksomheter gjennom 2027.
Praktiske steg for team som vil teste Lambda Web Functions
Et konseptuelt eksempel på hvordan port-lytting-modellen ser ut i praksis, uten å kopiere spesifikk AWS-kildekode, kan illustreres med en enkel Node.js-server som tar imot forespørsler og skriver ut svaret gradvis:
const http = require('http');
const server = http.createServer((req, res) => {
res.writeHead(200, { 'Content-Type': 'text/plain' });
// Skriv ut data gradvis i stedet for å samle alt før svar sendes
res.write('Behandler forespørsel...\n');
res.end('Ferdig.\n');
});
server.listen(process.env.PORT || 8080);Poenget med eksempelet er ikke den eksakte koden, men prinsippet: applikasjonen eier hele livssyklusen til en vanlig HTTP-forbindelse, inkludert muligheten til å skrive data gradvis, i stedet for å returnere ett ferdig svar via en handler-funksjon. Team som vil teste dette i praksis bør starte med en ikke-kritisk tjeneste, måle faktisk aktiv CPU-tid mot tidligere varighetsbasert fakturering, og først deretter flytte produksjonstrafikk over.
Ofte stilte spørsmål om AWS Lambda Web Functions
Hva er AWS Lambda Web Functions?
Det er en ny kjøremodell for AWS Lambda, lansert 12. oktober 2026, der koden lytter på en port og svarer på HTTP-forespørsler som en vanlig webserver, i stedet for å ta imot ett hendelsesobjekt og returnere ett svar.
Når ble Lambda Web Functions tilgjengelig, og i hvilke regioner?
Tjenesten ble allment tilgjengelig 12. oktober 2026 i fem regioner: US East (Nord-Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) og Europa (Irland).
Hvordan er prismodellen forskjellig fra vanlig Lambda?
I stedet for å fakturere total kjøretid, fakturerer Lambda Web Functions etter antall forespørsler, aktiv CPU-tid målt i 1-millisekunds steg, minne brukt mens miljøet kjører, og datatrafikk. Tid koden bruker på å vente på databaser eller eksterne tjenester faktureres ikke som aktiv CPU-tid.
Hvor mye billigere er den nye modellen for KI-strømming?
I AWS sitt eget regneeksempel, med 5 millioner forespørsler i måneden og en typisk strømmende KI-arbeidsmengde, kostet Lambda Web Functions 33,94 dollar mot 101,00 dollar for en tilsvarende tradisjonell Event Function, en reduksjon på nesten 66 prosent for dette spesifikke scenarioet.
Hvilken kjøretid støttes ved lansering?
Node.js 24 (nodejs24.x) er den eneste kjøretiden som er bekreftet å støtte Lambda Web Functions ved lansering, ifølge testing fra DevelopersIO i Tokyo-regionen.
Hva er Durable Execution SDK for Go?
Det er et SDK som ble allment tilgjengelig 15. oktober 2026 og lar Go-utviklere bygge langvarige, tilstandsbevisste arbeidsflyter på Lambda, pakket som en statisk binærfil på kjøretiden provided.al2023.
Hvor lenge kan en durable arbeidsflyt vare, og hva er grensen for vanlige kall?
En hel orkestrering kan vare i opptil ett år fordi den ikke forbruker beregningskraft mens den venter, mens en vanlig synkron Lambda-invokering fortsatt er begrenset til maksimalt 15 minutter.
Passer Lambda Web Functions for nordiske bedrifter som bruker AWS i Irland-regionen?
Ja. Europa (Irland) er en av de fem regionene som fikk tilgang ved lansering, så nordiske virksomheter som allerede bruker denne regionen for EU/EØS-data kan teste tjenesten uten å flytte data til USA eller Asia.