Un'applicazione personalizzata consente agli utenti di caricare immagini. I caricamenti richiamano una funzione Lambda che elabora e archivia le immagini in S3. L'applicazione chiama la funzione Lambda tramite uno specifico ARN della versione della funzione. I parametri di elaborazione delle immagini vengono forniti tramite variabili d'ambiente. Il team modifica frequentemente le variabili d'ambiente per ottimizzare l'elaborazione, quindi pubblica una nuova versione della funzione e aggiorna l'applicazione per chiamare il nuovo ARN della versione, causando interruzioni agli utenti. In che modo un architetto di soluzioni può semplificare questo flusso di lavoro con il MINOR overhead operativo?

La risposta corretta è creare un alias della funzione Lambda. Gli alias consentono di puntare a versioni specifiche di una funzione Lambda e di aggiornare l'alias per puntare a una nuova versione senza modificare il codice dell'applicazione client. Questo riduce l'overhead operativo poiché l'applicazione chiama sempre lo stesso ARN dell'alias, eliminando la necessità di aggiornamenti dell'applicazione ogni volta che viene rilasciata una nuova versione della funzione. Modificare direttamente le variabili d'ambiente di una versione pubblicata non è possibile, e usare $LATEST per la produzione è sconsigliato per la sua natura mutevole. Creare una tabella DynamoDB introduce un overhead operativo e di sviluppo aggiuntivo per la gestione dei parametri. Codificare i parametri e pubblicare nuove versioni per ogni modifica è inefficiente e causa interruzioni, come descritto nel problema.