developersIO
CloudWatch Logs のマネージド Syslog 取り込みを EC2 から擬似送信して試してみた

CloudWatch Logs のマネージド Syslog 取り込みを EC2 から擬似送信して試してみた

CloudWatch Logs の新機能「マネージド Syslog 取り込み」を検証し、VPC エンドポイント経由でオンプレミス機器のログを直接取り込める仕組みを試してみました。構築手順から実際に届いたログ、つまずいた点までをまとめます。
Amazon CloudWatchAWSCloudWatch Logs
ito-taiga
2026.10.26

はじめに

オンプレミスのネットワーク機器のログを自動的に取得したい、という要件があり、Amazon CloudWatch Logs の マネージド Syslog 取り込み を検証しました。

実機を接続する前に、AWS 側だけで次の 3 点を確認するため、EC2 インスタンスから擬似的に syslog を送って動作確認しました。

  • syslog が届くこと
  • ロググループに保存されること
  • ホスト名などのフィールドが分解されること

この記事では、マネジメントコンソールでの構築手順と、実際に届いたログの様子、つまずいた点をまとめます。

マネージド Syslog 取り込みとは

syslog を受け取るためのサーバー（rsyslog を入れた EC2 や CloudWatch エージェントなど）を自分で用意しなくても、機器から送られた syslog を CloudWatch Logs のロググループに直接取り込める機能です。

  • 受け口は VPC 内の VPC エンドポイント（Interface 型、PrivateLink） です。インターネットには公開されません
  • 受け付けるプロトコルとポートは次のとおりです
    • TCP + TLS：6514
    • TCP（平文）：1514
    • UDP：514（ベストエフォート）
  • メッセージ形式は RFC 5424・RFC 3164 などに対応しており、facility・severity・hostname・appName などのフィールドが自動で抽出されます

オンプレミスの機器から使う場合は、機器から VPC エンドポイントへ届く経路（VPN や Direct Connect）が必要です。

検証の構成

テスト用 EC2（同じ VPC 内）
  → syslog（TCP 1514 / UDP 514）
  → VPC エンドポイント（com.amazonaws.ap-northeast-1.syslog-logs）
  → CloudWatch Logs（ロググループ /syslog/test）
  → Log Analytics（ログ分析）で確認

検証環境

  • リージョン：ap-northeast-1（東京）
  • VPC：検証用に作成（DNS 解決・DNS ホスト名ともに有効）
  • 送信元：Amazon Linux 2023 の EC2（t3.micro）
  • 接続方法：Session Manager
  • 操作：マネジメントコンソール（一部のみ CloudShell を使用）

検証手順

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

VPC エンドポイントにアタッチするセキュリティグループを作成し、VPC 内からの syslog だけを許可します。

  • インバウンド：カスタム TCP 1514（ソース：VPC の CIDR）
  • インバウンド：カスタム UDP 514（ソース：VPC の CIDR）

2. VPC エンドポイントの作成

VPC コンソールの「エンドポイント」から作成します。

  • サービスカテゴリ：AWS のサービス
  • サービス：com.amazonaws.ap-northeast-1.syslog-logs
  • サブネット：EC2 と同じ VPC 内のサブネット（インターネットへのルートは不要です）
  • セキュリティグループ：手順 1 で作成したもの

状態が「利用可能」になったら、エンドポイント ID（vpce-...）とDNS 名を控えておきます。DNS 名は、後でテストメッセージの送信先に使います。

3. ロググループの作成

CloudWatch Logs でロググループ /syslog/test を作成します。保持期間は、テストログが保存され続けないよう 7 日にしました。

ログストリームは作成不要です。最初のメッセージを受信したときに、{VPC エンドポイント ID}_Syslog_{リージョン} という名前で自動作成されます。

4. リソースポリシーの設定

syslog サービス（syslog.logs.amazonaws.com）にロググループへの書き込みを許可するリソースポリシーを設定します。

