Managed Syslog Ingestion in CloudWatch: Anatomy of a Pattern

For sixteen years I've watched teams build brittle syslog collection pipelines: an rsyslog running on EC2, a Fluentd stitched together with tape, a Lambda that fails silently when firewall log volume triples during a security incident. On June 23, 2026, AWS removed much of that friction with managed syslog ingestion in CloudWatch Logs. But 'managed' does not mean 'fit for every case'. This article tears down the pattern, the problem it solves, its technical anatomy, when it is the right choice, and when it will hurt you.

The Real Problem: Network Devices Are Second-Class Citizens in Modern Observability

Every modern observability conversation revolves around OpenTelemetry-instrumented applications, distributed traces, and RED metrics. What rarely appears in that conversation are the devices that carry the traffic for those applications: Cisco ASA/FTD firewalls, edge switches, BGP routers, VPN appliances. These devices do not run agents. They speak syslog: RFC 3164 since 2001, RFC 5424 since 2009, and that is it.

In regulated financial environments, these logs are not optional. PCI-DSS 4.0 requires retention and monitoring of network device logs within the cardholder data environment scope. BACEN 4.658 and SUSEP Resolution 85/2021 require traceability of security events in critical infrastructure. What I repeatedly saw was the following pattern: a dedicated Linux server running rsyslog or syslog-ng as a relay, exporting to S3 via cron script, with a Glue job attempting to parse semi-structured fields that vary by vendor. The operational cost was high, alert latency was in minutes, and the failure surface was enormous, the relay itself became an unmonitored single point of failure.

The CloudWatch Logs managed syslog proposal collapses that pipeline into a single managed endpoint: you point the device at a VPC endpoint in your account, and the service parses, structures the fields, and delivers to a log group. Simple on the surface. The complexity lies in the details of how this fits, or does not, into a real security and compliance architecture.

Pattern Anatomy: Managed Syslog Ingestion in CloudWatch

End-to-end flow from network devices to alerts and compliance archival, showing the role of the VPC endpoint, automatic parsing, and downstream routing.

🏭 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)

Flows

• fw -> vpce: TCP+TLS :6514
• sw -> vpce: UDP :514
• lx -> vpce: TCP :514
• vpce -> sg: ingress filter
• sg -> cwl: authorized
• cwl -> parse: RFC 5424/3164/FTD
• parse -> lg: structured fields
• lg -> la: interactive query
• lg -> mf: pattern filter
• mf -> alarm: threshold breach
• lg -> s3arc: export task / S3 sink
• lg -> siem: subscription filter

Technical Anatomy: What the Service Actually Does (and How to Configure It Correctly)

The ingestion endpoint is exposed as an Interface VPC Endpoint inside your VPC, meaning traffic never leaves the AWS network. You configure the source device to send to the endpoint's private DNS name. The service accepts three transports: UDP on port 514 (no delivery guarantee, suitable for legacy devices that don't support TCP), TCP on port 514 (with per-session delivery order guarantee), and TCP+TLS on port 6514 (the only acceptable mode for regulated environments, use TLS 1.2 minimum, preferably 1.3).

Automatic parsing extracts the fields defined by the RFCs: facility (0-23, mapped to names like kern, auth, local7), severity (0-7, from emerg to debug), hostname, appName, procId, and msgId for RFC 5424. For RFC 3164, the parser infers hostname and tag from the header. For Cisco FTD/ASA, the parser recognizes the proprietary %ASA-severity-mnemonic format and extracts the mnemonic as an indexed field, this is significant because it enables direct metric filters on events like %ASA-4-106023 (ACL deny) without custom regex.

The destination is a CloudWatch Logs log group that you pre-create and associate with the endpoint. Retention is configured on the log group, set it explicitly; the default is Never Expire, which in financial environments will generate unplanned storage costs rapidly. For PCI/BACEN compliance, configure 365-day retention in CloudWatch and export to S3 with Glacier for the remaining 6 years via S3 Lifecycle policy. The endpoint IAM needs logs:PutLogEvents and logs:CreateLogStream on the log group resource, use a resource-based policy with an aws:SourceVpc condition to ensure only traffic from the correct VPC can write.

A critical capacity detail: CloudWatch Logs has a default limit of 5 MB/s per log group for PutLogEvents. In an environment with dozens of firewalls under heavy load (a DDoS event can generate 50k events/second on an ASA), you need to distribute across multiple log groups and proactively request limit increases via Service Quotas.

When This Pattern Is the Right Choice

This pattern solves a specific problem very well: devices that only speak syslog and need their logs centralized in an AWS environment without intermediate infrastructure. The use cases where I would apply this without hesitation are:

