CloudWatchアラームから3分で自動調査開始 — DevOps Agent × EventBridge構成パターン

「深夜3時、CloudWatchアラームが鳴った。Slackを開いて、ログを漁って、原因を特定して……気づけば朝5時」

オンコール担当になった経験のある方なら、この疲労感は身に覚えがあるはずです。アラームが鳴るたびに人間がログを読みに行くフローは、チーム規模が小さいほど属人化しやすく、夜間や休日の対応は「翌営業日に確認」で済まされることも少なくありません。

この記事では、CloudWatch → EventBridge → AWS DevOps Agent で「アラーム発火から3分で自動調査が始まる」構成パターンを、実際の Lambda コード付きで解説します。

この記事で分かること

• CloudWatch → EventBridge → DevOps Agent の自動調査パイプラインの全体像
• Lambda Webhook Bridge の実装コード（Python + HMAC-SHA256署名）
• EventBridge ルールのイベントパターン設定
• 実際に動かしたときの調査レポートの中身
• 月額コストのリアルな試算（月間100件で約$400）

構成の説明に入る前に、前提知識を確認しておきましょう。

前提知識

以下の操作経験があることを前提にしています。

• AWS CloudWatch アラームの基本設定ができる
• EventBridge ルールの概念がわかる
• Lambda 関数のデプロイ経験がある（SAMまたはマネジメントコンソール）
• IAM ロール・ARN（Amazon Resource Name）の基本がわかる

本記事で使う用語を2つだけ先に押さえておきます。HMAC（Hash-based Message Authentication Code）は秘密鍵とハッシュ関数を組み合わせてメッセージの認証と改ざん検知を行う仕組みです。Agent Space は DevOps Agent がアクセスできる AWS アカウント・ツール・権限を定義する論理的な境界で、本番用と検証用で分けるのがベストプラクティスです。

なぜ「アラーム→自動調査」が必要なのか

従来のインシデント対応フローを振り返ってみます。「アラーム発火→Slack通知→ログイン→ログ確認→メトリクス横断チェック→原因特定」に平均30〜60分。夜間なら、まず Slack の通知に気づくところから始まるのでさらに遅いですよね。

DevOps Agent を導入すると、調査開始までの所要時間は約3分ほどに縮まります。人間が介在するのは「判断」だけです（もう「とりあえずログ見てきます」は卒業です）。

仕組みが分かったところで、全体のアーキテクチャを確認しましょう。

全体アーキテクチャ

ポイントは Lambda が間に入ることです。CloudWatch アラームから DevOps Agent を直接呼び出すネイティブアクションは存在しません。Lambda が「Webhook Bridge」として、アラーム情報を DevOps Agent の Webhook エンドポイントに HMAC 署名付きで転送します。

関連記事 AIOpsとは？ AWS DevOps Agent で始める次世代運用の全体像 DevOps Agent の基本概念と適用範囲をまとめています。本記事の前に読むと理解が深まります。

全体像を押さえたところで、Step 1 から順に設定していきます。

【Step 1】DevOps Agent の Agent Space を作成する

まず、DevOps Agent のコンソールで Agent Space を作成します。

1. AWS マネジメントコンソールで「DevOps Agent」を検索して開く
2. 「Create agent space」をクリック
3. Agent Space 名を入力（例: prod-auto-investigation）
4. IAM ロールを設定する

IAM ロールには信頼ポリシーと権限ポリシーの両方が必要です。

まず信頼ポリシー。プリンシパルは aidevops.amazonaws.com です（devops-agent.amazonaws.com ではないので注意。ここを間違えると Agent がリソースにアクセスできません）。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "<YOUR_ACCOUNT_ID>"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:<REGION>:<YOUR_ACCOUNT_ID>:agentspace/<SPACE_ID>"
        }
      }
    }
  ]
}

次に権限ポリシー。DevOps Agent が調査時にログやメトリクスを読み取るための権限です。本番環境では Resource を特定のロググループやリソースの ARN に絞り込んでください（機密情報を含むログへの意図しないアクセスを防ぐため）。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:GetLogEvents",
        "logs:FilterLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams",
        "cloudwatch:GetMetricData",
        "cloudwatch:DescribeAlarms",
        "cloudwatch:ListMetrics",
        "ec2:DescribeInstances",
        "ecs:DescribeServices",
        "ecs:DescribeTasks",
        "health:DescribeEvents"
      ],
      "Resource": "*"
    }
  ]
}

