# AWS オブザービリティ三兄弟：Azure Monitor ユーザーが陥る罠と趣味開発での問題切り分けメモ

はじめに：Application Insights から CloudWatch へ、想定外の分散設計

個人の趣味開発で Azure から AWS に移行することになり、Application Insights + Azure Monitor で構築していた監視の仕組みを AWS のオブザービリティサービスに移植してみようかなと考えました。「監視ツールなんてどこも似たようなもの」という楽観的な見立てで始めた結果、本番環境で次々と予期しない問題が発生。Azure Monitor の「統合された世界」と AWS の「分散された役割分担」の根本的な違いを痛感しました。

最初のローカル環境でのテストは順調でした。Lambda のログも CloudWatch Logs に流れているし、メトリクスも見えます。

# これは普通に動く
import boto3
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info("Lambda invoked successfully")
    return {"statusCode": 200, "body": "OK"}

しかし実際に障害対応訓練で複数サービスにまたがるトラブルシューティングを始めた途端、問題が続出しました。

問題1：CloudWatch Logs がサービスごとにバラバラで全体像が見えない

Application Insights では KQL で全サービスのログを横断検索できたのに、CloudWatch Logs は Lambda、API Gateway、ECS などサービスごとに Log Group が分離していて、「どこから見ればいいのか」がわかりませんでした。

問題2：メトリクスとログが別世界で紐付けが困難

Azure Monitor では「メトリクス → ログ」へのドリルダウンが直感的でしたが、CloudWatch では Metrics と Logs が完全に別画面。同じタイムスタンプのログとメトリクスを並べて見るのに 10 分以上かかりました。

問題3：X-Ray のトレースが「自動」ではなく「明示的に仕込む」必要がある

Application Insights では SDK を入れるだけで自動的に依存関係が追跡されたのに、X-Ray は Lambda の環境変数や IAM ロールを手動設定しないと何も見えず、初回は真っ白な画面に絶望しました。

問題4：CloudTrail が「監視」ではなく「監査」ツールだと気づくのに時間がかかった

Azure Activity Log のように「リソースの状態変化をリアルタイムで追える」と思っていたら、CloudTrail は「誰が何をしたか」の監査ログであり、アプリケーションの障害とは直接関係ないことに気づくまで迷走しました。

問題5：CloudWatch Insights のクエリ言語が KQL ではない

Application Insights の KQL に慣れていたので、CloudWatch Logs Insights の独自クエリ言語に戸惑いました。fields, filter, stats の書き方が微妙に違い、最初のクエリを書くのに 30 分かかりました。

問題6：コスト構造が Azure と根本的に違う（ログ保存期間とデータ取り込み量）

Azure Monitor では「ワークスペース単位で課金」だったのが、CloudWatch は「Log Group ごとの保存期間」と「取り込み量」が別課金。初月の請求で予算の 3 倍になり、慌てて保存期間を見直しました。

これら全ての問題と向き合う中で、AWS のオブザービリティは「役割分担が明確だが、統合は自分でやる」という設計思想だと理解しました（気がします）。

---

Azure Monitor との設計の違い：統合 vs 分散の世界観

Azure Monitor と AWS オブザービリティサービスは、どちらも「監視」が目的ですが、アーキテクチャと統合度が大きく異なります。

項目	Azure Monitor / Application Insights	AWS (CloudWatch / X-Ray / CloudTrail)	影響（実経験）
統合度	統合された単一プラットフォーム	3 つの独立サービス（役割分担）	AWS は「どこに何があるか」を理解する必要あり
ログ検索	KQL で全サービス横断検索	Log Group 単位（サービス別に分離）	横断検索には CloudWatch Logs Insights で複数 Log Group 指定が必要
メトリクス ⇔ ログ連携	直感的なドリルダウン	手動で相関（タイムスタンプ一致を自分で探す）	障害時の原因特定に時間がかかる
分散トレーシング	自動計装（SDK のみ）	明示的設定（環境変数 + IAM + SDK）	X-Ray は「仕込む」ことを忘れると何も見えない
監査ログ	Activity Log（リソース操作 + 状態変化）	CloudTrail（API 操作のみ）	CloudTrail はアプリ障害には直結しない
クエリ言語	KQL（Kusto Query Language）	CloudWatch Logs Insights 独自構文	学習コスト高い（KQL とは別物）
料金	ワークスペース単位	Log Group 単位 + データ取り込み量	細かい制御が必要（予算超過しやすい）

