Une entreprise souhaite exécuter son application de paiement sur AWS. L'application reçoit des notifications de paiement d'appareils mobiles. Les notifications nécessitent une validation de base avant d'être envoyées pour un traitement ultérieur. Le traitement backend est de longue durée et nécessite une capacité de calcul et une mémoire ajustables. L'entreprise ne veut pas gérer l'infrastructure. Quelle solution répond à ces exigences avec le MOINS de frais opérationnels ?

Cette solution est la plus appropriée car elle utilise des services entièrement gérés qui minimisent les frais opérationnels et la gestion de l'infrastructure. Amazon API Gateway fournit un point d'entrée évolutif pour les notifications mobiles. AWS Lambda gère la validation des notifications sans serveur, éliminant la gestion des serveurs. Amazon ECS avec AWS Fargate exécute l'application backend dans des conteneurs sans nécessiter la gestion des instances EC2 sous-jacentes, offrant une capacité de calcul et une mémoire ajustables. Les autres options sont moins optimales : Utiliser Amazon EKS Anywhere ou un cluster EKS avec des nœuds autogérés (options 1 et 2) implique une gestion d'infrastructure Kubernetes, ce que l'entreprise souhaite éviter. L'intégration d'Amazon SQS avec EventBridge (options 1 et 3) est une approche valide pour la messagerie, mais EventBridge n'est pas le service principal pour la validation directe des notifications entrantes d'appareils mobiles comme l'est Lambda après API Gateway. L'utilisation d'instances Spot Amazon EC2 (option 3) peut réduire les coûts, mais introduit une complexité de gestion des interruptions et nécessite toujours la gestion des serveurs EC2, augmentant les frais opérationnels.