1. Firewalls and edge devices in AWS landing zone environments. If you have a Cisco FTD or Palo Alto sending syslog to an EC2 relay today, replacing that relay with the managed endpoint eliminates a failure point, reduces instance cost, and removes relay patch responsibility. Native FTD/ASA parsing is the real differentiator here.

2. Linux servers in private subnets without internet access. CloudWatch Agent is the standard solution for Linux, but in environments with extreme connectivity restrictions (partial air-gapped, no NAT gateway by cost policy), the VPC endpoint for syslog is simpler to configure and requires no agent version management.

3. Lift-and-shift migration environments with tight deadlines. When you are moving 200 servers to AWS in 90 days and don't have time to instrument everything with CloudWatch Agent, configuring syslog forwarding is a single line in the existing rsyslog/syslog-ng config. You get immediate visibility without blocking the migration.

4. Short-term compliance for audits. To demonstrate to a PCI or BACEN auditor that network device logs are being collected and retained centrally, this pattern delivers the requirement with minimal configuration and an audit trail via CloudTrail (the endpoint itself generates API events).

The inflection point is volume and enrichment need. Below ~10 MB/s of aggregated syslog and without real-time correlation with other events, the pattern is excellent. Above that, or when you need correlation with application traces, the conversation changes.

Syslog Collection Patterns: Technical Comparison

Anti-Patterns: Where This Design Will Hurt You

• UDP in regulated environment without fallback: UDP has no delivery guarantee. During a critical security event, exactly when you need logs most, a traffic burst can cause silent message loss. For PCI-DSS and BACEN, use TCP+TLS mandatorily. If the device doesn't support TCP, that is a signal the device needs replacement, not that UDP is acceptable.
• Single log group for all devices: Putting firewalls, switches, and Linux servers in the same log group seems convenient but creates three problems: (1) the 5 MB/s per log group limit becomes a bottleneck during incidents; (2) the retention policy is uniform, you may need 7 years for firewall logs and 90 days for application logs; (3) IAM resource policies become excessively permissive.
• Replacing the SIEM with CloudWatch Logs Analytics: Logs Analytics is excellent for ad-hoc queries and operational dashboards, but it is not a SIEM. It has no multi-source event correlation with temporal rules, no case management, no native integration with threat intelligence feeds.
• Ignoring retention cost with the default 'Never Expire' policy: CloudWatch Logs charges $0.03/GB/month for storage (us-east-1). An environment with 10 firewalls generating 1 GB/day each accumulates 300 GB/month, ~$9/month in storage, seems cheap until you realize without a retention policy it grows indefinitely. In 12 months that is 3.6 TB and ~$108/month in storage alone.
• VPC endpoint without restrictive Security Group: The VPC endpoint accepts traffic from any source within the VPC by default. In an environment with multiple workloads, this means any compromised instance can inject false logs into the firewall log group, contaminating the audit trail. Restrict the endpoint Security Group to accept only CIDRs of legitimate network devices.

Security and Compliance: What Is Not Documented But Matters

The announcement mentions TCP+TLS as a transport option, but does not detail the encryption key model for data at rest. CloudWatch Logs supports Customer Managed Keys (CMK) via KMS for log group encryption, this is mandatory in regulated financial environments where you need to demonstrate exclusive control over encryption keys for audit data. Configure the log group with kms-key-id pointing to a CMK with a key policy that restricts usage to logs.amazonaws.com with condition kms:EncryptionContext:aws:logs:arn, this ensures the key can only be used by the CloudWatch Logs service for that specific log group.

For log immutability, a critical requirement for forensic evidence and compliance: CloudWatch Logs does not natively offer write-once semantics on the log group. The strategy I use is twofold: (1) CloudTrail with S3 Object Lock for API logs, and (2) immediate export to S3 with Object Lock in COMPLIANCE mode for syslog logs. Configure a subscription filter that triggers a Lambda to copy each log batch to an S3 bucket with Object Lock enabled and a retention period aligned to the regulatory requirement. The additional cost is low (Lambda + S3 Standard-IA), but the immutability guarantee is strong.

A security aspect frequently overlooked: log injection. Legitimate network devices send structured syslog, but in a compromised environment, an attacker who gained access to a Linux server can send forged syslog messages with a firewall's hostname, attempting to create false alibis or cover tracks. The defense is twofold: restrict the endpoint Security Group to static CIDRs of network devices (not entire subnets), and implement anomaly detection via CloudWatch Metric Filter that alerts when a hostname sends abnormally high volume, an indicator of exfiltration via log channel or injection.

Operational Observability of the Ingestion Pipeline Itself

