今月の AWS オブザーバビリティ: 2026 年 8 月と 9 月

はじめに

8 月と 9 月は、Amazon CloudWatch Omni が一般提供 (GA) となりました。Omni は AI ファーストかつアプリケーション中心のオブザーバビリティを提供し、AWS アカウント、リージョン、Azure のワークロードをまたいだテレメトリを 1 つのスペースに集約します。アラームにはウォームアップ期間 (アラーム作成後、一定時間だけ評価を遅延させる機能) とウォールクロック評価ウィンドウ (毎時 0 分や深夜 0 時といった暦の境界に評価を揃える機能) が追加され、起動時のデータの欠落やスライディングウィンドウ (時間の経過とともに対象範囲がずれていく従来の評価ウィンドウ) 特有のエッジケースから生じるノイズを削減できるようになりました。データベースのオブザーバビリティは Amazon EC2 上に自前で構築・運用する自己管理型 PostgreSQL と Amazon Aurora DSQL にも対応し、デプロイ形態を問わずデータベースフリート全体を 1 つのコンソールでモニタリングできます。AWS CloudTrail には AI による調査機能が加わり、アカウント内で誰が何をしたのかを Amazon Q Console にふだんの言葉で質問できるようになりました。ログ収集は対応範囲を拡大し、journald のネイティブサポート、GeoIP・Amazon RDS・XML 用の新しいパイプラインプロセッサ、一元化されたログへのタグの伝播に対応しました。そして AWS HealthOmics から Amazon WorkSpaces、Amazon MSK まで、ポートフォリオ全体のサービスがより充実したテレメトリを CloudWatch に発行し始めており、その多くは OpenTelemetry を使って構築されています。

それでは、Amazon CloudWatch と AWS DevOps Agent の最新情報をご紹介します。

これらのローンチのライブデモをご覧になりたい方は、2026 年 10 月 13 日 11:00〜12:00 (ET、日本時間 10 月 14 日 0:00〜1:00) 開催の「I didn’t know Amazon CloudWatch could do that!」ウェビナー (英語開催) にご登録ください。過去のまとめを見逃した方は、「今月の AWS オブザーバビリティ」の 2026 年 1 月〜5 月、2026 年 6 月、2026 年 7 月 のブログをご覧ください。

Amazon CloudWatch Omni のご紹介: エージェントとアプリケーションのための AI ファーストなオブザーバビリティ

この期間で最も大きなローンチは、一般提供が開始された Amazon CloudWatch Omni です。Omni は、チームとそのチームが運用するアプリケーションを軸に構成し直し、Amazon CloudWatch を AI 駆動のオブザーバビリティへと進化させたものです。中央アカウントにスペースを作成すると、AWS アカウントやリージョンをまたいだテレメトリに加えて、Azure のワークロードを含む他のクラウドのテレメトリも確認できます。Omni はサービスを自動的に検出し、依存関係をマッピングし、ゴールデンメトリクスを提示することで、運用ワークフローを効率化します。

図 1: アプリケーションと AI エージェントが 1 つのビューを共有します。CloudWatch Omni はインフラストラクチャとエージェントのオブザーバビリティを単一の体験に統合し、IDE または Omni の Web UI 上でエンタープライズ SSO とともに提供します。

Omni の特徴は、テレメトリとの関わり方そのものです。自然言語でチャットすれば、Omni が関連するシグナルを見つけ出し、動的なビューを構築し、AWS DevOps Agent を活用して根本原因の特定を支援します。自分で操作したい場合は、重要なシグナルをクリックしながら辿っていくこともできます。パフォーマンスが劣化しているアプリケーションを調査する場合でも、トレースや評価を深掘りする場合でも同様です。

Omni は、LangGraph、CrewAI、OpenAI Agents SDK、Vercel AI SDK、Strands といったフレームワークにわたって、評価駆動の開発ワークフローによるエージェントのオブザーバビリティを提供します。プロンプト、モデル呼び出し、ツール呼び出しのそれぞれについて品質を評価し、実験を実行できます。VS Code、Cursor、Kiro 用の CloudWatch Omni 拡張機能は無料で利用でき、ローカル環境でのエージェントの計装、デバッグ、評価が可能です。

