ここ 3 年くらいの CloudWatch アップデートについて丸っと解説します

Transcript

1. ここ 3 年くらいの CloudWatch アップデートについて丸っと解説します クラウド事業本部 ソリューションアーキテクト 枡川 健太郎
2. ⾃⼰紹介 • 部署 クラウド事業本部 ◦ • 役割 ◦ • 名前 ◦ • ソリューションアーキテクト 枡川 健太郎 特に興味のある領域 ◦ © 2026 Classmethod, Inc. コンテナ、オブザーバビリティ 2
3. 最近の CloudWatch について 3
4. 2023 年辺りから継続的に進化を続ける CloudWatch 4 2023 年頃の CloudWatch も機能⾃体は揃っていたが、オブザーバビリティ特化の SaaS とは使い勝 ⼿に⼤きな差があった。 • • • • • • • ログの取り扱いに関する機能がシンプル過ぎる アラームを定義する際にリソース ID を埋め込む必要がある テレメトリ間の関連付けがし⾟い マルチクラウド対応していない OpenTelemetry 対応していない プリセットのダッシュボードが簡素 AWS の API と権限が密接に結びついていて、権限管理が⾯倒 (ReadOnly で⾒せる運⽤が多くなる) ビルディングブロックの思想の中で、開発者向けの使いやすさに注⼒しているとは⾔えない部分も あったが、近年良い意味で SaaS 化した。 その中で⼀つの到達点として、2026 年 9 ⽉に登場した CloudWatch Omni がある。 主なアップデート Application Signals GA CloudWatch Logs インデックス対応 2024 © 2026 Classmethod, Inc. 強化された Container Insights (ECS) CloudWatch Logs 統合データストア 2025 OTel/PromQL 対応 2026 CloudWatch Omni
5. CloudWatch 公式ドキュメントのトップページを眺めてみる 5 ここ数年は「オブザーバビリティ」という⾔葉を使うことが増えた。 > Amazon CloudWatch monitors your Amazon Web Services (AWS) resources and the applications you run on AWS in real time, and offers many tools to give you system-wide observability of your application performance, operational health, and resource utilization. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html トップページに特徴として記載があるのは下記 (2026 年 10 ⽉時点)。 • CloudWatch Omni • OpenTelemetry 対応 • APM (CloudWatch Application Signals, CloudWatch Synthetics, CloudWatch RUM) • インフラストラクチャ監視 (Database Insights, Container Insights などを含む) • ログの収集、保存、クエリ • CloudWatch エージェントを利⽤した EC2 フリート管理 (SSM 連携含む) • クロスアカウント監視 • ソリューションカタログ (JVM, NVIDIA GPU 向けなどの事前定義されたカスタムダッシュボードなど) • ネットワーク監視 (CloudWatch Network Monitoring) 太字はこの 3 年で追加されたもの、それ以外も全て強化が⼊っている。 © 2026 Classmethod, Inc.
6. オブザーバビリティは重要になってきている • オブザーバビリティとは「システムの状態を把握できる能⼒」 • AI を使った運⽤はオブザーバビリティの上に成り⽴つ。 ◦ AI は⼗分なコンテキストが無いと、質の⾼い判断を⾏うことができない。 ◦ とはいえ、本番サーバーの中で AI エージェントを好き勝⼿動かすのは怖い。 • 「システムの状態を把握するために⼗分な情報」が CloudWatch にまとまっていると望ましい。 © 2026 Classmethod, Inc. 6
7. CloudWatch の進化をキャッチアップしよう 重要度は上がってますが、どんどん概念が増えてキャッチアップが⼤変なので、本⽇丸っとおさらい しましょう！！ • CloudWatch Application Signals • CloudWatch OpenTelemetry 対応 • アラーム周りのアップデート (PromQL ベース、ログベース、リソースタグを活⽤したアラート) • CloudWatch ログ統合データストア • Log Analytics • Logs Intelligent-Tiering • CloudWatch Omni © 2026 Classmethod, Inc. 7
8. CloudWatch Application Signals 8
9. CloudWatch Application Signals • オブザーバビリティや SRE などの考え⽅を、AWS 上で⼿間なく実践できるようにした ◦ サービスとオペレーション (パス + メソッド) を中⼼にしたプリセットのダッシュボード ◦ 作り込み無しで SLI/SLO 管理を可能にした ◦ OpenTelemetry のゼロコード計装を活⽤して簡単にセットアップできるようにした © 2026 Classmethod, Inc. 9
10. CloudWatch Application Signals で SLI/SLO を定めよう 10 • SLO を定めることで、アプリケーションチームやビジネスチームを含めて正常な状態の定義が揃う ◦ 可⽤性 100 % を⽬指すのは厳しい、SLO を元に優先順位を決められる • セットアップが済んだ段階で、オペレーションごとのレイテンシーやエラーレートが確認可能 ◦ オペレーション単位で信頼性を定義できる © 2026 Classmethod, Inc.
11. アプリケーションの状態を⼀覧で確認しやすくなる 11 アプリケーションの状態を SLO Dashboad で確認しつつ、追加調査が必要な時に各種テレメトリを⾒に⾏くイメージ Amazon CloudWatch Application Signalsの全貌 © 2026 Classmethod, Inc.
12. ゼロコード計装前提で設計されている • • • アプリケーションコードを書き換えずに APM を利⽤可能 ADOT (AWS 利⽤向けの OpenTelemetry ディストリビューション) のゼロコード計装を利⽤できる ◦ OpenTelemetry SDK も利⽤は可能だが、Application Signals の⼀部機能を利⽤できなくなる ◦ Java, Python, .NET, Node.js 以外の⾔語を使う場合は OpenTelemetry SDK 必須 細かい仕組みは⾔語とアーキテクチャ (EC2/ECS/EKS/Lambda) 次第で変わるが、ドキュメント通りセット アップすれば良い ◦ EKS の場合、Init コンテナの差し込みと環境変数の設定も⾃動化できる © 2026 Classmethod, Inc. ECS 上で Node.js アプリケーションを動かす場合の例 12
13. CloudWatch OpenTelemetry 対応 13
14. CloudWatch OpenTelemety 対応 • CloudWatch エージェントに OTLP でテレメトリを送信することはできたが、CloudWatch 側に OTLP エンドポイントが揃っていなかった © 2026 Classmethod, Inc. 14
15. CloudWatch OpenTelemety 対応 • • 15 2026 年 6 ⽉に OTLP エンドポイントが追加され、ログ/メトリクス/トレースが揃った ◦ テレメトリごとにホストごと別れる、Sigv4 認証が基本だがエンドポイントに依っては Bearer 認証も可 ▪ monitoring.{AWS リージョン}.amazonaws.com/v1/metrics ▪ logs.{AWS リージョン}.amazonaws.com/v1/logs ▪ xray.{AWS リージョン}.amazonaws.com/v1/traces CloudWatch Omni では Azure や Google Cloud のインフラもまとめて監視する前提でビューが組まれている ◦ AWS 中⼼のワークロードだが、⼀部だけ Azure/Google Cloud があるようなケースでまとめて監視しやす くなる © 2026 Classmethod, Inc.
16. CloudWatch OpenTelemety 対応 (GCE の場合) • 例えば GCE であれば、CloudWatch エージェントをインストールすれば CloudWatch で監視可能 © 2026 Classmethod, Inc. 16
17. CloudWatch OpenTelemety 対応 (CloudWatch Omni での⾒え⽅) 17 • CloudWatch Omni では Cloud provider も⾃動で識別されてビューに表⽰される © 2026 Classmethod, Inc.
18. PromQL 対応 • • 18 Query Studio という専⽤のクエリ画⾯が登場して、OTel メトリクスを PromQL でクエリできるようになった ◦ ラベル付きメトリクスを扱いやすく、業界標準で乗り換えコストが低い 既存のメトリクスはビューが変わっただけで、これまで通り SQL (のサブセット) でクエリする 切り替え可能 © 2026 Classmethod, Inc.
19. AWS メトリクスの OTel メトリクス化について • • 19 CloudWatch 設定から AWS メトリクスの OTel エンリッチメントを有効化すれば、AWS メトリクスも OTel メトリクス 化して PromQL でクエリ可能 OTel エンリッチメントを有効化すると、メトリクスの量に応じた課⾦が発⽣する (旧来のメトリクスも併⽤する形) > If you enable vended metric enrichment for 500 EC2 instances, 50 RDS instances, and 100 ELB load balancers, and these resources publish a combined total of approximately 8,000 metrics at 1-minute intervals, your monthly charges would be: Total observations per month = 8,000 metrics × 60 min × 24 hrs × 30 days = 345,600,000 observations Average enriched observation size = 450 bytes (includes AWS resource tags and metadata) Monthly enriched ingestion = 345,600,000 × 450 bytes = ~155 GB/month Monthly Vended Enrichment charges = 155 GB × $0.50/GB = $77.50 per month https://aws.amazon.com/cloudwatch/pricing/ • 今すぐ OTel エンリッチメントを有効化して、PromQL に移⾏する必要は無い ◦ OpenTelemetry Metrics (Recommended)、CloudWatch Metrics (Classic) という表現に反応し過ぎなくても良い © 2026 Classmethod, Inc.
20. カスタムメトリクスは OpenTelemetry を積極的に使って良い • ⾼カーディナリティ (ラベルの組み合わせが多い) の場合はコストメリットが⼤きい ◦ ラベルの種類が増えると従来のカスタムメトリクスは料⾦が嵩む ◦ ⼀⽅で、ある程度積極的にラベルをつけた⽅が便利 ▪ 他テレメトリとの相関付けに使える • エラーが発⽣した時のメトリクス情報を抜き出す等 ▪ アラーム設定時もラベルで指定できると便利 • Datadog や Grafana Cloud など、オブザーバビリティ系の SaaS を利⽤したくなった際に移⾏しやすい • CloudWatch エージェントの設定を変えるだけで OTLP エンドポイントを使える ◦ 細かいことを考えなくてもテレメトリごとに振り分けてくれる © 2026 Classmethod, Inc. Send OpenTelemetry data using the agent configuration file 20
21. OTel Container Insights for Amazon EKS が便利 21 • EKS を CloudWatch で監視するなら OTel Container Insights for Amazon EKS が便利 ◦ アドオンを⼊れるだけで、⼀通りのセットアップが完了して専⽤ビューが⾒れる • 後から Grafana を使いたくなったら、CloudWatch を Prometheus 代わりに使えるメリットもある ◦ CloudWatch PromQL エンドポイントを指して Prometheus データソースを追加すれば良い • node-exporter や kube-state-metrics など、Kubernetes エコシステム標準のメトリクス収集⽅式 へ変わっている © 2026 Classmethod, Inc.
22. アラーム関連のアップデート 22
23. PromQL ベースのアラーム • OpenTelemetry メトリクスに対しては PromQL ベースのアラームを利⽤可能 © 2026 Classmethod, Inc. 23
24. PromQL ベースのアラーム 24 • ラベル付きメトリクスに対する表現⼒が上がった ◦ 例えば、Google SRE book に書いてあるような、期間を変えた条件の組み合わせを複合 アラームが不要になる 以前はそれぞれアラームを作って 複合アラームにする必要があった Alerting on SLOs © 2026 Classmethod, Inc.
25. ログベースアラート 25 • Log Insights でクエリした結果についてアラートを仕込むことが可能 • ⼿軽に使えて便利だが、何だかんだメトリクスフィルターやカスタムメトリクス化の⽅が使 うケースは多そう © 2026 Classmethod, Inc.
26. リソースタグを活⽤したアラート 26 • 旧来の SQL でも 2025 年 9 ⽉にタグベースでアラームを設定することができるようになっている 個別に状態を判定可能 [アップデート] Amazon CloudWatchがリソースのタグを⽤いてメトリクスモニタリングができるようになり、リソースの追加や変更に⾃動的に適応する動的なCloudWatchアラームを設定可能になりました © 2026 Classmethod, Inc.
27. CloudWatchログ統合データストア 27
28. re:Invent2025でCloudWatchログ統合データストアが機能強化 © 2026 Classmethod, Inc. Amazon CloudWatch がオペレーション、セキュリティ、コンプライアンスデータの統合管理と分析を開始 28
29. CloudWatch ログでログ基盤を作りやすくなった 収集/キュレーション/分析の全てで機能が強化された © 2026 Classmethod, Inc. 29
30. CloudWatchログ統合データストアのポイント • CloudWatchログでログ基盤を作りやすくなる、複数の機能が追加された ◦ 厳密には re:Invent 前から続いたアップデートの集合体 • 各アップデートは単体利⽤も可能、⼤規模なログ基盤を作らなくても恩恵を受けられる • 追加料⾦無しで利⽤できるため、CloudWatchログを利⽤しているなら活⽤しないと損 ◦ もちろん、ログの取り込み料⾦、保存料⾦、クエリ料⾦は従来通り発⽣する ◦ 各機能を上⼿く活⽤すればコストカットできる可能性もあり © 2026 Classmethod, Inc. 30
31. アカウント/Organizations単位でのAWSログ収集設定 © 2026 Classmethod, Inc. 31
32. アカウント/Organizations単位でのAWSログ収集設定 OUやアカウントを指定して、特定ログをCloudWatchに出⼒することが可能 CloudWatch テレメトリ設定でOU単位のVPCフローログ⾃動設定を試してみた © 2026 Classmethod, Inc. 32
33. アカウント/Organizations単位でのAWSログ収集設定 OUやアカウントを指定してログを有効化できる © 2026 Classmethod, Inc. 33
34. アカウント/Organizations単位でのAWSログ収集設定 各種ログを有効化する設定は「テレメトリルール」と呼ばれる ※ EC2の詳細モニタリング設定なども同じ枠組みで扱うことが可能 © 2026 Classmethod, Inc. 34
35. アカウント/Organizations単位でのAWSログ収集設定 ログ種別ごとにテレメトリルールを設定する © 2026 Classmethod, Inc. 35
36. アカウント/Organizations単位でのAWSログ収集設定 組織全体、OU、アカウントにいずれかを指定して有効化 © 2026 Classmethod, Inc. 36
37. AWSマネージド3rdパーティーログ収集 © 2026 Classmethod, Inc. 37
38. AWSマネージド3rdパーティーログ収集 AWS側から3rdパーティーアプリケーションのログを取得しにいく形での連携が可能に © 2026 Classmethod, Inc. 38
39. ログの⾃動分類 © 2026 Classmethod, Inc. 39
40. ログの⾃動分類 ロググループの上位概念にあたる「データソース」が追加された Logs Insightsのクエリやパイプライン‧インデックス設定を「データソース」ごとに⾏うことができる © 2026 Classmethod, Inc. 40
41. ログの⾃動分類 ロググループをデータソースごとにグルーピング可能 多くのAWSサービスログは⾃動で検出されてまとめられる アプリケーションログなども、タグを付与することでデータソースとして認識させることが可能 © 2026 Classmethod, Inc. 41
42. ログの⾃動分類 ⼀部のAWSログは検知されると⾃動でインデックス設定が適⽤される • • • • VPC フローログ Route53 クエリログ WAF アクセスログ CloudTrail ログ アプリケーションログなども、データソースごとにインデックス設定を⾏うことが可能 © 2026 Classmethod, Inc. 42
43. パイプライン © 2026 Classmethod, Inc. 43
44. パイプライン ログのパースや変換などをAWSマネージドな形で実現 (LambdaやFirehose不要!) © 2026 Classmethod, Inc. 44
45. パイプライン Grokパーサー、JSONプロセッサなどが利⽤可能 特定のログ(WAFのログなど)では、OCSFプロセッサを利⽤してOCSF変換することも可能 © 2026 Classmethod, Inc. 45
46. クロスアカウント‧クロスリージョンのログ⼀元化 © 2026 Classmethod, Inc. 46
47. クロスアカウント‧クロスリージョンのログ⼀元化 • 「⼀元化ルール」を作成することで、特定アカウントにログのコピーを集約することが可能 • 1つ⽬のコピーまでは無料 © 2026 Classmethod, Inc. Amazon CloudWatch Logs の⼀元化を使⽤したログ管理の簡素化 47
48. AWSマネージドS3 Table統合 © 2026 Classmethod, Inc. 48
49. AWS マネージド S3 Table 統合 ログデータを AWS マネージドで S3 Tables に連携可能 保持期間はロググループと同じになり、追加料⾦は不要 (S3 ストレージ料⾦も不要) CloudWatch Logs Insights を利⽤しつつ、必要に応じて Apache Iceberg 互換のツールで分析できる © 2026 Classmethod, Inc. 49
50. AWS マネージド S3 Table 統合 CloudWatch Insights を利⽤しつつ、複雑な分析にはSQLベースのクエリも実⾏可能 © 2026 Classmethod, Inc. 50
51. ファセットによるクエリレス分析 © 2026 Classmethod, Inc. 51
52. ファセットを利⽤したクエリレス分析 Logs Insights のクエリを毎回組み⽴てずにログを絞り込める ファセットを指定した場合はインデックスも⾃動で利⽤される © 2026 Classmethod, Inc. 52
53. ログ管理機能 © 2026 Classmethod, Inc. 53
54. ログ管理機能 コスト管理に便利なダッシュボード © 2026 Classmethod, Inc. 54
55. Log Analytics 55
56. Log Analytics • Log Insights がリッチな画⾯になった • もちろんファセットやロググループによる絞り込みも可能 © 2026 Classmethod, Inc. 56
57. AI によるクエリ⽣成 • AI に投げる差分付きでクエリ修正をしてくれる • ログ種別ごとにプリセットのクエリが⽤意されている © 2026 Classmethod, Inc. 57
58. Top N 分析 • ログを継続的に処理して、上位 N 個を集計し続けることが可能 ◦ リクエスト元のクライアント IP、エラーが多いパスなど • ルール数と、ルールに⼀致したイベント数に課⾦ © 2026 Classmethod, Inc. 58
59. Logs Intelligent-Tiering 59
60. CloudWatch Logs Intelligent-Tiering 60 • アクセスパターンに応じてログを 3 つのストレージ層（Standard / Infrequent Access / Archive Instant Access）に⾃動分類してくれる • クエリへの影響は無く、ログ保管料⾦削減に繋がるため、メリットしか無い • Data Firehose 経由で S3 にアーカイブする構成のメリットが薄くなった • ⼀⽅で、取り込み料⾦ (0.76USD/GB、ap-northeast-1) は削減できないため、Fluent Bit などを利⽤して⼀部ログを S3 にルーティングする設計は変わらず有効 • アカウント設定で有効化することで利⽤可能 © 2026 Classmethod, Inc.
61. CloudWatch Omni 61
62. CloudWatch Omni 62 • 専⽤コンソールとして再構成された CloudWatch 専⽤エージェント付き (Omni エージェント) © 2026 Classmethod, Inc.
63. CloudWatch Omni 63 • 参照するデータ⾃体は CloudWatch と⼀緒 ◦ 追加の保存、取り込み料⾦無しで併⽤可能 • Organizations 連携することで IAM Identity Center グループを利⽤して権限付与が可能 • アカウントとリージョンの組み合わせごとにスペースが作成され、権限付与の単位となる © 2026 Classmethod, Inc. CloudWatch Omni
64. CloudWatch Omni 64 • 権限モデルが完全にこれまでの CloudWatch (AWS の 1 サービス扱い) とは別 ◦ AWS のアプリケーションを触る権限を与えずに調査するといったことをやりやすい • IAM Identity Center のグループを指定して権限付与できる IAM Identity Center グループを指定 プリセットとして下記が存在 • Viewer (読み取り) • Editor (編集) • admin (権限管理) © 2026 Classmethod, Inc.
65. CloudWatch Omni • CloudWatch と同じデータセットを⾒ているが、CloudWatch の全機能を使えるわけでは無い ◦ 特に Database Insights や Container Insights, Synthetics Canary などは⾒れない © 2026 Classmethod, Inc. 65
66. CloudWatch Omni 66 • Thread (作業場所) と Canvas (ビュー、メモなど実際に⾒る内容) がある • 話題ごとに Thread を作成し、その中に複数の Canvas を開くことが可能 Canvas Thread Omni エージェントに聞くと ⾒るべきビューを出してくれる © 2026 Classmethod, Inc.
67. CloudWatch Omni • 開発者と Omni エージェントの両⽅が触れるマークダウンも使える © 2026 Classmethod, Inc. 67
68. CloudWatch Omni • DevOps Agent と連携した調査も可能 © 2026 Classmethod, Inc. 68
69. CloudWatch Omni • AI エージェントの開発向けの機能が追加されている • 障害やパフォーマンスだけで無く、AI エージェントの回答の質まで踏み込んで確認可能 ◦ Bedrock Evaluations が CloudWatch に取り込まれたイメージ © 2026 Classmethod, Inc. 69
70. CloudWatch Omni 70 • 専⽤の VS Code 拡張を利⽤して、ローカル環境と CloudWatch Omni を連携させた開発が可能 • CloudWatch Omni の Web コンソールで発⾒した、問題のある回答データをローカル端末に連 携し、システムプロンプトやモデルなどを細かく調整しながら開発することが可能 Tutorial: Fix a production quality regression © 2026 Classmethod, Inc.
71. CloudWatch Omni 71 • CloudWatch Omni の Web コンソールで発⾒した、問題のある回答データをローカル端末に連 携し、システムプロンプトやモデルなどを細かく調整しながら開発することが可能 ⾃由に変えられる データセットを選択 回答の変化 を表⽰ © 2026 Classmethod, Inc.
72. まとめ 72
73. まとめ 73 • CloudWatch は進化し続けています • とても良いなと思う所 ◦ ユーザー体験/セットアップがどんどん良くなっている ▪ CloudWatch Application Signals や CloudWatch Omni は是⾮触ってみて欲しいです ◦ OpenTelemetry や PromQL など、業界標準に追随している ◦ 追加課⾦無しで多くの新機能が使えるようになっており、機能が増えたことによる課⾦構造 の複雑化が抑えられている ◦ マルチクラウド対応してきている ▪ ⼀部サーバーのみ Azure/Google Cloud に存在するケースで便利 ◦ DevOps エージェントとの連携が進んでいる ◦ CloudWatch Omni で専⽤コンソールが使えるようになった ◦ CloudWatch Omni で AI エージェント開発向けの機能も追加 © 2026 Classmethod, Inc.
74. まとめ 74 • もっと進化して欲しい所 ◦ CloudWatch Omni の中で Database Insights/Container Insights をみたい ◦ ログ取り込み料⾦を抑えるために Fluent Bit が必要でサイドカーが増える ▪ どちらかといえば、OpenTelemetry ログの成熟度次第かも ◦ ドリルダウンしてテレメトリを深堀っていくには、ビューの柔軟性が⾜りない ▪ CloudWatch Omni が出たり、CloudWatch の上に Grafana を被せたりといった⼿段は 増えている ◦ ログを絞り込む際、反映させるには「クエリの実⾏」が必要 ▪ Datadog のようにファセットを選択したら即ビューに反映といった操作感にはならない • とはいえ、クエリ単位の課⾦なこともあり、しょうがない？ ◦ 過去の障害情報を良い感じに貯めたい ▪ AWS のマネージドサービスだけだとインシデント管理機能が弱い • OpsCenter に投資されると嬉しい ▪ DevOps Agent にJira や PagerDuty を連携するのが、現時点の最適解 ◦ PromQL と CloudWatch 独⾃記法の両⽅を使えるようににならないといけない © 2026 Classmethod, Inc.