エージェント不要でネットワーク機器のログをCloudWatchに集約 - Amazon CloudWatch Logs マネージドsyslogインジェストを試してみた

みなさんこんにちは。マネージドサービス課の塩野です。

ネットワーク機器のログをAWSに集約したいと思ったとき、これまでは「どうやってCloudWatchに送ろう？」と頭を悩ませた方も多いのではないでしょうか。ルーターやファイアウォール、スイッチはCloudWatch Agentをインストールできないため、EC2上に中継サーバーを構築するなど、ひと手間かける必要がありました。

2026年6月23日のアップデートで、その状況が大きく変わりました。Amazon CloudWatch Logs がsyslogプロトコルによる直接受信に対応し、エージェントや中継サーバーなしでネットワーク機器やLinuxサーバーのログをCloudWatch Logsへ取り込めるようになっています。

この記事では、今回のアップデートの概要から、マネジメントコンソールを使った設定手順、そして実際に使う前に知っておきたい注意点まで順を追ってご紹介します。

今回のアップデートの概要

Amazon CloudWatch Logsのマネージドsyslogインジェストは、ファイアウォール・ルーター・スイッチ・LinuxサーバーなどからのsyslogメッセージをCloudWatch Logsへ直接取り込める機能です。

aws.amazon.com

ログの送信には、VPCエンドポイント（AWS PrivateLink）を経由した3種類のプロトコルが使えます。

プロトコル	ポート	備考
TCP + TLS	6514	暗号化転送。コンプライアンス要件がある場合に推奨
TCP plaintext	1514	AWS PrivateLink経由でネットワーク分離済み
UDP	514	ベストエフォート配信（損失の可能性あり）

syslogのフォーマットは、新形式のRFC 5424・旧形式のRFC 3164・Cisco FTD/ASAの3種類を自動検出して解析します。受信したメッセージはそのままログに保存しつつ、facility・severity・hostname・appNameといった構造化フィールドを自動で抽出してくれるのも特徴のひとつです。抽出されたフィールドはそのままCloudWatch Logs Insightsのクエリで使えるため、到着したログをすぐに絞り込んで分析できます。

このアップデートでどう変わるか

エージェントが不要になった意味

これまでCloudWatch Logsにログを送るためには、CloudWatch AgentやFluent Bitといったエージェントを各マシンにインストールし、設定ファイルを配布・管理する必要がありました。EC2インスタンスやLinuxサーバーであれば比較的対応しやすかったものの、ルーターやスイッチ・ファイアウォールといったネットワーク機器は独自のOSで動いているため、エージェントをインストールする手段がありません。そのため、syslogを受け取るEC2インスタンスを中継サーバーとして立ててから転送する、という構成が一般的でした。

今回のアップデートでは、そのような中継コンポーネントが不要になります。ネットワーク機器がsyslogを送れる宛先さえ用意すれば、それだけでCloudWatch Logsにログが届く設計になっています。

自動パースでInsightsがすぐ使える

受信したsyslogメッセージはCloudWatch Logsが自動的に解析し、構造化フィールドとして展開します。たとえばRFC 5424形式であれば、facility・severity・hostname・appName・procId・messageといったフィールドが抽出され、Insightsでそのまま検索できます。これまでのようにログのパース設定を別途書く手間がなくなるのは、実際の運用でかなり助かると感じています。

従来構成との違い

観点	従来方式（Agent / 中継サーバー）	マネージドsyslogインジェスト
概要	エージェントまたはEC2中継サーバー経由でCloudWatch Logsへ送信	VPCエンドポイント経由でCloudWatch Logsへ直接送信
エージェント	各ホストへのインストールが必要	不要
ネットワーク機器への対応	中継サーバーが必要	直接syslogを送信可能
パース設定	手動で設定ファイルに記述	自動（RFC 5424 / 3164 / Cisco FTD/ASA対応）
優位性	ファイルベースのログ収集も可能。より細かなフィルタリング設定が可能	構築・運用コストが低い。ネットワーク機器からの直接収集が容易
注意点	エージェントの管理・更新が必要。中継サーバーは費用と可用性の考慮が必要	VPCエンドポイント経由のみ対応。インターネット直接送信は不可
備考	既存のAgent構成をすぐに移行する必要はない	新規にネットワーク機器のログ収集を始めるケースに特に有効

従来のエージェント構成が不要になるわけではなく、ファイルベースのログ収集には引き続きCloudWatch Agentが適しています。ネットワーク機器やエージェントを入れられない環境向けの選択肢が増えたと捉えるのが自然でしょう。

マネジメントコンソールで設定してみる

設定は「セキュリティグループの作成」「VPCエンドポイントの作成」「ロググループの作成」「リソースポリシーの設定」「Syslog Configurationの作成」の5つの手順で完了します。なお、リソースポリシーの設定のみコンソールから操作できないため、その箇所だけAWS CLIを使います。

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

VPCエンドポイントに関連付けるセキュリティグループを用意します。

VPCコンソールを開く
左メニューの「セキュリティグループ」をクリックする
「セキュリティグループを作成」をクリックする
「セキュリティグループ名」に任意の名前（例: syslog-vpce-sg）を入力する
「VPC」で対象のVPCを選択する
「インバウンドルール」の「ルールを追加」をクリックし、使用するプロトコルに合わせて以下のルールを追加する
- TCP+TLSを使う場合 - Type: カスタムTCP、Port: 6514、Source: 送信元のCIDR
- TCPを使う場合 - Type: カスタムTCP、Port: 1514、Source: 送信元のCIDR
- UDPを使う場合 - Type: カスタムUDP、Port: 514、Source: 送信元のCIDR
「セキュリティグループを作成」をクリックする

VPCエンドポイントの作成

