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.

2. 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 <service-revision-arn> \
       --query 'serviceRevisions[0].networkConfiguration.awsvpcConfiguration.subnets'

3. 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

4. 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 <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.

5. 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.

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

2. 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

3. 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.

4. 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.

Pour les autorisations, hostSharedAlb type de passerelle requis, voir AmazonECSInfrastructureRoleForGatewayHostSharedALB 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.

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.

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.

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. 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

2. 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.

3. 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.

   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.

4. 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.

5. 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. 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.

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.

2. 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.

3. 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.