Une application .NET héritée sur site (niveau web à charge équilibrée, niveau application à charge équilibrée et base de données Microsoft SQL Server) est en cours de migration vers AWS. L'entreprise préfère les services gérés et ne souhaite pas réécrire l'application. L'architecte de solutions doit éliminer les problèmes de mise à l'échelle tout en minimisant les coûts de licence à mesure que l'application évolue. Quelle est l'option la plus rentable qui répond à ces objectifs ?

L'option correcte est la plus rentable et répond aux exigences de services gérés et de minimisation des coûts de licence sans réécriture. Le déploiement d'instances EC2 dans des groupes Auto Scaling derrière un Application Load Balancer offre une mise à l'échelle automatique et une haute disponibilité pour les niveaux web et application. La migration de la base de données SQL Server vers Amazon Aurora PostgreSQL avec Babelfish est cruciale. Aurora PostgreSQL est un service géré, et Babelfish permet à Aurora de comprendre les requêtes et le protocole SQL Server, réduisant ainsi considérablement les coûts de licence SQL Server sans nécessiter de réécriture de l'application. Les autres options sont moins optimales : La création d'images avec AWS DMS et l'utilisation de DynamoDB ne conviennent pas car DynamoDB n'est pas une base de données relationnelle et nécessiterait une réécriture significative de l'application. La conteneurisation avec Amazon EKS est une bonne option technique mais n'aborde pas la réduction des coûts de licence SQL Server et peut être plus complexe à gérer pour une application existante sans réécriture. La refactorisation complète de l'application en fonctions AWS Lambda, API Gateway, S3 et Athena implique une réécriture majeure de l'application, ce qui est explicitement exclu par l'exigence.