🐾

AWS SystemsManager - Incident Managerの使いどころ

2025/02/09に公開

AWS

 この記事の概要
Scenario: Lambda のエラーが増加 → 2種類のエラーをハンドリング (エラー A は通常インシデント、エラー B はクリティカルでエスカレーション)

Action: AWS Systems Manager Incident Manager を使い、Runbook でエラー情報を収集し Amazon SNS で通知

Goal:
設定手順の紹介 (ステップバイステップ)
Incident Manager の強み・制限
商用製品との比較と、Incident Manager で十分カバーできるケース


 なぜ Incident Manager を使うのかAWS Systems Manager Incident Manager は、AWS サービスで発生するインシデントの自動対応やエスカレーションを一元管理できるサービスです。以下のような特徴があります:

AWS とのネイティブ統合: Amazon CloudWatch アラーム、AWS Lambda イベント、Amazon EventBridge などと連携が容易。

Runbook と連携: トラブルシュートを自動化・半自動化し、必要に応じてマニュアル手順を踏むワークフローを提供。

マルチチャネル通知: Amazon SNS や Slack、Amazon Chime などを柔軟に利用可能。

コスト効率: 小～中規模であれば、他の商用インシデント管理サービスよりも安価になるケースが多い。
一方で、複雑なチーム編成や 多重エスカレーションフロー、詳細なレポーティング を必要とする大規模組織の場合は、専門の商用ソリューション（PagerDuty, ServiceNow, Datadog Incident Management など）の方が便利な場合があります。

 アーキテクチャ概要下図のように、Lambda 関数でエラーが多発した際に Amazon CloudWatch アラームが発火 → Incident Manager がインシデントを自動作成 → Runbook で情報を収集し、SNS 通知・エスカレーションフローを実行します。

 2種類のエラー想定
エラー A: 通常のインシデント対応 (警告レベル)

エラー B: クリティカル (エスカレーション必須)
これらを区別する方法として、CloudWatch アラームをそれぞれ別個で設定し、アラームが発火するたびに対応するインシデントが発行されるようにします。

 Step-by-Step: 設定手順
 Step 1. Lambda のエラーをモニタリングする CloudWatch アラームの作成Lambda(SampleFunc01)の作成。

サンプルのため簡易的なもとのします。テスト用に引数でエラーが発生するようにしています。
import logging

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

def lambda_handler(event, context):
    error_type = event.get("errorType")

    try:
        if error_type == "A":
            # 通常の Exception (エラー A)
            logger.error("Error A: A standard exception occurred.")
            raise Exception("Error A occurred")
        
        elif error_type == "B":
            # クリティカルな RuntimeError (エラー B)
            logger.error("Error B: A critical runtime error occurred.")
            raise RuntimeError("Critical Error B occurred")
        
        else:
            # 正常処理
            logger.info("No error triggered.")
            return {"statusCode": 200, "body": "Success"}
    
    except Exception as e:
        logger.exception("An error occurred: %s", e)
        raise

*CloudWatch Metrics Filter を準備

ErrorA, ErrorBをそれぞれ処理するためにMetric Filterを準備します
ErrorA用

ErrorB用

CloudWatch Alarm の作成
作成したMetric Filterに対してAlermを作成
Period: 1分 or 5分等、要件に合わせて
Threshold: 連続してエラー数が一定以上を超えた場合にアラームとなるよう設定
ErrorA用

ErrorB用

Alarm actions: 後述する Incident Manager でインシデントを作成するトリガーに設定


 Step 2. Incident Manager (Systems Manager) のセットアップIncident Manager を有効化

AWS Systems Manager コンソール > Incident Manager > Settings でオンボーディング。

 STEP 3. Contactsの作成管理者に対してEMailで通知（ErrorA用）

管理者に対してSMSで通知（ErrorB、エスカレーション用）

※E-Mail, SMSともにActivateのためのコードが発信されます

 Step 4. Escalation Planの作成今回は、ErrorAは、通常のエラー処理としてまずメールで通知、一定時間処理が行われない場合はエスカレーション。ErrorBは、エスカレーション対応が行われるという形とします。
エスカレーションの設定（現在は経過時間以外にエスカレーションする条件を設定できない様子）

 Step 5. Runbook (Automation)の作成Runbook は、インシデント発生時に自動または手動で実行される対処手順のことです。ここでは以下を想定します:

エラー情報の収集: エラーの発生源、関連する CloudWatch Logs などを取得

サンプルでは省略。Lambdaのエラー情報をCloudWatch、DynamoDBなどに出力しておいて、Runbookから読みだして送付するイメージ

通知: Amazon SNS を用いたチームへの通知
AWS Systems Manager コンソール > Automation > Create automation
schemaVersion: '0.3'
description: Sample Runbook for handling Lambda errors, collecting logs, and sending notifications.
parameters:
  AlarmName:
    type: String
    description: Name of the CloudWatch Alarm
  snsTopicArn:
    type: String
    description: SNS Topic ARN for notifications
