I tried ingesting syslog directly from within a VPC without an agent using the new Amazon CloudWatch Logs feature "Managed Syslog Ingestion"

Introduction

On June 23, 2026, a managed syslog ingestion feature was added to Amazon CloudWatch Logs.

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-cloudwatch-syslog-ingestion/

By simply sending syslog messages to a VPC endpoint (AWS PrivateLink), they are ingested into CloudWatch Logs.

Previously, CloudWatch Agent or Fluent Bit was required, but this new feature allows syslog to be ingested directly.

The supported protocols are as follows.

The supported syslog formats are RFC 5424, RFC 3164, and Cisco FTD/ASA.

Setup Procedure

The environment used in this article is as follows.

• Region: ap-northeast-1 (Tokyo)
• VPC: Default VPC
• EC2: t3.micro, Amazon Linux 2023, SSM connection
• VPC endpoint: com.amazonaws.ap-northeast-1.syslog-logs (Interface type)

This feature requires the creation of a VPC endpoint (Interface type). No public endpoint is provided.

Resources are created in the following order.

Creating a Security Group

Create a security group to associate with the VPC endpoint. Allow inbound TCP 1514 and UDP 514 from the syslog source.

aws ec2 create-security-group \
  --group-name syslog-vpce-sg \
  --description "Security group for syslog VPC endpoint" \
  --vpc-id <VPC_ID>

# Allow TCP 1514
aws ec2 authorize-security-group-ingress \
  --group-id <SG_ID> \
  --protocol tcp \
  --port 1514 \
  --cidr 172.31.0.0/16

# Allow UDP 514
aws ec2 authorize-security-group-ingress \
  --group-id <SG_ID> \
  --protocol udp \
  --port 514 \
  --cidr 172.31.0.0/16

Creating a VPC Endpoint

aws ec2 create-vpc-endpoint \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.ap-northeast-1.syslog-logs \
  --vpc-id <VPC_ID> \
  --subnet-ids <SUBNET_ID> \
  --security-group-ids <SG_ID>

After creation, check the DNS name of the endpoint.

aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids <VPCE_ID> \
  --query 'VpcEndpoints[0].DnsEntries[0].DnsName' \
  --output text

Example output:

vpce-0123456789abcdef0-abcdefgh.syslog-logs.ap-northeast-1.vpce.amazonaws.com

This DNS name becomes the syslog destination.

Creating a Log Group

Create a log group as the destination for syslog messages.

aws logs create-log-group --log-group-name /syslog/test

aws logs put-retention-policy \
  --log-group-name /syslog/test \
  --retention-in-days 7

Configuring a Resource Policy

Grant write permissions to the log group for the CloudWatch Logs syslog service principal.

aws logs put-resource-policy \
  --policy-name syslog-ingestion \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "syslog.logs.amazonaws.com"
        },
        "Action": [
          "logs:PutLogEvents",
          "logs:CreateLogStream"
        ],
        "Resource": "arn:aws:logs:ap-northeast-1:<ACCOUNT_ID>:log-group:/syslog/test:*"
      }
    ]
  }'

Creating a Syslog Configuration

Create a Syslog Configuration that links the log group and VPC endpoint.

aws logs create-syslog-delivery \
  --log-group-name /syslog/test \
  --vpc-endpoint-id <VPCE_ID>

The setup is now complete. Log streams are automatically created when syslog messages are received. The naming convention is {VPCE_ID}_Syslog_{Region}.

Verification: Sending Messages via TCP

Send an RFC 5424 format syslog message from an EC2 instance via TCP (port 1514).

Since nc (netcat) is not installed by default on Amazon Linux 2023, we use bash's /dev/tcp. Because the echo command appends a newline, messages are sent with newline-terminated framing (non-transparent framing).

exec 3<>/dev/tcp/<VPCE_DNS>/1514 && \
echo '<134>1 2026-06-24T07:38:00Z syslog-test myapp 1234 - - Hello from syslog ingestion test' >&3 && \
exec 3>&-

After 10–20 seconds, the event is recorded in CloudWatch Logs.

aws logs get-log-events \
  --log-group-name /syslog/test \
  --log-stream-name <VPCE_ID>_Syslog_ap-northeast-1

The get-log-events API response:

{
  "timestamp": 1782286680000,
  "message": "<134>1 2026-06-24T07:38:00Z syslog-test myapp 1234 - - Hello from syslog ingestion test",
  "ingestionTime": 1782286667881
}

The timestamp (1782286680000 = 2026-06-24T07:38:00Z) uses the timestamp from within the syslog message, which differs from ingestionTime (1782286667881 = 07:37:47Z).
At least for messages containing a parseable timestamp such as RFC 5424 format, the syslog timestamp is used as the event timestamp.

