CloudWatchオブザーバビリティソリューションとは？
CloudWatchのおさらい
まず、CloudWatchオブザーバビリティソリューションを理解する前に、CloudWatch自体について簡単におさらいしましょう。
Amazon CloudWatch（以下、CloudWatch）は、AWSリソースとアプリケーションをリアルタイムで監視するサービスです。主な機能は以下の通りです。
メトリクス（指標）の収集
• CPU使用率、メモリ使用量、ディスク容量など、システムの状態を数値で表現
• EC2、RDS、Lambdaなど多くのAWSサービスが自動的にメトリクスを送信
ダッシュボード
• 収集したメトリクスをグラフやチャートで視覚化
• 複数のリソースの状態を一画面で確認可能
アラーム
• 設定した閾値を超えた際に通知やアクションを実行
• 例：CPU使用率が80%を超えたらメール通知
ログ管理
• アプリケーションやシステムのログを収集・保存・分析
その他CloudWatchの詳細については、弊社で関連記事がありますのでご確認ください。
以下の記事は本コラムの内容と非常に親和性が高いので、ぜひご覧ください。
CloudWatchオブザーバビリティソリューション
CloudWatchオブザーバビリティソリューションは、「システムの見える化」を実現する機能 です。
2024年11月にCloudWatchの新機能として登場しました。
従来の監視では「何が起きているか」を知ることに重点を置いていますが、
オブザーバビリティでは「なぜ起こっているのか」を理解することに重点を置いています。
本機能はそれをソリューションとして提供しており、コンソールでは利用者側が行うべき作業をステップごとに説明してくれてます。（後述します）
またCloudwatchダッシュボードをAWS側で用意しており以下の特徴があります。
• 各ワークロードに最適化されたダッシュボードが自動作成
• 重要なメトリクスが見やすくレイアウトされている
なおCloudWatchエージェントのインストールや、CloudWatchエージェントの設定ファイル（どんなメトリクスを収集するか）、メトリクスに対するアラート設定は利用者側の作業になります。
オブザーバビリティソリューションが対応しているサービスの代表的なものとして以下があります：
• JVMワークロード：Java アプリケーションの監視
• NGINXワークロード：Webサーバーの監視
• Apache Tomcatワークロード：アプリケーションサーバーの監視
• EC2：EC2インスタンスの基本的な健全性監視
その他提供されているソリューションや詳細については以下の公式ドキュメントをご確認ください。
CloudWatch オブザーバビリティソリューション
使ってみた
EC2を監視してみる
今回はEC2を対象にデプロイしたいと思います。
なおEC2にCloudWatchエージェントはインストールしていない環境となります。
早速手順をご紹介します。なお弊社検証環境のため一部マスクをしております。
①オブザーバビリティソリューションを有効化する
まずCloudWatchコンソールから、[利用開始]を押下して[今すぐ始める]を押下します。
②対象サービスを選択する
オブザーバビリティソリューションで利用できるサービスの一覧が確認できます。
[EC2]を選択します。
③ダッシュボードをデプロイする
コンソールを開くと英語でEC2のオブザーバビリティソリューションの説明がされてます。
執筆時点（2025/7）では日本語未対応でした。
ざっくり要約すると以下のようになります。
■概要・メリット（画像1枚目）
・CPU、ディスク、メモリ、ネットワークなどのEC2の運用において重要なメトリクスを収集する
・それに合わせたダッシュボードやアラートを提供する
・作成するリソースでコストが発生する
■オブザーバビリティソリューションを実現するまでのステップ（画像2,3枚目）
・取得するメトリクスを確認する
・Cloudwatchエージェントの設定ファイルを構成してインストールする
・一元管理するダッシュボードを作成する
・各メトリクスに対してアラームを作成する
今回はCloudFormationでダッシュボードをデプロイします。
[In CloudFormation]を押下します。
スタック名を入力して、項目にチェックを入れて[スタックの作成]を押下します。
少し待つとCloudFormationがデプロイされます。
④ダッシュボードを確認する
デプロイしたスタックのリソースタブから作成されたダッシュボードの[物理ID]を押下します。
[EC2HealthDashboard]というダッシュボードが作成されているかと思います。
確認してみると、[CloudWatch Agent Metrics]と[AWS/EC2 Vended Metrics]の2セクションにわかれています。
これは名前の通り、CloudWatchエージェントから取得されたメトリクスか、デフォルトで取得されるメトリクスの違いです。
今回はCloudWatchエージェントをインストールしていないので[CloudWatch Agent Metrics]のほうに表示がない状態です。
EC2を追加しても自動で対象に含めてくれるので追加する手間が省けていいですね。
なおEC2のオブザーバビリティソリューションの各セクションで表示されるメトリクス（重要とされるメトリクス）は以下でした。
■CloudWatch Agent Metrics
・CPU
– cpu_usage_idle：CPUがアイドル状態の時間の割合
– cpu_usage_iowait：CPUがI/O操作の完了を待機している時間の割合
– cpu_usage_user：CPUがユーザーモードで動作している時間の割合
– cpu_usage_system：CPUがシステムモードで動作している時間の割合
・Disk
– disk_used_percent：総ディスク容量に対する使用済み容量の割合
– disk_inodes_free：ディスク上で利用可能なinodeの数
・DiskIO
– diskio_io_time：ディスクにI/Oリクエストがキューイングされていた時間
・Memory
– mem_used_percent：利用可能メモリに対する使用済みメモリの割合
・Swap
– swap_used_percent：スワップ領域の使用率
■AWS/EC2 Vended Metrics
・CPU
– CPUUtilization：ハイパーバイザーレベルでのCPU使用率
・Network
– NetworkIn：インスタンスが受信したバイト数
– NetworkOut：インスタンスが送信したバイト数
– NetworkPacketsIn：インスタンスが受信したパケット数
– NetworkPacketsOut：インスタンスが送信したパケット数
メリット
以下のようなメリットが期待できると思います。
1.システムの見える化を実現
ダッシュボードではサービスにおいて重要なメトリクスが取得および確認することができます。
「何がどんな原因で起こったか」を追究することが可能です。
また推奨アラーム設定を行えば、重要でないアラートによるノイズが減り、本当に対応が必要な問題に集中できます。
2. 学習コストの削減
初学者でも完成されたダッシュボードを見ることで「どのような監視が重要なのか」を学ぶことができます。これにより、監視に関する知識を実践的に身につけることができます。また監視すべきポイントをAWSが教えてくれるので重要なメトリクスを見落とすリスクが大幅に減少します。
3. カスタマイズの柔軟性
基本設定をベースに、必要に応じて独自の要件に合わせてカスタマイズすることも可能です。ゼロから作るよりも効率的に、自社に最適な監視環境を構築できます。
まとめ
以上、CloudWatchオブザーバビリティソリューションをご紹介しました。
AWS初学者にとって監視環境構築の大きな障壁を取り除いてくれる素晴らしい機能です。
個人的にはますはオブザーバビリティソリューションを使ってダッシュボードを作成するところから始めるのが良いと思いました。
重要なメトリクスを知れますし、監視を始めるには持って来いの機能だと思います。
場合によってはCloudwatchエージェントの設定などの一部利用者側の作業が必要なものの、AWSにおける監視環境を体系的に構築できることは非常に良いと感じます。
AWSサービスでもステップバイステップで教えてくれるものは中々ないので、運用を始めたばかりの方でも手順に沿って設定できるはうれしい点です。
一から監視環境を構築するより短時間でかつベストプラクティスに沿った形で環境構築できるので、本来注力すべきアプリケーション開発や運用改善により多くの時間を割くことができます。
まだ使ったことがない方は、ぜひ体験してみてください。
