Résolution des erreurs RFC dans AMS - Guide de l'utilisateur avancé d'AMS
Erreurs RFC de « gestion »Erreurs RFC « Déploiement »Validation RFC et erreurs d'exécutionMessages d'erreur RFCComment obtenir de l'aide concernant un RFC

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.

Résolution des erreurs RFC dans AMS

De nombreuses défaillances RFC de provisionnement AMS peuvent être étudiées dans la CloudFormation documentation. Voir Résolution des problèmes liés à AWS CloudFormation : résolution des erreurs

Des suggestions de résolution des problèmes supplémentaires sont fournies dans les sections suivantes.

Erreurs RFC de « gestion » dans AMS

Les types de changement de catégorie AMS « Management » (CTs) vous permettent de demander l'accès aux ressources ainsi que de gérer les ressources existantes. Cette section décrit certains problèmes courants.

Erreurs d'accès RFC

  • Assurez-vous que le nom d'utilisateur et le FQDN que vous avez spécifiés dans la RFC sont corrects et existent dans le domaine. Pour obtenir de l'aide pour trouver votre nom de domaine complet, consultez la section Trouver votre nom de domaine complet.

  • Assurez-vous que l'ID de pile que vous avez spécifié pour l'accès est EC2 une pile associée. Les piles telles que ELB et Amazon Simple Storage Service (S3) ne sont pas candidates à l'accès. Utilisez plutôt votre rôle d'accès RFCs en lecture seule pour accéder aux ressources de ces piles. Pour obtenir de l'aide pour trouver un identifiant de pile, voir Trouver une pile IDs

  • Assurez-vous que l'identifiant de pile que vous avez fourni est correct et qu'il appartient au compte concerné.

Pour obtenir de l'aide concernant d'autres défaillances RFC d'accès, consultez la section Gestion des accès.

YouTube Vidéo : Comment lancer correctement une demande de modification (RFC) pour éviter les rejets et les échecs ?

Erreurs de planification RFC (manuelle) CT

La plupart des types de modifications sont ExecutionMode = automatisés, mais certains sont ExecutionMode = manuels, ce qui affecte la façon dont vous devez les planifier pour éviter une défaillance de la RFC.

RFCs Planifié avec ExecutionMode =Manual, il doit être configuré pour s'exécuter au moins 24 heures dans le futur si vous utilisez la console AMS pour créer le RFC. Cette mise en garde ne s'applique pas à l'API/CLI AMS, mais il est tout de même important de planifier le manuel au moins 8 heures RFCs à l'avance.

AMS a pour objectif de répondre à un scanner manuel dans les quatre heures et vous contactera dès que possible, mais l'exécution de la RFC peut prendre beaucoup plus de temps.

Utilisation RFCs avec mise à jour manuelle CTs

AMS Operations rejette Management | Other | Other RFCs pour les mises à jour des piles, lorsqu'il existe un type de modification de mise à jour pour le type de pile que vous souhaitez mettre à jour.

Erreurs de suppression de pile RFC

Défaillances de la pile de suppression RFC : si vous utilisez le CT Management | Standard Stacks | Stack | Delete, vous verrez les événements détaillés dans la CloudFormation console pour la pile portant le nom de la pile AMS. Vous pouvez identifier votre pile en la comparant au nom qu'elle porte dans la console AMS. La CloudFormation console fournit plus de détails sur les causes des défaillances.

Avant de supprimer une pile, vous devez réfléchir à la manière dont elle a été créée. Si vous avez créé la pile à l'aide d'un AMS CT et que vous n'avez ni ajouté ni modifié les ressources de la pile, vous pouvez vous attendre à la supprimer sans problème. Cependant, il est conseillé de supprimer toutes les ressources ajoutées manuellement d'une pile avant de soumettre une RFC de suppression de pile à son encontre. Par exemple, si vous créez une pile à l'aide de la pile complète CT (HA Two Tier), elle inclut un groupe de sécurité - SG1. Si vous utilisez ensuite AMS pour créer un autre groupe de sécurité - SG2, et que vous référencez le nouveau groupe SG1 créé SG2 dans le cadre de la pile complète, puis que vous utilisez la pile de suppression CT pour supprimer la pile, il ne SG1 sera pas supprimé car il est référencé par SG2.

