Een aangepaste applicatie laat gebruikers afbeeldingen uploaden. Uploads roepen een Lambda-functie aan die afbeeldingen verwerkt en opslaat in S3. De applicatie roept de Lambda-functie aan via een specifieke functieversie-ARN. Afbeeldingsverwerkingsparameters worden geleverd via omgevingsvariabelen. Het team wijzigt regelmatig omgevingsvariabelen om de verwerking af te stemmen, publiceert vervolgens een nieuwe functieversie en werkt de applicatie bij om de nieuwe versie-ARN aan te roepen, wat verstoringen voor gebruikers veroorzaakt. Hoe kan een solutions architect deze workflow vereenvoudigen met de MINSTE operationele overhead?

De correcte oplossing is het aanmaken van een Lambda-functiealias. Aliassen bieden een stabiele ARN die de applicatie kan aanroepen, onafhankelijk van de onderliggende functieversie. Wanneer nieuwe parameters of code worden geïmplementeerd, publiceert het team een nieuwe functieversie. Na succesvol testen kan de alias eenvoudig naar deze nieuwe versie worden verwezen, zonder de applicatiecode aan te passen. Dit minimaliseert operationele overhead en voorkomt verstoringen voor gebruikers. Het direct wijzigen van omgevingsvariabelen van een gepubliceerde versie is niet mogelijk; omgevingsvariabelen zijn gekoppeld aan de specifieke versie op het moment van publicatie. Het gebruik van $LATEST voor testen is prima, maar lost het probleem van applicatie-updates niet op. Een DynamoDB-tabel toevoegen introduceert extra complexiteit en operationele overhead voor het beheren van de tabel en het aanpassen van de Lambda-code om deze te lezen. Het hardcoden van parameters en het publiceren van nieuwe versies bij elke wijziging is inefficiënt en verhoogt de operationele overhead aanzienlijk.