AWS kunngjorde 2. september 2026 at Lambda SnapStart, teknologien som skal fjerne den berømte “kalde starten” i serverless-databehandling, nå også fungerer for funksjoner pakket som container-images. Endringen høres teknisk ut, men den treffer et problem utviklere har klaget over siden Lambda-tjenesten ble lansert i 2014: at en funksjon som ikke har kjørt på en stund, kan bruke flere sekunder på å starte opp igjen før den svarer på en eneste forespørsel. For team som bygger AI-inferens, betalingsflyter eller interaktive API-er i sky-infrastruktur i Norden, er det forskjellen mellom en respons brukeren knapt merker og en ventetid som får dem til å klikke bort.
AWS selv beskriver gevinsten slik: “Starting today, AWS Lambda supports SnapStart for functions packaged as container images, reducing startup times from several seconds to as low as sub-second.” Oversatt betyr det at oppstartstiden faller fra flere sekunder til under ett sekund for arbeidsmengder som tidligere måtte velge mellom containerens fleksibilitet og funksjonens raske respons. Denne artikkelen går gjennom hva som faktisk er nytt, hvordan teknologien virker under panseret, hva det koster, og hvordan AWS sitt grep stiller seg mot Google Cloud Run og Azure Functions.
Hva er AWS Lambda SnapStart, og hvorfor er det nyheter nå
Lambda SnapStart er en valgfri optimalisering utviklere kan slå på for en funksjonsversjon. I stedet for at AWS initialiserer en helt ny kjøremiljø-instans hver gang trafikken skalerer opp, kjører Lambda initialiseringsfasen én gang, tar et øyeblikksbilde av det ferdig oppvarmede miljøet, og gjenbruker det øyeblikksbildet neste gang en ny instans trengs. Funksjonen slipper dermed å laste avhengigheter, starte kjøretidsmiljøet og kjøre oppstartskode på nytt for hver eneste skalering.
Teknologien ble opprinnelig lansert for Java-kjøretider under re:Invent i november 2022, med et offisielt lanseringsinnlegg datert 29. november samme år. Java var det naturlige startpunktet fordi JVM-oppstart historisk har vært blant de tregeste i Lambda-økosystemet, ofte flere sekunder for applikasjoner med tunge rammeverk som Spring. Siden den gang har AWS gradvis utvidet støtten til Python og .NET som administrerte kjøretider. Frem til september 2026 var funksjonen likevel begrenset til disse tre administrerte kjøretidene. Utviklere som pakket funksjonene sine som container-images, en vanlig løsning for maskinlæringsmodeller, tunge avhengigheter eller egendefinerte kjøretider, hadde ikke tilgang til den samme snapshot-mekanismen. Det er nettopp dette gapet AWS nå tetter.
Slik fungerer snapshot-teknologien under panseret
Lambda-kjøremiljøet bygger på lettvekts-mikrovirtuelle maskiner fra Firecracker-teknologien AWS selv utviklet. Når en funksjonsversjon publiseres med SnapStart aktivert, kjører AWS følgende sekvens: mikroVM-en starter, kjøretiden initialiseres, avhengigheter lastes inn, og all statisk kode kjøres helt til funksjonen er klar til å motta forespørsler. På det punktet fryser AWS tilstanden og lagrer et kryptert øyeblikksbilde i en cache som er bygget for lav ventetid ved storskala gjenoppretting. Neste gang Lambda trenger en ny instans av funksjonen, gjenoppretter systemet øyeblikksbildet i stedet for å kjøre hele initialiseringen fra bunnen.
Det praktiske skillet blir tydelig når man sammenligner de to forløpene. Uten SnapStart må Lambda tildele en mikroVM, starte kjøretiden, laste avhengigheter, kjøre initialiseringskode og først deretter behandle forespørselen. Med SnapStart gjenoppretter systemet i stedet en allerede initialisert mikroVM og går rett til behandling av forespørselen, med et kort restaureringstrinn innimellom. Det er verdt å presisere at SnapStart primært kutter initialiseringstiden. Den gjør ikke selve funksjonslogikken raskere, og den fjerner ikke all ventetid knyttet til nettverk, lagring, utvidelser eller selve gjenopprettingsoperasjonen.
For container-images krever AWS at utviklere eksplisitt godtar funksjonen. Det gjøres enten ved å bruke et av AWS sine ferdige basisbilder med SnapStart-støtte, eller ved å legge til en egen etikett i Dockerfile-filen for egendefinerte images:
LABEL com.amazonaws.lambda.feature.snapstart="Allow"AWS har også dokumentert et livssyklus-hook-mønster med et eget gjenopprettings-API kalt /restore/next, som lar utviklere kjøre kode rett før øyeblikksbildet tas og rett etter gjenoppretting. Det er relevant for funksjoner som holder på tilstand som ikke bør fryses og gjenbrukes rått, som åpne nettverkstilkoblinger, tilfeldighetsgeneratorer, midlertidige legitimasjoner eller lokale mellomlagre.
Container-images får full SnapStart-støtte fra september 2026
Det virkelig nye i kunngjøringen er ikke selve snapshot-mekanikken, som har eksistert i flere år. Det nye er at AWS nå anerkjenner containere som et likeverdig pakkeformat til de administrerte kjøretidene. Frem til nå måtte team som ville ha rask oppstart, velge bort containerens fordeler: full kontroll over operativsystem-laget, mulighet til å pakke store maskinlæringsmodeller og tunge biblioteker, og enklere overføring mellom Lambda og andre containerbaserte tjenester som Fargate eller Kubernetes.
AWS peker selv på maskinlæringsinferens og interaktive API-er som de tyngste bruksområdene for endringen. Det gir mening: modeller pakket i containere drar ofte med seg store rammeverk, vektfiler og GPU-drivere som tar tid å laste inn ved kald oppstart. Med SnapStart kan den kostbare oppstartsjobben gjøres én gang og gjenbrukes, mens selve inferensen fortsatt kjører frisk for hver forespørsel. For team som allerede har investert i containerbaserte pipelines for AI-arbeidslaster, fjerner det et argument for å flytte alt til lengre levende servere bare for å slippe kald oppstart.
Ytelsestallene: fra flere sekunder til under ett sekund
AWS sin offisielle markedsføring har historisk brukt Java som referanse, med et anslag om at SnapStart kan redusere oppstartstiden med opptil ti ganger, fra flere sekunder til under ett sekund for egnede arbeidslaster. Det presise resultatet varierer med kjøretidsversjon, avhengighetsgraf, minnestørrelse, tilkoblede utvidelser og hvorvidt målingen bare teller initialisering eller hele responstiden for det første kallet. “Opptil ti ganger” er derfor et maksimalt markedsføringstall, ikke en garantert tjenestenivå-avtale.
For container-images bruker AWS samme formulering: oppstartstid kan falle fra flere sekunder til så lavt som under ett sekund. Selskapet publiserer imidlertid ingen detaljert, uavhengig benchmark-tabell med bildestørrelse, kjøretid, minneallokering, arkitektur, grunnlinje for kald oppstart og p50/p95/p99-ventetider. Det offisielle tallet bør derfor leses som et lanseringsanslag, ikke som en universell garanti for hvor raskt akkurat din arbeidslast blir.
Et frittstående benchmark fra det japanske konsulentselskapet Classmethod ga et mer konkret bilde: i deres eget testoppsett lå fakturert kjøretid på rundt 3 til 34 millisekunder, mens selve gjenopprettingen av øyeblikksbildet tok mellom 0 og 1 millisekund. Det er ett enkeltstående testresultat fra én arbeidslast, ikke et AWS-garantert gjennomsnitt, men det gir en pekepinn på hvor lite som faktisk gjenstår av “kald” oppstart når gjenopprettingen fungerer optimalt.
Hvilke regioner og kjøretider som støttes ved lansering
SnapStart for container-images er tilgjengelig i alle kommersielle AWS-regioner, med to unntak: Asia-Stillehavet (New Zealand) og Asia-Stillehavet (Taipei). For europeiske og nordiske kunder betyr det i praksis full dekning, inkludert regionene i Stockholm, Frankfurt, Irland og Paris som de fleste norske virksomheter allerede bruker for produksjonstrafikk.
På kjøretidssiden dokumenterer AWS støtte for Java 11 og nyere, Python 3.12 og nyere, samt tilsvarende basisbilder på tvers av både ZIP-baserte og containerbaserte distribusjonsformater. Det finnes også støtte for en tilsvarende familie av .NET-kjøretider, men den nøyaktige versjonslisten bør sjekkes direkte i AWS sin dokumentasjon siden selskapet kan oppdatere støtten uavhengig av selve lanseringskunngjøringen. For egendefinerte container-images kreves enten den nevnte SnapStart-etiketten i Dockerfile, eller en implementasjon av livssyklus-protokollen med gjenopprettings-API-et. Mangler begge deler, feiler publiseringen av funksjonsversjonen.
Prismodellen: hva koster snapshot-caching og gjenoppretting
SnapStart er ikke gratis for alle kjøretider. For de administrerte kjøretidene utenom Java kommer det en egen kostnad for å mellomlagre øyeblikksbildet, i tillegg til en kostnad per gjenoppretting. AWS sin prisside beskriver at kunder betaler for å cache et øyeblikksbilde så lenge funksjonsversjonen er aktiv, med en minimumsperiode på tre timer, i tillegg til en egen kostnad hver gang et øyeblikksbilde gjenopprettes basert på tildelt minne. Java-kjøretidene som støttes er unntatt fra denne ekstrakostnaden.
En uavhengig gjennomgang fra Classmethod fant følgende eksempelpriser for regionen US East (N. Virginia): mellomlagring av øyeblikksbilde kostet 0,0000015046 dollar per GB-sekund, mens hver gjenoppretting kostet 0,0001397998 dollar per GB. Disse tallene er regions- og datospesifikke eksempler, ikke universelle priser som gjelder i alle AWS-regioner. Poenget som ofte overses er at minimumsperioden på tre timer betyr at en publisert funksjonsversjon kan pådra seg cache-kostnad selv i perioder med lite eller ingen trafikk, fordi cachen forblir knyttet til den aktive versjonen uansett kallvolum.
| Kostnadskomponent | Gjelder for container-SnapStart? | Merknad |
|---|---|---|
| Vanlig forespørselskostnad | Ja | Standard Lambda-fakturering per kall |
| Kjøretid, GB-sekund | Ja | Betales som for enhver Lambda-funksjon |
| Mellomlagring av øyeblikksbilde | Ja, unntatt for støttede Java-kjøretider | Fakturert per GB-sekund, minimum tre timers periode |
| Gjenoppretting av øyeblikksbilde | Ja, unntatt for støttede Java-kjøretider | Fakturert per GB tildelt minne per gjenoppretting |
| Minimum cache-periode | Ja | Tre timer, uavhengig av faktisk trafikkvolum |
AWS Lambda mot Google Cloud Run og Azure Functions
Ingen av de tre store skyleverandørene publiserer tall som er direkte sammenlignbare. AWS oppgir et “opptil”-anslag og et “under ett sekund”-krav for SnapStart. Google og Microsoft eksponerer i stedet kald-oppstart-atferd gjennom produktarkitektur, minimumsinstanser eller uavhengige benchmark-studier. Tallene under bør derfor leses som retningsgivende spenn, ikke som en direkte hode-mot-hode-måling av identiske arbeidslaster.
Google Cloud Run er containerbasert og har typisk en større oppstartsflate enn en lettvekts funksjonskjøretid, fordi tjenesten må starte hele brukercontaineren, applikasjonsserveren og alle biblioteker. Google sin egen dokumentasjon skiller mellom oppstartsventetid mens en ny instans opprettes, og selve forespørselsventetiden etter at instansen er tilgjengelig. Cloud Run støtter minimumsinstanser, som holder instanser varme og kan redusere eller fjerne kald oppstart helt, mot en ekstra kostnad for den varme kapasiteten. Azure Functions har enda mer variasjon fordi ventetiden avhenger sterkt av hvilken hosting-plan som er valgt. Forbruksplanen kan skalere til null og pådra seg kald oppstart, Premium-planen bruker forhåndsvarmede instanser, og Flex Consumption-planen tilbyr konfigurerbare alltid-klare instanser med forbedret skaleringsatferd.
| Plattform | Typisk kald oppstart (rapportert) | Hovedmekanisme mot ventetid |
|---|---|---|
| AWS Lambda SnapStart | AWS oppgir “under ett sekund”, historisk opptil 10x for Java | Gjenoppretting av forhåndsinitialisert øyeblikksbilde |
| Google Cloud Run | Vanligvis noen hundre millisekunder til noen sekunder | Minimumsinstanser holder containere varme |
| Google Cloud Functions | Under ett sekund til flere sekunder, avhengig av generasjon | Minimumsinstanser og redusert avhengighetsgraf |
| Azure Functions (Forbruksplan) | Noen hundre millisekunder til flere sekunder | Ingen forhåndsvarming som standard |
| Azure Functions (Premium / Flex) | Redusert vesentlig sammenlignet med Forbruksplanen | Forhåndsvarmede eller alltid-klare instanser |
Det arkitektoniske skillet er egentlig viktigere enn selve millisekund-tallene. Lambda SnapStart gjenoppretter et allerede initialisert øyeblikksbilde. Cloud Run starter normalt en helt ny container, med mindre en varm minimumsinstans allerede står klar. Cloud Run støtter til gjengjeld vilkårlige containere og lengre levende tjenester, en fleksibilitet som kan øke selve oppstartsarbeidet sammenlignet med en smalere Lambda-funksjon.
Historisk kontekst: fra Java-eksklusiv teknologi til full plattformdekning
Da AWS lanserte SnapStart i november 2022, var løftet begrenset til Java-funksjoner som kjørte på Corretto-kjøretiden java11. Det var et logisk startpunkt: JVM-en er kjent for tung oppstart sammenlignet med lettere kjøretider som Node.js eller Go, og Java-brukere hadde lenge klaget høyest over kald-oppstart-problemet i Lambda-forum og på konferanser. Suksessen med Java-implementasjonen ga AWS et bevist mønster de siden har bygget videre på for Python og .NET som administrerte kjøretider.
Container-images har vært en del av Lambda-plattformen siden 2020, og har blitt stadig mer populært for arbeidslaster som krever store avhengigheter, egendefinerte binærfiler eller maskinlæringsmodeller som ikke passer naturlig inn i en tradisjonell ZIP-pakke. At det tok fra 2022 til september 2026 før snapshot-teknologien nådde containerformatet, illustrerer hvor mye mer kompleks oppgaven er når kjøremiljøet ikke lenger er begrenset til AWS sine egne, kontrollerte basisbilder. En container kan i prinsippet inneholde hva som helst, noe som gjør det vesentlig vanskeligere å garantere at et frosset øyeblikksbilde kan gjenopprettes trygt og forutsigbart på tvers av tusenvis av samtidige instanser.
Hvorfor kaldstart er et forretningsproblem, ikke bare en teknisk detalj
Kald oppstart handler i bunn og grunn om en avveining mellom to økonomiske hensyn. Skalering til null gir lave eller ingen kostnader for inaktiv kapasitet, mens forhåndsvarmet kapasitet koster penger uansett om den brukes eller ikke. Den avveiningen rammer hardest for arbeidslaster der ventetiden faktisk merkes av en menneskelig bruker: interaktive API-er, betalingsløp, innlogging, sanntids-personalisering, maskinlæringsinferens og interne tjenester med strenge ventetidskrav.
Et enkelt kaldt kall kan dra opp haleventetiden selv når gjennomsnittet ser helt greit ut i et dashbord. Det påvirker konverteringsrate i netthandel, evnen til å overholde interne ventetidsmål, opplevd kvalitet for sluttbrukeren og hvor mye overflødig, oppvarmet kapasitet et selskap må kjøpe for å unngå problemet i utgangspunktet. For nordiske selskaper som allerede balanserer strømkostnader og skyregning nøye, er det et konkret argument: mindre behov for permanent oppvarmet kapasitet betyr lavere driftskostnad uten at brukeropplevelsen svekkes.
Markedet for serverless vokser mens kaldstart forblir flaskehalsen
Ifølge et bransjeanslag fra analyseselskapet Kanerika ligger det globale markedet for serverless-databehandling på rundt 32,6 milliarder dollar i 2026. Det er verdt å understreke at tallet kommer fra en enkelt industrianalyse og ikke fra en av de store, etablerte analytikerhusene, så det bør leses som ett anslag blant flere, ikke som en fastsatt konsensus for hele bransjen. Uansett nøyaktig tall peker retningen samme vei: stadig flere arbeidslaster som tidligere krevde permanent kjørende servere, flyttes over til funksjoner som betales per kall.
Det AWS selv sier mellom linjene i kunngjøringen, er kanskje det mest interessante markedssignalet. Ved å prioritere nettopp maskinlæringsinferens og interaktive API-er som de fremste bruksområdene for container-SnapStart, bekrefter selskapet at serverless-adopsjon i økende grad omfatter arbeidslaster som tidligere favoriserte containere eller lengre levende tjenester nettopp fordi de hadde for tung oppstart til å fungere godt som funksjoner. Det er en indirekte innrømmelse av at kald oppstart har vært en reell brems på hvor langt serverless-modellen har kunnet strekke seg inn i tyngre, mer krevende arbeidslaster.
Hva bransjen og AWS selv sier om endringen
AWS sin egen dokumentasjon og produktblogger er foreløpig den klareste kilden til hvordan selskapet selv rammer endringen. I den offisielle kunngjøringen skriver AWS ordrett: “Starting today, AWS Lambda supports SnapStart for functions packaged as container images, reducing startup times from several seconds to as low as sub-second.” (Amazon Web Services, offisiell kunngjøring).
I den tekniske dokumentasjonen understreker AWS at det normalt ikke kreves kodeendringer for å ta i bruk funksjonen: “Lambda SnapStart can provide as low as sub-second startup performance, typically with no changes to your function code.” (Amazon Web Services, AWS-dokumentasjon). Det samme poenget går igjen på tvers av flere av AWS sine kanaler. På AWS Compute Blog skriver selskapet at “AWS Lambda SnapStart can deliver as low as sub-second startup performance for Java, .NET, and Python functions with long initialization times.” (Amazon Web Services, AWS Compute Blog), mens .NET-teamet formulerte den historiske utvidelsen slik: “AWS recently added AWS Lambda SnapStart support for .NET Lambda functions to deliver faster function startup performance, from several seconds to as low as sub-second, typically with minimal or no code changes.” (Amazon Web Services, AWS .NET Blog).
Selskapets serverless-team har tidligere oppsummert den underliggende gevinsten slik: “SnapStart delivers up to 10x faster function startup performance at no extra cost by creating and caching a snapshot of the initialized execution environment.” (Amazon Web Services, AWS Serverless Blog). Alle disse uttalelsene kommer fra AWS selv, ikke fra uavhengige analytikere. Det er verdt å ha i bakhodet når man vurderer hvor mye av “opptil ti ganger”-tallet som gjelder ens egen, konkrete arbeidslast.
Konkurransebildet: containere mot funksjoner i skyen
Konkurransen om raskest oppstart har egentlig pågått i flere år, bare under andre navn. Google har svart med minimumsinstanser for Cloud Run og Cloud Functions, som effektivt fjerner kald oppstart mot at kunden betaler for konstant oppvarmet kapasitet. Microsoft har løst det samme problemet gjennom hosting-planene sine, der Premium og Flex Consumption tilbyr forhåndsvarmede eller alltid-klare instanser mot en tilsvarende kostnadspremie. Ingen av løsningene er gratis i praksis. Forskjellen ligger i hvor kostnaden legges: AWS sin SnapStart-modell lar deg beholde skalering-til-null for selve kjøretiden, men legger på en separat, mindre kostnad for cache og gjenoppretting. Google og Microsoft sine løsninger krever i stedet at du betaler for permanent oppvarmet kapasitet, uavhengig av faktisk trafikk.
For team som allerede har lagt arkitekturen sin på containere, gir SnapStart-utvidelsen en tredje vei som ikke fantes tidligere: behold containerens fleksibilitet, men få tilgang til samme snapshot-mekanikk som Java-brukere har hatt siden 2022. Det gjør AWS sitt tilbud mer direkte sammenlignbart med Google Cloud Run sine minimumsinstanser, samtidig som prismodellen forblir nærmere den opprinnelige, forbruksbaserte Lambda-logikken enn Cloud Run sin abonnementslignende varmholding.
Hva betyr dette for norske og nordiske utviklerteam
Nordiske selskaper som bygger på AWS i regioner som Stockholm, Frankfurt eller Irland, får tilgang til funksjonen fra første dag siden ingen av de europeiske regionene er blant unntakene. Det praktiske spørsmålet for norske utviklerteam blir dermed ikke om funksjonen er tilgjengelig, men om den passer arbeidslasten deres. Team som kjører container-pakkede funksjoner med tunge avhengigheter, maskinlæringsmodeller eller egendefinerte kjøretider, og som samtidig har merket kald-oppstart-problemer i produksjon, har nå et konkret alternativ til å bygge om alt til permanent kjørende tjenester.
Samtidig bør team være nøkterne på kostnadssiden. Minimumsperioden på tre timer for cache-fakturering betyr at funksjoner med svært lavt og sporadisk trafikkvolum kan ende opp med å betale for cache de sjelden får glede av. For høytrafikk-funksjoner der kald oppstart faktisk rammer mange brukere, vil derimot den relativt lille cache- og gjenopprettingskostnaden trolig veies opp av bedre svartid og lavere behov for overprovisjonert, permanent varm kapasitet. Det anbefales å teste funksjonen på en avgrenset arbeidslast før den rulles ut bredt, og å måle faktisk gjenopprettingstid for egen container fremfor å stole blindt på AWS sitt “under ett sekund”-anslag.
Fem spådommer for SnapStart og serverless kaldstart fremover
- Google og Microsoft svarer trolig med egne snapshot-baserte mekanismer for containerbaserte funksjoner i løpet av de neste 12 til 18 månedene, i stedet for å bare stole på minimumsinstanser og alltid-klare kapasitet.
- Flere maskinlæringsteam flytter inferens-arbeidslaster fra permanent kjørende GPU-instanser til container-pakkede Lambda-funksjoner med SnapStart, ettersom kald-oppstart-argumentet mot serverless-inferens svekkes.
- AWS utvider trolig SnapStart-støtten til flere .NET- og Python-versjoner samt eventuelt nye kjøretider i løpet av det kommende året, i tråd med det historiske mønsteret fra Java-utvidelsen.
- Kostnadsdiskusjonen rundt minimumsperioden på tre timer får trolig mer oppmerksomhet etter hvert som flere lavtrafikk-team oppdager cache-kostnaden i fakturaen sin, noe som kan presse AWS til å justere modellen.
- Konkurransen om raskeste oppstartstid blir et fastere element i sky-leverandørenes markedsføring overfor AI-team, ettersom inferens-ventetid i økende grad regnes som en konkurransefaktor på linje med selve modellkvaliteten.
Ofte stilte spørsmål om AWS Lambda SnapStart for containere
Hva er AWS Lambda SnapStart?
SnapStart er en valgfri Lambda-funksjon som tar et øyeblikksbilde av en ferdig initialisert funksjonsinstans og gjenoppretter det øyeblikksbildet ved skalering, i stedet for å starte funksjonen helt fra bunnen hver gang.
Koster SnapStart ekstra for container-images?
Ja, for de fleste kjøretider betaler du for mellomlagring av øyeblikksbildet og for hver gjenoppretting, med en minimumsperiode på tre timer for cachen. Støttede Java-kjøretider er unntatt fra denne ekstrakostnaden.
Hvilke kjøretider støtter SnapStart nå?
Java 11 og nyere, Python 3.12 og nyere, en tilsvarende familie av .NET-kjøretider, samt de tilsvarende basisbildene for containerbasert distribusjon.
Er funksjonen tilgjengelig i europeiske AWS-regioner?
Ja. SnapStart for container-images er tilgjengelig i alle kommersielle regioner unntatt Asia-Stillehavet (New Zealand) og Asia-Stillehavet (Taipei), noe som gir full dekning for de vanlige europeiske og nordiske regionene.
Hvordan skiller SnapStart seg fra Provisioned Concurrency?
Provisioned Concurrency holder et fast antall ferdig initialiserte instanser kjørende hele tiden, mot en løpende kostnad. SnapStart gjenoppretter i stedet et lagret øyeblikksbilde på forespørsel, og beholder dermed mye av skalering-til-null-fordelen samtidig som oppstartstiden kuttes.
Må jeg endre koden min for å bruke SnapStart?
I de fleste tilfeller ikke. For egendefinerte container-images må du derimot legge til en egen etikett i Dockerfile-filen, eller implementere livssyklus-hooks dersom funksjonen holder på tilstand som ikke bør gjenbrukes rått mellom gjenopprettinger.
Hvordan sammenlignes SnapStart med Google Cloud Run sin kald-oppstart-løsning?
Cloud Run løser i hovedsak problemet med minimumsinstanser som holdes varme mot en løpende kostnad, mens SnapStart gjenoppretter et lagret øyeblikksbilde og beholder mer av den forbruksbaserte prismodellen. De to tilnærmingene er arkitektonisk ulike, så direkte millisekund-sammenligning bør tolkes med forsiktighet.
Bør alle Lambda-funksjoner bruke SnapStart?
Nei. Funksjoner med høyt trafikkvolum og merkbare kald-oppstart-problemer har mest å hente. Funksjoner med svært lavt og sporadisk trafikkvolum kan ende opp med å betale mer i cache-kostnad enn de sparer i ventetid, gitt minimumsperioden på tre timer.