この表を見ると、Azure Monitor は「統合プラットフォーム」、AWS は「専門特化した複数サービスの組み合わせ」です。障害切り分けでは「どのサービスで何を見るか」の理解が AWS では必須になります。

---

実際の障害シナリオ：Azure ユーザーがハマるポイント

シナリオA：Lambda のエラーログがどこにあるか分からない

背景

• API Gateway + Lambda 構成で「500 Internal Server Error」が発生
• Application Insights なら「Failures」タブで一発だが、AWS ではどこから見ればいいのか不明

問題検知

# ユーザーから「API がエラーを返す」という報告
# まず CloudWatch のダッシュボードを開く → Lambda のメトリクスは見えるが、エラー内容が不明

# Azure なら Application Insights で「exceptions」を検索すればすぐ見つかるのに…

迷走開始

# CloudWatch Metrics で Lambda の「Errors」メトリクスを確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda \
  --metric-name Errors \
  --dimensions Name=FunctionName,Value=my-api-handler \
  --start-time $(Get-Date).ToUniversalTime().AddMinutes(-15).ToString("s") \
  --end-time $(Get-Date).ToUniversalTime().ToString("s") \
  --period 60 --statistics Sum
# → Sum: 12（エラーが起きているのは確認できた）

# しかし「どんなエラーか」はメトリクスだけでは分からない

CloudWatch Logs への気づき

# Lambda のログは CloudWatch Logs に流れていることを思い出す
# Log Group 名は /aws/lambda/my-api-handler

# ログをリアルタイムで tail
aws logs tail /aws/lambda/my-api-handler --since 10m --follow

# または Insights でクエリ
aws logs start-query \
  --log-group-name /aws/lambda/my-api-handler \
  --start-time $(([DateTimeOffset](Get-Date).ToUniversalTime().AddMinutes(-15)).ToUnixTimeSeconds()) \
  --end-time $(([DateTimeOffset](Get-Date).ToUniversalTime()).ToUnixTimeSeconds()) \
  --query-string 'fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20'

# クエリ ID を取得して結果を確認
$queryId = "取得したクエリ ID"
aws logs get-query-results --query-id $queryId
# → "KeyError: 'user_id'" というエラーが見つかった！

学び

• Azure では「Failures」タブ 1 クリックだったが、AWS では「Metrics → Logs」への移動が必要
• CloudWatch Logs Insights のクエリ構文を覚える必要がある（KQL とは別物）
• Log Group 名の命名規則（/aws/lambda/関数名）を理解しておく

根本原因

• Lambda コードで event['user_id'] にアクセスしているが、API Gateway からのイベントには含まれていなかった
• Application Insights なら自動的にリクエストボディも記録されるが、CloudWatch は明示的にログ出力が必要

---

シナリオB：API Gateway + Lambda の連携で遅延が発生

背景

• API のレスポンスタイムが急に 5 秒以上に悪化
• Application Insights なら「依存関係の追跡」で一発だが、AWS では？

問題検知

# CloudWatch Metrics で API Gateway の Latency を確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApiGateway \
  --metric-name Latency \
  --dimensions Name=ApiName,Value=my-api \
  --start-time $(Get-Date).ToUniversalTime().AddMinutes(-30).ToString("s") \
  --end-time $(Get-Date).ToUniversalTime().ToString("s") \
  --period 60 --statistics Average,Maximum
# → Average: 5200ms, Maximum: 8500ms（異常に遅い）

Lambda のレイテンシを確認

# Lambda の Duration メトリクスを確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda \
  --metric-name Duration \
  --dimensions Name=FunctionName,Value=my-api-handler \
  --period 60 --statistics Average,Maximum
# → Average: 4800ms（Lambda 自体も遅い）

# しかし「Lambda の中のどこが遅いのか」はメトリクスだけでは分からない

X-Ray の存在を思い出す

# X-Ray が有効になっているか確認
aws lambda get-function-configuration \
  --function-name my-api-handler \
  --query 'TracingConfig'
# → { "Mode": "PassThrough" }  ← Active ではない！

# X-Ray を有効化
aws lambda update-function-configuration \
  --function-name my-api-handler \
  --tracing-config Mode=Active

