複数のAWSリージョンでクリティカルなワークロードを運用する企業があります。AWSサービスの中断が自社リソースに影響する際、オンコールチームが即座に調査を開始できるよう、カスタムコードを書かずにAWS Systems Manager OpsCenterへ自動的にOpsItemを作成したいと考えています。最も運用オーバーヘッドが少ない実装はどれですか？
Systems Manager OpsCenterはAWS Healthとのネイティブ統合を提供しており、カスタムコードなしにAWSサービス中断を自動検知してOpsItemを作成できます。 具体的には、Amazon EventBridgeでイベントソース「aws.health」を受信するルールを作成し、イベントタイプカテゴリを「issue」に設定します。OpsCenterのAWS Health統合を有効化すると、条件に合致したAWSサービス障害イベントが自動的にOpsItemとして作成され、オンコールチームが即座に調査を開始できます。この統合は複数のAWSリージョンのヘルスイベントにも対応しています。 選択肢AのCloudWatchアラーム＋Lambda実装は、カスタムコードの開発・テスト・保守が必要であり「カスタムコードを書かずに」という要件を直接満たしません。また、CloudWatchメトリクスではAWSサービス自体の障害を直接検知できない場合があります。 選択肢BのPersonal Health Dashboardの手動確認は自動化されておらず、担当者が見逃すリスクがあります。オンコールチームが即座に調査を開始するという要件に対して、手動対応では応答時間が保証されません。 選択肢DのAWS Configはリソースの設定変更や非準拠状態を検知するサービスであり、AWSサービス自体の障害イベントの検知には設計されていません。OpsItem作成にもカスタムAutomationドキュメントが必要となり、運用オーバーヘッドが増加します。