# Ingestão Gerenciada de Syslog no CloudWatch: Anatomia de um Padrão

O CloudWatch Logs agora aceita syslog diretamente via endpoint de VPC — sem agentes, com parsing automático de RFC 5424, RFC 3164 e Cisco FTD/ASA. Isso muda o padrão de coleta de logs para dispositivos de rede e servidores Linux em ambientes regulados. Neste artigo, desmonto a anatomia do padrão, seus limites reais e os anti-padrões que já vi queimar equipes em produção.

- URL: https://fernando.moretes.com/blog/ingestao-gerenciada-de-syslog-no-cloudwatch-anatomia-de-um-padrao-amazon-cloud

- Markdown: https://fernando.moretes.com/blog/ingestao-gerenciada-de-syslog-no-cloudwatch-anatomia-de-um-padrao-amazon-cloud/article.md?lang=pt

- Published: 2026-06-24T09:03:32.890Z

- Category: IA & Agentes

- Tags: cloudwatch, syslog, observability, network-security, financial-grade, log-ingestion, vpc-endpoint, compliance

- Reading time: 9 min

- Source: [Amazon CloudWatch Logs supports managed syslog ingestion](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cloudwatch-syslog-ingestion/)

---

Por dezesseis anos eu vi equipes montarem pipelines frágeis de coleta de syslog: um rsyslog rodando em EC2, um Fluentd costurado com fita adesiva, um Lambda que falha silenciosamente quando o volume de logs de firewall triplica durante um incidente de segurança. Em 23 de junho de 2026, a AWS removeu boa parte dessa fricção com a ingestão gerenciada de syslog no CloudWatch Logs. Mas 'gerenciado' não significa 'adequado para qualquer caso'. Este artigo desmonta o padrão — o problema que ele resolve, sua anatomia técnica, quando ele é a escolha certa e quando ele vai te machucar.

## O Problema Real: Dispositivos de Rede São Cidadãos de Segunda Classe na Observabilidade Moderna

Toda conversa sobre observabilidade moderna gira em torno de aplicações instrumentadas com OpenTelemetry, traces distribuídos e métricas de RED. O que raramente aparece nessa conversa são os dispositivos que carregam o tráfego dessas aplicações: firewalls Cisco ASA/FTD, switches de borda, roteadores BGP, appliances de VPN. Esses dispositivos não rodam agentes. Eles falam syslog — RFC 3164 desde 2001, RFC 5424 desde 2009 — e é isso.

Em ambientes financeiros regulados, esses logs não são opcionais. PCI-DSS 4.0 exige retenção e monitoramento de logs de dispositivos de rede no escopo do cardholder data environment. BACEN 4.658 e a Resolução 85/2021 da SUSEP exigem rastreabilidade de eventos de segurança em infraestrutura crítica. O que eu via repetidamente era o seguinte padrão: um servidor Linux dedicado rodando rsyslog ou syslog-ng como relay, exportando para S3 via script cron, com um Glue job tentando parsear campos semi-estruturados que variam por fabricante. O custo operacional era alto, a latência para alertas era de minutos, e a superfície de falha era enorme — o relay em si se tornava um ponto único de falha não monitorado.

A proposta do CloudWatch Logs managed syslog é colapsar esse pipeline em um único endpoint gerenciado: você aponta o dispositivo para um VPC endpoint na sua conta, e o serviço faz o parsing, estrutura os campos e entrega em um log group. Simples na superfície. A complexidade está nos detalhes de como isso se encaixa — ou não — em uma arquitetura de segurança e compliance real.

## Anatomia do Padrão: Ingestão Gerenciada de Syslog no CloudWatch

Fluxo completo desde dispositivos de rede até alertas e arquivamento de conformidade, mostrando o papel do VPC endpoint, parsing automático e roteamento downstream.

### 🏭 On-Prem / Edge Sources

- Cisco FTD/ASA Firewall (security)
- Router / Switch RFC 3164 / 5424 (network)
- Linux Server syslog-ng / rsyslog (compute)

### 🔒 AWS Network Boundary

