AWS Systems Manager Incident Manager は新規顧客に公開されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[AWS Systems Manager Incident Manager 可用性の変更](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.html)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS Systems Manager Incident Manager 可用性の変更
慎重に検討した後、 AWS は 2025 年 11 月 7 日以降、 AWS Systems Manager Incident Manager への新規顧客の受け入れを停止することを決定し、今後は Incident Manager に新機能や機能を追加しません。 AWS は Incident Manager のセキュリティと可用性に引き続き投資し、既存の Incident Manager のお客様は Incident Manager が既に有効になっているアカウントで通常どおりサービスを使用できるようになります。
Incident Manager は新機能を追加しなくなるため、インシデント管理の代替案を理解することが重要です。代替方法の詳細については、「」を参照してください[移行ガイド](migration-guides.md)。
Incident Manager から代替ソリューションに移行する場合は、さらなる分析またはアーカイブの目的でインシデントデータをエクスポートすることをお勧めします。詳細については、「[Incident Manager データのエクスポート](export-data.md)」を参照してください。
移行が完了したら、残りの Incident Manager リソースをクリーンアップして、継続的な料金が発生しないようにすることをお勧めします。詳細については、「[Incident Manager リソースのクリーンアップ](migration-cleanup.md)」を参照してください。
サポートの詳細については、テクニカルアカウントマネージャーに問い合わせるか[、 のサポートセンターでサポートケースを作成](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)してください AWS マネジメントコンソール。
# 移行ガイド
は新機能を追加 AWS Systems Manager Incident Manager しなくなるため、インシデント管理の代替案を理解することが重要です。このセクションでは、Incident Manager から代替ソリューションへの移行に役立つ移行ガイドを提供します。
AWS インフラストラクチャの運用上の問題を管理するには、[AWS Systems Manager OpsCenter ](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)を使用することをお勧めします。ページングとレスポンスの自動機能については、 [AWS パートナーネットワークパートナー](https://partners.amazonaws.com/)が提供するソリューションをお勧めします。 AWS ソリューションアーキテクトとテクニカルアカウントマネージャーは、特定の要件に基づいて最適なオプションを案内できます。
パートナーソリューションとの統合については、以下の移行ガイドも参照してください。
+ [AWS Systems Manager OpsCenter への移行](migration-opscenter.md)
+ [Jira Service Management への移行](migration-jira.md)
+ [ServiceNow への移行](migration-servicenow.md)
+ [PagerDuty への移行](migration-pagerduty.md)
# AWS Systems Manager OpsCenter への移行
このガイドは、Incident Manager と OpsCenter の主な違いを理解し、OpsCenter が運用ニーズに適しているかどうかを判断し、 AWS Systems Manager Incident Manager から OpsCenter に移行する方法を提供するのに役立ちます。
の一機能である [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) は AWS Systems Manager、オペレーションエンジニアや IT プロフェッショナルが AWS リソースに関連する運用作業項目 (OpsItems) を表示、調査、解決できる一元的な場所を提供します。OpsCenter は、 AWS リソースに影響を与える問題の平均解決時間 (MTTR) を短縮するように設計されています。OpsCenter では、各 OpsItem、関連する OpsItems、関連リソースに関するコンテキスト調査データを提供しながら、サービス全体で OpsItems を集約および標準化します。OpsCenter は Systems Manager Automation と統合されているため、Automation ランブックを使用して問題を調査および解決できます。OpsItems に関する自動生成された概要レポートをステータスとソース別に表示できます。[OpsCenter のクロスアカウント](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-setting-up-cross-account.html)機能を使用して、アカウント間で OpsItems を一元管理することもできます。
**注記**
OpsCenter の使用には料金がかかります。詳細については、[AWS Systems Manager 料金表ページ](https://aws.amazon.com/systems-manager/pricing/)を参照してください。
Incident Manager と同様に、OpsCenter は Amazon CloudWatch および Amazon EventBridge と統合されています。つまり、CloudWatch アラームが `ALARM`状態になったとき、または EventBridge がイベントを発行 AWS のサービス する からイベントを処理するときに、OpsCenter で OpsItem OpsItem を自動的に作成するようにこれらのサービスを設定できます。OpsItems を自動的に作成するように CloudWatch アラームと EventBridge イベントを設定すると、単一のコンソールから AWS リソースの問題をすばやく診断して修正できます。
## 違いを理解する
AWS Systems Manager Incident Manager は、自動対応計画、応答者のエンゲージメントとエスカレーション、オンコールローテーション管理、ランブック自動化、チャットオペレーション統合 (Slack、Microsoft Teams、Amazon Chime)、インシデント後分析などのインシデント対応機能を提供します。これらの機能は、 AWSホストされたアプリケーションに影響する重要で時間的制約のあるインシデントを組織が調整および解決するのに役立ちます。
対照的に、 AWS Systems Manager OpsCenter は、セキュリティアラート、パフォーマンスの低下、リソースの障害、ヘルス通知、状態の変化などのday-to-day運用上の問題に対する運用作業項目 (OpsItems) の管理に焦点を当てています。OpsCenter は、Amazon CloudWatch と Amazon EventBridge を介して AWS リソースと統合され、Systems Manager Automation ランブックを使用した OpsItem の自動作成と修復を可能にします。OpsCenter は、リージョン内の OpsItems のクロスアカウント管理をサポートしているため、運用チームは複数の AWS アカウントにわたる問題を表示、調査、解決できます。ただし、OpsCenter にはページングまたはオンコールローテーション機能は含まれません。
これら 2 つの AWS サービスの主な違いは、その焦点と範囲にあります。Incident Manager は重要で時間的制約のあるインシデント対応向けに設計されており、OpsCenter はより広範な運用タスクと作業項目の管理を目指しています。
次の表は、Incident Manager と OpsCenter の主な機能を比較したものです。この比較を使用して、OpsCenter が運用ニーズに適しているかどうかを判断します。
| 機能 | AWS Systems Manager Incident Manager | AWS Systems Manager OpsCenter |
| --- | --- | --- |
| 主な目的 | 重要で時間的制約のあるインシデント対応と調整 | Day-to-dayの作業項目管理 |
| ユースケース | アプリケーションに影響するインシデント、セキュリティ違反、サービス停止、重大なシステム障害 | セキュリティアラート、パフォーマンスの低下、リソースの障害、ヘルス通知、状態の変更 |
| 自動ページング | はい - 組み込みのページングとレスポンダーエンゲージメント | いいえ - サードパーティーの統合が必要 (PagerDuty、ServiceNow、Jira) |
| 通話中のローテーション管理 | はい - ネイティブのオンコールスケジュールとローテーション | いいえ - サポートされていません |
| エスカレーションポリシー | はい - 自動エスカレーションチェーン | いいえ - 手動エスカレーションが必要 |
| Chat-Ops の統合 | はい - Slack、Microsoft Teams、Amazon Chime | 制限あり - 手動統合が必要 |
| ランブックの自動化 | はい - 対応計画による自動実行 | はい - Systems Manager Automation ランブックの手動実行 |
| クロスアカウント管理 | はい - クロスアカウントインシデント共有 | はい - リージョン内のクロスアカウント OpsItem 管理 |
## 移行オプション
Incident Manager と統合された既存の CloudWatch アラームと EventBridge ルールがある場合は、それらを更新して OpsCenter と統合する必要があります。次のいずれかのアプローチを使用して移行できます。
ランブックを使用した自動移行
[Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) ランブックを使用して、CloudWatch アラームと EventBridge ルールを Incident Manager から OpsCenter に自動的に移行します。このアプローチには、バックアップ、設定可能な承認ワークフロー、詳細なログ記録が含まれます。移行前に手動承認を要求するか、自動大規模移行の承認ステップをスキップするかを選択できます。手順については、「[OpsCenter での移行ランブックの使用](migration-opscenter-runbooks.md)」を参照してください。
手動統合
CloudWatch アラームと EventBridge ルールを手動で設定して、OpsCenter と統合します。手順については、Systems Manager ユーザーガイドの[OpsItems を作成する CloudWatch アラーム](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)の設定」および[OpsItems を作成する EventBridge の設定](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-automatically-create-OpsItems-2.html)」を参照してください。
## 関連リソース
+ [AWS Systems Manager OpsCenter ユーザーガイド](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [Incident Manager データのエクスポート](export-data.md)
+ [Incident Manager リソースのクリーンアップ](migration-cleanup.md)
# OpsCenter での移行ランブックの使用
このガイドでは、自動移行ランブックを使用してAmazon CloudWatch アラームと Amazon EventBridge ルールを AWS Systems Manager Incident Manager から AWS Systems Manager OpsCenter に移行するstep-by-stepについて説明します。
OpsCenter 機能の概要と Incident Manager と OpsCenter の違いについては、「」を参照してください[AWS Systems Manager OpsCenter への移行](migration-opscenter.md)。
## 移行の概要
移行プロセスでは、[Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) ランブックを使用して、既存の CloudWatch アラームと EventBridge ルールを OpsCenter と統合します。このプロセスには、以下のステップが含まれます。
+ **インフラストラクチャのデプロイ** - CloudFormation スタックをデプロイして、移行ランブックに必要なリソースを作成します。
+ **CloudWatch アラームと EventBridge ルールの移行** - オートメーションランブックを実行して、リソースを OpsCenter に移行します。
+ **リソースのクリーンアップ** - オプションで、レプリケーションセットとその他の Incident Manager リソースを削除します。
**注記**
ランブックは、単一のアカウントとリージョンのペアの移行をサポートします。複数のアカウントまたはリージョンにリソースがある場合は、アカウントとリージョンの組み合わせごとに個別に移行を実行する必要があります。
## ステップ 1: CloudFormation テンプレートをデプロイする
CloudFormation テンプレートをデプロイして、移行ランブックに必要な IAM ロール、Amazon S3 バケット、Amazon SNS トピックを作成します。
### 必要な IAM 許可
この CloudFormation テンプレートをデプロイするには、 CloudFormation スタックオペレーション (`cloudformation:CreateStack`、`cloudformation:DescribeStacks`)、IAM ロール管理 (`iam:CreateRole`、`iam:PutRolePolicy`、`iam:PassRole`)`iam:AttachRolePolicy`、Amazon S3 バケットの作成と設定 (`s3:CreateBucket`、`s3:PutBucket*`)、および Amazon SNS トピックオペレーション (`sns:CreateTopic`、`sns:Subscribe`、) の IAM アクセス許可が必要です`sns:SetTopicAttributes`。
アクセス CloudFormation 許可の詳細については、「 CloudFormation ユーザーガイド」の「 アクセス[CloudFormation 許可リファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)」を参照してください。
### コンソールを使用して CloudFormation テンプレートをデプロイするには
1. `AWS-IncidentManager-MigrationResources.yaml` テンプレートを含む [AWS-IncidentManager-MigrationResources.zip](./samples/AWS-IncidentManager-MigrationResources.zip) ファイルをダウンロードして抽出します。
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation) で CloudFormation コンソールを開きます。
1. **[スタックの作成]** を選択してください。
1. **[テンプレートの指定]** セクションで、**[テンプレートファイルのアップロード]** を選択します。
1. **ファイルの選択**を選択し、`AWS-IncidentManager-MigrationResources.yaml`ファイルを選択します。
1. [**次へ**] を選択します。
1. **スタックの詳細を指定**ページで、次のように入力します。
+ **スタック名** - 名前を入力します (例: `im-migration-infrastructure`)
+ **ApprovalEmail** - 承認通知を受信する E メールアドレスを入力します (RequireManualApproval ランブックパラメータが true に設定されている場合にのみ使用されます）。
+ **IsPrimaryMigrationRegion** - スタックをデプロイするアカウント内の最初のリージョン`true`の場合は を選択し、それ以外の場合は を選択します。 `false`
1. [**次へ**] を選択します。
1. **[スタックオプションの設定]** ページで、**[次へ]** を選択します。
1. **レビュー**ページで、下にスクロールし、 **がカスタム名で IAM リソースを作成する CloudFormation 可能性があることを承認**します。
1. [**Submit**] を選択してください。
CloudFormation に`CREATE_IN_PROGRESS`ステータスが表示されます。スタックの準備が完了すると、ステータスは `CREATE_COMPLETE` に変わります。
**注記**
複数のリージョンに CloudWatch アラームまたは EventBridge ルールがある場合は、移行を実行する各リージョンにこの CloudFormation スタックをデプロイします。
AWS Organizations 間でマルチアカウントデプロイを行う場合は、次の 2 つの CloudFormation StackSets を使用します。
**プライマリ StackSet** - アカウントごとに 1 つのリージョンで IsPrimaryMigrationRegion を true に設定します
**セカンダリ StackSet** - 他のすべてのリージョンで IsPrimaryMigrationRegion を false に設定します
手順については、「 CloudFormation ユーザーガイド」の[CloudFormation StackSets の使用](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)」を参照してください。
### を使用して CloudFormation テンプレートをデプロイするには AWS CLI
アカウントの最初のリージョンでは、次のコマンドを使用します。
```
aws cloudformation create-stack \
--stack-name im-migration-infrastructure \
--template-body file://AWS-IncidentManager-MigrationResources.yaml \
--parameters ParameterKey=ApprovalEmail,ParameterValue=your-email@example.com \
ParameterKey=IsPrimaryMigrationRegion,ParameterValue=true \
--capabilities CAPABILITY_NAMED_IAM \
--region us-east-1
```
同じアカウント内の追加のリージョンについては、 `IsPrimaryMigrationRegion`を に設定します`false`。
```
aws cloudformation create-stack \
--stack-name im-migration-infrastructure \
--template-body file://AWS-IncidentManager-MigrationResources.yaml \
--parameters ParameterKey=ApprovalEmail,ParameterValue=your-email@example.com \
ParameterKey=IsPrimaryMigrationRegion,ParameterValue=false \
--capabilities CAPABILITY_NAMED_IAM \
--region us-west-2
```
スタックのステータスを確認するには:
```
aws cloudformation describe-stacks \
--stack-name im-migration-infrastructure \
--query 'Stacks[0].StackStatus' \
--output text
```
コマンドが戻るまで待って`CREATE_COMPLETE`から、次のステップに進みます。
## ステップ 2: CloudWatch アラームと EventBridge ルールを移行する
Systems Manager Automation ランブックを使用して、CloudWatch アラームと EventBridge ルールを Incident Manager から OpsCenter に移行します。
### 移行ランブック
+ [AWS-MigrateIncidentManagerCloudWatchAlarms](https://console.aws.amazon.com/systems-manager/documents/AWS-MigrateIncidentManagerCloudWatchAlarms)
+ [AWS-MigrateIncidentManagerEventBridgeRules](https://console.aws.amazon.com/systems-manager/documents/AWS-MigrateIncidentManagerEventBridgeRules)
詳細なステップの説明、入力パラメータ、出力など、これらのランブックの動作の詳細については、ランブックのドキュメントを参照してください。
### ランブックの仕組み
どちらの移行ランブックも同じワークフローに従います。
+ **検出とバッチ処理** - Incident Manager 対応計画アクションで設定されたすべての CloudWatch アラームまたは EventBridge ルールを検出し、設定可能なバッチに整理します。
+ **手動承認 (オプション)** - デフォルトでは、移行に進む前に 24 時間のタイムアウトで明示的な承認が必要です。Amazon SNS 通知は、 CloudFormation デプロイ中に指定された E メールアドレスに送信されます。すべての設定は Amazon S3 にバックアップされ、移行するリソースの完全なリストは手動レビューのために保存されます。このステップは、RequireManualApproval を false に設定することでスキップできます。
+ **バックアップと移行** - 手動承認が true に設定されている場合、 は承認を待ってから各設定を Amazon S3 にバックアップし、移行を実行します。false に設定すると、 は直接バックアップと移行に進みます。
### 入力パラメータ
どちらのランブックにも次のパラメータが必要です。
AutomationAssumeRole (必須)
CloudFormation スタックによって`IM-Migration-Automation-Role`作成された の ARN。
ApproverArn (必須)
移行を確認して承認できる IAM ロールまたはユーザーの ARN。
S3BucketName (必須)
CloudFormation スタックによって作成された Amazon S3 バケットの名前。
SNSTopicArn (必須)
CloudFormation スタックによって作成された Amazon SNS トピックの ARN。
MaxNumberOfAlarmsToMigrate または MaxNumberOfRulesToMigrate (オプション)
1 回の実行で移行するリソースの最大数。有効な値: 1、5、10、50、100、500、5000、10000、25000、50000。デフォルト：10000
BatchSize (オプション)
各バッチで処理するリソースの数。有効な値: 25、50、100、200、250、300、350、400、450、500。デフォルト: 100。ランブックは、実行ごとに最大 100 × BatchSize リソースをサポートします。
RequireManualApproval (オプション)
移行前に手動承認が必要かどうかを制御するブール値。true (デフォルト) に設定すると、リソースリストの Amazon S3 の場所と、承認、拒否、またはキャンセルする自動化実行コンソールへのリンクが記載された Amazon SNS 通知メールが送信されます。 Amazon S3 false に設定すると、ランブックは検出とバックアップの後に自動的に処理されます。有効な値: true、false。デフォルト: true。
### コンソールを使用して移行するには
1. [https://console.aws.amazon.com/ Systems Manager](https://console.aws.amazon.com/systems-manager) で Systems Manager コンソールを開きます。
1. ナビゲーションペインで **[オートメーション]** を選択します。
1. ランブック名 (`AWS-MigrateIncidentManagerCloudWatchAlarms` または `AWS-MigrateIncidentManagerEventBridgeRules`) を検索します。
1. [**Execute automation (自動化の実行)**] を選択してください。
1. CloudFormation スタック出力のパラメータ値を入力します。
1. (オプション) 手動承認ステップをスキップ`false`する場合は、**RequireManualApproval** を に設定します。
1. **[実行]** を選択してください。
1. `RequireManualApproval` が true (デフォルト) に設定されている場合、実行が手動レビューを待つと E メール通知が送信されます。E メールには、自動化実行コンソールページへの承認リンクが含まれています。Amazon S3 バケットのリソースリストを確認し、E メールリンクまたはコンソールページから 24 時間以内に承認、拒否、またはキャンセルします。移行は承認後にのみ続行されます。false に設定すると、バックアップ後に移行が自動的に続行されます。
1. 実行ステータスが**成功**に変わるまで待ちます。
### を使用して移行するには AWS CLI
**CloudWatch アラームの場合:**
```
aws ssm start-automation-execution \
--document-name "AWS-MigrateIncidentManagerCloudWatchAlarms" \
--parameters '{
"AutomationAssumeRole": ["arn:aws:iam::123456789012:role/IM-Migration-Automation-Role"],
"ApproverArn": ["arn:aws:iam::123456789012:role/Admin"],
"S3BucketName": ["im-migration-logs-123456789012-us-east-1"],
"SNSTopicArn": ["arn:aws:sns:us-east-1:123456789012:Automation-IM-Migration-Approvals"],
"RequireManualApproval": ["false"]
}' \
--region us-east-1
```
**EventBridge ルールの場合:**
```
aws ssm start-automation-execution \
--document-name "AWS-MigrateIncidentManagerEventBridgeRules" \
--parameters '{
"AutomationAssumeRole": ["arn:aws:iam::123456789012:role/IM-Migration-Automation-Role"],
"ApproverArn": ["arn:aws:iam::123456789012:role/Admin"],
"S3BucketName": ["im-migration-logs-123456789012-us-east-1"],
"SNSTopicArn": ["arn:aws:sns:us-east-1:123456789012:Automation-IM-Migration-Approvals"],
"RequireManualApproval": ["false"]
}' \
--region us-east-1
```
Amazon S3 でリソースリストを確認するには:
```
# For CloudWatch alarms
aws s3 cp s3://im-migration-logs-123456789012-us-east-1/review/CloudWatch/review_CW_alarms_to_migrate_123456789012_us-east-1.json ./
# For EventBridge rules
aws s3 cp s3://im-migration-logs-123456789012-us-east-1/review/EventBridge/review_EB_rules_to_migrate_123456789012_us-east-1.json ./
```
RequireManualApproval が true に設定されている場合は、リソースリストを確認し、E メール通知の承認リンクをクリックするか、オートメーション実行コンソールページから移行を承認します。false に設定すると、バックアップ後に自動的に移行が続行されます。
## ステップ 3: 移行を検証する
移行が完了したら、リソースが正しく機能していることを確認します。
+ **テストアラームまたはイベントをトリガー**する - 移行した CloudWatch アラームまたは EventBridge ルールのいずれかをアクティブ化してテスト通知を生成します。
+ **OpsItem の作成を確認する** - アラームまたはイベントがトリガーされたときに OpsCenter で OpsItem が自動的に作成されることを確認します。 OpsCenter
+ **重要度マッピングを検証する** - 元の Incident Manager 設定の重要度レベルが OpsItem に正しく保持されていることを確認します。(CloudWatch アラームにのみ適用されます）。
## ステップ 4: Incident Manager リソースをクリーンアップする
CloudWatch アラームと EventBridge ルールを正常に移行したら、オプションで Incident Manager リソースをクリーンアップして、サービスから完全にオフボードできます。
レプリケーションセット、対応計画、連絡先、ランブック、その他の Incident Manager リソースを削除する詳細な手順については、「」を参照してください[Incident Manager リソースのクリーンアップ](migration-cleanup.md)。
### CloudFormation スタックの削除 (オプション)
CloudFormation スタックを削除して、移行用に作成された IAM ロール、Amazon SNS トピック、および Amazon S3 バケットを削除できます。
**重要**
移行されたすべてのリソースのバックアップを含む Amazon S3 バケットは、スタックを削除する前に空にする必要があります。 オブジェクトを含む Amazon S3 バケット CloudFormation は削除できません。
** CloudFormation スタックを削除するには**
```
aws cloudformation delete-stack --stack-name
```
## モニタリングとトラブルシューティング
**CloudWatch Logs** - 移行アクティビティは CloudWatch Logs に記録されます。
+ CloudWatch アラーム: `/aws/ssm/incidentmanager/cwmigration`
+ EventBridge ルール: `/aws/ssm/incidentmanager/ebmigration`
**Amazon S3 バックアップ構造** - 移行前にすべての設定が Amazon S3 にバックアップされます。
```
migration-logs-{AccountId}-{Region}/
├── backups/
│ ├── CloudWatch/
│ │ └── {AccountId}/
│ │ └── {Region}/
│ │ └── {AlarmName}_backup.json
│ └── EventBridge/
│ └── {AccountId}/
│ └── {Region}/
│ └── {RuleName}_backup.json
└── review/
├── CloudWatch/
│ └── review_CW_alarms_to_migrate_{AccountId}_{Region}.json
└── EventBridge/
└── review_EB_rules_to_migrate_{AccountId}_{Region}.json
```
**一般的な問題:**
+ **Amazon SNS 通知が受信されない** (RequireManualApproval=true の場合) - Amazon SNS トピックサブスクリプションを確認します。
```
aws sns list-subscriptions-by-topic --topic-arn
```
+ **部分的な移行の失敗** - CloudWatch Logs で詳細なエラーメッセージを確認し、バッチサイズを小さくして自動化を再試行します。
**ロールバック手順:**
移行をロールバックする必要がある場合:
+ Amazon S3 からバックアップを取得します。
```
aws s3 sync s3://im-migration-logs-123456789012-us-east-1/backups/ ./backups/
```
+ リソースの復元:
```
# For CloudWatch alarms
aws cloudwatch put-metric-alarm --cli-input-json file://backups/CloudWatch/123456789012/us-east-1/MyAlarm_backup.json
# For EventBridge rules
aws events put-targets --rule MyRule --targets file://backups/EventBridge/123456789012/us-east-1/MyRule_backup.json
```
## よくある質問
Q: 承認中にオートメーションがタイムアウトした場合どうなりますか?
A: 承認を受け取らない場合、自動化は 24 時間後にタイムアウトします。同じパラメータを使用してオートメーションを再起動できます。
Q: リージョン間でリソースを移行できますか?
A: いいえ。各リージョンは、リージョン固有のオートメーション実行を使用して個別に移行する必要があります。
Q: 移行にはどれくらいの時間がかかりますか?
A: 移行時間はリソースの数によって異なります。
+ \$1100 アラーム/ルール: 5～10 分
+ ～1000 アラーム/ルール: 30～60 分
+ \$110,000 アラーム/ルール: 2～4 時間
Q: 重要度は OpsCenter への移行後も保持されますか?
A: はい。Incident Manager 対応計画の影響レベルで設定された重要度は保持され、CloudWatch アラームの移行中に適切な OpsCenter 重要度レベルに自動的にマッピングされます。これは EventBridge ルールには適用されません。
Q: オートメーションランブックの実行に対して課金されますか?
A: いいえ。移行自動化ランブックには実行料金はかかりません。ただし、移行後の OpsCenter の使用には料金が発生します。詳細については、[Systems Manager の料金](https://aws.amazon.com/systems-manager/pricing/)ドキュメントを参照してください。
## 関連リソース
+ [AWS Systems Manager OpsCenter への移行](migration-opscenter.md)
+ [AWS Systems Manager OpsCenter ユーザーガイド](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [Systems Manager の自動化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Incident Manager データのエクスポート](export-data.md)
+ [Incident Manager リソースのクリーンアップ](migration-cleanup.md)
# Jira Service Management への移行
[Jira Service Management (JSM) ](https://www.atlassian.com/software/jira/service-management/features/itsm#incident-management)は、チームが E メール、チャット、ヘルプセンター、ウィジェットなどの複数のチャネルを通じて従業員および顧客のリクエストを受信、追跡、管理、解決するのに役立つ IT サービス管理 (ITSM) ソリューションです。Jira プラットフォーム上に構築された Jira Service Management は、開発から IT、人事まで、組織全体のチームがリクエストを受け取り、アラートやインシデントに対応し、変更をデプロイし、アセットを追跡し、知識を深め、ワークフローを自動化できるようにします。Jira Service Management には、DevOps ワークフロー用に設計されたオンコールスケジューリング、アラート、主要なインシデント管理、変更管理、責任のない事後分析 (PIR) 機能などのインシデント管理機能が含まれており、既存の CI/CD パイプラインと自動化を活用して手動作業を削減します。
Jira Service Management は Amazon CloudWatch および Amazon EventBridge と統合されているため、CloudWatch アラームが `ALARM`状態になったとき、または EventBridge がイベントを発行 AWS のサービス する からイベントを処理するときに、Jira Service Management アラートを自動的に作成できます。Jira Service Management アラートを自動的に作成するように CloudWatch アラームと EventBridge イベントを設定すると、単一のプラットフォームから AWS リソースの問題をすばやく診断して修正できます。Jira Service Management はディスパッチャーとして機能し、オンコールスケジュールとエスカレーションポリシーに基づいて、複数のチャネル (E メール、SMS、電話、モバイルプッシュ) を通じて適切なユーザーに通知します。
既存の CloudWatch アラームと EventBridge ルールが と統合されている場合は AWS Systems Manager Incident Manager、代わりに Jira Service Management を使用するようにこれらの統合を更新することをお勧めします。Atlassian の公式ドキュメントには、[Jira Service Management と CloudWatch の統合](https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-amazon-cloudwatch/)と [Jira Service Management と EventBridge の統合](https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-amazon-eventbridge/)に関する詳細な手順が記載されています。
Jira Service Management は、自動アラート作成に加えて、オンコールスケジューリング、エスカレーションポリシー、自動化ルールなど、インシデント管理を合理化するためのさまざまな機能を提供します。これらの機能の設定の詳細については、次の Atlassian ドキュメントを参照してください。
+ [アラートとオンコールの検出](https://support.atlassian.com/jira-service-management-cloud/docs/discover-alerting-and-on-call/)
+ [オンコールスケジュールを作成する](https://support.atlassian.com/jira-service-management-cloud/docs/create-an-on-call-schedule/)
+ [エスカレーションポリシーの作成](https://support.atlassian.com/jira-service-management-cloud/docs/create-edit-delete-an-escalation-policy/)
+ [チームおよび人材をセットアップする](https://support.atlassian.com/platform-experiences/docs/start-an-atlassian-team/)
+ [問い合わせ方法の設定](https://support.atlassian.com/jira-service-management-cloud/docs/add-contact-methods/)
+ [通知ルールの設定](https://support.atlassian.com/jira-service-management-cloud/docs/add-notification-rules/)
+ [SMS および音声通知を設定する](https://support.atlassian.com/jira-service-management-cloud/docs/set-up-sms-and-voice-notifications/)
+ [自動化ルールの設定](https://www.atlassian.com/software/jira/service-management/product-guide/tips-and-tricks/automation#overview)
+ [インシデントステークホルダーの設定と管理](https://support.atlassian.com/jira-service-management-cloud/docs/how-can-i-add-and-manage-internal-stakeholders/)
サポートの詳細については、テクニカルアカウントマネージャーまたは [Atlassian 販売担当者](https://www.atlassian.com/enterprise/contact)にお問い合わせください。
# ServiceNow への移行
ServiceNow [Incident Management](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-management/concept/c_IncidentManagement.html) は、ビジネスへの影響を最小限に抑えながら、予期しない中断後に通常のサービスオペレーションを復元するように設計されたコア ITSM モジュールです。Incident Manager と同様に、ServiceNow Incident Management は、自動優先順位付けや組み込みエスカレーションプロセスなどの機能を使用して、IT インシデントを表示、調査、解決するための構造化された自動化されたシステムを提供します。
インシデント管理とイベント管理を備えた ServiceNow サービスオペレーションモジュールは Amazon CloudWatch と統合されているため、CloudWatch アラームが `ALARM`状態になったときに ServiceNow イベント/アラートとインシデントを自動的に作成できます。ウェブフックから AIOps イベント管理への ServiceNow インシデントを自動的に作成するように CloudWatch アラームを設定すると、単一のプラットフォームから AWS リソースの問題をすばやく診断して修正できます。
既存の CloudWatch アラームが と統合されている場合は AWS Systems Manager Incident Manager、代わりに ServiceNow [Incident Management](https://www.servicenow.com/products/incident-management.html) と [AIOps イベントインテリジェンス](https://www.servicenow.com/products/event-management.html)プラットフォームを使用するようにこれらの統合を更新することをお勧めします。ServiceNow の公式ドキュメントには、[ServiceNow を Amazon CloudWatch と統合](https://www.servicenow.com/docs/bundle/zurich-integrate-applications/page/administer/integrationhub-store-spokes/concept/amazon-cloudwatch.html)するための詳細な手順が記載されています。
ServiceNow Incident Management は、自動インシデント作成に加えて、インシデントコミュニケーション管理、オンコールスケジューリング、エスカレーションポリシーなど、インシデント管理を改善するさまざまな機能を提供します。これらの機能の設定の詳細については、次の ServiceNow ドキュメントを参照してください。
+ [インシデント管理ドキュメント](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-management/concept/c_IncidentManagement.html)
+ [サービスの信頼性管理](https://www.servicenow.com/docs/bundle/zurich-it-operations-management/page/product/service-reliability/reference/sr-landing-page.html)
+ [インシデントコミュニケーションの管理と連絡先](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-alert-management/concept/c_IncidentAlertContact.html)
+ [オンコールスケジュール](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/administer/on-call-scheduling/concept/c_OnCallScheduling.html)
+ [エスカレーションプロセス](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/administer/on-call-scheduling/concept/designing-escalation-process-oncall.html)
サポートの詳細については、テクニカルアカウントマネージャーまたは [ServiceNow 販売担当者](https://www.servicenow.com/be/contact-us/sales.html)にお問い合わせください。
# PagerDuty への移行
[PagerDuty](https://support.pagerduty.com/main/docs/introduction) は、組織がインシデントを検出、対応、さらには防止するのに役立つインシデント管理プラットフォームです。Incident Manager と同様に、PagerDuty は運用チームが AWS リソースに関連する重要な作業に取り組む一元的な場所を提供し、顧客への影響を軽減します。
PagerDuty は Amazon CloudWatch および Amazon EventBridge と統合されているため、CloudWatch アラームが `ALARM`状態になったとき、または EventBridge がイベントを発行 AWS のサービス する からイベントを処理するときに、PagerDuty インシデントを自動的に作成できます。PagerDuty インシデントを自動的に作成するように CloudWatch アラームと EventBridge イベントを設定することで、単一のプラットフォームからリソースの問題をすばやく診断して修正 AWS できます。
既存の CloudWatch アラームと EventBridge ルールが と統合されている場合は AWS Systems Manager Incident Manager、代わりに PagerDuty を使用するようにこれらの統合を更新することをお勧めします。PagerDuty の公式ドキュメントには、[PagerDuty と CloudWatch の統合](https://support.pagerduty.com/main/docs/amazon-cloudwatch-integration-guide)および [ PagerDuty と EventBridge の統合](https://support.pagerduty.com/main/docs/amazon-eventbridge-integration-guide)に関する詳細な手順が記載されています。
PagerDuty は、自動インシデント作成に加えて、オンコールスケジューリング、エスカレーションポリシー、700 を超えるout-of-boxプラットフォーム統合など、インシデント管理を改善するさまざまな機能を提供します。また、通知ルールのカスタマイズ、チャットサーフェスの設定、PagerDuty プラットフォーム内の AI とオートメーションを活用して、インシデントの解決を高速化することもできます。
+ [ユーザーを管理する](https://support.pagerduty.com/main/docs/manage-users)
+ [チームの作成](https://support.pagerduty.com/main/docs/teams)
+ [問い合わせ方法の設定](https://support.pagerduty.com/main/docs/contact-information)
+ [通知ルールの設定](https://support.pagerduty.com/main/docs/notification-rules)
+ [オンコールローテーションのセットアップ](https://support.pagerduty.com/main/docs/schedule-basics)
+ [エスカレーションポリシーの作成](https://support.pagerduty.com/main/docs/escalation-policies)
+ [Slack 統合を設定する](https://support.pagerduty.com/main/docs/slack-integration-guide)
+ [自動化アクションのセットアップ](https://support.pagerduty.com/main/docs/automation-actions)
サポートの詳細については、テクニカルアカウントマネージャーまたは [AWS-IM-help@pagerduty.com](mailto:AWS-IM-help@pagerduty.com) にお問い合わせください。
# Incident Manager データのエクスポート
このトピックでは、Python スクリプトを使用してインシデントレコードとインシデント後の分析をエクスポートする方法について説明します AWS Systems Manager Incident Manager。このスクリプトは、さらなる分析またはアーカイブの目的で、構造化された JSON ファイルにデータをエクスポートします。
## エクスポートできる内容
スクリプトは次のデータをエクスポートします。
+ 以下を含むインシデントレコードを完了します。
+ タイムラインイベント
+ 関連項目
+ エンゲージメント
+ 自動化の実行
+ セキュリティの検出結果
+ タグ
+ Systems Manager からのインシデント後分析ドキュメント
## 前提条件
開始する前に、以下の準備が整っていることを確認します。
+ Python 3.7 以降がインストールされている
+ AWS CLI 適切な認証情報で設定されている
+ 次の Python パッケージがインストールされています。
```
pip install boto3 python-dateutil
```
## 必要な IAM 許可
このスクリプトを使用するには、次のアクセス許可があることを確認してください。
Systems Manager Incidents のアクセス許可
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm-incidents:ListIncidentRecords",
"ssm-incidents:GetIncidentRecord",
"ssm-incidents:ListTimelineEvents",
"ssm-incidents:GetTimelineEvent",
"ssm-incidents:ListRelatedItems",
"ssm-incidents:ListEngagements",
"ssm-incidents:GetEngagement",
"ssm-incidents:BatchGetIncidentFindings",
"ssm-incidents:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
Systems Manager のアクセス許可
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:ListDocuments",
"ssm:GetDocument",
"ssm:GetAutomationExecution"
],
"Resource": "*"
}
]
}
```
## エクスポート構造
スクリプトは、エクスポートされたデータの次のディレクトリ構造を作成します。
```
incident_manager_export_YYYYMMDD_HHMMSS/
├── incident_records/
│ ├── 20250309_102129_IAD_Service_A_Lambda_High_Latency.json
│ ├── 20250314_114820_SecurityFinding_SecurityHubFindings.json
│ └── ...
└── post_incident_analyses/
├── 20250310_143022_Root_Cause_Analysis_Service_A.json
├── 20250315_091545_Security_Incident_Review.json
└── ...
```
## エクスポートスクリプトの実行
### 基本的な使用法
Incident Manager データエクスポートスクリプトは で提供されます`[here](samples/export-incident-manager-data.zip)`。スクリプトをダウンロードし、次の手順を使用してスクリプトを実行してください。
デフォルト設定でスクリプトを実行するには:
```
python3 export-incident-manager-data.py
```
### 利用可能なオプション
エクスポートは、次のコマンドラインオプションを使用してカスタマイズできます。
| オプション | 説明 | デフォルト |
| --- | --- | --- |
| --region | AWS リージョン | us-east-1 |
| --profile | AWS プロファイル名 | デフォルトプロファイル |
| --verbose, -v | 詳細ログ記録を有効にする | FALSE |
| --limit | エクスポートするインシデントの最大数 | 無制限 |
| --timeline-events-limit | インシデントあたりのタイムラインイベントの最大数 | 100 |
| --timeline-details-limit | インシデントあたりのタイムラインイベントの最大詳細 | 100 |
| --related-items-limit | インシデントあたりの関連項目の最大数 | 50 |
| --engagements-limit | インシデントあたりの最大エンゲージメント数 | 20 |
| --analysis-docs-limit | エクスポートする分析ドキュメントの最大数 | 50 |
### 例
カスタムプロファイルを使用して特定のリージョンからエクスポートします。
```
python3 export-incident-manager-data.py --region us-east-1 --profile my-aws-profile
```
詳細なログ記録とテストの制限を使用してエクスポートします。
```
python3 export-incident-manager-data.py --verbose --limit 5 --timeline-events-limit 10
```
大規模なデータセットの保守的な制限でエクスポートする:
```
python3 export-incident-manager-data.py --timeline-events-limit 50 --timeline-details-limit 25
```
## 出力ファイル構造
### インシデントレコードの JSON 構造
各インシデントレコードファイルには、次の構造が含まれています。
```
{
"incident_record": {
// Complete incident record from get-incident-record
},
"incident_summary": {
// Incident summary from list-incident-records
},
"incident_source_details": {
"from_incident_record": {},
"from_incident_summary": {},
"enhanced_details": {
"created_by": "arn:aws:sts::...",
"source": "aws.ssm-incidents.custom",
"source_analysis": {
"source_type": "manual",
"creation_method": "human_via_console",
"automation_involved": false,
"human_created": true
}
}
},
"timeline_events": {
"detailed_events": [
{
"summary": {}, // From list-timeline-events
"details": {} // From get-timeline-event
}
],
"summary_only_events": [],
"metadata": {
"total_events_found": 45,
"events_with_details": 25,
"limits_applied": {}
}
},
"related_items": {
"items": [],
"metadata": {}
},
"engagements": {
"engagements": [],
"metadata": {}
},
"automation_executions": [],
"findings": [],
"tags": [],
"post_incident_analysis": {
"analysis_reference": {},
"metadata": {}
},
"export_metadata": {
"exported_at": "2025-09-18T...",
"region": "us-east-*",
"incident_arn": "arn:aws:ssm-incidents::..."
}
}
```
### インシデント後分析の JSON 構造
各分析ドキュメントファイルには以下が含まれます。
```
{
"document_metadata": {
// Document metadata from list-documents
},
"document_details": {
"Name": "037fc5dd-cd86-49bb-9c3d-15720e78798e",
"Content": "...", // Full JSON content
"DocumentType": "ProblemAnalysis",
"CreatedDate": 1234567890,
"ReviewStatus": "APPROVED",
"AttachmentsContent": [],
// ... other fields from get-document
},
"export_metadata": {
"exported_at": "2025-09-18T...",
"region": "us-east-*",
"document_name": "..."
}
}
```
# Incident Manager リソースのクリーンアップ
を使用しなくなった場合は AWS Systems Manager Incident Manager、残りの Incident Manager リソースをクリーンアップすることをお勧めします。これにより、サービスから完全にオフボードされ、継続的な料金が発生しなくなります。詳細については、[AWS Systems Manager 料金ページ](https://aws.amazon.com/systems-manager/pricing/)を参照してください。
## レプリケーションセットの削除
レプリケーションセットは、Incident Manager の主要なコンポーネントであり、複数の AWS リージョンにまたがるインシデントデータのレプリケーションを容易にします。Incident Manager が不要になった場合は、レプリケーションセットを削除する必要があります。
レプリケーションセットを削除するには:
1. AWS Systems Manager コンソールを開く
1. ナビゲーションペインで、Incident Manager を選択します。
1. 「レプリケーションセット」で、削除するレプリケーションセットを見つけます。
1. レプリケーションセット名をクリックして詳細ページを開きます。
1. レプリケーションセットの詳細ページで、「削除」ボタンをクリックします。
1. 確認ダイアログで、情報を確認し、「レプリケーションセットの削除」をクリックして削除を続行します。
**注記**
レプリケーションセットを削除すると、Incident Manager に保存されているすべてのインシデントデータが完全に削除されます。削除を続行する前に、過去のインシデント情報へのアクセスが不要になったことを確認します。
## Incident Manager 関連のリソースの削除
レプリケーションセットに加えて、対応計画、連絡先、ランブックなど、他の Incident Manager 関連のリソースがある場合があります。これらのリソースが不要になった場合は、それらを削除して Incident Manager から完全にオフボードすることを検討できます。
Incident Manager 関連のリソースを削除するには:
1. AWS Systems Manager コンソールを開く
1. ナビゲーションペインで、Incident Manager を選択します。
1. 適切なセクション (「対応計画」、「連絡先」、「ランブック」など) に移動し、削除するリソースを見つけます。
1. リソースを選択し、「削除」ボタンをクリックしてリソースを削除します。