Amazon CloudWatch Logsの新機能「マネージドsyslogインジェスト」で、エージェントなしにVPC内からsyslogを直接取り込んでみた

はじめに

2026年6月23日、Amazon CloudWatch Logsにマネージドsyslogインジェスト機能が追加されました。

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

VPCエンドポイント（AWS PrivateLink）にsyslogメッセージを送信するだけで、CloudWatch Logsに取り込まれます。

従来はCloudWatch AgentやFluent Bitが必要でしたが、今回の機能ではsyslogを直接取り込めます。

対応プロトコルは以下の通りです。

対応syslogフォーマットはRFC 5424、RFC 3164、Cisco FTD/ASAです。

セットアップ手順

本記事で使用した環境は以下の通りです。

• リージョン： ap-northeast-1（東京）
• VPC: デフォルトVPC
• EC2: t3.micro、Amazon Linux 2023、SSM接続
• VPCエンドポイント： com.amazonaws.ap-northeast-1.syslog-logs（Interface型）

この機能ではVPCエンドポイント（Interface型）の作成が必須です。パブリックエンドポイントは提供されていません。

以下の順でリソースを作成します。

セキュリティグループの作成

VPCエンドポイントに関連付けるセキュリティグループを作成します。syslog送信元からTCP 1514とUDP 514のinboundを許可します。

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

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

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

VPC エンドポイントの作成

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>

作成後、エンドポイントのDNS名を確認します。

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

出力例：

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

このDNS名がsyslogの送信先になります。

ロググループの作成

syslogメッセージの保存先となるロググループを作成します。

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

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

リソースポリシーの設定

CloudWatch Logsのsyslogサービスプリンシパルに対して、ロググループへの書き込み権限を付与します。

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:*"
      }
    ]
  }'

Syslog Configuration の作成

ロググループとVPCエンドポイントを紐付けるSyslog Configurationを作成します。

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

これでセットアップは完了です。ログストリームはsyslogメッセージの受信時に自動作成されます。命名規則は {VPCE_ID}_Syslog_{Region} です。

検証: TCP でのメッセージ送信

EC2インスタンスからTCP（ポート1514）でRFC 5424形式のsyslogメッセージを送信します。

Amazon Linux 2023には nc（netcat）がデフォルトでインストールされていないため、bashの /dev/tcp を使います。echo コマンドが改行を付与するため、改行終端のフレーミング（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>&-

10〜20秒後、CloudWatch Logsにイベントが記録されます。

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

get-log-events APIのレスポンスです。

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

timestamp（1782286680000 = 2026-06-24T07:38:00Z）はsyslogメッセージ内のタイムスタンプが採用されており、ingestionTime（1782286667881 = 07:37:47Z）とは異なります。
少なくともRFC 5424形式のようにパース可能なタイムスタンプを含むメッセージでは、syslogのタイムスタンプがイベントタイムスタンプに使用されます。

構造化フィールドの自動抽出

CloudWatch Logs Insightsでクエリすると、syslogヘッダーから自動抽出された構造化フィールドを参照できます。

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

抽出結果：

Logs Insightsで参照できる抽出フィールドとしての message にはsyslogのメッセージ本文のみが入ります。一方、@message には元のsyslogメッセージ全体（ヘッダー含む）が格納されます。

Structured Data 付きメッセージの抽出

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>&-

抽出結果：

msgId と structuredData も個別フィールドとして抽出されました。structured dataの中身（key-valueペア）は自動では個別フィールドに分解されず、文字列としてそのまま格納されます。

検証: UDP でのメッセージ送信

UDP（ポート514）でも同様に送信します。

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

CloudWatch Logsに記録されたイベント：

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

UDPでもTCPと同様に構造化フィールド（facility, severity, hostname, appName, procId）が抽出されます。echo により末尾に改行が付与されますが、今回の確認では抽出フィールドの message は末尾改行を含まない値として参照できました。

リソースの削除

検証で作成したリソースの削除手順です。

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

# VPC エンドポイントの削除
aws ec2 delete-vpc-endpoints --vpc-endpoint-ids <VPCE_ID>

# ロググループの削除
aws logs delete-log-group --log-group-name /syslog/test

# リソースポリシーの削除
aws logs delete-resource-policy --policy-name syslog-ingestion

# セキュリティグループの削除
aws ec2 delete-security-group --group-id <SG_ID>

プロトコルの使い分け

TCPでは、CloudWatch Logs側で配送エラーや受け付け不能な状態が生じた場合、接続リセットとして送信元に見えることがあります。ただし、CloudWatch Logsへの永続化完了をメッセージ単位で確認するプロトコルではありません。

UDPはベストエフォートです。ネットワーク輻輳やサービス側の容量制約でメッセージが破棄されても送信元へのフィードバックはありません。サービス側で観測されたドロップの確認には、CloudWatchメトリクス SyslogMessagesDropped を利用できます。

今回の検証はTCP plaintext（1514）とUDP（514）で実施しました。本番環境ではコンプライアンス要件に応じてTLS（6514）の利用を検討してください。

コスト

VPCエンドポイントにはInterface Endpointの標準料金が適用されます（記事執筆時点、東京リージョン $0.014/ENI/時間）。最新の料金はAWS PrivateLink料金ページをご確認ください。

データ処理料は $0.01/GBです。syslogメッセージは一般的に数百バイト程度なので、日10万メッセージ（平均200B）でも月0.6GB程度（$0.006）とPrivateLinkのデータ処理料としては小さいです。

これとは別に、CloudWatch Logsの取り込み料金（記事執筆時点、東京リージョン $0.76/GB）と保存料金（$0.033/GB/月）が発生します。最新の料金はCloudWatch料金ページをご確認ください。

まとめ

Amazon CloudWatch Logsのマネージドsyslogインジェスト機能を使い、VPC内のEC2からTCPとUDPでsyslogメッセージを送信し、CloudWatch Logsへの取り込みを確認しました。
syslogヘッダーのfacility・severity・hostnameなどに加え、RFC 5424のmsgIdやstructured dataも自動抽出されます。
今回確認したRFC 5424形式では、イベントタイムスタンプにsyslogメッセージ内のタイムスタンプが使用されました。
Logs Insightsでは抽出フィールドによる構造化クエリと @message による原文参照を両立できます。

従来、EC2上にsyslogサーバーを構築したり、EC2とNLBでsyslog受信基盤を用意していた構成では、マネージドなsyslog取り込み先として採用を検討する価値があります。VPCエンドポイントとSyslog Configurationを用意すれば、送信元からCloudWatch Logsへsyslogを直接取り込めるため、受信サーバーの運用を減らせる可能性があります。

ただし、利用にはVPCエンドポイントが必須であり、既存のsyslogサーバーで行っていた監視・アラート・後続連携をCloudWatch Logs側でどう置き換えるかは確認が必要です。既存環境からの乗り換えでは、送信元の対応プロトコルやフォーマット、抽出フィールド、監視フローへの影響を含めて十分に評価することをおすすめします。

参考リンク

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

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