- VPC Endpoint TCP / TCP+TLS / UDP (network)
- Security Group Port 514 / 6514 (security)

### 📋 CloudWatch Logs — Managed Syslog

- CloudWatch Logs Managed Syslog Receiver (data)
- Auto-Parser facility · severity hostname · appName (data)
- Log Group /syslog/network-devices (storage)

### 🔍 Operational & Compliance Routing

- Logs Analytics Query by severity / hostname (data)
- Metric Filter ERROR / CRITICAL count alarm (data)
- CloudWatch Alarm → SNS → PagerDuty (messaging)
- S3 Archive KMS-encrypted 7-year retention (storage)
- SIEM / Security Lake (subscription filter) (security)

### Fluxos

- fw -> vpce: TCP+TLS :6514
- sw -> vpce: UDP :514
- lx -> vpce: TCP :514
- vpce -> sg: ingress filter
- sg -> cwl: autorizado
- cwl -> parse: RFC 5424/3164/FTD
- parse -> lg: campos estruturados
- lg -> la: query interativa
- lg -> mf: filtro de padrão
- mf -> alarm: threshold breach
- lg -> s3arc: export task / S3 sink
- lg -> siem: subscription filter

## Anatomia Técnica: O Que o Serviço Realmente Faz (e Como Configurar Corretamente)

O endpoint de ingestão é exposto como um **Interface VPC Endpoint** na sua VPC — o que significa que o tráfego nunca sai da rede AWS. Você configura o dispositivo de origem para enviar para o DNS privado do endpoint. O serviço aceita três transportes: **UDP na porta 514** (sem garantia de entrega, adequado para dispositivos legados que não suportam TCP), **TCP na porta 514** (com garantia de ordem de entrega por sessão) e **TCP+TLS na porta 6514** (o único modo aceitável para ambientes regulados — use TLS 1.2 mínimo, preferencialmente 1.3).

O parsing automático extrai os campos definidos pelos RFCs: `facility` (0-23, mapeado para nomes como `kern`, `auth`, `local7`), `severity` (0-7, de `emerg` a `debug`), `hostname`, `appName`, `procId` e `msgId` para RFC 5424. Para RFC 3164, o parser infere hostname e tag do cabeçalho. Para Cisco FTD/ASA, o parser reconhece o formato proprietário `%ASA-severity-mnemonic` e extrai o mnemônico como campo indexado — isso é significativo porque permite metric filters diretos em eventos como `%ASA-4-106023` (ACL deny) sem regex customizado.

O destino é um **CloudWatch Logs log group** que você pré-cria e associa ao endpoint. A retenção é configurada no log group — defina explicitamente; o padrão é `Never Expire`, o que em ambientes financeiros vai gerar custo de armazenamento não planejado rapidamente. Para compliance PCI/BACEN, configure retenção de 365 dias no CloudWatch e exporte para S3 com Glacier para os 6 anos restantes via S3 Lifecycle policy. O IAM do endpoint precisa de `logs:PutLogEvents` e `logs:CreateLogStream` na resource do log group — use uma **resource-based policy** com condição `aws:SourceVpc` para garantir que apenas tráfego da VPC correta possa escrever.

Um detalhe crítico de capacidade: CloudWatch Logs tem um limite padrão de **5 MB/s por log group** para PutLogEvents. Em um ambiente com dezenas de firewalls em alta carga (um evento de DDoS pode gerar 50k eventos/segundo em um ASA), você precisa distribuir em múltiplos log groups e solicitar aumento de limite antecipadamente via Service Quotas.

## Quando Este Padrão é a Escolha Certa

Este padrão resolve um problema específico muito bem: **dispositivos que só falam syslog e que precisam ter seus logs centralizados em um ambiente AWS sem infraestrutura intermediária**. Os casos de uso onde eu aplicaria isso sem hesitação são:

**1. Firewalls e dispositivos de borda em ambientes de landing zone AWS.** Se você tem um Cisco FTD ou um Palo Alto enviando syslog para um relay EC2 hoje, substituir esse relay pelo endpoint gerenciado elimina um ponto de falha, reduz custo de instância e remove a responsabilidade de patch do relay. O parsing nativo de FTD/ASA é o diferencial real aqui.

