既存システムを継続的に改善するには、まず「今どう動いているか」を正確に把握する観測基盤が必要です。Amazon CloudWatchはAWSにおける監視の中核サービスです。

SAA レベル：基礎概念

CloudWatchの基本構成要素

要素	説明
メトリクス	CPU使用率など時系列の数値データ
ログ	アプリケーション・システムのログデータ
アラーム	メトリクスのしきい値超過を検知し通知
ダッシュボード	メトリクスを可視化するカスタム画面

SAA 試験のポイント

標準メトリクス（CPU使用率等）は自動収集されますが、メモリ使用率はデフォルトでは収集されません。CloudWatchエージェントを導入し、カスタムメトリクスとして送信する必要がある、という点がSAAで頻出します。

SAP レベル：高度な設計シナリオ

複合アラーム（Composite Alarm）

SAP 試験のポイント

単一のメトリクスだけを見たアラームは、誤検知（フォールスポジティブ）が多くなりがちです。SAPレベルでは、複数のアラームをAND/OR条件で組み合わせた複合アラームを使い、「CPU使用率が高く、かつレイテンシも増加している場合のみ本当の異常とみなす」という、ノイズを減らした高精度なアラート設計が問われます。

CloudWatch Logs Insightsによるログ分析

SAP 試験のポイント

大量のログを人手で追跡するのは非効率です。CloudWatch Logs Insightsを使うと、独自のクエリ言語でログデータを横断的に検索・集計できます。「過去1時間でエラーレスポンスを返したエンドポイントの上位10件」といった分析を、追加のログ基盤を構築せずに実現できる点が実務で重宝されます。

カスタムメトリクスによるビジネスKPIの監視

インフラのメトリクスだけでなく、注文成功率、決済エラー率といったビジネスKPIをカスタムメトリクスとして送信し、アラームの対象にすることで、インフラは正常でもビジネス上の異常（外部決済API障害等）を検知できる
Embedded Metric Format (EMF) を使うと、ログの一部として構造化されたメトリクスデータを埋め込み、追加のAPI呼び出しなしでメトリクスを生成できる

設計上の落とし穴

「インフラメトリクス（CPU、メモリ等）さえ監視していれば十分」という設計は、SAPレベルでは不十分とされることがあります。インフラが正常でも、外部APIの応答異常やビジネスロジックのエラー率上昇など、ビジネス影響に直結する異常はカスタムメトリクスでなければ検知できないという視点が問われます。

アンオマリー検出（Anomaly Detection）

CloudWatchのAnomaly Detection機能は、機械学習でメトリクスの正常範囲を学習し、通常のパターンから逸脱した場合にアラームを発報する
固定しきい値では捉えにくい季節性のあるトラフィック（週末は低い、月末は高い等）に対して有効

まとめ

SAA: CloudWatchの基本構成要素、メモリ使用率がデフォルトで収集されない点を理解する。
SAP: 複合アラームによる誤検知の削減、Logs Insightsによる横断分析、ビジネスKPIのカスタムメトリクス化ができる。

次は X-Rayによるトレーシング・可観測性設計を見ていきましょう。