# IAM ロールに X-Ray の権限を追加（これを忘れると何も記録されない）
# ポリシー: AWSXRayDaemonWriteAccess

X-Ray トレースの確認

# X-Ray コンソールまたは CLI でトレースを確認
aws xray get-trace-summaries \
  --start-time $(Get-Date).ToUniversalTime().AddMinutes(-10).ToString("s") \
  --end-time $(Get-Date).ToUniversalTime().ToString("s") \
  --filter-expression 'service("my-api-handler")'

# サービスマップで依存関係を可視化
# → Lambda → DynamoDB の呼び出しが 4.5 秒かかっていることが判明！

DynamoDB の問題を特定

# DynamoDB の ConsumedReadCapacityUnits を確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ConsumedReadCapacityUnits \
  --dimensions Name=TableName,Value=UserTable \
  --period 60 --statistics Average
# → Throttling が発生していた（別の問題）

学び

• Azure では Application Insights が自動的に依存関係を追跡するが、AWS では X-Ray を明示的に有効化する必要がある
• X-Ray の設定は「Lambda 環境変数」+「IAM ロール」+「SDK（場合により）」の 3 点セット
• トレースを見るまでに設定時間がかかる（Application Insights より手間）

---

シナリオC：複数サービスのログを横断検索したい

背景

• API Gateway → Lambda → DynamoDB の連携で、特定のリクエスト ID を追跡したい
• Application Insights なら KQL で requests | where operation_Id == "xxx" で一発だが…

問題

# リクエスト ID: "req-abc-123" を追跡したい
# しかし CloudWatch Logs は Log Group ごとに分離されている：
# - /aws/apigateway/my-api
# - /aws/lambda/my-api-handler
# - （DynamoDB はログを出力しない）

# Application Insights なら全サービスのログが統合されているのに…

CloudWatch Logs Insights で複数 Log Group を指定

# Insights クエリで複数 Log Group を対象にする
aws logs start-query \
  --log-group-names /aws/apigateway/my-api /aws/lambda/my-api-handler \
  --start-time $(([DateTimeOffset](Get-Date).ToUniversalTime().AddMinutes(-30)).ToUnixTimeSeconds()) \
  --end-time $(([DateTimeOffset](Get-Date).ToUniversalTime()).ToUnixTimeSeconds()) \
  --query-string 'fields @timestamp, @logStream, @message | filter @message like /req-abc-123/ | sort @timestamp asc'

# クエリ結果を取得
$queryId = "取得したクエリ ID"
Start-Sleep -Seconds 5
aws logs get-query-results --query-id $queryId
# → API Gateway と Lambda の両方のログが時系列で取得できた

X-Ray との組み合わせ

# X-Ray でトレース ID を特定
aws xray get-trace-summaries \
  --start-time $(Get-Date).ToUniversalTime().AddMinutes(-30).ToString("s") \
  --end-time $(Get-Date).ToUniversalTime().ToString("s") \
  --filter-expression 'annotation.request_id = "req-abc-123"'
# → トレース ID: "1-abc-def-ghi"

# トレース詳細を取得
aws xray batch-get-traces --trace-ids "1-abc-def-ghi"
# → Lambda → DynamoDB の呼び出しフローが可視化された

統合ダッシュボード作成

# CloudWatch Dashboard で Metrics + Logs + X-Ray リンクを 1 画面に統合
# （JSON 定義を手動で作成する必要がある）

# Application Insights ではこれが標準機能なのに…

学び

• Azure では単一クエリで全サービス横断検索できるが、AWS では Log Group を明示的に指定する必要がある
• CloudWatch Logs Insights は複数 Log Group 対応だが、クエリ構文が KQL と異なる
• X-Ray と CloudWatch Logs を組み合わせることで、Application Insights 相当の追跡は可能（手間はかかる）

---

シナリオD：CloudTrail を「監視ツール」と勘違いして迷走

背景

• Lambda の実行エラーを調査中に「CloudTrail に何か記録されているはず」と思い込む
• Azure Activity Log と同じだと勘違い

迷走開始

# CloudTrail でLambda の実行ログを探す
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::Lambda::Function \
  --start-time $(Get-Date).ToUniversalTime().AddHours(-1).ToString("s") \
  --max-results 50