A classic mistake I see in platform teams is instrumenting applications well and forgetting to monitor the observability pipeline itself. If the syslog ingestion endpoint stops receiving data, you may not notice until an auditor asks for firewall logs from the last 3 days.

The strategy I recommend is creating a CloudWatch Metric Filter on the syslog log group that counts the number of messages received per hostname per hour. Combine this with a CloudWatch Alarm with a minimum threshold: if a firewall that normally sends 10k messages/hour sends zero for 15 minutes, that is a critical-level alarm, it could be device failure, network connectivity failure, or the endpoint itself. Configure the alarm with TreatMissingData: breaching so that absence of data is treated as a violation, not as OK state.

For the VPC endpoint itself, monitor VPC Flow Logs metrics for the endpoint ENI: bytes in, packets rejected by Security Group, and established connections. A spike in rejected packets can indicate a misconfigured device trying to send on the wrong port, or a port scan on the endpoint. Configure a CloudWatch dashboard with these signals alongside received log volume, the visual correlation between network traffic and log volume is the fastest signal of a problem.

Finally, for multi-account environments (Landing Zone with multiple workload accounts), consider centralizing syslog log groups in a dedicated log archive account using CloudWatch cross-account observability. This keeps logs outside the blast radius of workload account compromise and simplifies auditor access without granting access to production accounts.

KMS Configuration for Syslog Log Groups in Regulated Environments: When creating the destination log group, always specify a CMK explicitly: aws logs create-log-group --log-group-name /syslog/network-devices --kms-key-id arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID. The KMS key policy must include kms:GenerateDataKey and kms:Decrypt for the logs.amazonaws.com principal with condition aws:SourceAccount equal to your account ID, this prevents confused deputy attacks where another service in the same region uses your key. Combine with an SCP on the OU that denies logs:DeleteLogGroup and logs:DeleteRetentionPolicy for log archive accounts.

AWS Well-Architected Framework Assessment

• security: Use TCP+TLS mandatorily. Configure CMK on the log group. Restrict the VPC endpoint Security Group to network device CIDRs. Implement resource-based policy with aws:SourceVpc. For forensic immutability, export to S3 with Object Lock in COMPLIANCE mode. Monitor log injection via anomaly detection on volume per hostname.
• reliability: Distribute devices across multiple log groups to avoid the 5 MB/s limit. Configure TreatMissingData: breaching on volume alarms to detect silent interruption. For critical devices, use TCP (not UDP) for delivery guarantee. Request Service Quota increases proactively for high-volume environments.

Curator's Note: In practice, I would adopt this pattern immediately for firewalls and Cisco devices in AWS landing zone environments, but with three non-negotiable conditions: mandatory TCP+TLS, CMK on the log group, and a TreatMissingData: breaching alarm per critical hostname. The hardest lesson I've learned in financial environments is that the observability pipeline is as critical as the application it monitors, and it rarely gets the same design rigor. The fact that CloudWatch Logs now natively parses FTD/ASA eliminates an entire category of regex bugs that I've seen cause audit gaps in PCI reviews. What I would not do is use this pattern as a SIEM replacement or as a solution for volumes above 50 MB/s without an explicit plan for log group partitioning and quota increases.

Verdict: Adopt with Clear Conditions

Managed syslog ingestion in CloudWatch Logs is a genuinely useful addition for teams operating network devices in AWS environments. It eliminates the intermediate relay, delivers native parsing of Cisco formats, and integrates directly into the CloudWatch alerting and query ecosystem. For regulated financial environments, it is a viable solution provided you configure TCP+TLS, CMK, restrictive Security Groups, explicit retention, and an S3 export pipeline with Object Lock for forensic immutability. It is not a SIEM replacement, does not scale trivially above tens of MB/s without quota planning, and does not solve the problem of real-time correlation with application traces. Use it as a normalization and centralization layer, not as a complete security analytics platform. The ROI is clear for teams currently maintaining EC2 relays for syslog, the swap is direct and the operational gain is immediate.

References

• Amazon CloudWatch Logs supports managed syslog ingestion: AWS What's New
• Amazon CloudWatch Logs Syslog Documentation
• Implementing Logging and Monitoring with Amazon CloudWatch: AWS Prescriptive Guidance
• Amazon CloudWatch FAQs: Ingestion Options
• CloudWatch Logs Third-Party Ingestion
• Amazon CloudWatch launches OTel Container Insights for Amazon EKS
• RFC 5424: The Syslog Protocol (IETF)
• AWS Well-Architected Framework: Security Pillar

Originally published at fernando.moretes.com. By Fernando F. Azevedo: Senior Solutions Architect.