VPCコンソールを開く
左メニューの「エンドポイント」をクリックする
「エンドポイントを作成」をクリックする
「名前タグ」に任意の名前（例: syslog-vpce）を入力する
「タイプ」で「AWS services」を選択する
「サービス」の検索欄に syslog-logs と入力し、com.amazonaws.リージョン名.syslog-logs を選択する
ネットワーク設定の「VPC」で対象のVPCを選択する
「サブネット」でエンドポイントを配置するサブネットを選択する
「セキュリティグループ」で手順1で作成したセキュリティグループを選択する
「Create endpoint」をクリックする
エンドポイントの状態が「使用可能」になったら、「DNS names」に表示されているDNS名をメモする（このアドレスがsyslogの送信先になります）

ロググループの作成

CloudWatchコンソールを開く
左メニューの「ログ」配下にある「ログ管理」をクリックする
「ロググループを作成」をクリックする
「ロググループ名」に任意の名前を入力する（例: /syslog/my-devices。公式ドキュメントでは /syslog/ プレフィックスが推奨されています）
「保持期間の設定」で保持期間を設定する
「作成」をクリックする

ソースポリシーの設定（AWS CLIが必要）

ロググループへの書き込み権限をsyslogサービスに付与するリソースポリシーを設定します。この手順はマネジメントコンソールのアクションメニューには対応していないため、AWS CLIで実施します。

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:リージョン:アカウントID:log-group:/syslog/my-devices:*",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "アカウントID" },
        "ArnEquals": { "aws:SourceArn": "arn:aws:ec2:リージョン:アカウントID:vpc-endpoint/VPCエンドポイントID" }
      }
    }]
  }'

Condition に aws:SourceArn を指定することで、特定のVPCエンドポイントからのみ書き込みを受け付けるよう絞り込んでいます。セキュリティ上、この条件は省略しないことをお勧めします。

Syslog Configurationの作成

CloudWatchコンソールを開く
左メニューの「ログ」配下にある「ログ管理」をクリックする
作成済みのロググループ（例: /syslog/my-devices）をクリックする
「アクション」から「syslog設定を作成」を選択する
VPCエンドポイントのドロップダウンから作成済みのVPCエンドポイントを選択する
「作成」をクリックする

これでVPCエンドポイントに届いたsyslogメッセージがロググループへ転送されるようになります。

送信元デバイスの設定

あとは送信元のデバイスに対して、syslogの送信先としてVPCエンドポイントのDNS名（またはエンドポイントに割り当てられているIPアドレス）を設定するだけです。

設定が完了したら、CloudWatch Logs で確認してみましょう。正しく設定ができていればログストリームやログイベントが作成されているはずです。

また、CloudWatch Logs Insightsで以下のクエリを実行してみましょう。ログが届いていれば、自動抽出されたフィールドが確認できます。

SOURCE logGroups(logGroupNamePrefixes: ["ロググループ名"], class: "STANDARD") |
fields @timestamp, facility, severity, hostname, appName, procId, message
| sort @timestamp desc
| limit 10

設定時のポイントと注意事項

VPCエンドポイント経由のみ対応

syslogをCloudWatch Logsに送るにはVPCエンドポイントが必須です。インターネット経由での直接送信には対応していません。

リソースポリシーの設定を忘れずに

リソースポリシーを設定しないと、VPCエンドポイントへのsyslog送信は拒否されてしまいます。この設定はマネジメントコンソールのアクションメニューには項目がないため、AWS CLIで実施する必要があります。aws:SourceArn 条件を指定して特定のVPCエンドポイントからのみ書き込めるよう絞り込むことをお勧めします。

なお put-resource-policy は --resource-arn を省略するとアカウントレベルのポリシーとして設定されます。公式ドキュメントのサンプルもアカウントレベルですが、--resource-arn にロググループARNを指定することで特定ロググループのみに絞り込んだスコープで設定することも可能です。より厳密に管理したい場合はロググループARNを指定する形を検討してみてください。

UDPはメッセージが失われることがある

UDP（ポート514）はベストエフォートプロトコルのため、ネットワーク輻輳や容量制約が発生するとメッセージが失われる可能性があります。ログの確実な収集が求められる場合はTCP（ポート1514）またはTCP+TLS（ポート6514）を選択しましょう。

docs.aws.amazon.com

VPCエンドポイントは時間課金が発生する

Interface型のVPCエンドポイントは稼働している間、ENI（Elastic Network Interface）ごとに時間単位で課金されます。検証目的で作成した場合は、使い終わったあとに削除するのを忘れないようにしましょう。なお、CloudWatch Logsの通常の取り込み料金・保存料金も別途発生します。

ログストリームはVPCエンドポイント単位で作成される

ログストリームはVPCエンドポイントごとに1つ自動作成されます。複数の機器から1つのVPCエンドポイントを共有している場合、すべての機器のログが同じストリームに混在します。機器ごとにストリームを分けたい場合は、VPCエンドポイントをデバイス単位で分けるか、Insightsでhostnameフィールドを使って絞り込む運用を検討してみてください。

まとめ

今回のアップデートを実際に触ってみて、ネットワーク機器のログ収集の選択肢がひとつ増えたという印象を持ちました。エージェントの管理から解放されてシンプルに構築できるのは、特に機器の台数が多い環境では大きなメリットになるのではないかと思っています。

ただし、VPCエンドポイント経由のみ対応という制約はしっかり把握しておく必要があります。オンプレ環境からの接続にはVPNやDirect Connectが前提になるため、既存のネットワーク構成とどう組み合わせるかは事前に確認しておくと安心です。

syslogを扱えるルーター・スイッチ・ファイアウォールをお持ちで、CloudWatchへのログ集約を検討されている方は、ぜひ一度試してみてください。

この記事がどなたかのお役に立てれば幸いです。