# → 結果: Lambda の「作成」「更新」「削除」は記録されているが、「実行」は記録されていない

混乱
Azure Activity Log ではリソースの「状態変化」や「イベント」が記録されるのに、
CloudTrail には Lambda の実行エラーが見当たらない

「CloudTrail は壊れているのか？」と疑い始める

勘違いの理解
CloudTrail は「API 操作の監査ログ」であり、「アプリケーション動作の監視ログ」ではない

記録されるもの

• Lambda 関数の作成/更新/削除（CreateFunction, UpdateFunctionCode など）
• IAM ロールの変更
• S3 バケットの作成

記録されないもの

• Lambda の実行（Invoke）← これは CloudWatch Logs へ
• Lambda 内部のエラー ← これも CloudWatch Logs へ
• DynamoDB のクエリ ← これは X-Ray または CloudWatch Logs へ

CloudTrail の正しい使い方

# 「誰が Lambda 関数を削除したか」を調査する場合は CloudTrail
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteFunction \
  --start-time $(Get-Date).ToUniversalTime().AddDays(-7).ToString("s")

# 「Lambda が実行時にエラーを出した」を調査する場合は CloudWatch Logs
aws logs tail /aws/lambda/my-function --since 1h --filter-pattern "ERROR"

学び

• Azure Activity Log は「リソース操作 + アプリイベント」の両方を記録するが、CloudTrail は「API 操作の監査」のみ
• アプリケーション障害の調査には CloudTrail は直接役立たない（権限変更や誤削除の調査には有効）
• 障害対応では「CloudWatch Logs + X-Ray」、監査では「CloudTrail」と役割を分ける

---

AWS オブザービリティの優先順位：障害発生時の実戦順序

最初の 3 分：どこで何が起きているか把握

# 1. CloudWatch Metrics でサービスの健全性を確認
# API Gateway の 5xx エラー率
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApiGateway \
  --metric-name 5XXError \
  --dimensions Name=ApiName,Value=$API_NAME \
  --period 60 --statistics Sum

# Lambda のエラー数
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda \
  --metric-name Errors \
  --dimensions Name=FunctionName,Value=$FUNCTION_NAME \
  --period 60 --statistics Sum

# DynamoDB のスロットル
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name UserErrors \
  --dimensions Name=TableName,Value=$TABLE_NAME \
  --period 60 --statistics Sum

# 2. CloudWatch Logs でエラーメッセージを確認
aws logs tail /aws/lambda/$FUNCTION_NAME --since 10m --filter-pattern "ERROR"

# 3. X-Ray でボトルネックを特定（有効化されている場合）
aws xray get-trace-summaries \
  --start-time $(Get-Date).ToUniversalTime().AddMinutes(-15).ToString("s") \
  --end-time $(Get-Date).ToUniversalTime().ToString("s") \
  --filter-expression 'responsetime > 3'

次の 10 分：原因カテゴリ別切り分け

1) ログが見つからない → Log Group の場所を確認

Azure では統合されているが、AWS では各サービスに分散。

# Log Group 一覧を確認
aws logs describe-log-groups --log-group-name-prefix /aws/

# 主要な Log Group の命名規則：
# - Lambda: /aws/lambda/関数名
# - API Gateway: /aws/apigateway/API名
# - ECS: /ecs/クラスター名/タスク定義名
# - RDS: /aws/rds/instance/インスタンス名/error（有効化が必要）

対応案

• サービスごとの Log Group 命名規則を事前に把握
• CloudWatch Logs Insights で複数 Log Group を一括検索

2) メトリクスとログの相関が取れない → タイムスタンプで手動マッピング

Azure では自動的に紐付くが、AWS では手動。

# メトリクスでスパイクした時刻を特定
# 例：15:23 に Lambda Errors が急増

# その時刻のログを CloudWatch Logs Insights で検索
aws logs start-query \
  --log-group-name /aws/lambda/$FUNCTION_NAME \
  --start-time $(([DateTimeOffset](Get-Date "2025-11-02 15:20:00").ToUniversalTime()).ToUnixTimeSeconds()) \
  --end-time $(([DateTimeOffset](Get-Date "2025-11-02 15:25:00").ToUniversalTime()).ToUnixTimeSeconds()) \
  --query-string 'fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc'

