AWS Systems Manager Incident Manager n'est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour plus d'informations, consultez [AWS Systems Manager Incident Manager la section Modification de la disponibilité](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.html).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Migration vers AWS Systems Manager OpsCenter
Ce guide vous aide à comprendre les principales différences entre Incident Manager et OpsCenter à déterminer s'il OpsCenter répond à vos besoins opérationnels et propose des moyens de migrer OpsCenter vers AWS Systems Manager Incident Manager.
[AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html), une fonctionnalité de AWS Systems Manager, fournit un emplacement central où les ingénieurs des opérations et les professionnels de l'informatique peuvent consulter, étudier et résoudre les éléments de travail opérationnels (OpsItems) liés aux AWS ressources. OpsCenter est conçu pour réduire le délai moyen de résolution (MTTR) des problèmes ayant un impact sur AWS les ressources. OpsCenter agrège et normalise OpsItems l'ensemble des services tout en fournissant des données d'investigation contextuelles sur chacun des services OpsItem, ainsi que sur les ressources connexes OpsItems et connexes. OpsCenter s'intègre à Systems Manager Automation, ce qui vous permet d'utiliser les runbooks Automation pour étudier et résoudre les problèmes. Vous pouvez consulter des rapports de synthèse générés automatiquement OpsItems par statut et par source. Vous pouvez également utiliser [OpsCenterla fonctionnalité multi-comptes](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-setting-up-cross-account.html) pour gérer de manière centralisée OpsItems tous les comptes.
**Note**
Des frais sont associés à son OpsCenter utilisation. Reportez-vous à la [page de AWS Systems Manager tarification](https://aws.amazon.com/systems-manager/pricing/) pour plus de détails.
Semblable à Incident Manager, OpsCenter il est intégré à Amazon CloudWatch et Amazon EventBridge. Cela signifie que vous pouvez configurer ces services pour créer automatiquement un OpsItem in OpsCenter lorsqu'une CloudWatch alarme entre dans l'`ALARM`état ou lorsqu'il EventBridge traite un événement provenant d'un site Service AWS publiant des événements. La configuration des CloudWatch alarmes et EventBridge des événements pour qu'ils OpsItems soient créés automatiquement vous permet de diagnostiquer et de résoudre rapidement les problèmes liés aux AWS ressources à partir d'une console unique.
## Comprendre les différences
AWS Systems Manager Incident Manager fournit des fonctionnalités de réponse aux incidents, notamment des plans de réponse automatisés, l'engagement et l'escalade des intervenants, la gestion de la rotation sur appel, l'automatisation des runbooks, l'intégration des opérations de discussion (Slack, Microsoft Teams, Amazon Chime) et l'analyse post-incident. Ces fonctionnalités aident les entreprises à coordonner et à résoudre les incidents critiques et urgents affectant les applications AWS hébergées.
En revanche, il AWS Systems Manager OpsCenter se concentre sur la gestion des éléments de travail opérationnels (OpsItems) pour les problèmes day-to-day opérationnels tels que les alertes de sécurité, la dégradation des performances, les défaillances des ressources, les notifications de santé et les changements d'état. OpsCenter s'intègre aux AWS ressources via Amazon CloudWatch et Amazon EventBridge, permettant une OpsItem création et une correction automatisées à l'aide des runbooks Systems Manager Automation. OpsCenter prend en charge la gestion multicompte OpsItems au sein d'une région, permettant aux équipes opérationnelles de visualiser, d'étudier et de résoudre les problèmes liés à plusieurs AWS comptes. Toutefois, n' OpsCenter inclut pas les fonctionnalités de pagination ou de rotation sur appel.
Les principales différences entre ces deux AWS services résident dans leur objectif et leur portée. Le gestionnaire d'incidents est conçu pour répondre aux incidents critiques et urgents, tout en OpsCenter étant orienté vers la gestion de tâches opérationnelles et d'éléments de travail plus larges.
Le tableau suivant compare les principales fonctionnalités entre Incident Manager et OpsCenter. Utilisez cette comparaison pour déterminer si elle OpsCenter répond à vos besoins opérationnels.
| Fonctionnalité/capacité | AWS Systems Manager Incident Manager | AWS Systems Manager OpsCenter |
| --- | --- | --- |
| Objectif principal | Réponse et coordination aux incidents critiques et urgents | Day-to-day gestion opérationnelle des éléments de travail |
| Cas d'utilisation | Incidents ayant un impact sur les applications ; violations de sécurité ; pannes de service ; défaillances critiques du système | Alertes de sécurité ; Dégradation des performances ; Défaillances de ressources ; Notifications de santé ; Changements d'état |
| Pagination automatisée | Oui - Pagination intégrée et engagement du répondeur | Non - Nécessite une intégration tierce (PagerDuty, ServiceNow, Jira) |
| Gestion de la rotation sur appel | Oui - Horaires d'astreinte et rotation natifs | Non - Non pris en charge |
| Politiques d'escalade | Oui - Chaînes d'escalade automatisées | Non - Escalade manuelle requise |
| Intégration des Chat-Ops | Oui - Slack, Microsoft Teams, Amazon Chime | Limité - Intégration manuelle requise |
| Automatisation des runbooks | Oui - Exécution automatisée via des plans de réponse | Oui - Exécution manuelle des runbooks Systems Manager Automation |
| Gestion inter-comptes | Oui - Partage d'incidents entre comptes | Oui - OpsItem Gestion de comptes multiples au sein d'une région |
## Options de migration
Si vous avez déjà intégré des CloudWatch alarmes et des EventBridge règles à Incident Manager, vous devez les mettre à jour pour les intégrer OpsCenter. Vous pouvez effectuer la migration en utilisant l'une des approches suivantes :
Migration automatisée à l'aide de runbooks
Utilisez [les runbooks Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) pour migrer automatiquement vos CloudWatch alarmes et EventBridge règles d'Incident Manager vers OpsCenter. Cette approche inclut la sauvegarde, les flux de travail d'approbation configurables et la journalisation détaillée. Vous pouvez choisir d'exiger une approbation manuelle avant la migration ou de sauter l'étape d'approbation pour les migrations automatisées à grande échelle. Pour step-by-step obtenir des instructions, voir[Utilisation des runbooks de migration pour OpsCenter](migration-opscenter-runbooks.md).
Intégration manuelle
Configurez manuellement vos CloudWatch alarmes et vos EventBridge règles à intégrer OpsCenter. Pour obtenir des instructions, reportez-vous [aux sections Configuration des CloudWatch alarmes pour créer OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) et [Configuration EventBridge pour créer OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-automatically-create-OpsItems-2.html) dans le Guide de l'utilisateur de Systems Manager.
## Ressources connexes
+ [AWS Systems Manager OpsCenter Guide de l'utilisateur](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [Exportation des données d'Incident Manager](export-data.md)
+ [Nettoyage des ressources du gestionnaire d'incidents](migration-cleanup.md)
# Utilisation des runbooks de migration pour OpsCenter
Ce guide fournit des step-by-step instructions pour migrer vos CloudWatch alarmes Amazon et vos EventBridge règles Amazon depuis AWS Systems Manager Incident Manager vers l' AWS Systems Manager OpsCenter utilisation de runbooks de migration automatisés.
Pour un aperçu des OpsCenter fonctionnalités et pour comprendre les différences entre Incident Manager et OpsCenter, voir[Migration vers AWS Systems Manager OpsCenter](migration-opscenter.md).
## Présentation de la migration
Le processus de migration utilise [les runbooks Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) pour intégrer vos CloudWatch alarmes et EventBridge règles existantes. OpsCenter Le processus comprend les étapes suivantes :
+ **Déployer l'infrastructure** : déployez la CloudFormation pile pour créer les ressources requises pour les runbooks de migration.
+ **Migrer les CloudWatch alarmes et EventBridge les règles** : exécutez les runbooks d'automatisation vers lesquels migrer vos ressources. OpsCenter
+ **Nettoyer les ressources** : supprimez éventuellement le jeu de réplication et les autres ressources du gestionnaire d'incidents.
**Note**
Les runbooks prennent en charge la migration pour une seule paire compte-région. Si vous disposez de ressources réparties sur plusieurs comptes ou régions, vous devez exécuter la migration séparément pour chaque combinaison compte-région.
## Étape 1 : Déployer le CloudFormation modèle
Déployez le CloudFormation modèle pour créer le rôle IAM, le compartiment Amazon S3 et la rubrique Amazon SNS requis par les runbooks de migration.
### Autorisations IAM requises
Pour déployer ce CloudFormation modèle, vous avez besoin d'autorisations IAM pour les opérations de CloudFormation stack (`cloudformation:CreateStack`,`cloudformation:DescribeStacks`), la gestion des rôles IAM (`iam:CreateRole`,,`iam:PutRolePolicy`,`iam:PassRole`)`iam:AttachRolePolicy`, la création et la configuration de compartiments Amazon S3 (`s3:CreateBucket`,`s3:PutBucket*`) et les opérations sur les rubriques Amazon SNS `sns:CreateTopic` (`sns:Subscribe`,,). `sns:SetTopicAttributes`
Pour plus de détails sur CloudFormation les autorisations, consultez la [référence CloudFormation aux autorisations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) dans le guide de CloudFormation l'utilisateur.
### Pour déployer le CloudFormation modèle à l'aide de la console
1. Téléchargez et extrayez le fichier [AWS- IncidentManager - MigrationResources .zip](./samples/AWS-IncidentManager-MigrationResources.zip) qui contient le `AWS-IncidentManager-MigrationResources.yaml` modèle.
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation)
1. Sélectionnez **Créer la pile**.
1. Dans la section **Spécifier un modèle**, sélectionnez **Charger un modèle de fichier**.
1. Choisissez **Choisir un fichier**, puis sélectionnez le `AWS-IncidentManager-MigrationResources.yaml` fichier.
1. Choisissez **Suivant**.
1. Sur la page **Spécifier les détails de la pile**, entrez ce qui suit :
+ **Nom de la pile** : entrez un nom (par exemple,`im-migration-infrastructure`)
+ **ApprovalEmail**- Entrez l'adresse e-mail pour recevoir les notifications d'approbation (uniquement utilisée lorsque le paramètre RequireManualApproval runbook est défini sur true).
+ **IsPrimaryMigrationRegion**- Choisissez `true` s'il s'agit de la première région de votre compte dans laquelle vous déployez la pile, sinon choisissez `false`
1. Choisissez **Next** (Suivant).
1. Sur la page **Configurer les options de pile**, choisissez **Suivant**.
1. Sur la page de **révision**, faites défiler la page vers le bas et sélectionnez **Je reconnais que cela CloudFormation pourrait créer des ressources IAM avec des noms personnalisés**.
1. Sélectionnez **Soumettre**.
CloudFormation affiche le `CREATE_IN_PROGRESS` statut. Le statut passe au `CREATE_COMPLETE` moment où la pile est prête.
**Note**
Si vous avez des CloudWatch alarmes ou des EventBridge règles dans plusieurs régions, déployez cette CloudFormation pile dans chaque région où vous souhaitez effectuer la migration.
Pour les déploiements multi-comptes au sein d' AWS Organizations, utilisez-en deux : CloudFormation StackSets
** StackSetPrincipal** : défini IsPrimaryMigrationRegion sur true pour une région par compte
**Secondaire StackSet** : défini IsPrimaryMigrationRegion sur false pour toutes les autres régions
Pour obtenir des instructions, reportez-vous à la section [Travailler avec CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) dans le guide de CloudFormation l'utilisateur.
### Pour déployer le CloudFormation modèle à l'aide du AWS CLI
Pour la première région de votre compte, utilisez la commande suivante :
```
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
```
Pour les régions supplémentaires associées au même compte, définissez les paramètres `IsPrimaryMigrationRegion` `false` suivants :
```
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
```
Pour vérifier l'état de la pile :
```
aws cloudformation describe-stacks \
--stack-name im-migration-infrastructure \
--query 'Stacks[0].StackStatus' \
--output text
```
Attendez le retour de la commande `CREATE_COMPLETE` avant de passer à l'étape suivante.
## Étape 2 : migrer les CloudWatch alarmes et EventBridge les règles
Utilisez les runbooks Systems Manager Automation pour migrer vos CloudWatch alarmes et EventBridge règles d'Incident Manager vers OpsCenter.
### Runbooks de migration
+ [AWS- MigrateIncidentManagerCloudWatchAlarms](https://console.aws.amazon.com/systems-manager/documents/AWS-MigrateIncidentManagerCloudWatchAlarms)
+ [AWS- MigrateIncidentManagerEventBridgeRules](https://console.aws.amazon.com/systems-manager/documents/AWS-MigrateIncidentManagerEventBridgeRules)
Pour plus d'informations sur le fonctionnement de ces runbooks, y compris les descriptions détaillées des étapes, les paramètres d'entrée et les sorties, consultez la documentation des runbooks.
### Comment fonctionnent les runbooks
Les deux runbooks de migration suivent le même flux de travail :
+ **Découverte et traitement par lots** : découvre toutes les CloudWatch alarmes ou EventBridge règles configurées avec les actions du plan de réponse d'Incident Manager et les organise en lots configurables.
+ **Approbation manuelle (facultative)** : nécessite par défaut une approbation explicite avant de procéder à la migration, avec un délai d'expiration de 24 heures. Une notification Amazon SNS est envoyée à l'adresse e-mail spécifiée lors CloudFormation du déploiement. Toutes les configurations sont sauvegardées sur Amazon S3, et la liste complète des ressources à migrer est stockée pour examen manuel. Cette étape peut être ignorée en réglant la valeur RequireManualApproval sur false.
+ **Sauvegarde et migration** : si l'approbation manuelle est définie sur true, attend l'approbation, puis sauvegarde chaque configuration sur Amazon S3 et effectue la migration. Si ce paramètre est défini sur false, passe directement à la sauvegarde et à la migration.
### Paramètres d’entrée
Les deux runbooks nécessitent les paramètres suivants :
AutomationAssumeRole (Obligatoire)
L'ARN du `IM-Migration-Automation-Role` créé par la CloudFormation pile.
ApproverArn (Obligatoire)
L'ARN du rôle ou de l'utilisateur IAM qui peut examiner et approuver la migration.
S3 BucketName (obligatoire)
Nom du compartiment Amazon S3 créé par la CloudFormation pile.
SNSTopicArn (obligatoire)
L'ARN de la rubrique Amazon SNS créée par la CloudFormation pile.
MaxNumberOfAlarmsToMigrate ou MaxNumberOfRulesToMigrate (Facultatif)
Le nombre maximum de ressources à migrer en une seule exécution. Valeurs valides : 1, 5, 10, 50, 100, 500, 5000, 10000, 25000, 50000. Par défaut : 10 000
BatchSize (Facultatif)
Le nombre de ressources à traiter dans chaque lot. Valeurs valides : 25, 50, 100, 200, 250, 300, 350, 400, 450, 500. Par défaut : 100. Le runbook prend en charge un maximum de 100 BatchSize ressources par exécution.
RequireManualApproval (Facultatif)
Valeur booléenne permettant de contrôler si une approbation manuelle est requise avant la migration. Lorsque ce paramètre est défini sur true (par défaut), vous recevez un e-mail de notification Amazon SNS indiquant l'emplacement de la liste des ressources sur Amazon S3 et un lien vers la console d'exécution de l'automatisation pour approuver, refuser ou annuler. Lorsqu'il est défini sur false, le runbook se lance automatiquement après la découverte et la sauvegarde. Valeurs valides : vrai, faux. Valeur par défaut : vraie.
### Pour effectuer une migration à l'aide de la console
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager.](https://console.aws.amazon.com/systems-manager)
1. Dans le panneau de navigation de gauche, sélectionnez **Automation** (Automatisation).
1. Recherchez le nom du runbook (`AWS-MigrateIncidentManagerCloudWatchAlarms`ou`AWS-MigrateIncidentManagerEventBridgeRules`).
1. Choisissez **Execute automation (Exécuter l’automatisation)**.
1. Entrez les valeurs des paramètres à partir des sorties de votre CloudFormation pile.
1. (Facultatif) Définissez **RequireManualApproval**cette option `false` si vous souhaitez ignorer l'étape d'approbation manuelle.
1. Sélectionnez **Execute (Exécuter)**.
1. S'il `RequireManualApproval` est défini sur true (par défaut), vous recevez une notification par e-mail lorsque l'exécution attend une révision manuelle. L'e-mail contient un lien d'approbation vers la page de la console d'exécution automatique. Consultez la liste des ressources dans le compartiment Amazon S3, puis approuvez, refusez ou annulez dans les 24 heures suivant le lien de l'e-mail ou la page de console. La migration n'a lieu qu'après approbation. Si ce paramètre est défini sur false, la migration se poursuit automatiquement après la sauvegarde.
1. Attendez que le statut d'exécution passe à **Success**.
### Pour effectuer une migration à l'aide du AWS CLI
**Pour les CloudWatch alarmes :**
```
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
```
**Pour EventBridge les règles :**
```
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
```
Pour consulter la liste des ressources dans 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 ./
```
Si RequireManualApproval ce paramètre est défini sur true, consultez la liste des ressources et approuvez la migration en cliquant sur le lien d'approbation figurant dans la notification par e-mail ou sur la page de la console d'exécution automatique. Si ce paramètre est défini sur false, la migration se poursuit automatiquement après la sauvegarde.
## Étape 3 : vérifier votre migration
Une fois la migration terminée, vérifiez que vos ressources fonctionnent correctement :
+ **Déclenchez une alarme ou un événement de test** : activez l'une de vos CloudWatch alarmes ou EventBridge règles migrées pour générer une notification de test.
+ **Confirmer OpsItem la création** - Vérifiez qu'un OpsItem est automatiquement créé OpsCenter lorsque l'alarme ou l'événement se déclenche.
+ **Validez le mappage de gravité** : vérifiez que le niveau de gravité de votre configuration initiale d'Incident Manager est correctement préservé dans le OpsItem. (Applicable uniquement aux CloudWatch alarmes).
## Étape 4 : Nettoyer les ressources du gestionnaire d'incidents
Après avoir migré avec succès vos CloudWatch alarmes et vos EventBridge règles, vous pouvez éventuellement nettoyer les ressources d'Incident Manager pour vous déconnecter complètement du service.
Pour obtenir des instructions détaillées sur la suppression du kit de réplication, des plans de réponse, des contacts, des runbooks et d'autres ressources du gestionnaire d'incidents, consultez[Nettoyage des ressources du gestionnaire d'incidents](migration-cleanup.md).
### Supprimer CloudFormation des piles (facultatif)
Vous pouvez supprimer les CloudFormation piles pour supprimer le rôle IAM, la rubrique Amazon SNS et le compartiment Amazon S3 créés pour la migration.
**Important**
Le compartiment Amazon S3 contenant les sauvegardes de toutes les ressources migrées doit être vidé avant la suppression de la pile. CloudFormation Impossible de supprimer les compartiments Amazon S3 contenant des objets.
**Pour supprimer la CloudFormation pile**
```
aws cloudformation delete-stack --stack-name
```
## Surveillance et résolution des problèmes
**CloudWatch Journaux** : les activités de migration sont enregistrées dans CloudWatch Logs :
+ CloudWatch alarmes : `/aws/ssm/incidentmanager/cwmigration`
+ EventBridge règles : `/aws/ssm/incidentmanager/ebmigration`
**Structure de sauvegarde Amazon S3** : toutes les configurations sont sauvegardées sur Amazon S3 avant la migration :
```
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
```
**Problèmes courants :**
+ **Notification Amazon SNS non reçue** (lorsque RequireManualApproval =true) - Vérifiez l'abonnement à la rubrique Amazon SNS :
```
aws sns list-subscriptions-by-topic --topic-arn
```
+ **Échec partiel de la migration** : consultez CloudWatch les journaux pour obtenir des messages d'erreur détaillés et réessayez l'automatisation avec une taille de lot réduite.
**Procédure de rétrogradation :**
Si vous devez annuler la migration :
+ Récupérez des sauvegardes depuis Amazon S3 :
```
aws s3 sync s3://im-migration-logs-123456789012-us-east-1/backups/ ./backups/
```
+ Restaurez les ressources :
```
# 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
```
## Questions fréquentes (FAQ)
Q : Que se passe-t-il si l'automatisation expire pendant l'approbation ?
R : L'automatisation expire au bout de 24 heures si aucune approbation n'est reçue. Vous pouvez redémarrer l'automatisation avec les mêmes paramètres.
Q : Puis-je migrer des ressources d'une région à l'autre ?
R : Non. Chaque région doit être migrée séparément à l'aide d'exécutions automatisées spécifiques à chaque région.
Q : Combien de temps dure la migration ?
R : Le temps de migration dépend du nombre de ressources :
+ \$1100 alarmes/règles : 5 à 10 minutes
+ \$11000 alarmes/règles : 30 à 60 minutes
+ \$110000 alarmes/règles : 2-4 heures
Q : La sévérité est-elle préservée après la migration vers OpsCenter ?
A : Oui. La gravité configurée dans les niveaux d'impact du plan de réponse d'Incident Manager est préservée et automatiquement mappée aux niveaux de OpsCenter gravité appropriés lors de la migration des CloudWatch alarmes. Cela ne s'applique pas aux EventBridge règles.
Q : L'exécution des runbooks d'automatisation me sera-t-elle facturée ?
R : Non. Les runbooks d'automatisation de la migration n'entraînent pas de frais d'exécution. Toutefois, OpsCenter l'utilisation après la migration entraînera des frais. Pour plus de détails, consultez la documentation [tarifaire de Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Ressources connexes
+ [Migration vers AWS Systems Manager OpsCenter](migration-opscenter.md)
+ [AWS Systems Manager OpsCenter Guide de l'utilisateur](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Exportation des données d'Incident Manager](export-data.md)
+ [Nettoyage des ressources du gestionnaire d'incidents](migration-cleanup.md)