AWS 認定資格 ラボ
SAA（Solutions Architect Associate）攻略 ・

SAA CloudWatch / X-Ray 設計パターン｜監視・トレーシング4選と要件別の選択基準

AWS SAA-C03 でモニタリングは「どのメトリクスが自動収集されるか」「X-Ray はいつ使うか」が頻出。CloudWatch メトリクス（デフォルト vs CloudWatch Agent）・Alarms・Logs Insights・Container Insights・X-Ray の5機能を設計パターン4選に整理。EC2 のメモリ使用率はエージェント必須、分散トレーシングは X-Ray、ログ分析は Logs Insights という要件キーワード即断マップを完備。

#AWS #SAA #SAA-C03 #Solutions Architect #CloudWatch #X-Ray #監視 #モニタリング #分散トレーシング #試験対策 #AWS認定資格

CloudWatch の問題で「EC2 のメモリ使用率が監視できない」は試験の定番ひっかけだ。 AWS SAA-C03 でモニタリングは、配点26%の「高パフォーマンスなアーキテクチャ」と「セキュアなアーキテクチャ」にまたがって出題される。攻略の核心は、「どのメトリクスが自動収集されるか（デフォルト vs CloudWatch Agent）」「ログはどのツールで分析するか（Logs Insights / Subscription Filter）」「分散トレーシングが必要かどうか（X-Ray）」の3軸で設計を決めることだ。本記事では、SAA-C03 頻出の監視設計パターン4選を要件キーワードから即断できる粒度で解説する。読み終えればモニタリング問題をパターンマッチで解けるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

📑 目次

  1. 結論：監視設計は「収集 × 分析 × トレーシング」の3軸で決まる
  2. CloudWatch の基本構造（Metrics / Alarms / Logs / Dashboards）
  3. デフォルトメトリクス vs CloudWatch Agent（カスタムメトリクス）
  4. CloudWatch Alarms の設計（SNS・Auto Scaling・Composite Alarm）
  5. CloudWatch Logs の設計（Log Groups・Subscription Filter・Logs Insights）
  6. AWS X-Ray の基本構造（トレース・セグメント・サービスマップ）
  7. パターン1：基本アラーム監視（メトリクス→Alarm→SNS→通知/修復）
  8. パターン2：ログ集約・リアルタイム分析（Logs Insights / Subscription Filter）
  9. パターン3：分散トレーシング（X-Ray）
  10. パターン4：コンテナ監視（Container Insights）
  11. 要件キーワード早見表
  12. 頻出ひっかけパターンと正しい打ち手
  13. 次のアクション チェックリスト
  14. 関連記事
  15. 関連サイト

1. 結論：監視設計は「収集 × 分析 × トレーシング」の3軸で決まる

SAA-C03 のモニタリング問題を最短で解く骨格は、「どのデータをどのツールで収集し、どう分析・追跡するか」を3軸で独立して判断することだ。

軸問いかけ判断のキーワード
収集デフォルトで取れるか？カスタムが必要か？「メモリ」「ディスク」→ CloudWatch Agent 必須
分析ログを検索・可視化するか？閾値で通知するか？「ログクエリ」→ Logs Insights、「閾値超過で通知」→ Alarms + SNS
トレーシングマイクロサービス間の遅延・ボトルネックを追うか？「分散トレース」「ボトルネック特定」→ X-Ray

3軸を整理するだけで、SAA のモニタリング問題は4パターンに絞れる。「監視 = CloudWatch だけ」という思い込みを捨て、X-Ray・Container Insights・Logs Insights を用途別に使い分けることが正解への近道だ。

2. CloudWatch の基本構造（Metrics / Alarms / Logs / Dashboards）

Amazon CloudWatch は AWS の統合モニタリングサービスだ。4つの主要コンポーネントで構成される。

  • Metrics（メトリクス）：EC2・RDS・Lambda など AWS サービスが自動送信する時系列データ。名前空間（Namespace）・ディメンション（Dimension）で分類される。デフォルト収集間隔は1分（詳細モニタリングで1秒〜）。
  • Alarms（アラーム）：メトリクスが設定した閾値を超えた際にアクションを実行。状態は OK / ALARM / INSUFFICIENT_DATA の3種。アクションとして SNS 通知・EC2 アクション・Auto Scaling ポリシー実行が可能。
  • Logs（ログ）：アプリケーション・AWS サービスのログを集約・保存・検索。Log Group → Log Stream の階層構造。保持期間は1日〜永久まで設定可能。
  • Dashboards（ダッシュボード）：複数メトリクスを1画面に集約。クロスリージョン・クロスアカウントの統合ビューも構築可能。

3. デフォルトメトリクス vs CloudWatch Agent（カスタムメトリクス）