mainSteps:
  - name: GatherErrorLogs
    action: aws:executeScript
    nextStep: SendNotification
    isEnd: false
    inputs:
      Runtime: python3.8
      Handler: script_handler
      Script: |
        def script_handler(events, context):
            # CloudWatch Logs や Lambda のメタデータを取得する処理を実装
            # 必要に応じてログをフィルタして返すなど
            return {"status": "Logs gathered",
                   "error": "必要なエラー要素"}
  - name: SendNotification
    action: aws:executeAwsApi
    isEnd: true
    inputs:
      Service: sns
      Api: Publish
      TopicArn: arn:aws:sns:us-east-1:605266020853:sample_topic
      Message: 'Lambda Errors detected. AlarmName: {{ AlarmName }}'
      Subject: Incident Manager Notification
詳細: AWS Systems Manager Automation

 Step 6. Response Planの作成Response PlanをErrorA、ErrorBそれぞれで作成します。

共通のRunbookを設定しエラー情報が通知されるように設定

※ErrorBは省略

 Step 5. CloudWatch Alarm と Incident Manager の連携最後に、作成した CloudWatch Alarm の Alarm actions に Systems Manager Incident Manager を紐づけてインシデントを自動発行する設定を行います。

Amazon CloudWatch コンソール > Alarms で該当アラームを編集


※errorBも同様に設定
これによって、エラー A 用アラームにより、responseplan_errroAが、エラー B 用アラームによりresponseplan_errroBがインシデントとして発行されるようになります

 Demo
 ErrorBLambdaの特定のエラーをハンドリングし、Cloud Watch Alermを経由してIncident Managerに起票される。Response Planにより、管理者にSMSを送信して対応を促す。

同時にRunbookにより、エラー情報が収取されE-Mailで送信する

 ErrorALambdaの特定のエラーをハンドリングし、Cloud Watch Alermを経由してIncident Managerに起票される。Response PlanによりE-Mailを送付する。

同時にRunbookにより、エラー情報が収取されE-Mailで送信する

一定時間対応が行われなかった場合、EscalationPlanが起動し、管理者へのSMS送信が行われる。
発行されたIncidentはIncident Managerで確認
設定したメッセージや、原因となった情報についても確認可能

Timelineで起票されてからのアクションが確認できる。自動で追加されるものに加え、手動で追加もできるため、左上のStatus（Open, Resolved, Closed)を補完するなど様々用途で使用する

Runbookの実行状況も確認可能

その他
Incidentは分析対象として設定可能。分析対象に設定すると指定のテンプレートによりポストモーテムや原因分析を記録することが可能
通知の有効性を制御するスケジューリング機能。深夜には電話によるインシデント通知を行わないなどの設定に使用する

 商用インシデント管理ツールとの比較
 PagerDuty / ServiceNow / Datadog Incident Management / Opsgenie など
充実したマルチチームエスカレーション: 大規模組織でのオンコール管理、シフト設定、詳細なレポート機能などが強力

サードパーティ統合: Slack・Teams との高度な連携、CI/CD パイプラインとの統合など

コスト: ユーザ数が増えると比例してコストが上がるケースが多い

 Incident Manager で十分対応できるケース
AWS サービスのみでシステムが完結する小～中規模な環境

複雑なエスカレーションフローを必要としない、シンプルな運用体制

低コストかつ容易な導入を優先したい場面
一方で、複数チームや複数プロダクトが絡む 大規模インシデント管理 を要する場合や、レポート・ダッシュボード機能を重視する場合、PagerDuty や ServiceNow などの商用ソリューションを検討する価値があります。

 まとめSystemsManagerの機能の一つIncident Managerを実査に試してみて、当たり前ではあるものの機能のリッチさから言えば、他の製品に優位性があるものの、最低限実用に足る機能は実現されていること。AWSサービスとの統合が容易であること。そして何より無料であることが最大のアドバンテージといえるでしょう（Runbookの実行はSMS送信は別途課金される）

 参考情報AWS Systems Manager Incident Manager
AWS Systems Manager Automation
Amazon CloudWatch
AWS Lambda Metrics
Amazon SNS
PagerDuty (Official Site)
ServiceNow (Official Site)
Datadog Incident Management (Official Site)
以上、アプリケーションエラー率増加時のインシデント管理手法について、Incident Manager と Runbook を使ったサンプル設定や実務上の活用例、そして商用製品との比較を紹介しました。

この記事の概要

なぜ Incident Manager を使うのか

アーキテクチャ概要

2種類のエラー想定

Step-by-Step: 設定手順

Step 1. Lambda のエラーをモニタリングする CloudWatch アラームの作成

Step 2. Incident Manager (Systems Manager) のセットアップ

STEP 3. Contactsの作成

Step 4. Escalation Planの作成

Step 5. Runbook (Automation)の作成

Step 6. Response Planの作成

Step 5. CloudWatch Alarm と Incident Manager の連携

Demo

ErrorB

ErrorA

商用インシデント管理ツールとの比較

PagerDuty / ServiceNow / Datadog Incident Management / Opsgenie など

Incident Manager で十分対応できるケース

まとめ

参考情報

Discussion