CloudWatch ：AWSを担当するエンジニアが知るべき「監視設計」の最適解
はじめに
他クラウドやオンプレミスからAWSのEC2へ移行する際、必ず議論になるのが「ログ・メトリクス収集ツールの選定」である。
例えば、軽量・高機能な Fluent-bit (FB) の運用経験がある場合、CloudWatch Agent (CWA) へ乗り換えるべきか、FBを継続利用すべきか迷うことが多い。
本記事では、インフラ経験5年以上のエンジニアおよびAWSソリューションアーキテクトプロフェッショナル (SAP) の視点から、両者の仕様差と、AWSにおける「監視アーキテクチャの正解」を解説する。
1. Fluent-bit vs CloudWatch Agent 仕様比較
まずはエンジニア視点での機能・役割の違いを整理する。
| 特徴 | Fluent-bit (FB) | CloudWatch Agent (CWA) |
|---|---|---|
| 主目的 | ログの収集・加工・転送 | メトリクス収集 + ログ転送 |
| ベース技術 | C言語 (超軽量・高速) | Go言語 (Telegrafベース + ログ機能) |
| ログ加工 | 強力 (Filter, Rewrite_Tag, Parser) | 弱い (基本はファイル転送のみ) |
| AWS統合 | Plugin対応 | 完全ネイティブ (IAM, SSM連携) |
決定的な違い：EC2の「メモリ監視」
AWSの標準メトリクス（Hypervisorレベル）では、OS内部の「メモリ使用率」と「ディスク使用率」が見えない。
これらをCloudWatchで監視する場合、カスタムメトリクスを送出するエージェントが必要となる。FBはこの機能を持たない（※Plugin等で無理やり実装は可能だが非推奨）ため、EC2監視においてCWAの導入は事実上の必須要件となる。
2. 選定基準：どちらを採用すべきか
基本戦略：CloudWatch Agent 一本化
AWS上の仮想サーバ(EC2)であれば、管理コスト削減のため CWAへの一本化 を推奨する。
メモリ監視のためにCWAが必須である以上、ログ転送のためだけにFBを別プロセスとして常駐させるのは、エージェント管理（アップデート、設定配布）の二重苦を招くためだ。
例外戦略：Fluent-bit を併用すべきケース
以下の要件がある場合に限り、FBの併用（またはFB単独利用）を検討する。
-
高度なログフィルタリングが必要:
- DEBUGログは捨ててERRORのみ送りたい（Ingestionコスト削減）。
- 特定の個人情報（クレジットカード番号等）を正規表現でマスクしてから送りたい。
-
コンテナ環境 (EKS/ECS):
- サイドカー構成では軽量なFB（AWS for Fluent Bit）がデファクトスタンダードである。
3. SAP視点のアーキテクチャ設計
ここからは、「設定ができる」レベルを超え、コスト最適化・運用自動化・大規模スケーラビリティを考慮したアーキテクト（SAP）視点での設計論を述べる。
3.1. コストの罠：NAT Gateway vs VPC Endpoint
ログ転送において最も注意すべきは「データ転送経路」のコストである。
プライベートサブネットからCloudWatch Logsへログを送る際、経路によってコストが劇的に変わる。
比較試算（東京リージョン概算）：月間1TBのログ転送
| 経路 | 固定費/月 | データ処理料/GB | 1TB転送時の処理料 |
|---|---|---|---|
| NAT Gateway | 約 $33 | $0.062 | $62 |
| VPC Endpoint | 約 $10 | $0.010 | $10 |
NAT Gateway経由の場合、CloudWatch LogsのIngestion料金とは別に、NAT処理料金が発生する。ログ流量が多いシステムでは、VPC Endpoint (Interface型) を採用することで、データ転送コストを約1/6に圧縮できる。
3.2. 運用自動化：SSMによるフリート管理
数千台規模、あるいはAuto Scaling環境において、手動やUserDataでの設定管理は破綻する。
AWS Systems Manager (SSM) を中心とした管理構成がベストプラクティスである。
- SSM Parameter Store: 設定ファイル（JSON）を一元管理。
- SSM State Manager: 全EC2に対し、定期的に設定の適用（ドリフト検出・修復）を強制。
これにより、ゴールデンイメージ（AMI）に設定を焼き込むことなく、新規起動したインスタンスが自動的に最新の監視設定で稼働を開始する。