SAA で最も頻出なのが**「何がデフォルトで収集され、何はエージェントが必要か」**の問題だ。

EC2 デフォルトメトリクス（エージェント不要）

メトリクス収集方法
CPUUtilization（CPU使用率）✅ デフォルト自動収集
NetworkIn / NetworkOut（ネットワーク）✅ デフォルト自動収集
DiskReadOps / DiskWriteOps（I/O 回数）✅ デフォルト自動収集
StatusCheckFailed（ステータスチェック）✅ デフォルト自動収集
MemoryUtilization（メモリ使用率）❌ エージェント必須
DiskSpaceUtilization（ディスク使用率）❌ エージェント必須

CloudWatch Agent の役割

CloudWatch Agent（旧 CloudWatch Monitoring Scripts）は EC2 にインストールするソフトウェアで、以下を実現する。

  • カスタムメトリクスの送信：メモリ・ディスク・プロセス数などをカスタム名前空間（CWAgent）に送信
  • ログの収集と転送：アプリログ・システムログを CloudWatch Logs に送信
  • 収集間隔の細粒度制御：デフォルト1分を秒単位まで細かく設定可能
  • オンプレミス対応：EC2 以外の物理サーバー・VM にもインストール可能

4. CloudWatch Alarms の設計（SNS・Auto Scaling・Composite Alarm）

CloudWatch Alarms はメトリクスの閾値監視と自動アクションの核心だ。

アラームのアクション種別

アクションユースケース
SNS 通知Eメール通知・SMS・Lambda 呼び出しの起点
EC2 アクション停止・終了・再起動・リカバリ（インスタンス障害時）
Auto Scaling アクションスケールアウト（インスタンス追加）/スケールイン（削減）のトリガー
Systems ManagerAutomation ランブックの実行（自動修復）

Composite Alarm（複合アラーム）

Composite Alarm は複数のアラームを AND / OR 条件で組み合わせる機能だ。

例：
  Composite Alarm = CPU_High (ALARM) AND MemoryHigh (ALARM)
  → 両方が ALARM 状態のときだけ SNS 通知を発火
  → どちらか一方だけでは通知しない（誤検知を減らす）

5. CloudWatch Logs の設計（Log Groups・Subscription Filter・Logs Insights）

CloudWatch Logs はログデータの集約・保存・分析基盤だ。

基本構造

CloudWatch Logs
└── Log Group（アプリ・サービスごとに作成）
    └── Log Stream（EC2 インスタンス1台ごと / タスクごと）
        └── Log Events（タイムスタンプ付きログレコード）

Metric Filter（ログからメトリクスを作成）

Metric Filter はログのテキストパターンに一致するイベント数をカウントしてメトリクス化する機能だ。

例：Log Group のログに "ERROR" が出るたびカウント
  → "ErrorCount" メトリクスとして記録
  → CloudWatch Alarm で 5分間に10件超えたら SNS 通知

Subscription Filter（リアルタイム転送）

Subscription Filter はログをリアルタイムで別サービスに転送する機能だ。

転送先ユースケース
Lambdaリアルタイムログ処理・Slack 通知・エラー自動修復
Kinesis Data FirehoseS3 へのアーカイブ・Redshift / OpenSearch へのストリーミング
Kinesis Data Streams複数コンシューマーへのファンアウト処理
OpenSearch Service全文検索・Kibana ダッシュボードでの可視化

CloudWatch Logs Insights

Logs Insights はログデータに対するインタラクティブなクエリ分析サービスだ。SQL ライクな専用クエリ言語を使い、数十億件のログを数秒〜数分で検索できる。

例クエリ（Lambda のエラーを直近1時間で集計）：
  fields @timestamp, @message, @requestId
  | filter @message like /ERROR/
  | stats count() as errorCount by bin(5m)
  | sort errorCount desc

6. AWS X-Ray の基本構造（トレース・セグメント・サービスマップ）

AWS X-Ray は分散アプリケーションのリクエストをエンドツーエンドでトレーシングするサービスだ。マイクロサービス間の遅延・エラー・ボトルネックを可視化する。

主要概念

  • Trace（トレース）：1つのリクエストが複数サービスを通過する全体の記録。一意の Trace ID で識別。
  • Segment（セグメント）：各サービス（Lambda 関数・EC2 アプリ・RDS など）が記録する処理の単位。
  • Subsegment（サブセグメント）：セグメント内の処理の詳細（SQL クエリ・外部 HTTP 呼び出し・カスタム処理ブロック）。
  • Annotation（アノテーション）：インデックス化され検索・フィルタに使えるキーバリュータグ（例：userId・orderId）。
  • Metadata（メタデータ）：インデックス化されない任意のデータ（デバッグ情報など）。
  • Service Map（サービスマップ）：トレースデータを元に生成される依存関係グラフ。遅延・エラー率が一目でわかる。

