Eine benutzerdefinierte Anwendung ermöglicht es Benutzern, Bilder hochzuladen. Uploads rufen eine Lambda-Funktion auf, die Bilder verarbeitet und in S3 speichert. Die Anwendung ruft die Lambda-Funktion über eine bestimmte Funktionsversions-ARN auf. Bildverarbeitungsparameter werden über Umgebungsvariablen bereitgestellt. Das Team ändert häufig Umgebungsvariablen, um die Verarbeitung anzupassen, veröffentlicht dann eine neue Funktionsversion und aktualisiert die Anwendung, um die neue Versions-ARN aufzurufen, was zu Benutzerunterbrechungen führt. Wie kann ein Lösungsarchitekt diesen Workflow mit dem GERINGSTEN Betriebsaufwand vereinfachen?

Die Erstellung eines Lambda-Funktionsalias ist die beste Lösung, da sie es ermöglicht, die zugrunde liegende Funktionsversion ohne Unterbrechung für die Client-Anwendung zu ändern. Die Anwendung ruft immer dieselbe Alias-ARN auf, während der Alias auf eine neue Funktionsversion umgeleitet werden kann, sobald Tests abgeschlossen sind. Dies minimiert den Betriebsaufwand und vermeidet Benutzerunterbrechungen. Das direkte Ändern von Umgebungsvariablen einer veröffentlichten Version ist nicht möglich. Das Speichern von Parametern in DynamoDB wäre eine gültige Option für dynamische Konfigurationen, erfordert aber mehr Implementierungsaufwand als ein Alias. Das Hardcodieren von Parametern würde bei jeder Änderung eine neue Veröffentlichung und Anwendungsaktualisierung erfordern, was genau das Problem ist, das gelöst werden soll.