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ésoudre les problèmes liés à une passerelle Utilisez cette rubrique pour résoudre les problèmes liés à Amazon ECS Gateway, notamment les échecs de connexion au service, les échecs de provisionnement d'itinéraires de passerelle, les mises à jour de configuration de passerelle et les problèmes de connectivité. Les passerelles, routes de passerelle et cibles d'applications Amazon ECS signalent leur état de manière indépendante. Une passerelle peut rester `ACTIVE` même lorsqu'une route de passerelle n'est pas provisionnée et qu'une route de passerelle peut être `ACTIVE` même lorsque les cibles de ses applications ne sont pas saines. Pour identifier la cause d'une panne, examinez l'erreur renvoyée par l'opération de l'API ou examinez l'état et les détails de la panne de la passerelle ou de la route de passerelle concernée. Avant de poursuivre vos recherches, vérifiez que vous utilisez le nom de ressource ou l'ARN correct, AWS compte et région. Assurez-vous qu'Amazon ECS Gateway est pris en charge dans votre région et que vous disposez des autorisations requises. Pour les problèmes de connexion au service, vérifiez que la définition de tâche du service utilise le `awsvpc` mode réseau. Si le problème persiste, utilisez les procédures de dépannage suivantes pour identifier et résoudre la panne. ## Défaillances de connexion et de déploiement des services ### Aucune passerelle n'est associée au cluster UNE `CreateService` ou `UpdateService` Une requête qui inclut un connecteur de passerelle échoue lorsqu'aucune passerelle n'est associée au cluster du service. Rapports Amazon ECS `gatewayConnectors were specified but no gateways are associated with cluster` et rejette la demande au lieu de déployer un service auquel il ne peut pas donner d'URL. Vérifiez les associations de passerelles du cluster pour vérifier qu'au moins une passerelle est associée au cluster du service. ``` aws ecs list-gateway-cluster-associations \ --cluster my-cluster ``` Si aucune association n'est disponible, contactez l'équipe de votre plateforme pour associer une passerelle avant de déployer le service avec un connecteur. Une passerelle dont l'association est entrée `DISASSOCIATING` n'est pas disponible pour les nouvelles connexions. Cette erreur s'affiche également lorsque l'équipe de la plateforme a supprimé la dernière passerelle de votre cluster. Supprimez le connecteur de votre service ou attendez une passerelle de remplacement avant votre prochaine mise à jour. ### Aucune passerelle compatible ne correspond au service Amazon ECS évalue les passerelles associées au cluster et connecte le service à chaque passerelle qui répond à toutes les conditions suivantes : + **Type d'accès.** Le type d'accès de la passerelle correspond à `filters.accessTypes` réglage dans le connecteur de passerelle du service. Si vous omettez ce filtre, les deux `PUBLIC` et `PRIVATE` les passerelles sont éligibles. + **PVC.** La passerelle et le service se trouvent dans le même VPC. + **Zones de disponibilité.** La passerelle couvre toutes les zones de disponibilité utilisées par les sous-réseaux configurés du service. Les ID de sous-réseau eux-mêmes ne doivent pas nécessairement correspondre, mais la passerelle doit disposer d'une couverture de sous-réseau dans chaque zone de disponibilité utilisée par le service. Une passerelle qui ne répond pas à ces conditions est exclue. Si au moins une passerelle compatible est disponible, le service s'y connecte. Si aucune passerelle compatible n'est disponible, la demande échoue. Rapports Amazon ECS `has associated gateways but none are in the service's VPC` lorsqu'aucune passerelle associée ne se trouve dans le VPC du service, et `none of the gateways associated with cluster match` lorsque le filtre de type d'accès exclut toutes les passerelles restantes. **Pour identifier et résoudre un problème de compatibilité** 1. **Vérifiez le filtre de type d'accès du service.** Vérifiez que `filters.accessTypes` correspond au type d'accès de la passerelle à laquelle vous souhaitez vous connecter. 1. **Récupérez les sous-réseaux configurés du service.** Utiliser `list-service-deployments` pour identifier l'ARN de révision de service pertinent. ``` aws ecs list-service-deployments \ --cluster my-cluster \ --service my-service \ --query 'serviceDeployments[].targetServiceRevisionArn' ``` Ensuite, utilisez `describe-service-revisions` pour récupérer ses sous-réseaux configurés. ``` aws ecs describe-service-revisions \ --service-revision-arns \ --query 'serviceRevisions[0].networkConfiguration.awsvpcConfiguration.subnets' ``` 1. **Récupérez les sous-réseaux configurés de la passerelle.** Utiliser `describe-gateway` pour afficher la configuration réseau de la passerelle. ``` aws ecs describe-gateway \ --gateway my-gateway ``` 1. **Comparez les VPC et les zones de disponibilité.** Utiliser `describe-subnets` pour récupérer l'ID VPC et la zone de disponibilité pour les sous-réseaux de service et de passerelle. ``` aws ec2 describe-subnets \ --subnet-ids \ --query 'Subnets[].{SubnetId:SubnetId,VpcId:VpcId,AvailabilityZone:AvailabilityZone}' ``` Vérifiez que le service et la passerelle se trouvent dans le même VPC et que la passerelle couvre toutes les zones de disponibilité utilisées par le service. 1. **Résolvez le décalage.** Mettez à jour le filtre de type d'accès ou la configuration de sous-réseau du service, le cas échéant. Si aucune passerelle compatible n'est disponible, contactez l'équipe de votre plateforme pour configurer ou associer une passerelle qui correspond au type d'accès, au VPC et aux exigences de zone de disponibilité du service. Une fois l'incompatibilité résolue, réessayez de créer ou de mettre à jour le service. **Note** Pour une plus grande flexibilité lors de la connexion des services ECS, configurez des passerelles avec des sous-réseaux qui couvrent toutes les zones de disponibilité dans lesquelles vos services sont susceptibles d'être exécutés. Une couverture plus étendue de la zone de disponibilité permet à une passerelle de prendre en charge un plus grand nombre de services et réduit la nécessité de créer des passerelles supplémentaires. Les sous-réseaux de passerelle ne peuvent pas être modifiés après leur création. ### Le connecteur Gateway fait référence à un port de conteneur non valide Un connecteur de passerelle `portName` doit correspondre au nom d'un mappage de port dans la définition de tâche du service. Il s'agit du nom du port, et non du port de conteneur numérique. Lorsqu'aucun conteneur de la définition de tâche ne possède de mappage de port portant ce nom, Amazon ECS rapporte `InvalidConfiguration: "portName not found in task definition portMappings"`. Pour inspecter les mappages de ports nommés, exécutez : ``` aws ecs describe-task-definition \ --task-definition my-task-definition:1 \ --query 'taskDefinition.containerDefinitions[].portMappings[].name' ``` Corrigez le connecteur ou la définition de tâche pour que les noms correspondent, puis recommencez l'opération de service. Vérifiez cette option après avoir mis à jour une définition de tâche, car un nom de port précédemment valide n'existe peut-être plus. ### La mise à jour des bilans de santé échoue avec la stratégie de déploiement ROLLING La mise à jour des paramètres de vérification de l'état d'un connecteur de passerelle renvoie une erreur indiquant que les propriétés du groupe cible ne peuvent pas être modifiées avec `ROLLING` stratégie de déploiement. La modification de ces paramètres nécessite un groupe cible de remplacement et un service utilisant le `ROLLING` la stratégie de déploiement ne prend pas en charge ce remplacement lors d'une mise à jour. Conservez les paramètres de contrôle de santé existants ou utilisez un blue/green ou stratégie de déploiement de Canary pour le changement. Si vous devez déconnecter puis reconnecter le service pour remplacer le groupe cible, prévoyez de supprimer et de recréer son itinéraire de passerelle et son nom d'hôte. Pour la configuration des connecteurs, voir [Connectez les services Amazon ECS à une passerelle](gateway-connect-service.md). ## Défaillances de provisionnement des itinéraires de passerelle Une connexion de service peut avoir une passerelle dans `CREATE_FAILED` ou `UPDATE_FAILED` état, ou un déploiement de service peut ne pas terminer l'entrée de provisionnement. Une défaillance au niveau de l'itinéraire ne modifie pas nécessairement l'état général de la passerelle ni n'affecte l'itinéraire existant d'un autre service. 1. Trouvez les routes de passerelle défaillantes. ``` aws ecs list-gateway-routes \ --gateway my-gateway \ --status CREATE_FAILED UPDATE_FAILED ``` 1. Identifiez le service auquel appartient chaque itinéraire défaillant, ainsi que les ressources que la passerelle a créées pour celui-ci. ``` aws ecs describe-gateway-route \ --gateway-route-arn arn:aws:ecs:us-west-2:123456789012:gateway-route/my-gateway/a1b2c3d4/9f8e7d6c ``` 1. Vérifiez l'état de déploiement du service et les événements du service pour déterminer la raison de l'échec. Déterminez à partir de la raison de l'échec de l'émission d'un certificat, d'une règle d'écoute, d'un groupe cible, d'un groupe de sécurité ou d'une autre ressource. 1. Corrigez le problème sous-jacent et réessayez de déployer le service concerné. Une modification de la configuration de la passerelle ne relance pas nécessairement un déploiement de service qui a déjà échoué. **Note** Un itinéraire de passerelle signale un état de défaillance mais n'en indique pas la raison. Amazon ECS enregistre la raison du déploiement du service qui a déclenché le provisionnement, ainsi que dans les événements du service. Les causes courantes incluent l'insuffisance des autorisations de rôle dans l'infrastructure, la capacité de l'équilibreur de charge ou les quotas de service, l'épuisement des adresses IP des sous-réseaux et la suppression ou la modification de ressources en dehors d'Amazon ECS. Vous pouvez y voir deux raisons : `InsufficientAvailabilityZones`, ce qui signifie que les sous-réseaux de la passerelle se trouvent dans moins de deux zones de disponibilité, le minimum pour un équilibreur de charge d'application, et `InvalidSubnet`, ce qui signifie qu'aucun sous-réseau configuré n'existe, appartient à un autre VPC ou ne possède plus d'adresse IP libre. Les sections qui suivent décrivent comment étudier les conditions d'autorisation, de capacité et hors bande. Pour les procédures de surveillance, voir [Surveiller une passerelle](gateway-monitoring.md). Pour les autorisations, `hostSharedAlb` type de passerelle requis, voir [AmazonECSInfrastructureRoleForGatewayHostSharedALB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRoleForGatewayHostSharedALB.html) dans le *AWS Référence des politiques gérées*. ## Problèmes de capacité et de quotas Pour les valeurs des quotas, voir [Limites du service Gateway](gateway-overview.md#gateway-service-quotas). ### Le cluster a atteint sa limite d'association de passerelles Un cluster peut être associé à au plus 5 passerelles. Lorsqu'il atteint cette limite, Amazon ECS rapporte `Cluster has reached the maximum number of gateway associations (5)`. Dissociez une passerelle dont le cluster n'a plus besoin, ce qui nécessite de déconnecter d'abord les services qui l'utilisent encore. ### La passerelle a atteint son nombre maximum d'équilibreurs de charge Lorsque les équilibreurs de charge existants d'une passerelle ne peuvent pas accepter une autre connexion de service, Amazon ECS met en service un autre équilibreur de charge jusqu'à ce qu'il atteigne celui de la passerelle `maxAlbCount` réglage, dont la valeur par défaut est 10. Un équilibreur de charge peut fournir jusqu'à 25 services ECS. Lorsque chaque équilibreur de charge est plein et que la passerelle est `maxAlbCount`, le déploiement d'un nouveau service échoue. Vérifiez le `currentAlbCount` contre `maxAlbCount` et inspectez les ressources gérées : ``` aws ecs describe-gateway --gateway my-gateway aws ecs describe-gateway-resources --gateway my-gateway ``` Si `maxAlbCount` est le facteur limitant, augmentez-le dans la limite prise en charge. Par exemple : ``` aws ecs update-gateway \ --gateway my-gateway \ --configuration '{"hostSharedAlb":{"maxAlbCount":25}}' ``` Attendez que la mise à jour de la passerelle soit terminée, puis redéployez le service concerné. En hausse `maxAlbCount` ne réessaie pas automatiquement un déploiement de service qui a échoué. ### Un sous-jacent AWS le quota de ressources a été atteint Les ressources fournies par ECS Gateway sont soumises aux quotas de leurs propres services, y compris les équilibreurs de charge, les groupes cibles, les règles d'écoute, les certificats et les règles des groupes de sécurité. Le provisionnement peut également échouer si les sous-réseaux configurés ne disposent pas d'un nombre suffisant d'adresses IP disponibles. Vous pouvez voir les raisons suivantes : + `LoadBalancerQuotaExceeded` et `TargetGroupQuotaExceeded`, pour connaître les limites du compte dans la Région. + `ResourceQuotaExceeded`, pour une limite par équilibreur de charge, telle que des règles d'écoute ou des certificats. + `CertificateQuotaExceeded`, pour la limite de certificats du compte. + `CertificateAnnualLimitExceeded`, pour les certificats demandés au cours des 365 derniers jours. La suppression de certificats ne réduit pas ce nombre, donc celui-ci nécessite une augmentation du quota via AWS Soutien. + `SecurityGroupCapacityExceeded` et `SecurityGroupRuleCapacityExceeded`, pour les groupes de sécurité par VPC et les règles par groupe de sécurité. + `TestRuleLimitExceeded`, pour tester les règles de trafic sur un service. + `TagLimitExceeded`, pour une combinaison de balises de passerelle et de balises de service dépassant les limites autorisées par une ressource, ou pour les balises rejetées par la politique des balises de compte. Amazon ECS applique également ses propres `AmazonECSManaged` tag, qui utilise un emplacement. Utilisez la raison de l'échec pour identifier la ressource limitée, puis vérifiez le quota de service applicable. Demandez une augmentation de quota, libérez la capacité inutilisée ou utilisez une autre configuration prise en charge, puis réessayez le déploiement du service. Pour les limites d'Elastic Load Balancing, voir [Quotas pour les équilibreurs de charge de vos applications](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html). ## Problèmes liés à l'IAM et aux autorisations Les opérations de passerelle impliquent deux identités différentes : le principal IAM qui effectue la demande d'API et le rôle IAM de l'infrastructure qu'Amazon ECS assume pour gérer AWS ressources. Un problème d'autorisation sur l'un n'est pas résolu en modifiant l'autre. ### L'appelant ne peut pas passer le rôle d'infrastructure `CreateGateway` et `UpdateGateway` échouer avec une erreur d'autorisation impliquant `iam:PassRole` lorsque l'appelant ne peut pas passer le rôle fourni dans `infrastructureRoleArn`. Il s'agit de l'échec de première exécution le plus courant, car l'appel échoue même lorsque l'appelant est autorisé à créer des passerelles. Vérifiez que l'appelant a `iam:PassRole` autorisation sur le rôle exact de l'ARN dans `infrastructureRoleArn`, et vérifiez les limites des autorisations, les politiques de contrôle des services et les refus explicites. L'ajout d'autorisations au rôle d'infrastructure ne résout pas une autorisation manquante sur l'identité de l'appelant. Pour la configuration des rôles IAM, voir [Rôle IAM d'infrastructure pour Amazon ECS Gateway](gateway-managing.md#gateway-infrastructure-role). ### Amazon ECS ne peut pas assumer le rôle d'infrastructure Amazon ECS pouvait accéder à ce rôle mais ne pouvait pas l'assumer. Vérifiez que le rôle IAM existe et que sa politique de confiance le permet `ecs.amazonaws.com` appeler `sts:AssumeRole`. ``` aws iam get-role --role-name ecsInfrastructureRoleForGateways ``` La politique de confiance du rôle doit correspondre à ce qui suit. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessInfrastructureForECSGateways", "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Si le rôle vient d'être créé ou modifié, attendez que la modification d'IAM se propage avant de réessayer. Une relation de confiance manquante ou incorrecte n'est pas corrigée en accordant à l'appelant `iam:PassRole` seul. Vérifiez également que le rôle se trouve dans le même compte et la même partition que la passerelle. Un échec connexe, `AWS STS is not activated for this account in a Region`, signifie AWS Security Token Service n'est pas activé pour cette région. Activez-le, puis réessayez. ### Le rôle d'infrastructure ne peut pas gérer une ressource Un itinéraire de passerelle ou une mise à jour de passerelle signale une erreur d'accès refusé pour un Elastic Load Balancing, Amazon EC2 ou AWS Certificate Manager opération lorsque le rôle d'infrastructure n'a pas d'autorisation. Vérifiez que le rôle dispose des autorisations requises par la configuration de la passerelle. Pour `hostSharedAlb` type de passerelle, vérifiez la pièce jointe AWS politique gérée. ``` aws iam list-attached-role-policies --role-name ecsInfrastructureRoleForGateways ``` Joignez le `AmazonECSInfrastructureRoleForGatewayHostSharedALB` stratégie gérée ou, si vous l'avez remplacée par votre propre stratégie, comparez cette politique à l'action IAM nommée lors de l'échec. Vous pouvez consulter les autorisations accordées par cette politique dans le [*AWS Référence des politiques gérées*](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonECSInfrastructureRoleForGatewayHostSharedALB.html). Vérifiez également si une limite d'autorisations ou une autre restriction de compte empêche l'action. L'opération échouée exacte et l'ARN de la ressource sont plus utiles qu'un code indifférencié `AccessDenied` message. ## Connectivité des services et santé de la cible ### Le nom d'hôte du service ne répond pas Lorsque les demandes adressées à un nom d'hôte HTTPS généré par la passerelle expirent ou échouent, vérifiez la connexion entre la route de la passerelle et l'application. 1. **Vérifiez l'état de l'itinéraire de la passerelle.** Trouvez l'itinéraire pour le service et confirmez-le `ACTIVE`. Un itinéraire dans `CREATE_IN_PROGRESS` n'a pas terminé l'approvisionnement, et un itinéraire dans un `*_FAILED` l'État a un échec de provisionnement. Inspectez la défaillance de l'itinéraire avant de dépanner l'application : ``` aws ecs list-gateway-routes --cluster my-cluster --service my-service ``` 1. **Vérifiez l'accès à la passerelle.** Une passerelle interne nécessite une connectivité réseau à l'équilibreur de charge interne. Vérifiez que vous effectuez le test à partir d'un réseau qui peut y accéder. 1. **Vérifiez l'état de santé de la cible.** Obtenez l'ARN du groupe cible à partir de la connexion de passerelle du service, qui `describe-service-revisions` renvoie, puis inspecte ses cibles enregistrées. ``` aws elbv2 describe-target-health \ --target-group-arn arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-service/0123456789abcdef ``` Un groupe cible peut signaler des cibles défectueuses lorsque l'application renvoie un code d'état inattendu, expire, écoute sur un port différent ou ne peut pas être atteinte par l'équilibreur de charge. La réponse inclut l'état de santé de chaque cible et, le cas échéant, une raison et une description. Par exemple, une raison de `Target.ResponseCodeMismatch` indique que la réponse ne correspond pas à la plage de codes de réussite configurée. Vérifiez le chemin du contrôle de santé, la réponse de l'application et le port cible avant de modifier une infrastructure de passerelle. Pour les codes des motifs du bilan de santé, voir [Contrôles de santé pour les groupes cibles d'Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html). Un `ACTIVE` la route de passerelle signifie que le provisionnement d'entrée a réussi. Cela ne signifie pas que les cibles de l'application sont saines. 1. **Vérifiez les groupes de sécurité.** Vérifiez que le groupe de sécurité entrant de l'équilibreur de charge autorise le trafic en provenance des clients prévus et que le groupe de sécurité des tâches autorise le trafic provenant de l'équilibreur de charge sur le port de conteneur. Lorsque l'équipe de la plateforme fournit le groupe de sécurité entrant de la passerelle, Amazon ECS ne gère pas ses règles entrantes. 1. **Vérifiez l'application et les commandes de trafic.** Vérifiez le port d'écoute et le point final d'intégrité du conteneur. Si un AWS WAF l'ACL web est configurée, vérifiez si une règle bloque la demande. Utilisez les journaux d'accès de l'équilibreur de charge et CloudWatch des mesures permettant de distinguer les erreurs de l'équilibreur de charge des réponses des applications. ## Échecs de mise à jour `DescribeGateway` rapports `UPDATE_FAILED` après une mise à jour de configuration de passerelle qu'Amazon ECS n'a pas pu appliquer à tous les équilibreurs de charge. Amazon ECS applique une mise à jour à chaque équilibreur de charge géré à tour de rôle et fait de son mieux pour tous les mettre à jour plutôt que de s'arrêter au premier échec. Certains équilibreurs de charge peuvent donc accepter la modification tandis que d'autres échouent. Ne partez pas du principe que la mise à jour a été annulée sur la passerelle. Récupérez l'état et les informations de panne. ``` aws ecs describe-gateway --gateway my-gateway ``` Inspectez `statusReason` et `failures` pour les ressources et les opérations qui n'ont pas pu être mises à jour. Par exemple, une erreur concernant un identifiant de groupe de sécurité non valide pointe vers le groupe de sécurité entrant configuré pour la passerelle, et une erreur d'accès refusé pointe vers les autorisations disponibles pour le rôle d'infrastructure. Pour savoir comment lire le `failures` liste, voir [Localisez les détails des défaillances](gateway-monitoring.md#gateway-where-failures-recorded). Corrigez la cause signalée et réessayez la mise à jour demandée. Attendez que la passerelle signale une mise à jour réussie avant de supposer que chaque équilibreur de charge géré possède la nouvelle configuration, et attendez que la mise à jour soit terminée avant de réessayer. **Important** Une mise à jour partielle de la passerelle peut laisser différents équilibreurs de charge dotés de configurations différentes, ce qui peut modifier le comportement du trafic ou des politiques pour les services qui les sous-tendent. Traitez la mise à jour comme partiellement appliquée jusqu'à ce que la passerelle fasse rapport `UPDATE_COMPLETE`, et validez les ressources concernées après la restauration. ## Problèmes de dissociation et de suppression ### Une association de clusters reste DISSOCIANTE Une association de clusters de passerelles reste active `DISASSOCIATING` jusqu'à ce que toutes les routes de passerelle associées à ce cluster soient supprimées. Amazon ECS ne redéploie pas automatiquement les services connectés et ne supprime pas leurs itinéraires existants lorsque vous dissociez une passerelle. Pour identifier les services toujours connectés, utilisez la commande suivante : ``` aws ecs list-gateway-routes --gateway my-gateway --cluster my-cluster ``` Coordonnez-vous avec les équipes chargées de l'application pour mettre à jour ou redéployer les services concernés afin qu'ils se déconnectent de la passerelle. Lorsque le dernier itinéraire est supprimé, la dissociation est terminée. ### La passerelle ne peut pas être supprimée Une passerelle ne peut pas être supprimée tant que la protection contre la suppression est activée ou lorsqu'elle est associée à des clusters dans `ACTIVE` ou `DISASSOCIATING` état. Vérifiez les associations de clusters de la passerelle et assurez-vous que toutes les routes de passerelle restantes sont supprimées afin que la dissociation puisse être terminée. Une fois toutes les associations supprimées, assurez-vous que la protection contre la suppression est désactivée, puis réessayez de supprimer la passerelle. Pour la procédure complète, voir [Supprimer une passerelle](gateway-managing.md#gateway-delete). ``` aws ecs update-gateway --gateway my-gateway --no-deletion-protection aws ecs delete-gateway --gateway my-gateway ``` ## Modifications apportées en dehors d'Amazon ECS Amazon ECS ne répare ni ne recrée automatiquement les ressources gérées par la passerelle qui sont modifiées ou supprimées en dehors d'Amazon ECS. La modification ou la suppression de ressources gérées telles que des équilibreurs de charge, des écouteurs, des règles d'écoute, des groupes cibles, des certificats ou des groupes de sécurité extérieurs à Amazon ECS peut interrompre le trafic ou entraîner l'échec de déploiements de services ultérieurs, de mises à jour de passerelles ou d'opérations de nettoyage. Si une ressource gérée par passerelle a été modifiée ou supprimée en dehors d'Amazon ECS, procédez comme suit : 1. **Identifier la ressource concernée**: Utilisation `describe-gateway-resources` ou `describe-gateway-route` pour identifier les ressources gérées. Inspectez leur configuration actuelle dans le AWS service permettant d'identifier les ressources manquantes ou modifiées. Une modification apportée en dehors d'Amazon ECS peut apparaître comme l'une des raisons d'échec suivantes : + `ManagedResourceDeleted`, lorsqu'une ressource créée par Amazon ECS pour le service a été supprimée en dehors d'Amazon ECS. + `ConflictingListener`, lorsqu'un écouteur existe sur le port de la passerelle sur l'équilibreur de charge et qu'Amazon ECS ne l'a pas créé. + `SecurityGroupNameInUse`, lorsqu'un groupe de sécurité portant le nom souhaité par Amazon ECS existe et n'est pas géré par Amazon ECS. Amazon ECS ne le reconfigure ni ne le supprime. + `InvalidSecurityGroup`, lorsque le groupe de sécurité entrant de la passerelle n'existe plus. 1. **Restaurez le service concerné**: si une ressource a été modifiée, restaurez sa configuration d'origine et redéployez le service. Si une ressource a été supprimée, supprimez le connecteur de passerelle du service et déployez-le, puis ajoutez-le à nouveau et déployez-le à nouveau. Le second déploiement fournit de nouvelles ressources et une nouvelle passerelle. Étant donné que le service reçoit un nouveau nom d'hôte généré, mettez à jour tous les clients ou enregistrements DNS qui pointent vers l'ancien. 1. **Vérifiez la connectivité**: confirmez que la route de passerelle du service est `ACTIVE` et ses cibles sont saines avant que vous ne redirigiez le trafic vers ce site. **Important** Ne modifiez ni ne supprimez `AmazonECSManaged` balise provenant de ressources gérées par la passerelle. Amazon ECS l'utilise pour identifier les ressources qu'il gère, sans quoi Amazon ECS ne peut plus mettre à jour ni nettoyer ces ressources. Apportez les modifications de configuration prises en charge via les opérations d'Amazon ECS Gateway plutôt que de modifier directement les ressources sous-jacentes.