X-Ray デーモン

EC2・ECS・オンプレ環境では、X-Ray デーモン（サイドカープロセス）をインストールする必要がある。アプリ SDK からのトレースデータを受け取り、X-Ray サービスに送信する役割を担う。Lambda では自動統合のためデーモン不要。

7. パターン1：基本アラーム監視（メトリクス→Alarm→SNS→通知/修復）

要件のキーワード

  • 「EC2 の CPU 使用率が 80% を超えたら自動でスケールアウトしたい」
  • 「RDS のコネクション数が閾値超過したら エンジニアにメールで通知したい」
  • 「EC2 インスタンスの障害を検知して自動でリカバリしたい」

アーキテクチャ

CloudWatch Metrics（CPUUtilization など）
   ↓ 閾値超過
CloudWatch Alarm（ALARM 状態へ遷移）
   ├─ SNS トピック → Lambda → Slack 通知 / 修復スクリプト実行
   ├─ Auto Scaling ポリシー → スケールアウト（EC2 追加）
   └─ EC2 アクション → インスタンス再起動 / リカバリ

試験での正解条件

  • 「通知だけでよい」→ Alarm + SNS（メール/SMS）
  • 「検知して自動対応したい」→ Alarm + SNS → Lambda（修復処理）
  • 「スケーリングのトリガーにしたい」→ Alarm + Auto Scaling ポリシー

8. パターン2：ログ集約・リアルタイム分析（Logs Insights / Subscription Filter）

要件のキーワード

  • 「アプリの エラーログをリアルタイムで Lambda に転送して Slack 通知したい」
  • 「過去1週間の API エラーレートをクエリで分析したい」
  • 「ログを S3 に長期保存しつつ OpenSearch で全文検索したい」

アーキテクチャ（リアルタイム転送パターン）

EC2 / Lambda / ECS
   ↓ CloudWatch Agent / 自動統合
CloudWatch Logs（Log Group）
   ├─ Subscription Filter
   │   ├─ → Lambda → エラー通知・自動修復
   │   ├─ → Kinesis Firehose → S3（長期アーカイブ）
   │   └─ → OpenSearch → Kibana で可視化
   └─ Logs Insights（アドホッククエリ分析）

試験での正解条件

  • 「ログから 特定パターンを検出して即時アクション」→ Subscription Filter + Lambda
  • 「ログを S3 に全量アーカイブしたい」→ Subscription Filter + Kinesis Firehose + S3
  • 「過去ログのアドホック分析」→ CloudWatch Logs Insights

9. パターン3：分散トレーシング（X-Ray）

要件のキーワード

  • 「マイクロサービス間のレイテンシボトルネックを特定したい」
  • 「API Gateway → Lambda → DynamoDB の どのステップで遅延が発生しているか調べたい」
  • 「サービス間の依存関係グラフを可視化したい」
  • 「特定のリクエストのエラー原因をトレースで追いたい」

アーキテクチャ

ユーザーリクエスト
   ↓
API Gateway（X-Ray トレース有効化）
   ↓ Trace ID を伝播
Lambda（Active Tracing ON）
   ↓ Trace ID を伝播
DynamoDB / RDS / 外部API（セグメント記録）

      ↓ トレースデータ送信
AWS X-Ray サービス
   ├─ Service Map（依存関係グラフ・レイテンシ・エラー率表示）
   └─ Trace 詳細（各セグメント・サブセグメントの処理時間）

EC2 上のアプリでの X-Ray 利用

EC2 インスタンス
   ├─ アプリ（X-Ray SDK を組み込み）
   │     ↓ UDP 2000番ポートへ送信
   └─ X-Ray デーモン（サイドカープロセス）
         ↓ HTTPS で送信
      AWS X-Ray サービス

10. パターン4：コンテナ監視（Container Insights）

要件のキーワード

  • 「ECS / EKS のコンテナレベルのメトリクス（CPU・メモリ・ネットワーク）を監視したい」
  • 「Fargate タスクの パフォーマンス問題を特定したい」
  • 「コンテナ / Pod レベルのメトリクスを CloudWatch で一元管理したい」

Container Insights の仕組み

CloudWatch Container Insights は ECS・EKS・Kubernetes のコンテナレベルのメトリクス・ログを収集する機能だ。通常の CloudWatch Metrics よりも細粒度（コンテナ・Pod・タスクレベル）のデータを提供する。

プラットフォーム収集方法
ECS on Fargateクラスター設定で Container Insights を有効化（エージェント不要）
ECS on EC2クラスター設定で有効化 + CloudWatch Agent（コンテナ）
EKS on FargateFluent Bit アドオンを追加
EKS on EC2CloudWatch Agent（DaemonSet）を Pod としてデプロイ

