Une entreprise ingère un flux continu de données de marché à un rythme constant et les stocke. Un travail d'agrégation nocturne s'exécute pendant environ 4 heures pour calculer des statistiques ; l'analyse n'est pas critique et peut être relancée lors de la prochaine exécution en cas d'échec. Le système actuel utilise un pool d'instances réservées (Reserved Instances) d'un an fonctionnant en permanence pour ingérer et stocker des données sur des volumes EBS attachés. Un script planifié lance des instances EC2 à la demande (On-Demand) chaque nuit pour exécuter l'agrégation, qui accèdent aux données via NFS depuis les serveurs d'ingestion, et les termine une fois le travail terminé. Les réservations d'instances réservées arrivent à expiration. L'entreprise souhaite l'option la plus rentable. Quelle solution l'architecte devrait-il recommander ?

L'option correcte est la plus rentable car elle utilise Kinesis Data Firehose pour une ingestion de données évolutive et sans serveur vers S3, un stockage objet très économique. Pour le traitement nocturne, AWS Batch avec des instances Spot est idéal : les instances Spot sont significativement moins chères que les instances à la demande et conviennent aux charges de travail tolérantes aux pannes qui peuvent être interrompues et redémarrées, comme l'agrégation non critique mentionnée. Limiter le prix Spot maximum réduit encore les coûts. Les autres options sont moins optimales : La première option utilise des instances à la demande pour le traitement, ce qui est plus cher que les instances Spot. La troisième option maintient des instances réservées pour l'ingestion, ce qui est moins flexible et potentiellement plus cher que Firehose, et ne résout pas le problème de l'expiration des réservations. La quatrième option utilise Redshift, qui est plus coûteux que S3 pour le stockage brut et le traitement par Lambda pourrait être moins efficace et plus cher pour de grands volumes de données que AWS Batch.