Important

La suppression de piles peut avoir des conséquences indésirables et imprévues. Pour cette raison, AMS préfère *pas* supprimer des piles ou empiler des ressources pour le compte de ses clients. Notez qu'AMS supprimera uniquement les ressources en votre nom (par le biais d'un type de modification soumis par Gestion | Autre | Autre | Mettre à jour) qu'il n'est pas possible de supprimer en utilisant le type de modification automatique approprié à supprimer. Considérations supplémentaires :

  • Si les ressources sont activées pour la « protection contre la suppression », AMS peut vous aider à débloquer ce type de modification en soumettant une modification de type Gestion | Autre | Autre | Mise à jour et, une fois la protection contre la suppression de la protection contre la suppression, vous pouvez utiliser le CT automatique pour supprimer cette ressource.

  • Si une pile contient plusieurs ressources et que vous souhaitez supprimer uniquement un sous-ensemble des ressources de la pile, utilisez le type de modification CloudFormation Update (voir CloudFormation Ingest Stack : Updating). Vous pouvez également soumettre un type de modification Gestion | Autre | Autre | Mettre à jour et les ingénieurs d'AMS peuvent vous aider à élaborer l'ensemble de modifications, si nécessaire.

  • Si vous rencontrez des problèmes lors de l'utilisation de l' CloudFormation Update CT en raison de dérives, AMS peut vous aider en soumettant une mise à jour Management | Other | Other | pour résoudre le problème (dans la mesure où cela est pris en charge par le CloudFormation service AWS) et en fournissant une ChangeSet que vous pouvez ensuite valider et exécuter à l'aide du CT, du Management/Custom Stack/Stack From CloudFormation Template/Approve changeset et de la mise à jour automatisés.

AMS applique les restrictions ci-dessus afin de garantir qu'il n'y ait pas de suppressions de ressources inattendues ou imprévues.

Pour plus d'informations, consultez Résolution des problèmes liés à AWS CloudFormation : la suppression de la pile échoue.

Erreurs DNS de mise à jour RFC

Plusieurs RFCs pour mettre à jour une zone hébergée DNS peuvent échouer, parfois sans raison. La création simultanée de plusieurs RFCs zones hébergées pour mettre à jour les zones hébergées du DNS (privées ou publiques) peut entraîner l'échec de certaines RFCs d'entre elles car elles tentent de mettre à jour la même pile en même temps. La gestion des modifications AMS rejette ou échoue ceux RFCs qui ne sont pas en mesure de mettre à jour une pile parce que la pile est déjà mise à jour par une autre RFC. AMS vous recommande de créer une RFC à la fois et d'attendre qu'elle aboutisse avant d'en créer une nouvelle pour la même pile.

Erreurs d'entités RFC IAM

AMS fournit un certain nombre de rôles et de profils IAM par défaut dans des comptes AMS conçus pour répondre à vos besoins. Cependant, il se peut que vous deviez demander des ressources IAM supplémentaires de temps en temps.

Le processus de soumission des RFCs demandes de ressources IAM personnalisées suit le flux de travail standard pour le manuel RFCs, mais le processus d'approbation inclut également un examen de sécurité pour garantir que les contrôles de sécurité appropriés sont en place. Par conséquent, le processus prend généralement plus de temps que les autres manuels RFCs. Pour réduire le temps de cycle de ces RFCs appareils, veuillez suivre les instructions suivantes.

Pour plus d'informations sur ce que nous entendons par révision IAM et sur la manière dont elle correspond à nos normes techniques et à notre processus d'acceptation des risques, consultezComprendre les évaluations de sécurité RFC.

