Un environnement hybride comporte des instances EC2 dans un VPC qui envoient des journaux d'application à CloudWatch et lisent des données à partir de bases de données relationnelles sur site. L'entreprise a besoin d'une visibilité quasi en temps réel sur les instances EC2 connectées aux bases de données et utilise déjà Splunk sur site pour la surveillance. Comment un architecte de solutions doit-il acheminer le trafic de journaux réseau nécessaire vers Splunk pour répondre à ces exigences ?

L'option correcte permet une visibilité quasi en temps réel en acheminant les VPC Flow Logs vers CloudWatch Logs, puis en utilisant un abonnement CloudWatch Logs pour envoyer ces événements à Kinesis Data Firehose. Firehose peut ensuite livrer directement à Splunk. La fonction Lambda de pré-traitement est essentielle pour formater correctement les journaux pour Splunk, car les abonnements CloudWatch Logs envoient les données dans un format compressé et encodé en base64. Les autres options sont moins efficaces ou ne répondent pas aux exigences : Exporter vers S3 puis demander à Splunk de récupérer les journaux introduit une latence plus élevée et une complexité de gestion des informations d'identification. Enregistrer chaque requête de base de données, exporter vers S3, utiliser Athena, puis Lambda est un processus trop complexe et lent pour une visibilité quasi en temps réel. Utiliser Kinesis Data Analytics pour la détection d'anomalies est une solution d'analyse, pas une méthode directe pour acheminer les journaux réseau bruts vers Splunk pour une visibilité générale.