**2. Servidores Linux em subnets privadas sem acesso à internet.** O CloudWatch Agent é a solução padrão para Linux, mas em ambientes com restrições de conectividade extremas (air-gapped parcial, sem NAT gateway por política de custo), o endpoint de VPC para syslog é mais simples de configurar e não requer gerenciamento de versão de agente.

**3. Ambientes de migração lift-and-shift com prazo curto.** Quando você está movendo 200 servidores para AWS em 90 dias e não tem tempo para instrumentar tudo com CloudWatch Agent, configurar syslog forwarding é uma linha de configuração no rsyslog/syslog-ng existente. Você ganha visibilidade imediata sem bloquear a migração.

**4. Compliance de curto prazo para auditoria.** Para evidenciar para um auditor PCI ou BACEN que logs de dispositivos de rede estão sendo coletados e retidos de forma centralizada, este padrão entrega o requisito com configuração mínima e trilha de auditoria via CloudTrail (o endpoint em si gera eventos de API).

O ponto de inflexão é o volume e a necessidade de enriquecimento. Abaixo de ~10 MB/s de syslog agregado e sem necessidade de correlação com outros eventos em tempo real, o padrão é excelente. Acima disso, ou quando você precisa de correlação com traces de aplicação, a conversa muda.

## Padrões de Coleta de Syslog: Comparação Técnica
| Critério | Critério | Relay EC2 (rsyslog/syslog-ng) | CW Managed Syslog (novo) | MSK + Kafka Connect |
| --- | --- | --- | --- | --- |
| Gerenciamento de agente | Alto (patch, HA, monitoramento) | Zero | Médio (connector config) | — |
| Latência de ingestão | ~1-5s (buffer flush) | ~2-10s (managed buffer) | <1s (streaming) | — |
| Parsing nativo FTD/ASA | Manual (regex customizado) | Nativo (built-in) | Manual (SMT transforms) | — |
| Correlação com app traces | Possível via Logs Insights | Possível via Logs Insights | Excelente (stream unificado) | — |
| Custo base mensal (estimado) | ~$50-200 (EC2 t3.medium HA) | $0 infra + $0.50/GB ingestão CWL | ~$400+ (MSK mínimo) | — |
| Adequado para >50 MB/s | Sim (com cluster) | Requer múltiplos log groups + quota increase | Sim (escala horizontal) | — |

## Anti-Padrões: Onde Este Design Vai Te Machucar

- **UDP em ambiente regulado sem fallback:** UDP não tem garantia de entrega. Em um evento de segurança crítico — exatamente quando você mais precisa dos logs — um burst de tráfego pode causar perda silenciosa de mensagens. Para PCI-DSS e BACEN, use TCP+TLS obrigatoriamente. Se o dispositivo não suporta TCP, isso é um sinal de que o dispositivo precisa ser substituído, não de que UDP é aceitável.
- **Log group único para todos os dispositivos:** Colocar firewalls, switches e servidores Linux no mesmo log group parece conveniente mas cria três problemas: (1) o limite de 5 MB/s por log group vira gargalo em incidentes; (2) a política de retenção é única para todos — você pode precisar de 7 anos para logs de firewall e 90 dias para logs de aplicação; (3) as IAM resource policies ficam
- **Substituir o SIEM pelo CloudWatch Logs Analytics:** O Logs Analytics é excelente para queries ad-hoc e dashboards operacionais, mas não é um SIEM. Ele não tem correlação de eventos multi-fonte com regras temporais, não tem case management, não tem integração nativa com threat intelligence feeds.
- **Ignorar o custo de retenção com a política padrão 'Never Expire':** CloudWatch Logs cobra $0.03/GB/mês de armazenamento (us-east-1). Um ambiente com 10 firewalls gerando 1 GB/dia cada acumula 300 GB/mês, ~$9/mês de armazenamento — parece barato até você perceber que sem política de retenção isso cresce indefinidamente. Em 12 meses são 3.6 TB e ~$108/mês só de storage.
- **Endpoint de VPC sem Security Group restritivo:** O VPC endpoint aceita tráfego de qualquer origem dentro da VPC por padrão. Em um ambiente com múltiplas workloads, isso significa que qualquer instância comprometida pode injetar logs falsos no log group de firewall, contaminando a trilha de auditoria.

