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

by 枡川健太郎

Embed

Start on current slide

Slide 1

Slide 1 text

ここ 3 年くらいの CloudWatch アップデートについて丸っと解説しますクラウド事業本部ソリューションアーキテクト枡川健太郎

Slide 2

Slide 2 text

Slide 3

Slide 3 text

最近の CloudWatch について 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

CloudWatch 公式ドキュメントのトップページを眺めてみる 5 ここ数年は「オブザーバビリティ」という⾔葉を使うことが増えた。 > Amazon CloudWatch monitors your Amazon Web Services (AWS) resources and the applications you run on AWS in real time, and oﬀers 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.

Slide 6

Slide 6 text

オブザーバビリティは重要になってきている ● オブザーバビリティとは「システムの状態を把握できる能⼒」 ● AI を使った運⽤はオブザーバビリティの上に成り⽴つ。 ○ AI は⼗分なコンテキストが無いと、質の⾼い判断を⾏うことができない。 ○ とはいえ、本番サーバーの中で AI エージェントを好き勝⼿動かすのは怖い。 ● 「システムの状態を把握するために⼗分な情報」が CloudWatch にまとまっていると望ましい。 © 2026 Classmethod, Inc. 6

Slide 7

Slide 7 text

CloudWatch の進化をキャッチアップしよう重要度は上がってますが、どんどん概念が増えてキャッチアップが⼤変なので、本⽇丸っとおさらいしましょう！！ ● CloudWatch Application Signals ● CloudWatch OpenTelemetry 対応 ● アラーム周りのアップデート (PromQL ベース、ログベース、リソースタグを活⽤したアラート) ● CloudWatch ログ統合データストア ● Log Analytics ● Logs Intelligent-Tiering ● CloudWatch Omni © 2026 Classmethod, Inc. 7

Slide 8

Slide 8 text

CloudWatch Application Signals 8

Slide 9

Slide 9 text

CloudWatch Application Signals ● オブザーバビリティや SRE などの考え⽅を、AWS 上で⼿間なく実践できるようにした ○ サービスとオペレーション (パス + メソッド) を中⼼にしたプリセットのダッシュボード ○ 作り込み無しで SLI/SLO 管理を可能にした ○ OpenTelemetry のゼロコード計装を活⽤して簡単にセットアップできるようにした © 2026 Classmethod, Inc. 9

Slide 10

Slide 10 text

CloudWatch Application Signals で SLI/SLO を定めよう 10 ● SLO を定めることで、アプリケーションチームやビジネスチームを含めて正常な状態の定義が揃う ○ 可⽤性 100 % を⽬指すのは厳しい、SLO を元に優先順位を決められる ● セットアップが済んだ段階で、オペレーションごとのレイテンシーやエラーレートが確認可能 ○ オペレーション単位で信頼性を定義できる © 2026 Classmethod, Inc.

Slide 11

Slide 11 text

Slide 12

Slide 12 text

ゼロコード計装前提で設計されている ● ● ● アプリケーションコードを書き換えずに 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

Slide 13

Slide 13 text

CloudWatch OpenTelemetry 対応 13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

カスタムメトリクスは OpenTelemetry を積極的に使って良い ● ⾼カーディナリティ (ラベルの組み合わせが多い) の場合はコストメリットが⼤きい ○ ラベルの種類が増えると従来のカスタムメトリクスは料⾦が嵩む ○ ⼀⽅で、ある程度積極的にラベルをつけた⽅が便利 ■ 他テレメトリとの相関付けに使える ● エラーが発⽣した時のメトリクス情報を抜き出す等 ■ アラーム設定時もラベルで指定できると便利 ● Datadog や Grafana Cloud など、オブザーバビリティ系の SaaS を利⽤したくなった際に移⾏しやすい ● CloudWatch エージェントの設定を変えるだけで OTLP エンドポイントを使える ○ 細かいことを考えなくてもテレメトリごとに振り分けてくれる © 2026 Classmethod, Inc. Send OpenTelemetry data using the agent conﬁguration ﬁle 20

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