PoC 段階では Resource: "*" で問題ありませんが、本番では arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/ecs/your-service:* のようにスコープを絞るのが最小権限の原則です。

Agent Space を作成したら、「Capabilities」→「Webhooks」セクションで Webhook を追加します。ここで生成される Webhook URL と HMAC Secret をメモしてください。この2つの値は SSM Parameter Store に格納するのがベストプラクティスです（Lambda の環境変数でも動きますが、本番では Secrets Manager または SSM を推奨します）。

aws ssm put-parameter \
  --name "/devops-agent/webhook-url" \
  --type SecureString \
  --value "https://xxxx.devops-agent.amazonaws.com/webhook/yyyy"

aws ssm put-parameter \
  --name "/devops-agent/webhook-secret" \
  --type SecureString \
  --value "your-hmac-secret-here"

Agent Space の準備が整ったら、次は Lambda の実装に入ります。ここが構成のキモです。

【Step 2】Lambda Webhook Bridge を構築する

Lambda 関数が EventBridge から受け取ったアラーム情報を、DevOps Agent の Webhook に HMAC-SHA256 署名付きで POST します。

DevOps Agent の Webhook 認証は仕様が厳格で、ヘッダー名・タイムスタンプ形式・署名のエンコーディング・ペイロード構造のすべてが正確でないと 403 Forbidden で弾かれます（そしてエラーメッセージは何も教えてくれません）。以下が公式仕様に準拠した実装です。

import json
import hmac
import hashlib
import base64
import urllib3
import boto3
from datetime import datetime, timezone

ssm = boto3.client("ssm")
http = urllib3.PoolManager()


def get_parameter(name: str) -> str:
    resp = ssm.get_parameter(Name=name, WithDecryption=True)
    return resp["Parameter"]["Value"]


def lambda_handler(event, context):
    webhook_url = get_parameter("/devops-agent/webhook-url")
    webhook_secret = get_parameter("/devops-agent/webhook-secret")

    detail = event.get("detail", {})
    alarm_name = detail.get("alarmName", "Unknown")
    state = detail.get("state", {})
    new_state = state.get("value", "ALARM")
    reason = state.get("reason", "No reason provided")
    event_timestamp = state.get(
        "timestamp",
        datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.000Z"),
    )
    region = event.get("region", "ap-northeast-1")
    account_id = event.get("account", "unknown-account")

    if new_state != "ALARM":
        print(f"State is {new_state}. Skipping investigation.")
        return {"statusCode": 200, "body": "Skipped"}

    # DevOps Agent のペイロードスキーマに準拠
    payload = {
        "eventType": "incident",
        "incidentId": f"{alarm_name}-{event_timestamp}",
        "action": "created",
        "priority": "HIGH",
        "title": f"CloudWatch Alarm: {alarm_name}",
        "description": (
            f"Account: {account_id}\n"
            f"Region: {region}\n"
            f"State: {new_state}\n"
            f"Reason: {reason}"
        ),
        "timestamp": event_timestamp,
        "service": alarm_name,
        "data": {
            "metadata": {
                "alarmName": alarm_name,
                "region": region,
                "accountId": account_id,
            }
        },
    }

    payload_json = json.dumps(payload, separators=(",", ":"))

    # 署名用タイムスタンプは ISO 8601 形式
    current_time_iso = datetime.now(timezone.utc).strftime(
        "%Y-%m-%dT%H:%M:%S.000Z"
    )

    # HMAC-SHA256 署名: {timestamp}:{payload} をコロンで連結
    signature_string = f"{current_time_iso}:{payload_json}"
    signature = hmac.new(
        webhook_secret.encode("utf-8"),
        signature_string.encode("utf-8"),
        hashlib.sha256,
    ).digest()
    signature_b64 = base64.b64encode(signature).decode("utf-8")

    # DevOps Agent 専用ヘッダー
    resp = http.request(
        "POST",
        webhook_url,
        body=payload_json,
        headers={
            "Content-Type": "application/json",
            "x-amzn-event-timestamp": current_time_iso,
            "x-amzn-event-signature": signature_b64,
        },
    )

    print(f"DevOps Agent response: {resp.status} {resp.data.decode()}")

    if resp.status not in [200, 202]:
        raise Exception(
            f"Webhook failed: {resp.status} {resp.data.decode()}"
        )

    return {"statusCode": resp.status}