VPCE_ID=vpce-xxxxxxxxxxxxxxxxx    # 手順 2 で控えたエンドポイント ID
REGION=ap-northeast-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws logs put-resource-policy --policy-name syslog-ingestion --region $REGION --policy-document '{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "syslog.logs.amazonaws.com"},
    "Action": ["logs:PutLogEvents", "logs:CreateLogStream"],
    "Resource": "arn:aws:logs:'$REGION':'$ACCOUNT_ID':log-group:/syslog/test:*",
    "Condition": {
      "StringEquals": {"aws:SourceAccount": "'$ACCOUNT_ID'"},
      "ArnEquals": {"aws:SourceArn": "arn:aws:ec2:'$REGION':'$ACCOUNT_ID':vpc-endpoint/'$VPCE_ID'"}
    }
  }]
}'

aws:SourceAccount と aws:SourceArn の条件により、「自分のアカウントの、このエンドポイントからの書き込みだけ」を許可しています。

5. Syslog 設定の作成

ロググループ /syslog/test の詳細画面にある「syslog 取り込み」から「設定」を選び、手順 2 のエンドポイントを選択して作成します。この設定で、エンドポイントに届いた syslog がこのロググループに紐付きます。

6. テスト用 EC2 の起動

送信元として、同じ VPC 内に EC2 を作成します。接続には Session Manager を使うため、AmazonSSMManagedInstanceCore ポリシーをアタッチした IAM ロールを EC2 にアタッチしました。

  • AMI：Amazon Linux 2023
  • インスタンスタイプ：t3.micro
  • サブネット：インターネットゲートウェイへのルートがあるサブネット
  • パブリック IP の自動割り当て：有効化
  • セキュリティグループ：インバウンドなし

7. テストメッセージの送信

Session Manager で EC2 に接続し、次の 3 種類のメッセージを送りました。送信先は、手順 2 で控えた DNS 名です。

今回使用した Amazon Linux 2023 の AMI には nc が入っていなかったため、bash の /dev/tcp を使っています（sudo dnf install -y nmap-ncat で導入することもできます）。

VPCE_DNS=<手順 2 で控えた DNS 名>

# (1) TCP 1514 / RFC 5424 形式
exec 3<>/dev/tcp/$VPCE_DNS/1514 && \
echo "<134>1 $(date -u +%Y-%m-%dT%H:%M:%SZ) test-ap-01 myapp 1234 - - Hello RFC5424 over TCP" >&3 && \
exec 3>&-

# (2) TCP 1514 / RFC 3164 形式（古い形式）
exec 3<>/dev/tcp/$VPCE_DNS/1514 && \
echo "<134>$(date '+%b %e %H:%M:%S') test-ap-02 [SYSTEM] Hello RFC3164 over TCP" >&3 && \
exec 3>&-

# (3) UDP 514 / RFC 5424 形式
echo "<134>1 $(date -u +%Y-%m-%dT%H:%M:%SZ) test-ap-03 myapp 5678 - - Hello over UDP" > /dev/udp/$VPCE_DNS/514

<134> は facility = local0、severity = info を表します。ネットワーク機器は古い RFC 3164 形式で送ってくることが多いため、(2) でその場合も取り込めるかを確認しました。

  • TCP は、echo が末尾に付ける改行をメッセージの区切りとして送信しています
  • (2) の date は EC2 のローカル時刻で、今回の環境は UTC でした

検証結果

CloudWatch の Log Analytics で、次のクエリを実行して確認しました。

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



なお、上のクエリには、形式ごとの判別結果を表示する @data_source_type を入れています。実は私が実行したときは、この列を入れ忘れてしまい、画像の結果には出ていません。そのかわり、行を展開したログの詳細で、rfc5424・rfc3164 と形式ごとに自動で判別されていることを確認できました。