CloudWatch Omni について詳しくは、以下のウェビナーをご覧ください。10 月 7 日 14:00〜15:00 ET (GMT-4)、日本時間 10 月 8 日 3:00〜4:00、10 月 7 日 9:00〜10:00 シンガポール時間 (GMT+8)、日本時間 10 月 7 日 10:00〜11:00、10 月 8 日 14:30〜15:30 BST (GMT+1)、日本時間 10 月 8 日 22:30〜23:30。

よりスマートなアラームの構築: ノイズの削減と整合性の向上

今回のアラーム関連のローンチで最も明確なテーマは、アラームが「いつ、どのように評価するか」をより賢く判断できるようにすることです。

Amazon CloudWatch で、メトリクスアラームとログアラームにウォームアップ期間を設定できるようになりました。アラームを作成した後、設定した時間だけ評価を遅延させる機能です。これにより、新しいリソースやサービスが起動してメトリクスの発行を開始するまでの間に発生する、データの欠落に起因するノイズを削減できます。たとえば、CI/CD パイプラインで新しいマイクロサービスとそのアラームを同時にプロビジョニングするチームは、ウォームアップ期間を設定しておくことで、サービスの起動中にアラームがオンコールエンジニアを呼び出してしまうことを防げます。モードは 2 つあり、指定した固定時間だけ待機するモードと、メトリクスのデータが評価ウィンドウを満たした時点で CloudWatch が自動的に評価を開始するモードがあります。ウォームアップ期間は 1〜2,880 分の範囲で設定でき、標準の CloudWatch アラーム料金以外の追加料金はかかりません。

CloudWatch アラームは、ウォールクロック評価ウィンドウもサポートするようになりました。毎時 0 分、深夜 0 時、週の開始時点といった固定のカレンダー境界にアラームの評価を揃えられます。これは既存のスライディングウィンドウの動作を補完するもので、定期実行のワークロードやビジネスサイクルに沿ったワークロードを想定した機能です。スライディングウィンドウを使った日次バックアップのアラームは、連続するバックアップの間隔が 24 時間をわずかに超えただけで、暦日ごとにはバックアップが成功しているにもかかわらず誤って状態が変化することがあります。ウォールクロックウィンドウは暦日ごとに独立して評価するため、この問題が解消されます。タイムゾーンを指定できるため日次アラームを自社の営業日に合わせられ、夏時間への移行も自動的に処理されます。

データベースオブザーバビリティの拡大: 対応エンジンとデプロイ形態の拡充

Database Insights は対応エンジンを拡大し続けており、この 2 か月で 2 つの重要なマイルストーンに到達しました。

Amazon CloudWatch Database Insights が、Amazon EC2 上で稼働する自己管理型 PostgreSQL データベースをサポートしました。CloudWatch エージェントを使って自己管理型インスタンスからヘルスとパフォーマンスのデータを収集すると、それらが Database Insights のフリートビューに表示され、データベース負荷、待機イベントの分析、クエリレベルの統計、ホストメトリクスといったライブのパフォーマンスデータを確認できます。AWS マネージドのデータベースですでに使っているものと同じコンソールとワークフローでモニタリングとトラブルシューティングができるため、PostgreSQL フリート全体を 1 か所でモニタリングできます。

Amazon Aurora DSQL に、ステートメント単位・クラスターレベルのパフォーマンスモニタリングを提供する新しい Database Insights メトリクスが追加されました。アクティブなすべてのクラスターセッションについて、サンプリングされた待機状態と正規化された SQL ステートメントを取得するため、パフォーマンスの問題を診断し、最もリソースを消費しているクエリを特定できます。このメトリクスは Database Insights、PromQL、および Aurora DSQL のシステム診断 AI スキルからクエリでき、デフォルトで追加費用なしに利用できます。

AI による自然言語での調査

AWS CloudTrail が Amazon Q Console と統合され、自然言語で AWS アカウントのアクティビティを調査できるようになりました。Amazon Q Console に CloudTrail の設定について質問したり、セキュリティ調査のために記録済みのイベントをクエリしたり、クエリの記述やログファイルの手動でのパースをせずに運用上の問題をトラブルシューティングしたりできます。

