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

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

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

この記事では、CloudWatch → EventBridge → AWS DevOps Agentで、アラーム発火を起点に自動調査を始める構成パターンをLambdaコード付きで解説します。開始までの時間はEventBridge、Lambda、外部接続、DevOps Agent側の処理状況で変わるため、固定値では扱いません。

この記事で分かること

• 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 アカウント・ツール・権限を定義する論理的な境界で、本番用と検証用で分けるのがベストプラクティスです。

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

従来のインシデント対応フローを振り返ってみましょう。手動のインシデント対応では、「アラーム発火→通知確認→ログイン→ログ確認→メトリクス横断チェック→原因候補の整理」という工程が発生します。所要時間は体制と障害内容で変わるため、導入前に現在の初動時間を計測しておくと、自動化後と比較できます。

DevOps Agent を導入した構成では、アラーム状態の変化をEventBridgeで受け、LambdaからDevOps Agentへ調査依頼を送れます。人は調査結果の妥当性を確認し、緩和策を実行するか判断します。

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

全体アーキテクチャ

この構成のポイントは 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 が返ってきます。

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/回です。実際の見積もりには、PoCで計測した調査時間を使いましょう。なお、Agentが待機中（アイドル中）は課金されません。

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

この表はDevOps Agent本体だけの試算です。Lambda、EventBridge、CloudWatch Logsなどは各サービスの標準料金で別途課金されます。

新規顧客には2ヶ月間の無料トライアルがあり、毎月インシデント調査20時間・予防的評価15時間・オンデマンドタスク20時間が無料で使えます。20時間のインシデント調査は、1回8分と仮定すると月150回分に相当します。

また、AWS Support プランごとの月次クレジット還元率です。本番稟議の判断材料になるため、ここで押さえておきましょう。

Enterprise Support を契約済みなら、前月のSupport料金の75%に相当するクレジットで、DevOps Agent の利用料を相殺できます。利用料がこの枠に収まる場合は本体の追加負担を抑えられるため、社内稟議でも伝えておくとよさそうです。自社のSupport請求額とDevOps Agentの利用見込みを並べて、相殺できる額を確認しておきましょう。付与・適用条件は AWS公式の料金ページで確認できます。

ただし、全ての障害を 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段構成で、アラーム発火を起点に自動調査を開始できます。LambdaのWebhook BridgeではHMAC署名の形式を正確に合わせる必要があります。Step 2のコードを構成例に、エンドポイント、SSM Parameter Store、IAM権限、タイムアウト、リトライ方針を自社環境で検証していきましょう。

1回8分の調査を月間100件行う仮定なら、DevOps Agent本体は月額約$398です。周辺サービスの料金も含め、人の調査時間をどれだけ減らせるかと合わせて検討してみましょう。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テンプレート付き）