Il sistema di ordini di un'azienda invia richieste dai client a istanze Amazon EC2 che elaborano gli ordini e li archiviano in Amazon RDS. Attualmente, gli utenti devono rielaborare gli ordini quando il sistema fallisce. L'azienda desidera una soluzione resiliente che elabori automaticamente gli ordini dopo un'interruzione. Cosa dovrebbe fare un architetto di soluzioni per soddisfare questi requisiti?

La soluzione corretta garantisce resilienza e rielaborazione automatica degli ordini. Spostare le istanze EC2 in un gruppo Auto Scaling assicura che le istanze vengano sostituite automaticamente in caso di guasto, mantenendo la capacità. L'introduzione di Amazon SQS disaccoppia il sistema di ordini dai processori EC2. Se le istanze EC2 falliscono, i messaggi rimangono nella coda SQS e possono essere elaborati da nuove istanze EC2 avviate dall'Auto Scaling Group una volta ripristinato il servizio, eliminando la necessità di rielaborazione manuale. Le altre opzioni non risolvono completamente il problema della resilienza e della rielaborazione automatica: Spostare le istanze EC2 in un gruppo Auto Scaling e usare EventBridge per indirizzare un'attività ECS non è direttamente applicabile poiché il sistema attuale usa istanze EC2 e RDS, non ECS. Spostare le istanze EC2 in un gruppo Auto Scaling dietro un ALB migliora la disponibilità ma non risolve il problema dei messaggi persi o non elaborati in caso di guasto delle istanze, poiché l'ALB non persiste i messaggi. Usare SNS, Lambda e Systems Manager Run Command è una soluzione più complessa e meno efficiente per la persistenza dei messaggi rispetto a SQS, e Run Command non è il meccanismo ideale per l'elaborazione continua di messaggi da una coda.