Une entreprise migre sa plateforme IoT sur site vers AWS. La plateforme se compose des éléments suivants : un cluster MongoDB stockant les données IoT collectées et traitées ; une application qui utilise MQTT pour interroger les appareils toutes les 5 minutes ; des tâches périodiques qui génèrent des rapports (les tâches s'exécutent pendant 120 à 600 secondes) ; et une application web publique qui diffuse les rapports. L'entreprise souhaite réduire la charge opérationnelle tout en maintenant les performances. Quelle combinaison d'étapes fournit la solution requise avec la charge opérationnelle la PLUS FAIBLE ? (Choisissez trois.)

La migration du cluster MongoDB vers Amazon DocumentDB réduit la charge opérationnelle car DocumentDB est un service de base de données entièrement géré et compatible avec MongoDB, éliminant la nécessité de gérer l'infrastructure sous-jacente. Connecter les appareils à AWS IoT Core et utiliser une règle IoT pour déclencher une fonction Lambda permet une ingestion de données IoT évolutive et sans serveur, réduisant considérablement la charge opérationnelle par rapport à une application auto-gérée interrogeant les appareils. Utiliser AWS Step Functions avec des fonctions Lambda pour la génération de rapports et stocker ces rapports dans Amazon S3, puis les diffuser via CloudFront, fournit une solution sans serveur et hautement évolutive pour les rapports et la diffusion de contenu, minimisant la gestion de l'infrastructure. Les options incorrectes incluent le déploiement d'un cluster Amazon EKS, qui ajoute une charge opérationnelle significative pour la gestion de Kubernetes. L'utilisation d'une fonction Lambda pour se connecter directement aux appareils IoT n'est pas la meilleure pratique pour l'ingestion de données à grande échelle et en temps réel, car IoT Core est conçu pour cela. La migration de MongoDB vers des instances EC2 ne réduit pas la charge opérationnelle car l'entreprise devrait toujours gérer le cluster MongoDB.