この記事の概要
- 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
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
ErrorB
Lambdaの特定のエラーをハンドリングし、Cloud Watch Alermを経由してIncident Managerに起票される。Response Planにより、管理者にSMSを送信して対応を促す。
同時にRunbookにより、エラー情報が収取されE-Mailで送信する
ErrorA
Lambdaの特定のエラーをハンドリングし、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 を使ったサンプル設定や実務上の活用例、そして商用製品との比較を紹介しました。