はじめに
AWSの運用監視領域は、ここ数年「リソースを監視してメトリクス・ログ・トレースを貯める」から「あらゆるデータを集約・正規化して、それらを使って意思決定する」フェーズにフォーカスしています。
AWS re:Invent 2025 のセッション『[NEW LAUNCH] What's new with Amazon CloudWatch(COP363)』でも、"data to decisions faster/simpler/more autonomously"（データから意思決定へ、より速く・簡単に・より自律的に）という方向性が明確に打ち出されました。
本記事では、AWS re:Invent 2025のセッション（COP363等）および2025年11月〜12月のアップデートに基づき、我々がどのように設計思想の更新をすべきかについて解説をします。
直近のアップデート一覧
| リリース日 | 機能 | アップデート | メリット | 参照 |
|---|---|---|---|---|
| 2025/09/17 | Logs Centralization | クロスアカウント・クロスリージョンログ集約(一元化) | コンプライアンスとデータの保全 | What's New |
| 2025/11/5 | CloudWatch Database Insights - Enhanced Anomaly Detection | オンデマンド分析で異常検知能力が向上(OS、DB、SQLの各レベルで異常を検出して正常時と比較して問題を指摘) | 見えるか、解決手順の提示により解決時間の短縮 | 公式発表 |
| 2025/11/11 | CloudWatch Composite Alarms - Threshold-based Alerting |
AT_LEAST関数による柔軟なアラート設定 |
「4個中2個以上」「全体の50%以上」といった条件指定によりアラートラッシュを軽減、サーバーが増えても設定変更不要 | 公式発表 |
| 2025/11/19 | CloudWatch Logs Insights - Scheduled Queries | ログ分析クエリを定期実行、結果はS3に保存 or EventBridgeで通知 | 週次レポートを自動生成 | 公式発表 |
| 2025/11/19 | CloudWatch RUM - Mobile Support (iOS & Android) | iOSとAndroidアプリも監視対象となり画面の表示速度、クラッシュ、API応答時間の表示やAppHangを検出 | ウェブもモバイルも1つのダッシュボードで監視 | 公式発表 |
| 2025/11/20 | CloudWatch Application Map - Enhanced Discovery | 計測してないサービスを自動検出し、複数アカウントをまたいで全体マップを表示 | システム全体を見渡すことができる | 公式発表 |
| 2025/11/21 | CloudWatch Application Signals - GitHub Action & MCP Server | GitHub Issuesで@awsapmとメンション、遅延の特定や計測設定のコードまで記述 | AWSコンソールを開かずGitHubで完結 | 公式発表 |
| 2025/11/21 | CloudWatch In-Console Agent Management on EC2 | EC2のコンソールからワンクリックでエージェント導入 | 全環境で同じ監視を保証 | 公式発表 |
| 2025/11/21 | CloudWatch Database Insights - Cross-Account Cross-Region Monitoring | 複数アカウント・複数リージョンのDBを一画面で見える化 | 本番・検証・開発を横断して状況把握 | 公式発表 |
| 2025/11/21 | CloudWatch Container Insights - Neuron UltraServers Support | 大規模ML用のNeuron UltraServersに対応し、複数EC2を束ねた論理サーバーとして監視 | ML環境のパフォーマンスがまとめて見える化 | 公式発表 |
| 2025/11/21 | CloudWatch Container Insights - Sub-Minute GPU Metrics | EKSで動くAI/MLワークロードを対象にGPUメトリクスを秒単位で取得可能 | GPUの使い方、パフォーマンスの見える化 | 公式発表 |
| 2025/11/26 | CloudWatch Logs Deletion Protection | ロググループに削除保護をかける | 監査ログや本番ログの誤削除防止 | 公式発表 |
| 2025/11/30 | CloudWatch Incident Reports - Five Whys Analysis | チャットベースでのなぜなぜ分析 | 障害報告書作りが自動化 ・「なぜこうなった？」を明確にして障害報告にも利用可能 |
公式発表 |
| 2025/12/2 | CloudWatch Unified Data Management | ・運用、セキュリティ、監査のログを1箇所に集約 ・S3 TablesでIceberg形式に自動変換（無料） ・Athena、SageMaker、Redshiftで分析できる ・OCSF標準形式に自動変換 |
・ログが複数の場所に散らばらない ・ETLパイプライン作る手間が減る ・データストア維持費が削減できる ・標準化で分析が楽になる |
公式発表 |
| 2025/12/2 | CloudWatch Facets | ロググループを意識せずにログソース、アプリ名、リージョンで絞り込み | 「どのロググループだっけ？」が不要で10,000個のロググループを一気に検索 | ドキュメント |
| 2025/12/2 | CloudWatch GenAI Observability - AgentCore Evaluations | AIエージェントの品質を13項目で自動評価、CloudWatchダッシュボードで一元管理 | AI品質を継続的に測定 | 公式発表 |
| 2025/12/5 | CloudTrail Events in CloudWatch | CloudWatchコンソールから直接CloudTrailイベントのCloudWatch Logs保存の設定が可能 | 証跡を作成せずにCloudWatch Logsへイベントを配信 | 公式発表 |
| 2025/12/30 | CloudTrail Lake Data Import | CloudTrail Lakeの過去データを簡単取り込み | 運用ログと監査ログを一緒に分析、過去のコンプライアンスデータや長期トレンドを分析可能 | 公式発表 |
アップデートから見る CloudWatch の進化の方向性
1️⃣ データ面：ログ/イベントを「集める/守る/整える/探す」をCloudWatchで完結
- 運用基盤としての強化
- Unified Data Store / Pipelines / Facets / Logs Centralization / Deletion Protection など
2️⃣ 運用面：検知〜切り分け〜修正〜振り返り（Five Whys）までの時間短縮
- 運用プロセスの自動化
- Composite Alarm / Cross-Account Cross-Region Monitoring / In-Console Agent Management など
運用の現場における課題
-
データサイロと重複
- CloudTrail, VPC, WAFなどがSecurity/Ops/Audit が複数のデータストアに分散・重複
-
複雑な運用とMTTR増大
- 複雑なETLパイプライン管理のオーバーヘッドと、手動連携による復旧遅延
-
コスト非効率
- 同一データの重複保存、転送コストに加え、複数のツール運用コストが発生
Unified Data Store
収集・キュレーション・保管・分析を単一プラットフォームで実現するための仕組み
Unified Data Storeの仕組み
Collection
データソースとして以下を選択することが可能です。
- AWSサービスログ
- サードパーティコネクタ(CrowdStrike、Okta、GitHub、M365など)
- カスタムログ(CloudWatchカスタムログ、S3)
Curetion
- CloudWatch Pipelines: コードレスでログ変換・エンリッチメント処理を実行
- OCSF(Open Cybersecurity Schema Framework)変換
- OpenTelemetryフォーマット標準化
- Grokプロセッサによるカスタムパース
- メタデータ追加(Account ID、Application Name等)
- 自動スキーマ検出
- ログソースごとのスキーマ自動抽出
- Field Indexes
- リクエストID、トランザクションIDなどクリティカル属性をインデックス化
Storage
- クロスアカウント・クロスリージョン集約(単一アカウントへの統合管理)
- データソース別の保持期間設定
- Apache Iceberg対応(S3 Tablesとの統合によるオープンフォーマットサポート)
- 2つのストレージクラスによるコスト削減
- Standard Class: リアルタイム運用向け
- Infrequent Access Class: コンプライアンス向けの低頻度アクセス
Analytics
- Log Facetsによるクエリ実行前のフィールド分布可視化
- 10,000ロググループ同時クエリ(従来50-100から大幅拡張)
- S3 Tables統合によるAthena、Redshift、EMR、SageMaker Unified Studioからのインプレースクエリ
- 自然言語クエリ生成、自動分析
設計におけるメリット
- ✅ データ重複削減：同一ログの複数コピー不要（コスト削減）
- ✅ ETL不要：Kinesis/Lambda変換パイプラインの構築・運用負荷解消
- ✅ Iceberg互換：Spark/Trino等のOSSクエリエンジンも利用可能
- ✅ スキーマ管理：データソース別にフィールドインデックス自動生成
- ✅ KinesisやLambda などが不要になることでコストも削減
CloudWatch Pipelines
概要
CloudWatch Pipelinesは、「収集(Collection)」と「キュレーション(Curation)」の2つのフェーズにまたがってデータの「入口」から「構造化」までを担う基盤機能です。
AWS Organizationsと統合し、組織全体のログを自動収集し、OCSF(Open Cybersecurity Schema Framework)への変換をマネージドサービスとして提供します。
OCSF セキュリティイベントの共通スキーマ
パイプラインの中でログイベントを変換/解析/加工する処理ユニットをプロセッサと呼びます。定義した順に逐次適用されます。
-
パーサ（Parser）
生ログを構造化フィールドに変換します。
例：OCSF/CSV/JSON/Grok/key-value/VPC Flow Logs/Route 53 Resolver logs など -
トランスフォーマ（Transformation）
フィールドを追加/コピー/削除/移動/フラット化などして形式を整えます。
例：add_entries/copy_values/delete_entries/move_keys/flatten など -
文字列操作（String）
値の大文字小文字変換、トリム、置換など、文字列を加工します。
プロセッサ利用に“個別の処理課金”は基本なく、ログ取り込み課金がベース。S3 Tables 提供は追加ストレージ料金なし。従来のETLアーキテクチャーと比較して、設計次第で大きくコスト削減できる可能性があります。
制約
- 1パイプラインあたり 最大20プロセッサまで。
- パーサ系を使う場合は先頭に置く必要があります。
- プロセッサによって変換されたログに置き換わり、元の生ログは保持されません。
AI駆動Ops
CloudWatch Investigations
CloudWatch の中に組み込まれた生成AI機能で、システムのテレメトリ(メトリクス、ログ、トレースなど)をスキャンし、インシデントに関連するデータや根本原因の仮説を提示するトラブルシュートアシスタント。スコープとして、AWS環境内の CloudWatch データを対象とします。
- コンソール全体統合
Lambda、RDS、CloudWatch Alarmsから「Investigate」ボタンで起動します。 - エンドツーエンドガイド
アラームから原因解析まで自動分析します。 - 自動相関分析
リソース依存関係とテレメトリの相関性を自動検出します。
AWS DevOps Agentとの違い
DevOps Agentは、インシデントの解決と予防を自律的に行うフロンティアエージェント。リソースのトポロジーや関係性を学習し、オブザーバビリティツール、ランブック、コードリポジトリ、CI/CDパイプラインと連携して、テレメトリ・コード・デプロイデータを横断的に相関分析する。
Incident Report Generation
Amazon Correction of Errors(CoE)形式の自動レポート生成。
特徴:
- 自動データ収集
調査から得られたテレメトリ(メトリクス、ログ、トレース、変更履歴など)の自動で収集します。 - Five Whys分析
収集した事実（アラーム、ログ、変更履歴など）を材料にして、①現象の直接原因、②それが起きた背景、③設計・運用の欠陥、④プロセス上の欠陥、⑤組織・仕組みの欠陥について、仮説を提示します。 - 定型レポート出力
- Summary（要約）：何が起きたか／影響は何か
- Impact（影響）：影響時間、影響対象、SLO違反など
- Timeline（時系列）：検知、一次対応、復旧、恒久対応
- Root Cause / Five Whys（原因）：AIの叩き台 + 人が確定
- Corrective Actions（是正処置）：再発防止タスク（優先度付き）
- Lessons Learned（学び）：プロセス改善、監視改善、設計改善など
まとめ
2025年のCloudWatchは「データ統合」「AI駆動運用」で大きく進化を遂げました。特にUnified Data StoreとPipelinesは、長年の課題だった「ログのサイロ化」「ETLパイプライン運用負荷」を解決する画期的な機能といえるのではないでしょうか？
若干、CoudWatch のマネジメントコンソールが複雑になってきた気もしなくもないですが、、、ぜひキャッチアップして使ってみましょう。