Une plateforme de traitement des commandes sur site utilise un frontal web (VM), RabbitMQ pour la messagerie et un cluster Kubernetes pour le backend conteneurisé. L'entreprise souhaite migrer vers AWS sans modifications majeures de l'application et avec le moins de frais opérationnels possible. Quelle architecture répond à ces contraintes ?

L'option correcte minimise les modifications de l'application et les frais opérationnels. La création d'une AMI à partir de la VM existante et son exécution sur EC2 Auto Scaling avec un ALB permet de migrer le frontal web tel quel, sans réécriture. Le remplacement de RabbitMQ par Amazon MQ (qui prend en charge RabbitMQ) est un changement minimal avec une gestion déléguée. L'hébergement du backend sur Amazon EKS permet de migrer le cluster Kubernetes existant avec peu de modifications, tout en bénéficiant d'un service géré. L'option avec Lambda et API Gateway nécessiterait une réécriture significative du frontal web, ce qui va à l'encontre de l'exigence de "pas de modifications majeures". L'option d'installer Kubernetes sur des instances EC2 augmenterait considérablement les frais opérationnels car le client devrait gérer le cluster Kubernetes lui-même, plutôt que d'utiliser un service géré comme EKS. L'option de remplacer RabbitMQ par Amazon SQS nécessiterait des modifications de l'application pour s'adapter à une API de messagerie différente, ce qui n'est pas idéal.