## Segurança e Compliance: O Que Não Está Documentado Mas Importa

O anúncio menciona TCP+TLS como opção de transporte, mas não detalha o modelo de chave de criptografia para dados em repouso. CloudWatch Logs suporta **Customer Managed Keys (CMK) via KMS** para criptografia de log groups — isso é obrigatório em ambientes financeiros regulados onde você precisa demonstrar controle exclusivo sobre as chaves de criptografia de dados de auditoria. Configure o log group com `kms-key-id` apontando para uma CMK com política de chave que restrinja uso a `logs.amazonaws.com` com condição `kms:EncryptionContext:aws:logs:arn` — isso garante que a chave só pode ser usada pelo serviço CloudWatch Logs para aquele log group específico.

Para imutabilidade de logs — requisito crítico para evidência forense e compliance — CloudWatch Logs não oferece nativamente write-once semantics no log group. A estratégia que uso é dupla: (1) **CloudTrail com S3 Object Lock** para logs de API, e (2) **exportação imediata para S3 com Object Lock em modo COMPLIANCE** para os logs de syslog. Configure uma subscription filter que dispara um Lambda para copiar cada batch de logs para um bucket S3 com Object Lock habilitado e retention period alinhado ao requisito regulatório. O custo adicional é baixo (Lambda + S3 Standard-IA), mas a garantia de imutabilidade é alta.

Um aspecto de segurança que frequentemente é negligenciado: **log injection**. Dispositivos de rede legítimos enviam syslog estruturado, mas em um ambiente comprometido, um atacante que ganhou acesso a um servidor Linux pode enviar mensagens syslog forjadas com hostname de um firewall, tentando criar falsos alibis ou encobrir trilhas. A defesa é dupla: restringir o Security Group do endpoint aos CIDRs estáticos dos dispositivos de rede (não de subnets inteiras), e implementar anomaly detection via CloudWatch Metric Filter que alerta quando um hostname envia volume anormalmente alto — indicador de exfiltração via log channel ou de injeção.

## Observabilidade Operacional do Próprio Pipeline de Ingestão

Um erro clássico que vejo em times de plataforma é instrumentar bem as aplicações e esquecer de monitorar o pipeline de observabilidade em si. Se o endpoint de ingestão de syslog parar de receber dados, você pode não perceber até que um auditor pergunte pelos logs de firewall dos últimos 3 dias.

A estratégia que recomendo é criar um **CloudWatch Metric Filter** no log group de syslog que conta o número de mensagens recebidas por hostname e por hora. Combine isso com um **CloudWatch Alarm** com threshold mínimo: se um firewall que normalmente envia 10k mensagens/hora envia zero por 15 minutos, isso é um alarme de nível crítico — pode ser falha no dispositivo, na conectividade de rede, ou no próprio endpoint. Configure o alarme com `TreatMissingData: breaching` para que a ausência de dados seja tratada como violação, não como estado OK.

Para o endpoint de VPC em si, monitore as métricas de VPC Flow Logs para o ENI do endpoint: bytes de entrada, pacotes rejeitados pelo Security Group, e conexões estabelecidas. Um spike em pacotes rejeitados pode indicar um dispositivo mal configurado tentando enviar na porta errada, ou um scan de porta no endpoint. Configure um dashboard do CloudWatch com esses sinais lado a lado com o volume de logs recebidos — a correlação visual entre tráfego de rede e volume de logs é o sinal mais rápido de problema.

Finalmente, para ambientes multi-conta (Landing Zone com múltiplas contas de workload), considere centralizar os log groups de syslog em uma **conta de log archive dedicada** usando **CloudWatch cross-account observability**. Isso mantém os logs fora do blast radius de comprometimento de conta de workload e simplifica o acesso de auditores sem dar acesso às contas de produção.