Automatic Extraction of Structured Fields

When querying with CloudWatch Logs Insights, you can reference structured fields automatically extracted from the syslog header.

fields @timestamp, facility, severity, hostname, appName, procId, message
| sort @timestamp desc
| limit 10

Extraction results:

The extracted field message accessible in Logs Insights contains only the syslog message body. Meanwhile, @message stores the entire original syslog message (including the header).

Extraction of Messages with Structured Data

We also sent and verified a message containing RFC 5424 structured data.

exec 3<>/dev/tcp/<VPCE_DNS>/1514 && \
echo '<165>1 2026-06-24T08:50:00Z syslog-test myapp 9999 ID001 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] Structured data test message' >&3 && \
exec 3>&-

Extraction results:

msgId and structuredData were also extracted as individual fields. The contents of structured data (key-value pairs) are not automatically decomposed into individual fields, but are stored as a string as-is.

Verification: Sending Messages via UDP

Send messages in the same way via UDP (port 514).

echo '<134>1 2026-06-24T07:41:00Z syslog-test myapp 5678 - - Hello from UDP syslog test' > \
  /dev/udp/<VPCE_DNS>/514

Event recorded in CloudWatch Logs:

{
  "timestamp": 1782286860000,
  "message": "<134>1 2026-06-24T07:41:00Z syslog-test myapp 5678 - - Hello from UDP syslog test\n"
}

Structured fields (facility, severity, hostname, appName, procId) are also extracted via UDP just as with TCP. Although echo appends a newline at the end, in this verification the extracted field message was accessible as a value without the trailing newline.

Deleting Resources

Steps to delete the resources created during verification.

# Delete the Syslog Configuration
aws logs delete-syslog-delivery \
  --log-group-name /syslog/test \
  --vpc-endpoint-id <VPCE_ID>

# Delete the VPC endpoint
aws ec2 delete-vpc-endpoints --vpc-endpoint-ids <VPCE_ID>

# Delete the log group
aws logs delete-log-group --log-group-name /syslog/test

# Delete the resource policy
aws logs delete-resource-policy --policy-name syslog-ingestion

# Delete the security group
aws ec2 delete-security-group --group-id <SG_ID>

Choosing Between Protocols

With TCP, if a delivery error or unacceptable condition occurs on the CloudWatch Logs side, it may appear to the sender as a connection reset. However, it is not a protocol that confirms persistence to CloudWatch Logs on a per-message basis.

UDP is best-effort. If a message is dropped due to network congestion or service-side capacity constraints, there is no feedback to the sender. To check for drops observed on the service side, you can use the CloudWatch metric SyslogMessagesDropped.

This verification was conducted using TCP plaintext (1514) and UDP (514). For production environments, consider using TLS (6514) depending on compliance requirements.

Cost

Standard Interface Endpoint fees apply to VPC endpoints (at the time of writing, Tokyo region $0.014/ENI/hour). For the latest pricing, please check the AWS PrivateLink pricing page.

The data processing fee is $0.01/GB. Since syslog messages are generally a few hundred bytes, even at 100,000 messages per day (average 200B), the monthly volume is only about 0.6 GB ($0.006), which is small as a PrivateLink data processing cost.

Separately, CloudWatch Logs ingestion fees (at the time of writing, Tokyo region $0.76/GB) and storage fees ($0.033/GB/month) will be incurred. For the latest pricing, please check the CloudWatch pricing page.

Summary

Using the managed syslog ingestion feature of Amazon CloudWatch Logs, we sent syslog messages via TCP and UDP from EC2 instances within a VPC and confirmed ingestion into CloudWatch Logs.
In addition to facility, severity, hostname, and other syslog header fields, RFC 5424 msgId and structured data are also automatically extracted.
For the RFC 5424 format verified this time, the timestamp within the syslog message was used as the event timestamp.
In Logs Insights, both structured queries using extracted fields and raw text reference via @message can be used simultaneously.

For configurations that previously required building a syslog server on EC2 or preparing a syslog reception infrastructure using EC2 and NLB, this is worth considering as a managed syslog ingestion destination. By preparing a VPC endpoint and Syslog Configuration, syslog can be ingested directly from sources into CloudWatch Logs, potentially reducing the operational burden of managing reception servers.

However, a VPC endpoint is required for use, and it is necessary to verify how to replace the monitoring, alerting, and downstream integrations previously handled by existing syslog servers on the CloudWatch Logs side. When migrating from an existing environment, we recommend thoroughly evaluating the impact on source protocol and format compatibility, extracted fields, and monitoring workflows.

Reference Links

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Syslog.html

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Syslog_Setup.html