対応案

• CloudWatch Dashboard でメトリクスとログを並べて表示
• X-Ray の Trace ID をログに埋め込む（手動計装）

3) X-Ray トレースが表示されない → 設定漏れを疑う

Application Insights は自動計装だが、X-Ray は明示的設定が必要。

# Lambda の X-Ray 設定を確認
aws lambda get-function-configuration \
  --function-name $FUNCTION_NAME \
  --query 'TracingConfig'
# → { "Mode": "PassThrough" } なら無効

# 有効化
aws lambda update-function-configuration \
  --function-name $FUNCTION_NAME \
  --tracing-config Mode=Active

# IAM ロールに xray:PutTraceSegments 権限があるか確認
aws iam get-role-policy \
  --role-name lambda-execution-role \
  --policy-name xray-policy
# → AWSXRayDaemonWriteAccess が必要

対応案

• Lambda 作成時に X-Ray を有効化するテンプレート作成
• API Gateway でも X-Ray トレースを有効化（ステージ設定）
• SDK による手動計装（boto3 の場合は aws_xray_sdk）

4) CloudWatch Logs Insights のクエリが書けない → KQL との違いを理解

# KQL (Application Insights)
# requests | where timestamp > ago(1h) | summarize count() by bin(timestamp, 5m)

# CloudWatch Logs Insights（AWS）
# fields @timestamp | filter @timestamp > $(date -u -d '1 hour ago' +%s)000 | stats count() by bin(@timestamp, 5m)

# 主な違い：
# - fields で列を明示指定
# - filter（where ではない）
# - stats（summarize ではない）
# - タイムスタンプはミリ秒 Unix エポック

対応案

• CloudWatch Logs Insights のサンプルクエリを保存しておく
• よく使うクエリをテンプレート化

5) CloudTrail で障害原因を探してしまう → 役割の違いを理解

# CloudTrail が役立つケース：
# - 「誰が Lambda 関数を削除したか」
# - 「IAM ロールが変更されたのはいつか」
# - 「S3 バケットのポリシーを変更したのは誰か」

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteFunction

# CloudTrail が役立たないケース：
# - Lambda の実行エラー → CloudWatch Logs へ
# - API のレスポンスタイム悪化 → CloudWatch Metrics + X-Ray へ
# - DynamoDB のスロットル → CloudWatch Metrics へ

対応案

• 障害対応は CloudWatch + X-Ray、監査は CloudTrail と使い分け
• CloudTrail は「事後調査」「コンプライアンス」用途

---

よくある落とし穴と対策

落とし穴	理由	AWS での対策
ログがどこにあるか分からない	サービスごとに Log Group が分離	Log Group 命名規則を把握（/aws/lambda/xxx など）
メトリクスとログの相関が取れない	Azure のような自動紐付けがない	タイムスタンプで手動マッピング、Dashboard で並べて表示
X-Ray トレースが何も表示されない	自動計装ではなく明示的設定が必要	TracingConfig Mode=Active + IAM 権限 + SDK 計装
KQL が使えない	CloudWatch Logs Insights は独自構文	サンプルクエリをテンプレート化、構文の違いを理解
CloudTrail で障害調査してしまう	CloudTrail は監査ログ（監視ログではない）	障害は CloudWatch + X-Ray、監査は CloudTrail と使い分け
コストが予想外に高い	Log Group ごとの保存期間 + データ取り込み量	不要な Log Group の保存期間を短縮（1 日～7 日）、サンプリング活用
複数サービスのログを横断検索できない	Log Group が分離されている	Logs Insights で複数 Log Group を指定、X-Ray で依存関係追跡

---

移行実装時のチェックリスト

□ CloudWatch Logs：各サービスの Log Group 命名規則を把握
□ CloudWatch Metrics：主要メトリクス（Errors, Duration, Throttles）のアラート設定
□ X-Ray：Lambda + API Gateway で TracingConfig Mode=Active に設定
□ X-Ray IAM：実行ロールに AWSXRayDaemonWriteAccess 権限を追加
□ CloudWatch Logs Insights：よく使うクエリをテンプレート化（KQL との対応表作成）
□ CloudWatch Dashboard：メトリクス + ログ + X-Ray リンクを 1 画面に統合
□ CloudTrail：監査用途として有効化（障害調査には使わない）
□ コスト最適化：不要な Log Group の保存期間を 1～7 日に短縮
□ リクエスト ID 伝播：X-Ray Trace ID をログに埋め込む（手動計装）
□ Application Insights からの移行：KQL → Insights クエリへの変換リスト作成