署名まわりの仕様を表にまとめます。どれか1つでも間違えると 403 Forbidden が返ってきます。

項目	正しい仕様
ヘッダー名	x-amzn-event-timestamp / x-amzn-event-signature
タイムスタンプ	ISO 8601形式（2026-06-21T10:00:00.000Z）
署名の連結	コロン区切り（{timestamp}:{payload}）
署名のエンコード	Base64（hexdigest ではない）
ペイロード	eventType, incidentId, action, priority が必須

Lambda の設定ポイントも確認しておきましょう。ランタイムは Python 3.12 以上、タイムアウトは30秒以上（SSM パラメータの取得 + HTTP 通信があるため）、IAM ロールには ssm:GetParameter の権限が必要です。メモリは 128MB で十分です。

関連記事 AWS公式サンプル — CloudWatch Webhook チュートリアル（GitHub） SAMテンプレート付きの公式サンプルです（Node.js実装）。インフラ構成の参考として活用してください。

Lambda が完成したら、EventBridge ルールで CloudWatch と繋ぎます。

【Step 3】EventBridge ルールでアラームと繋ぐ

EventBridge ルールで「CloudWatch アラームが ALARM 状態になった」イベントをキャッチし、Step 2 の Lambda をターゲットにします。

PoC 向け（全アラーム対象）のイベントパターンです。

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"],
  "detail": {
    "state": {
      "value": ["ALARM"]
    }
  }
}

"value": ["ALARM"] でフィルタしているため、OK → ALARM の遷移だけが Lambda を起動します。ALARM → OK（復旧）や INSUFFICIENT_DATA は無視されます。

実運用では、CPU 一時スパイクなど軽微なアラームまで Agent に投げるとコストが膨らみます。resources フィールドで ARN を指定し、重要なアラームだけを対象にしましょう。

本番向けに特定アラームだけを対象にする場合はこうなります。

{
  "source": ["aws.cloudwatch"],
  "detail-type": ["CloudWatch Alarm State Change"],
  "resources": [
    "arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:Critical-DB-Error",
    "arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:Production-ECS-Failure"
  ],
  "detail": {
    "state": {
      "value": ["ALARM"]
    }
  }
}

設定手順はシンプルです。EventBridge コンソールで「ルールを作成」→ イベントバス: default → 上記のイベントパターンを入力 → ターゲットに Step 2 の Lambda を選択 → 作成完了。

これで CloudWatch アラームが鳴るたびに DevOps Agent が自動で調査を開始する仕組みが完成です。実際に動かして確認してみましょう。

【Step 4】動かしてみる（テストアラームで自動調査を確認）

構成が動くか確認しましょう。最も簡単なテスト方法は、CloudWatch アラームの状態を手動で ALARM に変更することです。

aws cloudwatch set-alarm-state \
  --alarm-name "test-high-cpu" \
  --state-value ALARM \
  --state-reason "Testing DevOps Agent auto-investigation"

実行後、以下の流れで確認します。

1. EventBridge: CloudWatch コンソール → EventBridge → ルールの「モニタリング」タブで呼び出し数が1増えていること
2. Lambda: CloudWatch Logs で Lambda の実行ログを確認。DevOps Agent response: 200 が出ていれば成功
3. DevOps Agent: Agent Space のコンソールで、新しい調査（Investigation）が開始されていること

調査レポートには以下の情報が含まれます。根本原因の推定（ログパターンとメトリクスの相関から分析）、影響範囲（関連するリソースやサービスの一覧）、推奨アクション（修復の提案）、参照したデータソース（どのログ・メトリクスを確認したかの証跡）です。

Agent が環境を変更しない安全設計は、本番導入する上で大きな安心材料です。「AI が勝手にインスタンスを再起動した」という事故は起きません。

動作が確認できたら、次は費用感を把握しておきましょう。

コストと制限

導入前に一番気になるのはコストだと思います。正直に数字を出します。

DevOps Agent の料金は $0.0083/秒（エージェント稼働時間）です。1回の調査が平均8分の場合、約$4/回。Agent が待機中（アイドル中）は課金されません。

月額コストのシミュレーションです。

月間アラーム数	平均調査時間	DevOps Agent	Lambda + EventBridge	合計
10件	8分	$40	~$0	~$40
50件	8分	$200	~$0	~$200
100件	8分	$400	~$0	~$400

