Une application existante utilise plusieurs composants .NET Framework qui partagent une base de données Microsoft SQL Server et communiquent de manière asynchrone à l'aide de Microsoft Message Queueing (MSMQ). L'entreprise migre vers des composants .NET Core conteneurisés et souhaite refactoriser l'application pour qu'elle s'exécute sur AWS. Les conteneurs .NET Core nécessitent une orchestration complexe, un contrôle total sur la mise en réseau et la configuration de l'hôte, et le modèle de base de données est fortement relationnel. Quelle architecture répond à ces exigences ?

L'option correcte répond à toutes les exigences. ECS avec le type de lancement EC2 offre un contrôle total au niveau de l'hôte, essentiel pour l'orchestration complexe et la configuration réseau spécifiées. Aurora MySQL Serverless v2 est une base de données relationnelle hautement évolutive et compatible avec les applications existantes. SQS est un service de file d'attente de messages entièrement géré, idéal pour remplacer MSMQ et gérer la communication asynchrone. Les autres options sont incorrectes car: App Runner ne permet pas un contrôle au niveau de l'hôte. EventBridge est un bus d'événements, pas une file d'attente de messages. Fargate ne permet pas un contrôle au niveau de l'hôte. DynamoDB est une base de données NoSQL, non adaptée à un modèle relationnel existant. SNS est un service de publication/abonnement, pas une file d'attente. Elastic Beanstalk est une plateforme PaaS qui limite le contrôle au niveau de l'hôte. Aurora PostgreSQL n'est pas la meilleure compatibilité directe pour SQL Server. MSK est plus complexe que nécessaire pour un simple remplacement de MSMQ.