---

さいごに

AWS のオブザービリティは Azure Monitor のような「統合プラットフォーム」というよりも、「役割特化した複数サービスの組み合わせ」なのかな、と感じました。CloudWatch Logs、CloudWatch Metrics、X-Ray、CloudTrail それぞれの役割を理解し、適切に使い分ける必要がありそうです。
※Azureはハッピーセット（これさえあれば大体行ける系の製品）を意識して作っているイメージ、AWSは、モスバーガーのように一つ一つの具材をこだわって作りこんでるイメージなのかな…と感じました。

Azure では「Application Insights を開けば全部ある」という快適さがありましたが、AWS では「どこで何を見るか」を理解する必要があります。しかし、役割分担が明確な分、大規模システムでの細かい制御は AWS の方が柔軟かもしれません。
この辺りは好き嫌いというか、音楽性の違い、というやつなのかもしれないです。

本記事のような優先度順に切り分ければ、もしかしたら落ち着いて障害対応できるのかな？、と思いました。

---

補足：AWS マネジメントコンソールでの基本操作

CLI に慣れていない場合、AWS マネジメントコンソール（ポータル）での操作が便利です。以下は障害対応で頻繁に使う画面の場所と確認方法です。

CloudWatch の基本操作

1. ダッシュボードの作成

1. AWS マネジメントコンソールで「CloudWatch」を検索
2. 左メニューから「Dashboards」を選択
3. 「Create dashboard」をクリック
4. Dashboard name を入力（例：production-monitoring）
5. 「Create dashboard」をクリック
6. ウィジェットタイプを選択：
   - Line: メトリクスの時系列グラフ
   - Number: 現在の値を大きく表示
   - Log table: ログの表形式表示
7. 例：Lambda のエラー数を表示する場合
   - 「Line」を選択 → 「Metrics」を選択
   - 「Lambda」→「By Function Name」を選択
   - 対象関数の「Errors」をチェック
   - 「Create widget」をクリック
8. 複数のウィジェットを追加して一覧化
9. 右上の「Save dashboard」をクリック

2. メトリクスの確認（Lambda のエラー数）

1. CloudWatch の左メニューから「Metrics」→「All metrics」を選択
2. 「Lambda」を選択
3. 「By Function Name」を選択
4. 確認したい関数の以下をチェック：
   - Invocations（実行回数）
   - Errors（エラー数）
   - Duration（実行時間）
   - Throttles（スロットリング）
5. 「Graphed metrics」タブで統計方法を選択（Sum, Average など）
6. 右上の期間を「Last 1 hour」「Last 3 hours」などに変更
7. グラフでスパイクやエラー増加を確認

3. ログの確認（リアルタイム tail）

1. CloudWatch の左メニューから「Logs」→「Log groups」を選択
2. 対象の Log group をクリック（例：/aws/lambda/my-function）
3. 「Log streams」タブで最新の Stream をクリック
4. ログが時系列で表示される
5. 右上の「Actions」→「Create live tail session」をクリック
   → リアルタイムでログが流れる（tail -f のような動作）
6. フィルターバーで「ERROR」や「Exception」を入力して絞り込み

4. Logs Insights でのクエリ検索

1. CloudWatch の左メニューから「Logs Insights」を選択
2. 「Select log group(s)」で対象を選択（複数選択可能）
3. クエリエディタに以下を入力：
   fields @timestamp, @message
   | filter @message like /ERROR/
   | sort @timestamp desc
   | limit 20
4. 右上の期間を選択（Last 1 hour など）
5. 「Run query」をクリック
6. 結果を CSV でエクスポート可能（「Actions」→「Export results to CSV」）

5. アラームの設定

1. CloudWatch の左メニューから「Alarms」→「All alarms」を選択
2. 「Create alarm」をクリック
3. 「Select metric」をクリック
4. 例：Lambda のエラー数でアラーム
   - 「Lambda」→「By Function Name」を選択
   - 対象関数の「Errors」をチェック
   - 「Select metric」をクリック
