Een bedrijf bouwt een latency-gevoelige applicatie. Verschillende Java AWS Lambda-functies voeren het laden van bibliotheken, klasse-initialisatie en het genereren van unieke ID's uit in initialisatiecode buiten de handler. De functies moeten zo snel mogelijk initialiseren. Welke aanpak is het meest kosteneffectief om te voldoen aan de opstartprestatievereisten?

De correcte optie pakt zowel de cold start-prestaties als de kosteneffectiviteit aan. Lambda SnapStart vermindert cold starts aanzienlijk door een vooraf geïnitialiseerde snapshot van de runtime-omgeving te hergebruiken. Het verplaatsen van het genereren van unieke ID's naar de handler is cruciaal omdat unieke ID's na het snapshot moeten worden gegenereerd om duplicatie te voorkomen bij het hergebruiken van een snapshot. Een pre-snapshot hook kan worden gebruikt om de omgeving voor te bereiden voordat het snapshot wordt gemaakt. Het publiceren van een versie is een vereiste voor SnapStart. De eerste optie is onjuist omdat het verplaatsen van alle initialisatiecode naar de handler de cold start-tijd zou verhogen, wat indruist tegen de vereisten. De tweede optie is onjuist omdat provisioned concurrency kostbaarder is dan SnapStart en alleen de cold start-tijd vermindert, niet de initiële initialisatietijd van de functie. De derde optie is onjuist omdat het configureren van provisioned concurrency en SnapStart voor gepubliceerde versies onnodig is en SnapStart effectiever is voor het aanpakken van de initialisatietijd, terwijl provisioned concurrency extra kosten met zich meebrengt.