この統合により、トレイルが適切に設定されているかの確認、ログ記録範囲の抜け漏れの特定、追跡しているデータイベントソースの確認が可能になります。セキュリティ上の懸念については、特定の IAM ロールに誰がアクセスしたか、VPC 設定にどのような変更が加えられたか、過去 1 週間に不正なアクセス試行がなかったかといった質問ができます。運用のトラブルシューティングでは、特定のリソースを作成または削除したのは誰か、どの API 呼び出しがエラーを発生させているか、特定の IP アドレスからのアクティビティの追跡、請求額が急増した理由の特定などを Q Console に尋ねられます。Q Console はお客様に代わってトレイル、関連する CloudWatch ロググループ、イベントデータストアをクエリし、一般的なドキュメントの内容ではなく実際のアカウントのアクティビティに基づいた回答を提供します。

大規模なログの収集とエンリッチメント

クエリやダッシュボードに届く前の段階で、収集できる対象とエンリッチできる方法を拡張するローンチが複数ありました。

Amazon CloudWatch エージェントが、Linux インスタンス上の systemd journal (journald) ログをネイティブに収集できるようになりました。ログをいったんディスク上のファイルに書き出す必要はありません。Amazon Linux 2023 を含む多くの最新の Linux ディストリビューションは systemd journal を主要なロギングシステムとして採用しており、デフォルトでは従来のテキストログファイルを出力しません。エージェントは journald のエントリをネイティブに読み取り、systemd ユニット、優先度、プロセス情報といった journald が取得する構造化メタデータを保持します。systemd ユニット、ジャーナルの優先度レベル、ジャーナルフィールドの一致条件でログエントリをフィルタリングしたり、発行前に正規表現フィルターを適用したりできるため、ノイズを削減し、ログの量とコストをコントロールできます。

Amazon CloudWatch Pipelines に、取り込み時にログデータをパースおよびエンリッチする 3 つの新しいプロセッサが追加されました。Amazon RDS プロセッサは、コンプライアンスレポート向けに Aurora の監査ログとエラーログを構造化フィールドにパースします。XML パーサーは、XML 文字列を含むフィールドを JSON に変換します。GeoIP プロセッサは、セキュリティ分析のために任意の IP アドレスフィールドに都市、国、座標といった地理的コンテキストを付加します。これらのプロセッサは個別にも、1 つのパイプライン内で組み合わせても利用でき、追加費用はかかりません。

CloudWatch Centralization が、一元化ルールによって作成された送信先ロググループに、ソースアカウントのロググループのタグをコピーし、同期を維持するようになりました。プラットフォームチームは、一元化されたロググループで Application タグや CostCenter タグを保持しておくことで、それらのタグを使って IAM 条件でアクセス範囲を限定したり、AWS Cost Explorer でチームごとに一元化されたログのコストをレポートしたりできます。

Transit Gateway ピアリングをまたぐネットワークヘルスのモニタリング

CloudWatch Network Monitoring が、AWS Transit Gateway のリージョン間ピアリング接続を経由するパスまでネットワークヘルスインジケーターを拡張しました。これまで合成モニターがカバーしていたのは、AWS Direct Connect 経由で接続するパスのみでした。今回から、Transit Gateway のリージョン間ピアリングを経由してピアリング先リージョンの送信先に到達するパスについて、ピアリング接続までの AWS ネットワークパスのヘルス状態がインジケーターに反映されます。これにより、ネットワーク運用者やアプリケーション開発者が、これらのパスで発生した劣化の原因を切り分けるのに費やす時間を短縮できます。

AWS サービスのオブザーバビリティ統合の深化

この 2 か月で、ポートフォリオ全体の AWS サービスが CloudWatch との統合を深めました。

AWS HealthOmics が、14 個のリアルタイムの実行メトリクスを CloudWatch に発行するようになりました。CPU と GPU の使用率、メモリ使用量、ファイルシステムの使用量と I/O、ネットワークスループット、エフェメラルストレージをカバーします。メトリクスは CloudWatch の OpenTelemetry 標準で出力されるため、ネイティブの CloudWatch ダッシュボードやアラームに加えて、サードパーティのオブザーバビリティツールと統合することもできます。実際の使用量と割り当て済みリソースを比較することで、バイオインフォマティクスワークフローのコンピューティングとストレージを過不足のないサイズに見直せます。

