Une charge de travail existante a sa couche d'application sans état sur une seule grande instance EC2 lancée à partir d'une AMI, et sa base de données MySQL sur une seule instance EC2. Le CPU sur le serveur d'applications atteint souvent 100 %, ce qui provoque des pannes. L'application des correctifs est effectuée manuellement et a entraîné des temps d'arrêt. L'entreprise doit rendre l'application hautement disponible avec le moins d'effort de développement possible. Quelle solution répond à cette exigence ?

La bonne réponse est de créer une nouvelle AMI avec l'agent SSM, d'utiliser un groupe Auto Scaling avec un ALB et de migrer la base de données vers Amazon Aurora MySQL. Cette approche résout les problèmes de haute disponibilité et de performance. L'agent SSM permet des mises à jour automatisées, réduisant les temps d'arrêt. Le groupe Auto Scaling avec ALB assure la scalabilité et la résilience de la couche applicative. Aurora MySQL est un service de base de données géré, hautement disponible et compatible avec MySQL, nécessitant un effort minimal de refactoring. Les autres options sont moins optimales. La refactorisation vers Lambda est un effort de développement important. Changer le type d'instance EC2 pour une instance Graviton plus petite sans résoudre les problèmes de mise à l'échelle n'est pas suffisant et DynamoDB n'est pas compatible avec MySQL. La conteneurisation est un effort de développement modéré et Neptune n'est pas une base de données relationnelle.