アラーム関連のアップデート 22

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

リソースタグを活⽤したアラート 26 ● 旧来の SQL でも 2025 年 9 ⽉にタグベースでアラームを設定することができるようになっている個別に状態を判定可能 [アップデート] Amazon CloudWatchがリソースのタグを⽤いてメトリクスモニタリングができるようになり、リソースの追加や変更に⾃動的に適応する動的なCloudWatchアラームを設定可能になりました © 2026 Classmethod, Inc.

Slide 27

Slide 27 text

CloudWatchログ統合データストア 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

CloudWatchログ統合データストアのポイント ● CloudWatchログでログ基盤を作りやすくなる、複数の機能が追加された ○ 厳密には re:Invent 前から続いたアップデートの集合体 ● 各アップデートは単体利⽤も可能、⼤規模なログ基盤を作らなくても恩恵を受けられる ● 追加料⾦無しで利⽤できるため、CloudWatchログを利⽤しているなら活⽤しないと損 ○ もちろん、ログの取り込み料⾦、保存料⾦、クエリ料⾦は従来通り発⽣する ○ 各機能を上⼿く活⽤すればコストカットできる可能性もあり © 2026 Classmethod, Inc. 30

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Log Analytics 55

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Logs Intelligent-Tiering 59

Slide 60

Slide 60 text

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.

Slide 61

Slide 61 text

CloudWatch Omni 61

Slide 62

Slide 62 text

Slide 63

Slide 63 text

CloudWatch Omni 63 ● 参照するデータ⾃体は CloudWatch と⼀緒 ○ 追加の保存、取り込み料⾦無しで併⽤可能 ● Organizations 連携することで IAM Identity Center グループを利⽤して権限付与が可能 ● アカウントとリージョンの組み合わせごとにスペースが作成され、権限付与の単位となる © 2026 Classmethod, Inc. CloudWatch Omni

Slide 64

Slide 64 text

CloudWatch Omni 64 ● 権限モデルが完全にこれまでの CloudWatch (AWS の 1 サービス扱い) とは別 ○ AWS のアプリケーションを触る権限を与えずに調査するといったことをやりやすい ● IAM Identity Center のグループを指定して権限付与できる IAM Identity Center グループを指定プリセットとして下記が存在 ● Viewer (読み取り) ● Editor (編集) ● admin (権限管理) © 2026 Classmethod, Inc.

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

CloudWatch Omni 70 ● 専⽤の VS Code 拡張を利⽤して、ローカル環境と CloudWatch Omni を連携させた開発が可能 ● CloudWatch Omni の Web コンソールで発⾒した、問題のある回答データをローカル端末に連携し、システムプロンプトやモデルなどを細かく調整しながら開発することが可能 Tutorial: Fix a production quality regression © 2026 Classmethod, Inc.

Slide 71

Slide 71 text

Slide 72

Slide 72 text

まとめ 72

Slide 73

Slide 73 text

まとめ 73 ● CloudWatch は進化し続けています ● とても良いなと思う所 ○ ユーザー体験/セットアップがどんどん良くなっている ■ CloudWatch Application Signals や CloudWatch Omni は是⾮触ってみて欲しいです ○ OpenTelemetry や PromQL など、業界標準に追随している ○ 追加課⾦無しで多くの新機能が使えるようになっており、機能が増えたことによる課⾦構造の複雑化が抑えられている ○ マルチクラウド対応してきている ■ ⼀部サーバーのみ Azure/Google Cloud に存在するケースで便利 ○ DevOps エージェントとの連携が進んでいる ○ CloudWatch Omni で専⽤コンソールが使えるようになった ○ CloudWatch Omni で AI エージェント開発向けの機能も追加 © 2026 Classmethod, Inc.

Slide 74

Slide 74 text

まとめ 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.

Slide 75

Slide 75 text

No content