Gestion des incidents par région Comptes AWS et par région dans Incident Manager - Incident Manager
Gestion des incidents entre régionsGestion des incidents entre comptes

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.

Gestion des incidents par région Comptes AWS et par région dans Incident Manager

Vous pouvez configurer Incident Manager, une fonctionnalité de AWS Systems Manager, pour qu'il fonctionne avec plusieurs Régions AWS comptes. Cette section décrit les meilleures pratiques entre régions et entre comptes, les étapes de configuration et les limites connues.

Gestion des incidents entre régions

Incident Manager prend en charge la création automatique et manuelle d'incidents dans plusieurs cas Régions AWS. Lors de votre première intégration à Incident Manager à l'aide de l'assistant de préparation, vous pouvez en spécifier jusqu'à trois Régions AWS pour votre ensemble de réplication. Pour les incidents créés automatiquement par les CloudWatch alarmes Amazon ou les EventBridge événements Amazon, Incident Manager tente de créer un incident identique Région AWS à la règle ou à l'alarme de l'événement. Si Incident Manager connaît une panne dans le premier Région AWS endroit où il a été configuré, CloudWatch ou s'il crée EventBridge automatiquement l'incident dans une autre des régions disponibles spécifiées pour votre ensemble de réplication.

Important

Prenez note des informations importantes suivantes.

  • Nous vous recommandons d'en spécifier au moins deux Régions AWS dans votre jeu de réplication. Si vous ne spécifiez pas au moins deux régions, le système ne créera pas d'incidents pendant la période pendant laquelle Incident Manager n'est pas disponible.

  • Les incidents créés par un basculement entre régions n'invoquent pas les runbooks spécifiés dans les plans de réponse.

Pour plus d'informations sur l'intégration à Incident Manager et sur la spécification de régions supplémentaires, consultezCommencer à utiliser Incident Manager.

Gestion des incidents entre comptes

Incident Manager utilise AWS Resource Access Manager (AWS RAM) pour partager les ressources du gestionnaire d'incidents entre les comptes de gestion et d'application. Cette section décrit les meilleures pratiques entre comptes, comment configurer la fonctionnalité multicomptes pour Incident Manager et les limites connues de la fonctionnalité multicomptes dans Incident Manager.

Un compte de gestion est le compte à partir duquel vous effectuez la gestion des opérations. Dans une configuration organisationnelle, le compte de gestion possède les plans d'intervention, les contacts, les plans d'escalade, les runbooks et les autres AWS Systems Manager ressources.

Un compte d'application est le compte qui possède les ressources qui constituent vos applications. Ces ressources peuvent être des EC2 instances Amazon, des tables Amazon DynamoDB ou toute autre ressource que vous utilisez pour créer des applications dans le. AWS Cloud Les comptes d'applications possèdent également les CloudWatch alarmes Amazon et les EventBridge événements Amazon qui créent des incidents dans Incident Manager.

AWS RAM utilise les partages de ressources pour partager les ressources entre les comptes. Vous pouvez partager le plan de réponse et les ressources de contact entre les comptes dans AWS RAM. En partageant ces ressources, les comptes d'applications et les comptes de gestion peuvent interagir avec les engagements et les incidents. Le partage d'un plan de réponse permet de partager tous les incidents passés et futurs créés à l'aide de ce plan d'intervention. Le partage d'un contact permet de partager tous les engagements passés et futurs du contact ou du plan de réponse.

Bonnes pratiques

Suivez ces bonnes pratiques lorsque vous partagez les ressources de votre gestionnaire d'incidents entre plusieurs comptes :

  • Mettez régulièrement à jour le partage des ressources avec les plans d'intervention et les contacts.

  • Passez régulièrement en revue les principes de partage des ressources.

  • Configurez le gestionnaire d'incidents, les runbooks et les canaux de discussion dans votre compte de gestion.

Configuration et configuration de la gestion des incidents entre comptes