送信したメッセージ 取り込み hostname appName / procId
(1) TCP / RFC 5424 届いた test-ap-01 myapp / 1234
(2) TCP / RFC 3164 届いた test-ap-02 （空）
(3) UDP / RFC 5424 届いた test-ap-03 myapp / 5678
  • 3 件とも届き、送信から取り込みまで 約 2 秒 でした（EC2 での送信時刻と、@ingestionTime の差から見た、今回の 1 回の計測です）
  • RFC 5424 / RFC 3164 のどちらの形式でも、facility・severity・hostname が分解されました
  • RFC 3164 のメッセージでは hostname が取れた一方、今回のメッセージでは appName と procId は空でした。今回の (2) は、RFC 3164 で一般的な myapp[1234]: のような TAG を付けずに送っているため、その影響の可能性があります（TAG 付きでの確認は行っていません）。公式ドキュメントでは、RFC 3164 の TAG から appName と procId を抽出できると説明されています。今回送った TAG なしのメッセージについては、機器の識別に hostname、内容の判定に message（本文）を使用しました
  • ログストリーム vpce-..._Syslog_ap-northeast-1 が自動作成されていました

つまずきポイント

CloudShell の変数が消える

CloudShell は、一定時間操作がないとセッションが終了し、シェル変数が失われます。時間を置いて手順 4 のようなコマンドを実行したところ、$REGION が空になり、
--region に値が渡らないエラーになりました。再接続後に変数を設定し直せば問題ありません。

後片付け

検証が終わったら、次のリソースを削除します。VPC エンドポイントは時間課金のため、特に忘れないようにしてください。

  1. テスト用 EC2
  2. Syslog 設定（ロググループの「syslog 取り込み」）
  3. VPC エンドポイント
  4. ロググループ /syslog/test
  5. リソースポリシー（aws logs delete-resource-policy --policy-name syslog-ingestion）
  6. セキュリティグループ（エンドポイント用・EC2 用）
  7. IAM ロール（他で使っていない場合）

注意事項

  • UDP は配信が保証されません。 今回の検証では届きましたが、取りこぼしの可能性はあります。機器が TCP で送れる場合は、TCP（可能であれば TCP + TLS）を優先することをおすすめします
  • TCP + TLS（6514）は今回検証していません。 本番でコンプライアンス要件がある場合は、別途確認が必要です
  • RFC 3164 のタイムスタンプには、年とタイムゾーンが含まれません。 そのため、機器の時刻のずれや、タイムゾーン設定（JST か UTC か）の違いによって、ログ上の時刻がずれる可能性があります。今回は送信元の EC2 から送ったため、この点は確認していません
  • オンプレミスの機器から使うには、VPC への経路（VPN や Direct Connect）が必要です。 今回は同じ VPC 内の EC2 から送ったため、この点は検証していません

まとめ

  • マネージド Syslog 取り込みは、VPC エンドポイント・ロググループ・リソースポリシー・Syslog 設定を作るだけで、受信用のサーバーなしで syslog を CloudWatch Logs に取り込める
  • RFC 5424・RFC 3164 の両方が自動判別され、hostname などのフィールドが分解された
  • RFC 3164（TAG なし）のメッセージでは appName と procId が空だったため、今回は hostname と message で識別・判定する（TAG 付きは未検証）
  • リソースポリシーの設定は、公式ドキュメントでは CLI の例のみ（今回は CloudShell で実行）。今回はアカウントスコープのリソースポリシーを作成したため、同名の既存ポリシーの上書きに注意する
  • VPC エンドポイントは時間課金とデータ処理料金がかかるため、検証後は削除する

実際の機器からの syslog 取り込みには、VPC への経路や機器側の設定が別途必要です。次は、実機を接続した検証を進めていきます。

参考

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

Amazon CloudWatch Logsの新機能「マネージドsyslogインジェスト」で、エージェントなしにVPC内からsyslogを直接取り込んでみた
suzuki.ryo
2026.06.24
Amazon CloudWatch Logsがエージェントを介さずSyslogプロトコルで直接ログを取り込めるようになったのでYamahaルーターのログを取り込んでみました
じゅんや
2026.06.24
【Amazon VPC】VPC フローログを CloudWatch に保存する方法
フニ
2026.04.27
[Amazon FSx for NetApp ONTAP] 管理アクティビティの監査ログをSyslogのVPCエンドポイントを用いてCloudWatch Logsに配信してみた
のんピ
2026.06.25