Container Insights で収集されるメトリクス

  • コンテナ / タスク / サービスレベル：CPU 使用率・メモリ使用率・ネットワーク I/O
  • Fargate タスク：通常の CloudWatch では取れないタスクレベルのメモリ使用率
  • EKS / Kubernetes：Pod ステータス・Node 使用率・クラスター全体のリソース効率

11. 要件キーワード早見表

要件キーワード正解のツール
EC2 の メモリ使用率を監視CloudWatch Agent（カスタムメトリクス）
EC2 の CPU 使用率でスケールアウトCloudWatch Alarm + Auto Scaling ポリシー
ログに ERROR が出たら Slack へ通知CloudWatch Logs + Subscription Filter → Lambda
過去ログを アドホックにクエリ分析CloudWatch Logs Insights
マイクロサービス間のレイテンシ特定AWS X-Ray
依存サービスのどこでエラーが出るか追跡AWS X-Ray（サービスマップ）
Lambda の コールドスタート時間を把握AWS X-Ray（セグメント詳細）
ECS / EKS の コンテナレベルのメトリクスCloudWatch Container Insights
ログを S3 にリアルタイムアーカイブSubscription Filter → Kinesis Firehose → S3
複数アラームを AND 条件でまとめて通知Composite Alarm
インスタンス障害を検知して自動修復CloudWatch Alarm（StatusCheckFailed） → EC2 アクション
外部エンドポイントの死活監視CloudWatch Synthetics（Canary）

12. 頻出ひっかけパターンと正しい打ち手

ひっかけ1：「EC2 のメモリ使用率は CloudWatch でデフォルト監視できる」

✗ 誤り：EC2 のメモリ使用率は AWS のハイパーバイザーからは見えないため、デフォルトで収集されない。

✓ 正しい打ち手：CloudWatch Agent を EC2 にインストールし、メモリ使用率をカスタムメトリクスとして送信。その上で CloudWatch Alarm を設定する。

ひっかけ2：「X-Ray は CloudWatch の代わりにメトリクス監視に使える」

✗ 誤り：X-Ray はトレーシングツールであり、CPU 使用率・メモリ使用率などのメトリクス監視はできない。

✓ 正しい打ち手：メトリクス監視は CloudWatch Metrics + Alarms。ボトルネック特定・リクエスト追跡は X-Ray。両者は補完関係にあり、どちらか一方で全てを賄うことはできない。

ひっかけ3：「Lambda の X-Ray トレースには X-Ray デーモンのインストールが必要」

✗ 誤り：Lambda は Active Tracing を有効化するだけで自動的にトレースが収集される。デーモンのインストールは不要。

✓ 正しい打ち手：Lambda コンソールまたは SAM/CDK で Tracing: Active を設定するだけ。EC2 はデーモン必要、Lambda は不要という対比を覚えよう。

ひっかけ4：「CloudWatch Logs Insights でリアルタイムにログを転送できる」

✗ 誤り：Logs Insights は蓄積されたログへのクエリ分析ツールであり、リアルタイム転送機能ではない。

✓ 正しい打ち手：リアルタイム転送が必要なら Subscription Filter を使い、Lambda・Kinesis Firehose に転送する。

ひっかけ5：「EKS で Container Insights を有効化するだけでコンテナメトリクスが取れる」

✗ 誤り：EKS では Container Insights 有効化に加え、CloudWatch Agent（EC2 Node）または Fluent Bit（Fargate）の追加デプロイが必要。

✓ 正しい打ち手：ECS on Fargate はクラスター設定のみで OK。EKS は追加のエージェント導入が必須と覚えよう。

13. 次のアクションチェックリスト

試験直前に確認すべき要点をリスト化した。

  • EC2 のメモリ・ディスクはデフォルト収集されない → CloudWatch Agent 必須を反射的に答えられる
  • CloudWatch Alarm のアクション3種（SNS / EC2 アクション / Auto Scaling）を言える
  • Composite Alarm の AND/OR 条件で誤検知を減らすユースケースを説明できる
  • Subscription Filter の転送先（Lambda / Kinesis Firehose / Kinesis Streams / OpenSearch）を列挙できる
  • Logs Insights と Subscription Filter の役割の違いを一文で言える
  • X-Ray の Trace / Segment / Subsegment / Annotation の役割を理解している
  • Lambda の X-Ray はデーモン不要（Active Tracing 設定のみ）を覚えている
  • EC2 の X-Ray はデーモンのインストールが必要を覚えている
  • Container Insights の ECS と EKS の違い（EKS はエージェント追加が必要）を言える
  • CloudWatch Synthetics（Canary）は外部エンドポイントの死活監視に使うことを覚えている

14. 関連記事

15. 関連サイト

出典・参考情報