Les étapes suivantes décrivent comment configurer et configurer les ressources d'Incident Manager et comment les utiliser pour les fonctionnalités multicomptes. Vous avez peut-être configuré certains services et ressources pour la fonctionnalité multi-comptes par le passé. Utilisez ces étapes comme liste de contrôle des exigences avant de commencer votre premier incident à l'aide des ressources multicomptes.

  1. (Facultatif) Créez des organisations et des unités organisationnelles à l'aide de AWS Organizations. Suivez les étapes décrites dans le didacticiel : Création et configuration d'une organisation dans le guide de AWS Organizations l'utilisateur.

  2. (Facultatif) Utilisez la fonctionnalité de configuration rapide de Systems Manager pour définir les AWS Identity and Access Management rôles appropriés à utiliser lors de la configuration de vos runbooks multicomptes. Pour plus d'informations, consultez Quick Setup dans le Guide de l'utilisateur AWS Systems Manager .

  3. Suivez les étapes répertoriées dans la section Exécuter des automatisations en plusieurs Régions AWS comptes dans le Guide de l'AWS Systems Manager utilisateur pour créer des runbooks dans vos documents d'automatisation de Systems Manager. Un runbook peut être géré soit par un compte de gestion, soit par l'un de vos comptes d'application. En fonction de votre cas d'utilisation, vous devrez installer le AWS CloudFormation modèle approprié pour les rôles nécessaires à la création et à l'affichage des runbooks lors d'un incident.

    • Exécution d'un runbook dans le compte de gestion. Le compte de gestion doit télécharger et installer le AWS-SystemsManager-AutomationReadOnlyRole CloudFormation modèle. Lors de l'installation AWS-SystemsManager-AutomationReadOnlyRole, spécifiez le compte IDs de tous les comptes d'applications. Ce rôle permettra aux comptes de votre application de lire l'état du runbook depuis la page des détails de l'incident. Le compte de l'application doit installer le AWS-SystemsManager-AutomationAdministrationReadOnlyRole CloudFormation modèle. La page de détails de l'incident utilise ce rôle pour obtenir l'état de l'automatisation à partir du compte de gestion.

    • Exécution d'un runbook dans un compte d'application. Le compte de gestion doit télécharger et installer le AWS-SystemsManager-AutomationAdministrationReadOnlyRole CloudFormation modèle. Ce rôle permet au compte de gestion de lire l'état du runbook dans le compte de l'application. Le compte de l'application doit télécharger et installer le AWS-SystemsManager-AutomationReadOnlyRole CloudFormation modèle. Lors de l'installationAWS-SystemsManager-AutomationReadOnlyRole, spécifiez l'ID du compte de gestion et des autres comptes de l'application. Le compte de gestion et les autres comptes d'application assument ce rôle pour lire l'état du runbook.

  4. (Facultatif) Dans chaque compte d'application de l'organisation, téléchargez et installez le AWS-SystemsManager-IncidentManagerIncidentAccessServiceRole CloudFormation modèle. Lors de l'installation AWS-SystemsManager-IncidentManagerIncidentAccessServiceRole, spécifiez l'ID du compte de gestion. Ce rôle fournit les autorisations dont Incident Manager a besoin pour accéder aux informations relatives aux AWS CodeDeploy déploiements et aux mises à jour de la AWS CloudFormation pile. Ces informations sont signalées sous forme de conclusions relatives à un incident si la fonctionnalité Résultats est activée. Pour de plus amples informations, veuillez consulter Identifier les causes potentielles des incidents provenant d'autres services en tant que « constatations » dans Incident Manager.

  5. Pour configurer et créer des contacts, des plans d'escalade, des canaux de discussion et des plans de réponse, suivez les étapes détaillées dansPréparation aux incidents dans Incident Manager.

  6. Ajoutez vos contacts et les ressources du plan de réponse à votre partage de ressources existant ou à un nouveau partage de ressources AWS RAM. Pour plus d'informations, consultez Démarrer avec AWS RAM dans le Guide de l'utilisateur AWS RAM . L'ajout de plans de réponse AWS RAM permet aux comptes d'applications d'accéder aux incidents et aux tableaux de bord des incidents créés à l'aide des plans de réponse. Les comptes d'applications peuvent également associer des CloudWatch alarmes et EventBridge des événements à un plan de réponse. L'ajout des contacts et des plans d'escalade AWS RAM permet aux comptes d'applications de consulter les engagements et d'engager les contacts depuis le tableau de bord des incidents.

  7. Ajoutez des fonctionnalités multicomptes et interrégions à votre CloudWatch console. Pour connaître les étapes à suivre et obtenir des informations, consultez la CloudWatch console multi-comptes inter-régions dans le guide de CloudWatch l'utilisateur Amazon. L'ajout de cette fonctionnalité garantit que les comptes d'application et le compte de gestion que vous avez créés peuvent consulter et modifier les indicateurs des tableaux de bord des incidents et des analyses.

  8. Créez un bus d' EventBridge événements Amazon multicomptes. Pour connaître les étapes à suivre et obtenir des informations, consultez la section Envoi et réception d' EventBridge événements Amazon entre AWS comptes. Vous pouvez ensuite utiliser ce bus d'événements pour créer des règles d'événements qui détectent les incidents dans les comptes d'applications et créent des incidents dans le compte de gestion.

Limites

Les limites connues de la fonctionnalité multi-comptes d'Incident Manager sont les suivantes :

  • Le compte qui crée une analyse post-incident est le seul à pouvoir la consulter et la modifier. Si vous utilisez un compte d'application pour créer une analyse post-incident, seuls les membres de ce compte peuvent la consulter et la modifier. Il en va de même si vous utilisez un compte de gestion pour créer une analyse post-incident.

  • Les événements de chronologie ne sont pas renseignés pour les documents automatisés exécutés dans les comptes d'applications. Les mises à jour des documents d'automatisation exécutés dans les comptes d'applications sont visibles dans l'onglet Runbook de l'incident.

  • Les rubriques Amazon Simple Notification Service ne peuvent pas être utilisées entre comptes. SNSLes sujets Amazon doivent être créés dans la même région et dans le même compte que le plan de réponse dans lequel ils sont utilisés. Nous vous recommandons d'utiliser le compte de gestion pour créer tous les SNS sujets et les plans de réponse.

  • Les plans d'escalade ne peuvent être créés qu'en utilisant les contacts du même compte. Un contact qui a été partagé avec vous ne peut pas être ajouté à un plan d'escalade dans votre compte.

  • Les balises appliquées aux plans d'intervention, aux enregistrements d'incidents et aux contacts ne peuvent être consultées et modifiées qu'à partir du compte du propriétaire de la ressource.