Demandes de ressources IAM courantes :

  • Si vous demandez une politique concernant une application majeure compatible avec le cloud, par exemple CloudEndure, consultez le fichier d'exemple de CloudEndure politique IAM préapprouvée par AMS : décompressez le fichier d'exemple de zone d'atterrissage WIGs Cloud Endure et ouvrez le customer_cloud_endure_policy.json

    Note

    Si vous souhaitez une politique plus permissive, discutez de vos besoins avec vous CloudArchitect/CSDM et obtenez, si nécessaire, un examen de sécurité AMS et une approbation avant de soumettre une RFC mettant en œuvre la politique.

  • Si vous souhaitez modifier une ressource déployée par AMS dans votre compte par défaut, nous vous recommandons de demander une copie modifiée de cette ressource plutôt que de modifier la ressource existante.

  • Si vous demandez des autorisations pour un utilisateur humain (au lieu de les associer à l'utilisateur), associez les autorisations à un rôle, puis accordez à l'utilisateur l'autorisation d'assumer ce rôle. Pour plus de détails sur cette procédure, consultez la section Accès temporaire à la console AMS Advanced.

  • Si vous avez besoin d'autorisations exceptionnelles pour une migration ou un flux de travail temporaire, indiquez une date de fin pour ces autorisations dans votre demande.

  • Si vous avez déjà discuté de l'objet de votre demande avec votre équipe de sécurité, fournissez la preuve de son approbation à votre CSDM avec le plus de détails possible.

Si AMS rejette une RFC IAM, nous fournissons une raison claire pour le rejet. Par exemple, nous pouvons rejeter une demande de création de politique IAM et expliquer en quoi cette politique est inappropriée. Dans ce cas, vous pouvez apporter les modifications identifiées et soumettre à nouveau la demande. Si des précisions supplémentaires sur le statut d'une demande sont nécessaires, soumettez une demande de service ou contactez votre CSDM.

La liste suivante décrit les risques typiques qu'AMS essaie d'atténuer lors de l'examen de votre IAM RFCs. Si votre RFC IAM présente l'un de ces risques, cela peut entraîner le rejet du RFC. Dans les cas où vous avez besoin d'une exception, AMS demande l'approbation de votre équipe de sécurité. Pour obtenir une telle exception, coordonnez-vous avec votre CSDM.

Note

AMS peut, pour quelque raison que ce soit, refuser toute modification des ressources IAM au sein d'un compte. Pour toute question concernant le rejet d'une RFC, contactez AMS Operations via une demande de service ou contactez votre CSDM.

  • Augmentation des privilèges, telle que les autorisations qui vous permettent de modifier vos propres autorisations ou de modifier les autorisations d'autres ressources du compte. Exemples :

    • L'utilisation iam:PassRole avec un autre rôle plus privilégié.

    • Autorisation d'accéder aux politiques attach/detach IAM à partir d'un rôle ou d'un utilisateur.

    • Modification des politiques IAM dans le compte.

    • Possibilité d'effectuer des appels d'API dans le contexte de l'infrastructure de gestion.

  • Autorisations permettant de modifier les ressources ou les applications requises pour vous fournir les services AMS. Exemples :

    • Modification de l'infrastructure AMS telle que les bastions, l'hôte de gestion ou l'infrastructure EPS.

    • Suppression des fonctions de gestion des journaux AWS Lambda, ou des flux de journaux.

    • Suppression ou modification de l'application de CloudTrail surveillance par défaut.

    • Modification de l'Active Directory (AD) des services d'annuaire.

    • Désactivation des CloudWatch alarmes (CW).

    • Modification des principes, des politiques et des espaces de noms déployés dans le compte dans le cadre de la zone de landing zone.

  • Déploiement d'une infrastructure en dehors des meilleures pratiques, telles que les autorisations qui permettent la création d'une infrastructure dans un état mettant en danger la sécurité de vos informations. Exemples :

    • Création de compartiments S3 publics ou non chiffrés ou partage public de volumes EBS.

    • Le provisionnement d'adresses IP publiques.

    • Modification des groupes de sécurité pour permettre un accès étendu.

  • Des autorisations trop larges susceptibles d'avoir un impact sur les applications, telles que des autorisations susceptibles d'entraîner une perte de données, une perte d'intégrité, une configuration inappropriée ou des interruptions de service pour votre infrastructure et les applications du compte. Exemples :

    • Désactiver ou rediriger le trafic réseau via APIs like ModifyNetworkInterfaceAttribute ou. UpdateRouteTable

    • Désactivation de l'infrastructure gérée en détachant les volumes des hôtes gérés.

  • Les autorisations pour les services ne font pas partie de la description du service AMS et ne sont pas prises en charge par AMS.

    Les services non répertoriés dans la description du service AMS ne peuvent pas être utilisés dans les comptes AMS. Pour demander de l'aide pour une fonctionnalité ou un service, veuillez contacter votre CSDM.

  • Autorisations qui ne répondent pas à l'objectif que vous vous êtes fixé, soit parce qu'elles sont trop généreuses, soit trop conservatrices, soit parce qu'elles ne sont pas appliquées aux bonnes ressources. Exemples :

    • Demande d's3:PutObjectautorisation d'accès à un compartiment S3 doté d'un chiffrement KMS obligatoire, sans KMS:Encrypt autorisation d'accès à la clé correspondante.

    • Autorisations relatives à des ressources qui n'existent pas dans le compte.

    • IAM RFCs où la description de la RFC ne semble pas correspondre à la demande.

Erreurs RFC « Déploiement »

Les types de changement de catégorie AMS « Déploiement » (CTs) vous permettent de demander que diverses ressources prises en charge par AMS soient ajoutées à votre compte.

La plupart des AMS CTs qui créent une ressource sont basés sur CloudFormation des modèles. En tant que client, vous avez un accès en lecture seule à tous les services AWS. Vous pouvez notamment CloudFormation identifier rapidement la CloudFormation pile qui représente votre pile en fonction de la description de la pile à l'aide de la CloudFormation console. La pile défaillante sera probablement dans l'état DELETE_COMPLETE. Une fois que vous avez identifié la CloudFormation pile, les événements vous indiqueront la ressource spécifique qui n'a pas pu être créée et pourquoi.

Utilisation de CloudFormation la documentation pour résoudre les problèmes

La plupart des approvisionnements AMS RFCs utilisent un CloudFormation modèle et cette documentation peut être utile pour le dépannage. Consultez la documentation de ce CloudFormation modèle :

RFC créant des erreurs AMIs

Une Amazon Machine Image (AMI) est un modèle qui contient une configuration logicielle (par exemple, un système d’exploitation, un serveur d’applications et des applications). À partir d'une AMI, vous lancez une instance, qui est une copie de l'AMI exécutée en tant que serveur virtuel dans le cloud. AMIs sont très utiles et nécessaires pour créer des EC2 instances ou des groupes Auto Scaling ; toutefois, vous devez respecter certaines exigences :

  • L'instance que vous spécifiez Ec2InstanceId doit être dans un état arrêté pour que la RFC réussisse. N'utilisez pas d'instances du groupe Auto Scaling (ASG) pour ce paramètre car l'ASG mettra fin à une instance arrêtée.

  • Pour créer une Amazon Machine Image (AMI) AMS, vous devez commencer par une instance AMS. Avant de pouvoir utiliser l'instance pour créer l'AMI, vous devez la préparer en vous assurant qu'elle est arrêtée et dissociée de son domaine. Pour plus de détails, consultez Créer une image de machine Amazon standard à l'aide de Sysprep

  • Le nom que vous spécifiez pour la nouvelle AMI doit être unique dans le compte, sinon la RFC échoue. La procédure à suivre est décrite dans AMI | Create, et pour plus de détails, consultez AWS AMI Design.

Note

Pour plus d'informations sur la préparation à la création d'AMI, voir AMI | Create.

RFCs création EC2s d' ASGs erreurs

En cas de EC2 défaillances ASG avec délais d'expiration, AMS vous recommande de vérifier si l'AMI utilisée est personnalisée. Si tel est le cas, reportez-vous aux étapes de création d'AMI incluses dans ce guide (voir AMI | Créer) pour vous assurer que l'AMI a été créée correctement. Une erreur courante lors de la création d'une AMI personnalisée est de ne pas suivre les étapes du guide pour renommer ou invoquer Sysprep.

RFCs création d'erreurs RDS

Les défaillances d'Amazon Relational Database Service (RDS) peuvent survenir pour de nombreuses raisons, car vous pouvez utiliser de nombreux moteurs différents lorsque vous créez le RDS, et chaque moteur a ses propres exigences et limites. Avant de tenter de créer une pile AMS RDS, examinez attentivement les valeurs des paramètres AWS RDS, voir Create. DBInstance

Pour en savoir plus sur Amazon RDS en général, y compris les recommandations relatives à la taille, consultez la documentation Amazon Relational Database Service.

RFCs création d'erreurs Amazon S3

L'une des erreurs les plus courantes lors de la création d'un compartiment de stockage S3 est le fait de ne pas utiliser un nom unique pour le compartiment. Si vous soumettez un compartiment S3 Create CT portant le même nom qu'un compartiment précédemment soumis, il échouera car un compartiment S3 portant ce nom existerait déjà BucketName. Cela sera détaillé dans la CloudFormation console, où vous verrez que l'événement stack indique que le nom du bucket est déjà utilisé.

Validation RFC et erreurs d'exécution

Les échecs RFC et les messages associés diffèrent dans les messages de sortie sur la page de détails RFC de la console AMS pour une RFC sélectionnée :

  • Les raisons des échecs de validation ne sont disponibles que dans le champ État

  • Les raisons des échecs d'exécution sont disponibles dans les champs de sortie et de statut de l'exécution.

Request for change details showing rejected status due to no domain trust found.

Messages d'erreur RFC

Lorsque vous rencontrez l'erreur suivante pour les types de modifications répertoriés (CTs), vous pouvez utiliser ces solutions pour vous aider à trouver la source des problèmes et à les résoudre.

{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}

Si vous avez besoin d'une assistance supplémentaire après avoir consulté les options de dépannage suivantes, contactez AMS par correspondance RFC ou créez une demande de service. Voir Correspondance et pièce jointe RFC (console) et Création d'une demande de service dans AMS pour plus de détails.

Erreurs d'ingestion de charge de travail (WIGS)

Note

Les outils de validation pour Windows et Linux peuvent être téléchargés et exécutés directement sur vos serveurs locaux, ainsi que sur les EC2 instances d'AWS. Vous pouvez les trouver dans le guide du développeur d'applications avancées d'AMS intitulé Migrating workloads : Linux pre-ingestion validation et Migrating workloads : Windows pre-ingestion validation.

  • Assurez-vous que l' EC2 instance existe dans le compte AMS cible. Par exemple, si vous avez partagé votre AMI d'un compte non-AMS vers un compte AMS, vous devrez créer une EC2 instance dans votre compte AMS avec l'AMI partagée avant de pouvoir soumettre une RFC d'ingestion de charge de travail.

  • Vérifiez si le trafic de sortie est autorisé pour les groupes de sécurité attachés à l'instance. L'agent SSM doit être en mesure de se connecter à son point de terminaison public.

  • Vérifiez si l'instance dispose des autorisations nécessaires pour se connecter à l'agent SSM. Ces autorisations sont fournies avec lecustomer-mc-ec2-instance-profile, vous pouvez vérifier cela dans la EC2 console :

    EC2 instance details showing IAM role set to customer-mc-ec2-instance-profile.

EC2 erreurs d'arrêt de la pile d'instances

  • Vérifiez si l'instance est déjà arrêtée ou terminée.

  • Si l' EC2 instance est en ligne et que le InternalError message d'erreur s'affiche, soumettez une demande de service pour qu'AMS examine la situation.

  • Notez que vous ne pouvez pas utiliser le type de changement Management | Advanced stack components | EC2 instance stack | Stop ct-3mvvt2zkyveqj pour arrêter une instance d'Auto Scaling group (ASG). Si vous devez arrêter une instance ASG, soumettez une demande de service.

EC2 la pile d'instances crée des erreurs

Le InternalError message provient de CloudFormation ; une raison de statut CREATION_FAILED. Vous pouvez obtenir des informations détaillées sur la défaillance d'une CloudWatch pile dans les événements de pile en suivant ces étapes :

  • Dans la console de gestion AWS, vous pouvez consulter la liste des événements de la pile lors de la création, de la mise à jour ou de la suppression de votre pile. Recherchez dans cette liste l'événement qui a échoué, puis consultez la raison du statut correspondant.

    La raison du statut peut contenir un message d'erreur provenant d'AWS CloudFormation ou d'un service spécifique qui peut vous aider à comprendre le problème.

  • Pour plus d'informations sur l'affichage des événements de stack, consultez la section Visualisation des données et des ressources AWS CloudFormation Stack sur l'AWS Management Console.

EC2 erreurs de restauration du volume d'instance

AMS crée une RFC de dépannage interne en cas d'échec de la restauration du volume d' EC2 instance. Cela est fait parce que la restauration du volume d' EC2 instance est un élément important de la reprise après sinistre (DR) et AMS crée automatiquement cette RFC de dépannage interne pour vous.

Lorsque le RFC de dépannage interne est créé, une bannière s'affiche vous fournissant des liens vers le RFC. Cette RFC de dépannage interne vous donne une meilleure visibilité sur les échecs RFC et, plutôt que de soumettre une nouvelle tentative RFCs entraînant les mêmes erreurs, ou de vous obliger à contacter AMS manuellement en cas d'échec, vous pouvez suivre vos modifications et savoir qu'AMS est en train de remédier à l'échec. Cela réduit également la métrique time-to-recovery (TTR) associée à leur modification, car les opérateurs AMS travaillent de manière proactive sur l'échec de la RFC au lieu d'attendre votre demande.

Comment obtenir de l'aide concernant un RFC

Vous pouvez contacter AMS pour identifier la cause première de votre échec. Les heures d'ouverture d'AMS sont 24 heures par jour, 7 jours par semaine, 365 jours par an.

AMS vous propose plusieurs moyens de demander de l'aide ou de faire des demandes de service.

  • Pour demander des informations ou des conseils, ou pour accéder à un service informatique géré par AMS, ou pour demander un service supplémentaire à AMS, utilisez la console AMS et soumettez une demande de service. Pour plus de détails, consultez la section Création d'une demande de service. Pour des informations générales sur les demandes de service AMS, consultez la section Gestion des demandes de service.

  • Pour signaler un problème de performance des services AWS ou AMS ayant une incidence sur votre environnement géré, utilisez la console AMS et soumettez un rapport d'incident. Pour plus de détails, voir Signaler un incident. Pour des informations générales sur la gestion des incidents AMS, consultez la section Réponse aux incidents.

  • Pour des questions spécifiques sur la façon dont vous ou vos ressources ou applications travaillez avec AMS, ou pour aggraver un incident, envoyez un e-mail à l'une ou plusieurs des adresses suivantes :

    1. Tout d'abord, si vous n'êtes pas satisfait de la demande de service ou de la réponse au rapport d'incident, envoyez un e-mail à votre CSDM : ams-csdm@amazon.com

    2. Ensuite, si l'escalade est requise, vous pouvez envoyer un e-mail au responsable des opérations AMS (mais votre CSDM le fera probablement) : ams-opsmanager@amazon.com

    3. Toute autre escalade serait adressée au directeur de l'AMS : ams-director@amazon.com

    4. Enfin, vous pouvez toujours joindre le vice-président de l'AMS : ams-vp@amazon.com