5. Conditions で Threshold を設定
   - Threshold type: Static
   - Whenever Errors is: Greater/Equal
   - than: 5（5 回以上エラーが発生したら通知）
6. 「Next」をクリック
7. Notification で SNS topic を選択（メール通知用）
   - 「Create new topic」で新規作成可能
   - Email を入力して「Create topic」
8. 「Next」→ Alarm name を入力 → 「Create alarm」
9. 登録したメールアドレスに確認メールが届くので承認

X-Ray の基本操作

1. サービスマップの確認

1. AWS マネジメントコンソールで「X-Ray」を検索
2. 左メニューから「Service map」を選択
3. サービス間の依存関係がグラフ表示される
   例：API Gateway → Lambda → DynamoDB
4. 各ノードをクリックすると詳細が右側に表示：
   - Response time distribution（レスポンスタイムの分布）
   - Requests（リクエスト数）
   - Error rate（エラー率）
5. 色で健全性を判断：
   - 緑: 正常
   - 黄色: 警告（レイテンシ増加）
   - 赤: エラー発生
6. 右上の期間を変更して過去の状況を確認

2. トレースの詳細確認

1. X-Ray の左メニューから「Traces」を選択
2. フィルターで期間を設定（Last 1 hour など）
3. トレース一覧が表示される：
   - URL: リクエストのエンドポイント
   - Duration: 処理時間
   - Status: 成功/失敗
4. レスポンスタイムが長いトレースをクリック
5. タイムラインで各サービスの処理時間を確認
   例：
   - API Gateway: 0.1 秒
   - Lambda: 4.5 秒
   - DynamoDB: 4.2 秒 ← ここが遅い
6. 「Segments」タブで詳細ログを確認

3. X-Ray の有効化（Lambda の場合）

1. AWS マネジメントコンソールで「Lambda」を検索
2. 対象の関数をクリック
3. 「Configuration」タブ → 「Monitoring and operations tools」を選択
4. 「Edit」をクリック
5. 「AWS X-Ray」セクションで「Active tracing」をチェック
6. 「Save」をクリック
7. IAM ロールに AWSXRayDaemonWriteAccess 権限があることを確認
   - 「Configuration」タブ → 「Permissions」を選択
   - Execution role をクリック
   - ポリシーに AWSXRayDaemonWriteAccess があるか確認

CloudTrail の基本操作（監査ログ）

1. イベント履歴の確認

1. AWS マネジメントコンソールで「CloudTrail」を検索
2. 左メニューから「Event history」を選択
3. 過去 90 日間のイベントが表示される
4. フィルターで絞り込み：
   - Event name: DeleteFunction（Lambda 削除）
   - User name: admin-user（特定ユーザー）
   - Resource type: AWS::Lambda::Function
5. イベントをクリックして詳細を確認：
   - Event time: 実行日時
   - User name: 実行ユーザー
   - Event source: lambda.amazonaws.com
   - Request parameters: API のパラメータ（JSON）

2. Trail の作成（長期保存用）

1. CloudTrail の左メニューから「Trails」を選択
2. 「Create trail」をクリック
3. Trail name を入力（例：production-audit）
4. Storage location で S3 バケットを選択
   - 「Create new S3 bucket」で自動作成
5. Log file SSE-KMS encryption を有効化（推奨）
6. CloudWatch Logs への送信を有効化（オプション）
   - 「Enabled」をチェック
   - Log group を新規作成
7. 「Next」をクリック
8. Event type で「Management events」を選択
9. 「Next」→「Create trail」をクリック

画面操作のチートシート

確認したいこと	開く画面	見るべき項目
Lambda のエラー数	CloudWatch → Metrics → Lambda	Errors の Sum
Lambda のログ	CloudWatch → Logs → /aws/lambda/xxx	最新の Log stream
API Gateway の 5xx エラー	CloudWatch → Metrics → API Gateway	5XXError の Sum
DynamoDB のスロットル	CloudWatch → Metrics → DynamoDB	UserErrors の Sum
サービス間のレイテンシ	X-Ray → Service map	各ノードの Response time
特定リクエストの追跡	X-Ray → Traces	Duration でソートして確認
Lambda 関数の削除履歴	CloudTrail → Event history	Event name: DeleteFunction
IAM ロールの変更履歴	CloudTrail → Event history	Event name: PutRolePolicy
複数 Log Group の横断検索	CloudWatch → Logs Insights	Select log group(s) で複数選択

