Une entreprise gère une plateforme de billetterie événementielle sur AWS et souhaite réduire ses coûts. La plateforme utilise Amazon EKS sur Amazon EC2 pour la plupart des charges de travail et une instance de base de données Amazon RDS for MySQL. Les nouvelles fonctionnalités s'exécuteront sur Amazon EKS avec AWS Fargate. La charge de travail présente des pics de demande peu fréquents, basés sur des dates. Quelle est l'approche la PLUS rentable pour cet environnement ?

L'option correcte est la plus rentable car les Compute Savings Plans offrent des réductions significatives pour une utilisation stable, couvrant la charge de base du cluster EKS. Les On-Demand Capacity Reservations sont idéales pour les pics de demande prévisibles et peu fréquents, garantissant la disponibilité sans surcoût permanent. Les Reserved Instances No Upfront pour RDS réduisent les coûts de la base de données sans investissement initial important. L'utilisation de réplicas en lecture pour gérer les pics de charge sur la base de données est une stratégie évolutive et rentable, évitant le surdimensionnement de l'instance principale. Les autres options sont moins optimales : Utiliser des Reserved Instances Standard pour EC2 et des Spot Instances pour les pics est moins flexible que les Savings Plans et les Capacity Reservations pour les pics planifiés. Acheter des Reserved Instances All Upfront pour la base de données dimensionnée pour la charge de pointe est coûteux et inefficace pour des pics peu fréquents. Mettre manuellement à l'échelle l'instance de base de données est moins efficace et peut entraîner des interruptions ou des surcoûts par rapport aux réplicas en lecture.