Un'applicazione distribuita tramite CloudFormation utilizza API REST di API Gateway integrate con Lambda e DynamoDB. Esistono ambienti di sviluppo, test e produzione, ognuno con la propria tabella DynamoDB. Le modifiche promosse in produzione hanno causato problemi imprevisti, anche se funzionavano in sviluppo e test. Per la prossima release, lo sviluppatore deve instradare il 20% del traffico di produzione al nuovo deployment dell'API e l'80% al deployment di produzione esistente, minimizzando la possibilità che un singolo cliente riscontri errori. Qual è l'approccio migliore?

L'opzione corretta è configurare le impostazioni di canary deployment per lo stage API di produzione. API Gateway supporta i canary deployment, che consentono di instradare una percentuale specifica del traffico a una nuova versione dell'API, mantenendo il resto del traffico sulla versione stabile. Questo approccio è ideale per minimizzare i rischi, poiché il 20% del traffico viene gradualmente esposto alle modifiche, permettendo di monitorare le prestazioni e rollbackare rapidamente in caso di problemi. Le altre opzioni sono meno efficaci o inappropriate: Distribuire il 20% delle modifiche cinque volte è un processo manuale e inefficiente, non un vero canary deployment. Modificare il record DNS di Route 53 per puntare all'ambiente di test non è una pratica consigliata per il traffico di produzione, poiché l'ambiente di test potrebbe non avere la scalabilità o la resilienza necessarie. Posizionare un Application Load Balancer (ALB) davanti all'API REST è eccessivamente complesso e non è il meccanismo nativo per i canary deployment in API Gateway. API Gateway gestisce già la distribuzione del traffico tra le versioni degli stage.