Amazon WorkSpaces と Amazon WorkSpaces Applications が、いずれもパフォーマンスとセッションヘルスに関する追加のメトリクスを CloudWatch に発行するようになりました。ネットワークパフォーマンス (TCP 再送率、輻輳ウィンドウ)、コンピューティングリソースの使用率 (GPU 使用率、CPU キュー長)、ストレージメトリクス (ディスク I/O キュー長、メモリページのハードフォールト)、セッションのライフサイクルイベントをカバーします。

Amazon ECS が Amazon EC2 G6f インスタンスでの GPU の分割スケジューリングをサポートし、NVIDIA L4 Tensor Core GPU の 8 分の 1 という小さな GPU パーティション上でワークロードを実行できるようになりました。GPU メトリクスは CloudWatch Container Insights から利用でき、自動ヘルスモニタリングが GPU のハードウェア障害を検出して異常なインスタンスを置き換えることで、ワークロードへの影響を最小限に抑えます。

AWS Cloud Operations Blog の関連記事 (2026 年 8 月〜9 月)

2026 年 8 月〜9 月に AWS Cloud Operations Blog で公開された記事は以下のとおりです。

Introducing Amazon CloudWatch Omni: Observability for the AI era – Mukul Karnik

Root cause analysis with Amazon Managed Service for Prometheus and AWS DevOps Agent – Mohamed Sherif

Investigate your AWS account activity in plain language with Amazon Q – Rizwan Mohammed, Parijat Protim Bezbaruah, Samir Behara

Reduce MTTR with AI-Driven RCA Using AWS DevOps Agent and Splunk – Amandeep Singh, Aakash Tanwani

Amazon CloudWatch Logs で Application Load Balancer のログを分析する – Raviteja Sunkavalli, Siva Guruvareddiar

Multi-cloud observability with Amazon CloudWatch using bearer token auth and OpenTelemetry – Imaya Kumar Jagannathan, Stephen McCurry

Use CloudWatch syslog and log alarms to give AWS DevOps Agent on-premises visibility – Salman Ahmed

まとめ

8 月と 9 月のローンチのハイライトは、AI ワークロードとエージェントのための AI ファーストかつアプリケーション中心のオブザーバビリティソリューションである CloudWatch Omni です。アラームはウォームアップ期間とウォールクロックウィンドウによってより賢くなり、ノイズを削減しつつ現実のスケジュールに合わせられるようになりました。データベースのオブザーバビリティは、Aurora DSQL から自己管理型 PostgreSQL までフリート全体をカバーします。AI による調査機能によって、CloudTrail をふだんの言葉でクエリできるようになりました。ログ収集は journald、より大きな API Gateway の実行ログ、新しいパイプラインプロセッサへと広がりました。そしてポートフォリオ全体の AWS サービスがより充実したテレメトリを CloudWatch に発行しており、いずれも OpenTelemetry ファーストという方向性を継続しています。

これらの機能を使い始めるにあたっての要点を以下に挙げます。

• CloudWatch Omni のスペースを作成してチーム用に SSO を設定し、VS Code、Cursor、または Kiro 用の CloudWatch Omni 拡張機能をインストールして、ローカル環境でエージェントを計装・評価する。
• 新しいアラームにウォームアップ期間を設定して起動時のノイズを解消し、定期実行のワークロードやビジネスサイクルに沿ったワークロードにはウォールクロック評価ウィンドウを追加する。
• Amazon EC2 上で稼働する自己管理型 PostgreSQL インスタンスで Database Insights を有効化する。
• CloudTrail の設定やアカウントのアクティビティについて、Amazon Q Console に質問する。
• CloudWatch エージェントの設定に journald のセクションを追加し、CloudWatch Pipelines に GeoIP、Amazon RDS、XML のプロセッサを追加する。

最近のローンチの一覧については、Amazon CloudWatch で絞り込んだ AWS What’s New ページをご覧ください。

さらに詳しく知りたい方へ

2026 年 10 月 13 日 11:00〜12:00 (ET、日本時間 10 月 14 日 0:00〜1:00) 開催の「I Didn’t Know Amazon CloudWatch Could Do That!」ウェビナー (英語開催) にご参加ください。これらの新機能の実際の動作をご覧いただき、トラブルシューティングにお役立てください。

著者について

本ブログは 2026 年 9 月 25 日に公開された This Month in AWS Observability: August – September 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。