AWS上のログとメトリクスをどのエージェントで集めるか。CloudWatch AgentとFluentd(td-agent)は競合というより役割が違い、多くの現場では併用が正解です。加えてtd-agentは既にサポート終了しており、新規採用には注意が必要です。判断軸を決定表で整理します。
「EC2やオンプレのログをどう集めるか」「CPU以外のメトリクス（メモリ・ディスク）をどう取るか」を考え始めると、必ず突き当たるのがエージェント選定です。候補は主に CloudWatch Agent と Fluentd（かつての td-agent）、そしてコンテナ時代の Fluent Bit。本記事では、日本のSIer・情シス・エンタープライズ運用の実務目線で、この3つの使い分けを判断軸と決定表に落とし込みます。まず結論から言えば、両者は排他ではなく併用が現実解になる場面が多く、選定の勘所は「送信先」と「ログ加工の複雑さ」です。
01CloudWatch Agent とは何か（AWS純正の統合エージェント）
CloudWatch Agent（統合CloudWatchエージェント）は、AWSが公式に提供する収集エージェントです。最大の特徴は、メトリクスとログを1つのエージェントで両方扱えること。EC2標準のCPU使用率などに加え、OS内部からしか見えないメモリ使用率・ディスク空き容量・スワップといった、いわゆる「カスタムメトリクス」をCloudWatchへ送れます。ログについても、指定したファイルをそのままCloudWatch Logsのロググループへ転送します。
- 対応環境：EC2だけでなくオンプレミスのLinux/Windowsサーバにも導入可能。
- 認証：EC2ではIAMロール、オンプレではIAMユーザの認証情報で連携。IAMと自然に統合されるため、権限管理が明瞭。
- 設定：JSON形式の設定ファイル（
metricsセクションとlogsセクション）で宣言的に定義。SSMパラメータストア経由の配布にも対応。 - 拡張：
StatsD／collectdプロトコルでアプリ側のカスタムメトリクスも取り込め、送信先はCloudWatchのほかAmazon Managed Service for Prometheusも選べます。
CloudWatch Agentを入れるのが定石です。アラーム設計の全体像はCloudWatchアラーム設計の勘所とCloudWatch監視のはじめの一歩もあわせてご覧ください。02Fluentd / td-agent とは何か（汎用ログコレクタ／ルータ）
Fluentdは、特定のクラウドに依存しない汎用ログコレクタ／ルータです。データをinput → filter → outputというパイプラインで処理し、あらゆる入力を受けて、あらゆる出力先へ振り分けられるのが本質です。CloudWatch Agentが「AWSへ送る」ことに最適化されているのに対し、Fluentdは送信先を選ばないのが強みです。
- 豊富な出力先：S3、Amazon OpenSearch Service、Kafka、各種SIEM、他社SaaSなど、プラグインで多数の宛先に対応。
- 加工・ルーティング：タグベースで「このログはS3へ、あのエラーだけはSlackへ」といった条件分岐した配送や、パース・マスキング・フィールド付与などの加工が得意。
- バッファリング：出力先が一時的に落ちてもメモリ／ファイルバッファで再送し、ログ欠損を抑える。
そしてtd-agentは、このFluentdをTreasure Data社が「すぐ使える安定版パッケージ」として配布していたものです。Fluentd本体とtd-agentは同一物ではなく、td-agentは配布物（ディストリビューション）という位置づけである点を押さえてください。
03【最重要】td-agent は既にサポート終了。新規は Fluent Package を
ここが本記事で最も注意喚起したい点です。td-agentは既にサポート終了（EOL）しています。Fluentd公式のアナウンスによれば、td-agent 4は2023年12月末でEOLとなり、以降はメンテナンス・新リリース・セキュリティ更新のいずれも行われません。
- 後継は
Fluent Package（fluent-package）。td-agent 4をリブランドしたもので、2023年8月に v5 としてリリースされました。「td-agentの正式な後継であり、後方互換を保つ」と公式が明言しています。 - 中身も刷新され、Rubyは2.7→3.2、Fluentd本体はv1.16系以降、Amazon Linux 2023やRHEL 9など新しいOSにも対応。ゼロダウンタイム更新やLTSチャネルも追加されています。
- さらに
fluent-package v5（LTS）も2025年12月にEOL済みで、現在の推奨はv6 LTS（少なくとも2027年末までサポート）です。
Fluent Package（現行はv6 LTS）またはFluentd本体、コンテナなら次章のFluent Bitを指定するのが正解です。既存でtd-agentが動いている環境は、後方互換を保ったままfluent-packageへの移行を計画してください。04Fluent Bit — コンテナ／K8s時代の軽量な現実解
コンテナやKubernetesが前提の環境では、FluentdよりFluent Bitが現実的な選択肢になります。Fluent BitはCNCFのGraduatedプロジェクトで、Fluentdと同じFluent組織のもとにある兄弟プロジェクトです。C言語製で、非常に軽量（最小フットプリントは数百KB規模）なため、DaemonSetとして各ノードに常駐させても負荷が小さいのが利点です。
- AWSは
aws-for-fluent-bitという公式ディストリビューションを提供。Fluent Bit本体に、CloudWatch Logs・Firehose・Kinesis・S3などAWSサービス向けの出力プラグインを同梱しています。 - ECS/Fargateの
FireLensログドライバの実体としても採用され、コンテナのstdoutを柔軟に転送・加工できます。 - イメージはAmazon ECR Public Galleryなどで配布。v3系はAmazon Linux 2023ベースで長期サポート、旧v2系（AL2ベース）は2026年6月末でEOL予定です。
ざっくり言えば、Fluentd＝サーバ集約・複雑なルーティング向けのフルスタック、Fluent Bit＝各ノード／各コンテナに置く軽量なフォワーダという役割分担で、両者を組み合わせる構成も一般的です。
05使い分けの判断軸 — 5つの問いで決める
選定は「どれが優れているか」ではなく「要件がどこにあるか」で決まります。次の5つの問いに答えると、自然と候補が絞れます。
- 送信先はCloudWatchだけか？ ── Yesなら
CloudWatch Agentが最短。S3やSIEM、他社基盤にも送るならFluentd／Fluent Bit。 - メモリ・ディスク等のカスタムメトリクスは要るか？ ── 要るなら
CloudWatch Agent（メトリクス収集はこちらの独擅場）。 - ログの加工・条件分岐した配送が必要か？ ── パース／マスキング／宛先の振り分けが要るなら
Fluentd／Fluent Bit。 - AWSネイティブか、マルチクラウド／オンプレ横断か？ ── ベンダー中立にしたいなら
Fluentd系。AWS完結なら純正が楽。 - コンテナ／Kubernetesか？ ── Yesなら
Fluent Bit（+ FireLens）を軸に。
06決定表 — 判断軸から推奨エージェントを引く
上の判断軸を1枚の表にまとめます。実務では「メトリクスはCloudWatch Agent、複雑なログ配送はFluentd/Fluent Bit」という併用が最も多いパターンです。
07併用構成の型と、選定時に外さないポイント
実際のエンタープライズ案件では、次のような併用構成に落ち着くことがよくあります。役割で切り分けると迷いません。
- メトリクス系：
CloudWatch Agentでメモリ・ディスク等を収集し、CloudWatchアラームへ。監視の一次窓口はCloudWatchに集約。 - ログ系（サーバ）：
Fluentd／Fluent Packageで受けて、S3（長期保管）・OpenSearch（検索）・SIEM（監査）へ振り分け。 - ログ系（コンテナ）：各ノード/タスクの
Fluent Bit（FireLens）で拾い、集約層へ転送。
選定時に外さないポイントは3つです。第一に、EOL製品を新規採用しないこと（td-agentは不可、Fluent Package/Fluent Bitの現行LTSを）。第二に、バッファとリトライの設計を必ず確認すること（出力先が落ちたときのログ欠損は後から効いてきます）。第三に、IAM権限を最小化すること（CloudWatch AgentもFluent BitのAWS出力も、必要なActionだけに絞る）。
—まとめ
CloudWatch AgentとFluentd（td-agent）は競合ではなく役割分担です。判断の芯は「送信先がCloudWatchで足りるか」と「ログの加工・振り分けがどれだけ要るか」。メトリクス（特にメモリ・ディスク）はCloudWatch Agentの独擅場、複雑なログ配送はFluentd/Fluent Bit、コンテナならFluent Bit。そして重要な前提として、td-agentは既にEOLであり、新規はFluent Package（現行v6 LTS）やFluent Bitを選んでください。多くの現場では、両者の併用が最もバランスの取れた解になります。