よく使う CloudWatch Logs Insights クエリ集

1. エラーログの抽出

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50

2. 特定のリクエスト ID を追跡

fields @timestamp, @message
| filter @message like /req-abc-123/
| sort @timestamp asc

3. レスポンスタイムが 3 秒以上のリクエスト

fields @timestamp, @message, @duration
| filter @duration > 3000
| sort @duration desc
| limit 20

4. エラー数の集計（5 分ごと）

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(@timestamp, 5m)

5. Lambda の実行時間統計

filter @type = "REPORT"
| fields @requestId, @billedDuration
| stats avg(@billedDuration), max(@billedDuration), min(@billedDuration)

---

注釈：本記事で出現する主要な専門用語

CloudWatch Logs

• AWS の各サービスが出力するログを集約するサービス。Log Group（ログの保存先）単位で管理され、サービスごとに分離されている。Application Insights のような統合ログではなく、各サービスが個別にログを出力する。

CloudWatch Metrics

• CPU 使用率、エラー数、レイテンシなどの数値データ（メトリクス）を収集・可視化するサービス。Azure Monitor のメトリクス機能に相当。

CloudWatch Logs Insights

• CloudWatch Logs に保存されたログをクエリで検索・分析するサービス。KQL とは異なる独自のクエリ構文を使用。

X-Ray

• 分散トレーシングサービス。API Gateway → Lambda → DynamoDB のような依存関係を可視化し、ボトルネックを特定できる。Application Insights の依存関係追跡に相当するが、明示的な設定が必要。

CloudTrail

• AWS アカウント内の API 操作を記録する監査ログサービス。「誰が何をしたか」を追跡するためのもので、アプリケーションの実行ログではない。Azure Activity Log に近いが、用途は監査に特化。

Log Group

• CloudWatch Logs でログを保存する単位。Lambda、API Gateway、ECS などサービスごとに個別の Log Group が作成される。Azure の Log Analytics Workspace のような統合ではなく、分散管理。

Trace ID

• X-Ray で 1 つのリクエストを追跡するための一意の識別子。複数サービスをまたがるリクエストフローを 1 本の線で可視化できる。

TracingConfig Mode=Active

• Lambda で X-Ray トレースを有効化する設定。PassThrough（デフォルト）では何も記録されない。Application Insights のような自動計装ではなく、明示的に有効化する必要がある。

KQL (Kusto Query Language)

• Azure Monitor / Application Insights で使われるクエリ言語。requests | where timestamp > ago(1h) のような直感的な構文。AWS の CloudWatch Logs Insights は独自構文（fields, filter, stats）を使用。

IAM ロール

• AWS リソースに権限を付与する仕組み。Lambda が X-Ray にデータを送信するには、実行ロールに xray:PutTraceSegments 権限が必要。Application Insights では自動的に権限が付与されるが、AWS では手動設定が必要。

Application Insights

• Azure のアプリケーション監視サービス。ログ、メトリクス、トレースが統合されたプラットフォーム。SDK を入れるだけで自動計装され、依存関係も自動追跡される。

Azure Monitor

• Azure の統合監視プラットフォーム。Application Insights、Log Analytics、Metrics、Alerts が 1 つの画面で管理できる。AWS では CloudWatch + X-Ray + CloudTrail の組み合わせが相当。

Activity Log (Azure)

• Azure リソースの操作ログ。リソースの作成/削除だけでなく、状態変化やイベントも記録される。AWS CloudTrail より広範囲をカバー。

Log Analytics Workspace (Azure)

• Azure Monitor でログを保存・検索する統合ワークスペース。全サービスのログを 1 箇所に集約できる。AWS の CloudWatch Logs は Log Group 単位で分散管理。

Sampling（サンプリング）

• トレースやログを全件記録するのではなく、一部だけ記録してコストを削減する手法。X-Ray はデフォルトでサンプリングを行う（1 秒あたり 1 リクエスト + 5% をランダム）。

Correlation ID

• 複数サービスをまたがるリクエストを追跡するための識別子。Application Insights では operation_Id として自動付与されるが、AWS では手動で伝播させる必要がある（X-Ray Trace ID または独自 ID）。