新規顧客には2ヶ月間の無料トライアルがあり、毎月インシデント調査20時間・予防的評価15時間・オンデマンドタスク20時間が無料で使えます。20時間のインシデント調査 = 約150回分（1回8分換算）なので、PoC には十分すぎる枠です。

AWS Support プランごとの月次クレジット還元率です（本番稟議の決め手になる数字なので押さえておいてください）。

AWS Support プラン	クレジット付与率	例: 月額$15,000の場合
Unified Operations	100%	$15,000分 → 月約3,750回の調査が実質無料
Enterprise Support	75%	$11,250分 → 月約2,800回
Business Support+	30%	$4,500分 → 月約1,125回

Enterprise Support を契約済みの企業なら、DevOps Agent の利用料は大部分がクレジットで相殺されます。社内稟議を通す際はこの点を強調しておくとよさそうです。

ただし、全ての障害を Agent が解決できるわけではありません。既知パターンの根本原因分析が得意で、未知の障害や複雑なアプリケーションロジックのバグは人間の判断が必要です。「調査・初動分析を自動化して、人間は判断とアクションに集中する」という分担がリアルなゴールです。

費用感を踏まえた上で、実際に構築してハマりやすいポイントを共有します。

ハマりポイント4選

実際に構築する上で注意すべきポイントを共有します。

1. HMAC署名の仕様違反（最頻出の403原因）

DevOps Agent の Webhook 認証は仕様が極めて厳格です。以下のどれか1つでも間違えると 403 Forbidden で弾かれます。

• ヘッダー名: x-amzn-event-timestamp / x-amzn-event-signature（独自のヘッダー名にしない）
• タイムスタンプ: ISO 8601 形式（Unixエポック秒ではない）
• 連結区切り: コロン :（ドット . ではない）
• エンコード: Base64（hex ではない）

→ Step 2 のコードをそのまま使うのが確実です。署名まわりを独自実装すると高確率でハマります。

2. IAMロールの信頼ポリシーとプリンシパル

Agent Space の IAM ロールの信頼ポリシーで、プリンシパルを aidevops.amazonaws.com に設定する必要があります。devops-agent.amazonaws.com と書くと Agent がリソースにアクセスできません。また、Condition で aws:SourceAccount と aws:SourceArn を絞り込むのがベストプラクティスです。

→ Step 1 の信頼ポリシーで <YOUR_ACCOUNT_ID>、<REGION>、<SPACE_ID> を実際の値に置き換えてください。

3. IAMロールの権限不足

DevOps Agent が調査中に AccessDenied で止まるケースがあります。Agent Space の IAM ロールに logs:FilterLogEvents を付け忘れるのが典型パターンです。

→ Step 1 の IAM ポリシーを漏れなく付与してください。特に logs:FilterLogEvents と cloudwatch:GetMetricData は忘れやすい権限です。

4. EventBridge ルールのイベントパターンの罠

detail-type を "CloudWatch Alarm State Change" と正確に書かないとマッチしません。"CloudWatch Alarm" だけだとイベントが素通りします。

→ EventBridge コンソールの「サンドボックス」機能でイベントパターンをテストしてから本番適用するのがおすすめです。

ハマりポイントを押さえれば、構成自体はシンプルです。最後にまとめます。

まとめ

CloudWatch → EventBridge → Lambda → DevOps Agent の4段構成で、アラーム発火から自動調査開始まで約3分のパイプラインが完成します。Lambda の Webhook Bridge が HMAC 署名をハンドリングする部分が唯一の難所ですが、Step 2 のコードをそのまま使えばほぼ詰まりません。

月間100件のアラーム対応で月額約$400。人間のオンコール対応コストと比べれば十分検討に値する水準です。Enterprise Support を契約済みの企業なら、クレジット還元でさらに実質コストは下がります。

まずは DevOps Agent のコンソールを開いて、Agent Space を1つ作るところから始めてみてください。

関連記事 AWS DevOps Agent の導入、自社でどこから始めるか 規模・体制・承認フロー別の導入ロードマップをまとめています。

参考文献

• AWS DevOps Agent ユーザーガイド — 公式ドキュメント
• AWS DevOps Agent FAQ — 料金体系・対応リージョン・前提条件
• sample-aws-devops-agent-cloudwatch（GitHub） — AWS公式サンプル（SAMテンプレート付き）