Uma aplicação em uma VPC usa um NAT gateway para acesso de saída à internet. Um engenheiro de rede observa um alto volume de tráfego de saída suspeito da VPC para endereços IP em uma lista de negação. O engenheiro precisa determinar quais recursos da AWS estão produzindo esse tráfego, mantendo os custos e o esforço administrativo baixos. Qual abordagem satisfaz esses requisitos?

A opção correta é habilitar o VPC Flow Logs e publicá-los no CloudWatch Logs, usando o CloudWatch Logs Insights para consultas. O VPC Flow Logs captura informações sobre o tráfego IP que entra e sai das interfaces de rede em sua VPC, incluindo endereços IP de origem/destino e portas, o que é essencial para identificar a origem do tráfego suspeito. Publicar no CloudWatch Logs permite armazenamento centralizado e o CloudWatch Logs Insights oferece uma linguagem de consulta poderosa e econômica para analisar esses logs e pinpointar os recursos específicos da AWS (via ENI ID) que geram o tráfego, sem a necessidade de infraestrutura adicional. As opções incorretas são: Traffic Mirroring é complexo de configurar, gera custos adicionais de EC2 e requer ferramentas de análise externas, aumentando o esforço administrativo e o custo. Implantar um SIEM na VPC para ingerir Flow Logs é uma solução robusta, mas é significativamente mais cara e complexa em termos de implantação e manutenção do que usar as ferramentas nativas da AWS, não atendendo ao requisito de baixo custo e esforço. Transmitir para Kinesis, Firehose, S3 e Athena é uma solução escalável para análise de dados em larga escala, mas é excessivamente complexa e cara para o objetivo específico de identificar a origem do tráfego suspeito, introduzindo latência e custos desnecessários em comparação com o CloudWatch Logs Insights.