> **Configuração de KMS para Log Groups de Syslog em Ambientes Regulados:** Ao criar o log group de destino, sempre especifique um CMK explicitamente: `aws logs create-log-group --log-group-name /syslog/network-devices --kms-key-id arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID`. A política da chave KMS deve incluir `kms:GenerateDataKey` e `kms:Decrypt` para o principal `logs.amazonaws.com` com condição `aws:SourceAccount` igual ao seu account ID — isso previne confused deputy attacks onde outro serviço na mesma região usa sua chave. Combine com uma SCP na OU que proíba `logs:DeleteLogGroup` e `logs:DeleteRetentionPolicy` para contas de log archive.

## Avaliação pelo AWS Well-Architected Framework

- **security**: Use TCP+TLS obrigatoriamente. Configure CMK no log group. Restrinja o Security Group do VPC endpoint aos CIDRs dos dispositivos de rede. Implemente resource-based policy com `aws:SourceVpc`. Para imutabilidade forense, exporte para S3 com Object Lock em modo COMPLIANCE. Monitore injeção de logs via anomaly detection em volume por hostname.
- **reliability**: Distribua dispositivos em múltiplos log groups para evitar o limite de 5 MB/s. Configure `TreatMissingData: breaching` em alarmes de volume para detectar interrupção silenciosa. Para dispositivos críticos, considere TCP (não UDP) para garantia de entrega. Solicite aumento de Service Quota antecipadamente para ambientes de alto volume.

> **Nota do Curador:** Na prática, eu adotaria este padrão imediatamente para firewalls e dispositivos Cisco em ambientes de landing zone AWS, mas com três condições inegociáveis: TCP+TLS obrigatório, CMK no log group, e um alarme `TreatMissingData: breaching` por hostname crítico. A lição mais dura que aprendi em ambientes financeiros é que o pipeline de observabilidade é tão crítico quanto a aplicação que ele monitora — e ele raramente tem o mesmo rigor de design. O fato de o CloudWatch Logs agora parsear FTD/ASA nativamente elimina uma categoria inteira de bugs de regex que eu já vi causar gaps de auditoria em revisões PCI. O que eu não faria é usar este padrão como substituto do SIEM ou como solução para volumes acima de 50 MB/s sem um plano explícito de particionamento de log groups e aumento de quota.

## Veredicto: Adote com Condições Claras

A ingestão gerenciada de syslog no CloudWatch Logs é uma adição genuinamente útil para times que operam dispositivos de rede em ambientes AWS. Ela elimina o relay intermediário, entrega parsing nativo de formatos Cisco, e se integra diretamente ao ecossistema de alertas e queries do CloudWatch. Para ambientes financeiros regulados, é uma solução viável desde que você configure TCP+TLS, CMK, Security Groups restritivos, retenção explícita, e um pipeline de exportação para S3 com Object Lock para imutabilidade forense. Não é um substituto para SIEM, não escala trivialmente acima de dezenas de MB/s sem planejamento de quotas, e não resolve o problema de correlação em tempo real com traces de aplicação. Use-o como camada de normalização e centralização, não como plataforma de análise de segurança completa. O ROI é claro para equipes que hoje mantêm relays EC2 para syslog — a troca é direta e o ganho operacional é imediato.

## Referências

- [Amazon CloudWatch Logs supports managed syslog ingestion — AWS What's New](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cloudwatch-syslog-ingestion/)
- [Amazon CloudWatch Logs Syslog Documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Syslog.html)
- [Implementing Logging and Monitoring with Amazon CloudWatch — AWS Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/system-level-cloudwatch-configuration.html)
- [Amazon CloudWatch FAQs — Ingestion Options](https://aws.amazon.com/cloudwatch/faqs/)
- [CloudWatch Logs Third-Party Ingestion](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/enable-logging-third-party.html)
- [Amazon CloudWatch launches OTel Container Insights for Amazon EKS](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cloudwatch-otel-amazon-eks/)
- [RFC 5424 — The Syslog Protocol (IETF)](https://datatracker.ietf.org/doc/html/rfc5424)
- [AWS Well-Architected Framework — Security Pillar](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)