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. # Architecture de votre solution pour Amazon ECS Vous devez bâtir vos applications de manière à ce qu’elles puissent s’exécuter sur des *conteneurs*. Un conteneur est une unité standardisée de développement logiciel qui contient tout ce dont votre application logicielle a besoin pour être exécutée. Cela inclut le code, l'exécution, les outils système et les bibliothèques système pertinents. Les conteneurs sont créés à partir d'un modèle en lecture seule appelé *image*. Une image de conteneur est un artefact statique contenant votre application et ses dépendances. Les images sont généralement créées à partir d'un fichier Dockerfile. Un Dockerfile est un fichier en texte brut qui contient les instructions pour créer un conteneur. Après leur création, ces images sont stockées dans un *registre*, comme Amazon ECR, d'où elles peuvent être téléchargées. Après avoir créé et stocké votre image, vous créez une définition de tâche Amazon ECS. Une *définition de tâche* est le plan de votre application. Il s'agit d'un fichier texte au format JSON qui décrit les paramètres et un ou plusieurs conteneurs qui forment votre application. Par exemple, vous pouvez l'utiliser pour spécifier l'image et les paramètres du système d'exploitation, les conteneurs à utiliser, les ports à ouvrir pour votre application et les volumes de données à utiliser avec les conteneurs dans la tâche. Les paramètres spécifiques disponibles pour votre définition de tâche dépendent des besoins de votre application spécifique. Après avoir défini votre définition de tâche, vous la déployez sous forme de service ou de tâche sur votre cluster. Un *cluster* est un regroupement logique de tâches ou de services qui s'exécute sur l'infrastructure de capacité enregistrée dans un cluster. Une *tâche* est l'instanciation d'une définition de tâche au sein d'un cluster. Vous pouvez exécuter une tâche autonome ou exécuter une tâche dans le cadre d'un service. Vous pouvez utiliser un service Amazon ECS *service* pour exécuter et gérer simultanément le nombre souhaité de tâches dans un cluster Amazon ECS. Le principe est le suivant : si l'une de vos tâches échoue ou s'arrête pour une raison quelconque, le planificateur de service d'Amazon ECS service lance une autre instance en fonction de votre définition de tâche. Il procède ainsi pour le remplacer et donc maintenir le nombre de tâches souhaité dans le service. L'*agent de conteneur* s'exécute sur chaque instance de conteneur dans un cluster Amazon ECS. L'agent envoie à Amazon ECS des informations relatives aux tâches en cours d'exécution et à l'utilisation des ressources de vos conteneurs. Il démarre et arrête les tâches lorsqu'il reçoit une requête de la part d'Amazon ECS. Une fois la tâche ou le service déployés, vous pouvez utiliser l'un des outils suivants pour surveiller votre déploiement et votre application : + CloudWatch + Surveillance d’exécution ## Capacity La capacité correspond à l’infrastructure sur laquelle vos conteneurs s’exécutent. Amazon ECS propose trois types d’infrastructure pour vos clusters : + Instances gérées Amazon ECS : gère AWS entièrement les instances Amazon EC2 sous-jacentes exécutées sur votre compte, y compris le provisionnement, l'application de correctifs et le dimensionnement. Cette option offre un équilibre optimal entre performances, rentabilité et simplicité opérationnelle. + Sans serveur (Fargate) : ne payez que pour les ressources utilisées par vos tâches sans gérer aucune infrastructure. Idéal pour les charges de travail variables et pour démarrer rapidement. + Instances Amazon EC2 : vous gérez directement les instances Amazon EC2 sous-jacentes, y compris la sélection, la configuration et la maintenance des instances. Utilisez les instances gérées Amazon ECS lorsque : + vous recherchez la simplicité de Fargate avec un meilleur contrôle de l’infrastructure sous-jacente ; + vous avez besoin de performances prévisibles et d’une optimisation des coûts ; + Vous souhaitez AWS gérer la gestion de l'infrastructure tout en préservant la flexibilité. Utilisez Fargate lorsque : + vous souhaitez vous concentrer sur votre application sans gérer l’infrastructure ; + vous avez des charges de travail variables ou imprévisibles ; + vous débutez avec les conteneurs et souhaitez l’option de déploiement la plus simple. Utiliser des instances Amazon EC2 lorsque : + vous avez besoin d’exigences matérielles spécifiques (accélération du GPU, calcul haute performance) ; + vous avez besoin de réserves de capacité ou de types d’instances spécifiques ; + Vous avez besoin de fonctionnalités privilégiées ou personnalisées AMIs. L’infrastructure est spécifiée lors de la création d’un cluster. Le type d’infrastructure est également spécifié lors de l’enregistrement d’une définition de tâche. La définition de la tâche désigne l’infrastructure sous le nom de « type de lancement ». Vous pouvez également faire appel à des fournisseurs de capacité. ## Points de terminaison de service Le point de terminaison du service est l'URL du point d'entrée d'Amazon ECS que vous utilisez pour vous connecter au service par programmation à l'aide du protocole Internet version 4 (IPv4) ou du protocole Internet version 6 (IPv6). Par défaut, les demandes que vous effectuez pour vous connecter à Amazon ECS par programmation utilisent des points de terminaison de service qui ne prennent en charge que les demandes. IPv4 Pour vous connecter par programmation à Amazon ECS à l'aide de l'une IPv4 ou de plusieurs IPv6 requêtes, vous pouvez utiliser un point de terminaison à double pile. Pour de plus amples informations sur les points de terminaison à double pile, consultez la section [Utilisation des points de terminaison à double pile Amazon ECS](dual-stack-endpoint.md). ## Réseaux AWS les ressources sont créées dans des sous-réseaux. Lorsque vous utilisez des instances EC2, Amazon ECS lance les instances dans le sous-réseau que vous spécifiez lorsque vous créez un cluster. Vos tâches s’exécutent dans le sous-réseau de l’instance. Pour Fargate ou les machines virtuelles sur site, vous spécifiez le sous-réseau lorsque vous exécutez une tâche ou créez un service. Selon votre application, le sous-réseau peut être un sous-réseau privé ou public et le sous-réseau peut se trouver dans l'une des ressources suivantes : AWS + Zones de disponibilité + Local Zones + Zones Wavelength + Régions AWS + AWS Outposts Pour plus d’informations, consultez [Applications Amazon ECS dans des sous-réseaux partagés, des zones locales et des Zones Wavelength](cluster-regions-zones.md) ou [Amazon Elastic Container Service sur AWS Outposts](using-outposts.md). Vous pouvez connecter votre application à Internet à l’aide de l’une des méthodes suivantes : + Un sous-réseau public avec une passerelle Internet Utilisez des sous-réseaux publics lorsque vous avez des applications publiques qui nécessitent de grandes quantités de bande passante ou une latence minimale. Les scénarios applicables incluent le streaming vidéo et les services de jeux. + Un sous-réseau privé avec une passerelle NAT Utilisez des sous-réseaux privés lorsque vous souhaitez protéger vos conteneurs d’un accès externe direct. Les scénarios applicables incluent les systèmes de traitement des paiements ou les conteneurs stockant les données utilisateur et les mots de passe. + AWS PrivateLink AWS PrivateLink Utilisez-le pour bénéficier d'une connectivité privée entre les VPCs AWS services et vos réseaux locaux sans exposer votre trafic à l'Internet public. ## Accès aux fonctionnalités Vous pouvez utiliser les paramètres de votre compte Amazon ECS pour accéder aux fonctionnalités suivantes : + Container Insights CloudWatch Container Insights collecte, agrège et résume les métriques et les journaux de vos applications conteneurisées et de vos microservices. Les métriques incluent l'utilisation des ressources telles que l'UC, la mémoire, le disque et le réseau. + Jonction `awsvpc` Pour certains types d'instances EC2, des interfaces réseau supplémentaires (ENIs) peuvent être disponibles sur les instances de conteneur récemment lancées. + Autorisation de balisage Les utilisateurs doivent être autorisés à effectuer les actions qui créent la ressource, comme `ecsCreateCluster`. Si des balises sont spécifiées dans l'action de création de ressources, octroie AWS une autorisation supplémentaire à l'`ecs:TagResource`action afin de vérifier si les utilisateurs ou les rôles sont autorisés à créer des balises. + Conformité de Fargate à la norme FIPS-140 Fargate prend en charge la norme Federal Information Processing Standard (FIPS-140), qui spécifie les exigences de sécurité pour les modules cryptographiques qui protègent des informations sensibles. Il s'agit de la norme gouvernementale en vigueur aux États-Unis et au Canada, applicable aux systèmes qui doivent être conformes à la loi sur la gestion de la sécurité des informations fédérales (FISMA) ou au programme fédéral de gestion des risques et des autorisations (FedRAMP). + Modification de l’heure de mise hors service de tâche Fargate Vous pouvez configurer la période d’attente avant que les tâches ne soient mises hors service pour l’application de correctif. + VPC à double pile Autorisez les tâches à communiquer entre IPv6 elles ou les deux. IPv4 + Format Amazon Resource Name (ARN) Certaines fonctionnalités, telles que l’autorisation d’étiquetage, nécessitent un nouveau format Amazon Resource Name (ARN). Pour de plus amples informations, veuillez consulter [Accès aux fonctionnalités d’Amazon ECS avec les paramètres du compte](ecs-account-settings.md). ## Rôles IAM Un rôle IAM est une identité IAM que vous pouvez créer dans votre compte et qui dispose d’autorisations spécifiques. Dans Amazon ECS, vous pouvez créer des rôles pour accorder des autorisations à des ressources Amazon ECS telles que des conteneurs ou des services. Certaines fonctionnalités d’Amazon ECS nécessitent des rôles. Pour de plus amples informations, veuillez consulter [Rôles IAM pour Amazon ECS](ecs-iam-role-overview.md). ## Logging La journalisation et la surveillance sont des aspects importants pour maintenir la fiabilité, la disponibilité et les performances des charges de travail Amazon ECS. Les options suivantes sont disponibles : + Amazon CloudWatch logs - acheminer les journaux vers Amazon CloudWatch + FireLenspour Amazon ECS : acheminez les journaux vers un AWS service ou une AWS Partner Network destination pour le stockage et l'analyse des journaux. AWS Partner Network Il s'agit d'une communauté mondiale de partenaires qui tire parti des programmes, de l'expertise et des ressources pour créer, commercialiser et vendre des offres aux clients. ## Pratiques exemplaires relatives aux images de conteneur Les principes clés relatifs aux images de conteneurs Amazon ECS sont les suivants : + Inclure toutes les dépendances dans l’image + Exécuter un processus par conteneur + Gérer `SIGTERM` pour des arrêts gracieux + Écrire des journaux dans `stdout` et `stderr` + Utilisez des balises uniques, évitez `latest` en production # Types de lancement d'Amazon Amazon ECS et fournisseurs de capacité Amazon ECS propose deux méthodes de configuration de la capacité pour les charges de travail. Vous pouvez utiliser des types de lancement ou des fournisseurs de capacité. Les types de lancement incluent EC2, Fargate et External. Les fournisseurs de capacité offrent une flexibilité accrue et des fonctionnalités avancées pour la gestion des capacités. Vous pouvez exécuter des charges de travail sur du calcul sans serveur avec les fournisseurs de capacité Fargate et Fargate Spot, sur des instances EC2 autogérées par le biais des fournisseurs de capacité du groupe Auto Scaling, ou sur un calcul entièrement géré à l'aide des fournisseurs de capacité Amazon ECS Managed Instances qui combinent la simplicité de Fargate à la flexibilité du calcul EC2. Les fournisseurs de capacité offrent un meilleur contrôle de l'allocation des ressources et peuvent contribuer à optimiser les performances et les coûts. Les fournisseurs de capacité sont la méthode recommandée pour configurer la capacité pour les charges de travail par rapport aux types de lancement traditionnels. Utilisez ce qui suit pour comprendre les différences entre les fournisseurs de capacité et les types de lancement. ## Bonnes pratiques Les meilleures pratiques sont les suivantes : Utiliser les types de lancement pour définir la compatibilité de l'infrastructure Les types de lancement définissent l'infrastructure sur laquelle les tâches et les services s'exécutent. Lorsque vous définissez des tâches, spécifiez `RequiresCompatibilities` d'inclure un ou plusieurs types de lancement compatibles avec les tâches. Vous pouvez utiliser les types de lancement suivants : EC2, Fargate, External et Amazon ECS Managed Instances. Bien que vous puissiez également utiliser le type de lancement pour exécuter vos tâches ou services, nous vous recommandons de n'utiliser le type de lancement que pour définir les compatibilités dans vos définitions de tâches et d'utiliser des fournisseurs de capacité pour lancer des tâches ou des services. Notez que vous pouvez choisir un ou plusieurs types de lancement pour définir les compatibilités des tâches. Utiliser des fournisseurs de capacité pour configurer la capacité de calcul Lorsque vous lancez des tâches ou des services, configurez une stratégie de fournisseur de capacité. Amazon ECS prend en charge les fournisseurs de capacité suivants : Fargate et FARGATE\$1SPOT, les groupes Auto Scaling pour les instances EC2 autogérées et les instances gérées Amazon ECS. Notez que Spot Fleet est uniquement disponible en tant que fournisseur de capacité et non en tant que type de lancement. Vous pouvez créer une ou plusieurs instances gérées Amazon ECS ou des fournisseurs de capacité de groupes Auto Scaling dans un cluster. Les fournisseurs de capacité Fargate et Fargate Spot sont créés et gérés par Amazon ECS sur chaque cluster et vous n'avez pas besoin de les créer. Un cluster peut combiner tous les types de fournisseurs de capacité, mais une stratégie de fournisseur de capacité ne peut pas combiner différents types de fournisseurs de capacité. Mettre à jour la capacité des services Vous pouvez simplement mettre à jour la stratégie d'un fournisseur de capacité pour un service afin de le déplacer d'un type de calcul à l'autre. ## Mutabilité des services Amazon ECS prend en charge les services de mise à jour entre différents fournisseurs de capacité. Cela permet de : + Mise à jour fluide des types de lancement aux fournisseurs de capacité + Transitions entre les différents types de fournisseurs de capacité + Tester différentes options de calcul sans recréation de service Voici un aperçu général du processus : 1. Mettez à jour la définition de la tâche : assurez-vous d'`requiresCompatibilities`inclure le fournisseur de capacité cible, par exemple` MANAGED_INSTANCES`. **Note** Les définitions de tâches doivent réussir la validation de compatibilité pour le fournisseur de capacité cible. Si la `requiresCompatibilities` vérification échoue pour la version de définition de tâche, l'`UpdateService`appel échoue. 1. Création d'un fournisseur de capacité : si vous utilisez des groupes Amazon EC2 Auto Scaling personnalisés, créez le fournisseur de capacité. 1. Mettre à jour le service : modifiez le service pour utiliser une stratégie de fournisseur de capacité au lieu du type de lancement. 1. Valider le déploiement : vérifiez que les tâches sont correctement déployées. 1. Surveiller et optimiser : ajustez les paramètres du fournisseur de capacité selon les besoins. ### De fournisseur de capacité à fournisseur de capacité Toutes les mises à jour entre fournisseurs de capacité sont prises en charge : + Fournisseur de capacité du groupe Amazon EC2 Auto Scaling pour les instances gérées Amazon ECS + Fournisseur de capacité Fargate pour les instances gérées Amazon ECS + Amazon EC2 Auto Scaling associe le fournisseur de capacité au fournisseur de capacité Fargate + Des instances gérées par Amazon ECS pour le fournisseur de capacité Fargate + Fournisseur de capacité Fargate au fournisseur de capacité du groupe Amazon EC2 Auto Scaling + Instances gérées par Amazon ECS pour le fournisseur de capacité du groupe Amazon EC2 Auto Scaling ### Type de lancement vers fournisseur de capacité Toutes les mises à jour du type de lancement vers le fournisseur de capacité sont prises en charge : + Type de lancement EC2 vers les instances gérées Amazon ECS + Type de lancement Fargate vers les instances gérées Amazon ECS + Type de lancement EC2 vers le fournisseur de capacité Fargate + Type de lancement EC2 vers le fournisseur de capacité du groupe EC2 Auto Scaling + Type de lancement Fargate vers le fournisseur de capacité du groupe Amazon EC2 Auto Scaling + Type de lancement Fargate vers le fournisseur de capacité Fargate + Type de lancement externe vers les instances gérées Amazon ECS + Type de lancement externe vers le fournisseur de capacité Fargate + Type de lancement externe vers le fournisseur de capacité du groupe Amazon EC2 Auto Scaling ### Type de lancement à type de lancement Les mises à jour de type de lancement à type de lancement ne sont pas prises en charge : + Type de lancement EC2 vers type de lancement Fargate (utilisez plutôt le fournisseur de capacité Fargate) + Type de lancement Fargate vers type de lancement EC2 (utilisez plutôt le fournisseur de capacité du groupe Amazon EC2 Auto Scaling) Au lieu de passer d'un type de lancement à un autre, migrez vers le fournisseur de capacité équivalent pour bénéficier de fonctionnalités améliorées et d'une compatibilité future. **Note** Les définitions de tâches doivent réussir la validation de compatibilité pour le fournisseur de capacité cible. Si la `requiresCompatibilities` vérification échoue pour la version de définition de tâche, l'`UpdateService`appel échouera. # Utilisation des points de terminaison à double pile Amazon ECS Les points de terminaison à double pile Amazon ECS prennent en charge les demandes adressées à Amazon ECS via le protocole Internet version 4 (IPv4) et le protocole Internet version 6 (IPv6). Pour obtenir la liste des points de terminaison Amazon ECS, consultez la section [Points de terminaison et quotas Amazon ECS](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html) dans le Références générales AWS. Lorsque vous utilisez l’API REST, vous accédez directement à un point de terminaison Amazon ECS à l’aide du nom de point de terminaison (URI). Amazon ECS ne prend en charge que les noms de points de terminaison à double pile régionaux ; vous devez donc spécifier la région dans le nom. Utilisez la convention de nommage suivante pour les noms des points de terminaison à double pile : `ecs.region.api.aws`. Lorsque vous utilisez le AWS Command Line Interface (AWS CLI) et AWS SDKs, vous pouvez utiliser un paramètre ou un indicateur pour passer à un point de terminaison à double pile. Vous pouvez également spécifier directement le point de terminaison à double pile en remplaçant le point de terminaison Amazon ECS dans le fichier de configuration. Les sections suivantes décrivent comment utiliser les points de terminaison à double pile à partir de l'API REST AWS CLI, de AWS SDKs, et de l'API REST. **Topics** + [En utilisant des points de terminaison à double pile à partir du AWS CLI](#dual-stack-endpoints-cli) + [En utilisant des points de terminaison à double pile à partir du AWS SDKs](#dual-stack-endpoints-sdks) + [Utilisation de points de terminaison Dual-Stack avec l'API REST](#dual-stack-endpoints-examples-rest-api) ## En utilisant des points de terminaison à double pile à partir du AWS CLI Cette section fournit des exemples de AWS CLI commandes utilisées pour envoyer des demandes à un point de terminaison à double pile. Pour plus d'informations sur l'installation AWS CLI ou la mise à jour vers la dernière version, voir [Installation ou mise à jour vers la dernière version du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) *Guide de l'AWS Command Line Interface utilisateur de la version 2*. Pour utiliser un point de terminaison à double pile, vous pouvez définir la valeur `use_dualstack_endpoint` de configuration sur `true` dans le `config` fichier AWS CLI afin de diriger toutes les demandes Amazon ECS effectuées par la `ecs` AWS CLI commande vers le point de terminaison à double pile pour la région spécifiée. Vous indiquez la Région dans le fichier `config` ou dans une commande à l’aide de l’option `--region`. Pour plus d'informations sur les fichiers de configuration pour le AWS CLI, consultez la section [Paramètres des fichiers de configuration et d'identification AWS CLI dans le](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) *guide de l'AWS Command Line Interface utilisateur de la version 2*. Si vous souhaitez utiliser un point de terminaison à double pile pour des AWS CLI commandes spécifiques, vous pouvez utiliser l'une des méthodes suivantes : + Vous pouvez utiliser le point de terminaison à double pile par commande en définissant le paramètre `--endpoint-url` sur `https://ecs.aws-region.api.aws` ou sur `http://ecs.aws-region.api.aws` pour toute commande `ecs`. L’exemple de commande suivant répertorie tous les clusters disponibles et utilise le point de terminaison à double pile pour la requête. ``` $ aws ecs list-clusters --endpoint-url https://ecs.aws-region.api.aws ``` + Vous pouvez configurer des profils distincts dans votre AWS Config fichier. Par exemple, vous pouvez créer un profil qui définit `use_dualstack_endpoint` sur `true` et un profil qui ne définit pas `use_dualstack_endpoint`. Lorsque vous exécutez une commande, spécifiez le profil adéquat selon que vous comptez utiliser ou non le point de terminaison Dual-Stack. ## En utilisant des points de terminaison à double pile à partir du AWS SDKs Cette section fournit des exemples de la manière d'accéder à un point de terminaison à double pile à l'aide du AWS SDKs. ------ #### [ AWS SDK for Java 2.x ] L’exemple suivant montre comment spécifier un point de terminaison à double pile pour la région `us-east-1` à l’aide de AWS SDK for Java 2.x. ``` Region region = Region.US_EAST_1 EcsClient client = EcsClient.builder().region(region).dualstackEnabled(true).build(); ``` ------ #### [ AWS SDK pour Go ] L’exemple suivant montre comment spécifier un point de terminaison à double pile pour la région `us-east-1` à l’aide de AWS SDK pour Go. ``` sess := session.Must(session.NewSession()) svc := ecs.New(sess, &aws.Config{ Region: aws.String(endpoints.UsEast1RegionID), Endpoint: aws.String("https://ecs.us-east-1.api.aws") }) ``` ------ Pour plus d'informations, consultez la section [Points de terminaison à double pile et FIPS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) dans le guide de référence *AWS SDKs et Tools*. ## Utilisation de points de terminaison Dual-Stack avec l'API REST Lorsque vous utilisez l’API REST, vous pouvez accéder directement à un point de terminaison à double pile si vous le spécifiez dans votre requête. L’exemple suivant utilise le point de terminaison à double pile pour répertorier tous les clusters Amazon ECS de la région `us-east-1`. ``` POST / HTTP/1.1 Host: ecs.us-east-1.api.aws Accept-Encoding: identity Content-Length: 2 X-Amz-Target: AmazonEC2ContainerServiceV20141113.ListClusters X-Amz-Date: 20150429T170621Z Content-Type: application/x-amz-json-1.1 Authorization: AUTHPARAMS {} ``` # Applications Amazon ECS dans des sous-réseaux partagés, des zones locales et des Zones Wavelength Amazon ECS prend en charge les charges de travail qui utilisent des zones locales, des zones de longueur d'onde, et AWS Outposts lorsqu'une faible latence ou un traitement local des données sont requis. + Vous pouvez utiliser les Zones Locales comme extension et Région AWS pour placer des ressources dans plusieurs emplacements plus proches de vos utilisateurs finaux. + Vous pouvez utiliser les zones Wavelength pour créer des applications qui offrent des latences ultra-faibles aux appareils 5G et aux utilisateurs finaux. Wavelength déploie des services de AWS calcul et de stockage standard à la périphérie des réseaux 5G des opérateurs de télécommunications. + AWS Outposts intègre des modèles natifs Services AWS, d'infrastructure et d'exploitation à pratiquement tous les centres de données, espaces de colocation ou installations sur site. **Important** Amazon ECS sur les AWS Fargate charges de travail n'est pas pris en charge dans les zones Local, les zones de longueur d'onde ou autres pour le AWS Outposts moment. Pour plus d'informations sur les différences entre les zones locales, les zones de longueur d'onde et AWS Outposts , voir [How should I think about when to use AWS Wavelength, AWS Local Zones, or AWS Outposts for applications nécessitant une faible latence ou un traitement local des données](https://aws.amazon.com/wavelength/faqs/) dans le AWS Wavelength FAQs. ## Sous-réseaux partagés Vous pouvez utiliser *Partage de VPC* pour partager des sous-réseaux avec d'autres comptes  AWS  au sein d'un même AWS Organizations. Vous pouvez utiliser des VPC partagés pour EC2 en tenant compte des considérations suivantes : + Le propriétaire du sous-réseau VPC doit partager un sous-réseau avec un compte participant avant que ce compte puisse y créer des ressources Amazon ECS. + Vous ne pouvez pas utiliser le groupe de sécurité par défaut VPC pour vos instances de conteneur, car il appartient au propriétaire. De plus, les participants ne peuvent pas lancer d’instances avec des groupes de sécurité détenus par d’autres participants ou par le propriétaire. + Dans un sous-réseau partagé, le participant et le propriétaire contrôlent séparément les groupes de sécurité au sein de leur compte respectif. Le propriétaire du sous-réseau peut voir ces groupes de sécurité créés par les participants, mais ne peut pas exécuter d'actions sur ceux-ci. Si le propriétaire du sous-réseau souhaite supprimer ou modifier ces groupes de sécurité, le participant qui a créé le groupe de sécurité doit effectuer l'action. + Le propriétaire du VPC partagé ne peut pas afficher, mettre à jour ou supprimer un cluster créé par un participant dans le sous-réseau partagé. Cela s'ajoute aux ressources VPC auxquelles chaque compte a un accès différent. Pour plus d'informations, consultez [Responsabilités et autorisations pour les propriétaires et les participants](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) dans le *Guide de l'utilisateur Amazon VPC*. Vous pouvez utiliser le partage VPCs pour Fargate en tenant compte des considérations suivantes : + Le propriétaire du sous-réseau VPC doit partager un sous-réseau avec un compte participant avant que ce compte puisse y créer des ressources Amazon ECS. + Vous ne pouvez pas créer de service ni exécuter de tâche à l’aide du groupe de sécurité par défaut pour le VPC, car celui-ci appartient au propriétaire. De plus, les participants ne peuvent pas créer un service ou exécuter une tâche à l’aide de groupes de sécurité appartenant à d’autres participants ou au propriétaire. + Dans un sous-réseau partagé, le participant et le propriétaire contrôlent séparément les groupes de sécurité au sein de leur compte respectif. Le propriétaire du sous-réseau peut voir ces groupes de sécurité créés par les participants, mais ne peut pas exécuter d'actions sur ceux-ci. Si le propriétaire du sous-réseau souhaite supprimer ou modifier ces groupes de sécurité, le participant qui a créé le groupe de sécurité doit effectuer l'action. + Le propriétaire du VPC partagé ne peut pas afficher, mettre à jour ou supprimer un cluster créé par un participant dans le sous-réseau partagé. Cela s'ajoute aux ressources VPC auxquelles chaque compte a un accès différent. Pour plus d'informations, consultez [Responsabilités et autorisations pour les propriétaires et les participants](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) dans le *Guide de l'utilisateur Amazon VPC*. Pour plus d'informations sur le partage de sous-réseaux VPC, consultez [Partager votre VPC avec d'autres comptes](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) dans le *Guide de l'utilisateur Amazon VPC*. ## Local Zones Une *zone locale* est une extension d'une Région AWS zone géographique très proche de vos utilisateurs. Les Local Zones ont leurs propres connexions à Internet et prennent en charge Direct Connect. Les ressources créées dans une zone locale peuvent servir les utilisateurs locaux avec des communications à faible latence. Pour plus d’informations, consultez [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Une zone locale est représentée par un code de région suivi d'un identifiant qui indique l'emplacement (par exemple, `us-west-2-lax-1a`). Pour utiliser une Local Zone, vous devez d'abord vous inscrire à la zone. Une fois que vous avez choisi, vous devez créer un VPC Amazon et un sous-réseau dans la Local Zone. Vous pouvez lancer des instances Amazon EC2, des serveurs de FSx fichiers Amazon et des équilibreurs de charge d'application à utiliser pour vos clusters et tâches Amazon ECS. Pour plus d'informations, voir [Qu'est-ce que AWS les zones locales ?](https://docs.aws.amazon.com/local-zones/latest/ug/what-is-aws-local-zones.html) dans le *Guide de l'utilisateur des Zones AWS Locales*. ## Zones Wavelength Vous pouvez utiliser *AWS Wavelength* pour créer des applications qui offrent une latence ultra-faible aux appareils mobiles et aux utilisateurs finaux. Wavelength déploie des services de AWS calcul et de stockage standard à la périphérie des réseaux 5G des opérateurs de télécommunications. Vous pouvez étendre un Amazon Virtual Private Cloud à une ou plusieurs zones Wavelength. Vous pouvez ensuite utiliser AWS des ressources telles que les instances Amazon EC2 pour exécuter des applications nécessitant une latence très faible et une connexion Services AWS à la région. Une zone Wavelength est une zone isolée située à l'emplacement du transporteur où l'infrastructure Wavelength est déployée. Les zones de longueur d'onde sont liées à un Région AWS. Une zone Wavelength est une extension logique d’une région et est gérée par le plan de contrôle de la région. Une zone Wavelength est représentée par un code de région suivi d'un identifiant qui indique la zone Wavelength (par exemple, `us-east-1-wl1-bos-wlz-1`). Pour utiliser une zone Wavelength, vous devez d'abord vous inscrire à la zone. Une fois que vous avez choisi, vous devez créer un VPC Amazon et un sous-réseau dans la zone Wavelength. Ensuite, vous pouvez lancer dans la zone vos instances Amazon EC2 à utiliser pour vos clusters et tâches Amazon ECS. Pour plus d’informations, consultez [Mise en route avec AWS Wavelength](https://docs.aws.amazon.com/wavelength/latest/developerguide/get-started-wavelength.html) dans le *Guide du développeur AWS Wavelength *. Les zones de longueur d'onde ne sont pas toutes disponibles Régions AWS. Pour plus d’informations sur les régions qui prennent en charge les zones Wavelength, consultez [Zones Wavelength disponibles](https://docs.aws.amazon.com/wavelength/latest/developerguide/available-wavelength-zones.html) dans le *Guide du développeur AWS Wavelength *. # Amazon Elastic Container Service sur AWS Outposts AWS Outposts permet AWS des services, une infrastructure et des modèles d'exploitation natifs dans les installations sur site. Dans AWS Outposts les environnements, vous pouvez utiliser les mêmes AWS APIs outils et infrastructures que ceux que vous utilisez dans le AWS Cloud. Amazon ECS on AWS Outposts est idéal pour les charges de travail à faible latence qui doivent être exécutées à proximité de données et d'applications sur site. Pour plus d'informations AWS Outposts, consultez le [https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html). ## Considérations Voici quelques considérations relatives à l’utilisation d’Amazon ECS sur AWS Outposts : + Amazon Elastic Container Registry et Network Load Balancer s'exécutent dans la AWS région, et non sur. Gestion des identités et des accès AWS AWS Outposts Cela a pour effet d'accroître les latences entre ces services et les conteneurs. + AWS Fargate n'est pas disponible sur AWS Outposts. Voici les considérations relatives à la connectivité réseau pour AWS Outposts : + Si la connectivité réseau entre votre AWS région AWS Outposts et sa région est perdue, vos clusters continueront à fonctionner. Toutefois, vous ne pouvez pas créer de nouveaux clusters ni effectuer de nouvelles actions sur les clusters existants tant que la connectivité n'a pas été rétablie. En cas de défaillance d'instance, l'instance ne sera pas automatiquement remplacée. L'agent CloudWatch Logs ne sera pas en mesure de mettre à jour les journaux et les données des événements. + Nous vous recommandons de fournir une connectivité fiable, à haute disponibilité et à faible latence entre votre AWS région AWS Outposts et la sienne. ## Conditions préalables Voici les prérequis à satisfaire pour utiliser Amazon ECS sur AWS Outposts : + Vous devez avoir installé et configuré un Outpost dans votre centre de données sur site. + Vous devez avoir une connexion réseau fiable entre votre Outpost et sa région AWS . ## Vue d'ensemble de la création de clusters sur AWS Outposts Voici un aperçu de la configuration : 1. Créez un rôle et une politique avec des droits activés AWS Outposts. 1. Créez un profil d'instance IAM avec des droits sur AWS Outposts. 1. Créez un VPC ou utilisez-en un existant situé dans la même région que celle de vôtre AWS Outposts. 1. Créez un sous-réseau ou utilisez un sous-réseau existant associé à l’ AWS Outposts. Il s’agit du sous-réseau sur lequel s’exécutent les instances de conteneur. 1. Créez un groupe de sécurité pour les instances de conteneur dans votre cluster. 1. Créez un nouveau cluster Amazon ECS. 1. Définissez les variables d’environnement de l’agent de conteneur Amazon ECS pour lancer l’instance dans le cluster. 1. Exécutez un conteneur. Pour obtenir des informations détaillées sur la façon d'intégrer Amazon ECS à Amazon ECS AWS Outposts, consultez [Étendre Amazon ECS sur deux AWS Outposts racks.](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks) L'exemple suivant crée un cluster Amazon ECS sur un AWS Outposts. 1. Créez un rôle et une politique avec des droits activés AWS Outposts. Le fichier `role-policy.json` est le document de politique qui contient l'effet et les actions des ressources. Pour plus d'informations sur le format de fichier, consultez le manuel [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)de référence de l'*API IAM* ``` aws iam create-role –-role-name ecsRole \ --assume-role-policy-document file://ecs-policy.json aws iam put-role-policy --role-name ecsRole --policy-name ecsRolePolicy \ --policy-document file://role-policy.json ``` 1. Créez un profil d'instance IAM avec des droits sur AWS Outposts. ``` aws iam create-instance-profile --instance-profile-name outpost aws iam add-role-to-instance-profile --instance-profile-name outpost \ --role-name ecsRole ``` 1. Créez un VPC. ``` aws ec2 create-vpc --cidr-block 10.0.0.0/16 ``` 1. Créez un sous-réseau associé à votre. AWS Outposts ``` aws ec2 create-subnet \ --cidr-block 10.0.3.0/24 \ --vpc-id vpc-xxxxxxxx \ --outpost-arn arn:aws:outposts:us-west-2:123456789012:outpost/op-xxxxxxxxxxxxxxxx \ --availability-zone-id usw2-az1 ``` 1. Créez un groupe de sécurité pour les instances de conteneur, en spécifiant la plage CIDR appropriée pour AWS Outposts. (Cette étape est différente pour AWS Outposts.) ``` aws ec2 create-security-group --group-name MyOutpostSG aws ec2 authorize-security-group-ingress --group-name MyOutpostSG --protocol tcp \ --port 22 --cidr 10.0.3.0/24 aws ec2 authorize-security-group-ingress --group-name MyOutpostSG --protocol tcp \ --port 80 --cidr 10.0.3.0/24 ``` 1. Créez le cluster. 1. Définissez les variables d'environnement de l'agent de conteneur Amazon ECS pour lancer l'instance dans le cluster créé à l'étape précédente et définissez les identifications que vous souhaitez ajouter afin d'identifier le cluster (par exemple `Outpost` pour indiquer que le cluster est destiné à un Outpost). ``` #! /bin/bash cat << ‘EOF’ >> /etc/ecs/ecs.config ECS_CLUSTER=MyCluster ECS_IMAGE_PULL_BEHAVIOR=prefer-cached ECS_CONTAINER_INSTANCE_TAGS={“environment”: ”Outpost”} EOF ``` **Note** Pour éviter les retards causés par l'extraction d'images de conteneur d'Amazon ECR dans la région, utilisez des caches d'images. Pour ce faire, chaque fois qu'une tâche est exécutée, configurez l'agent Amazon ECS pour qu'il utilise par défaut l'image mise en cache sur l'instance elle-même en définissant `ECS_IMAGE_PULL_BEHAVIOR` sur `prefer-cached`. 1. Créez l'instance de conteneur, en spécifiant le VPC et le sous-réseau de l' AWS Outposts sur lequel cette instance doit s'exécuter et un type d'instance disponible sur l' AWS Outposts. (Cette étape est différente pour AWS Outposts.) Le fichier `userdata.txt` contient les données des utilisateurs que l'instance peut utiliser pour effectuer des tâches de configuration automatisées courantes et même exécuter des scripts après le démarrage de l'instance. Pour plus d’informations sur le fichier pour les appels API, consultez la section [Exécuter des commandes sur votre instance Linux au démarrage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) dans le *Guide de l’utilisateur Amazon EC2*. ``` aws ec2 run-instances --count 1 --image-id ami-xxxxxxxx --instance-type c5.large \ --key-name aws-outpost-key –-subnet-id subnet-xxxxxxxxxxxxxxxxx \ --iam-instance-profile Name outpost --security-group-id sg-xxxxxx \ --associate-public-ip-address --user-data file://userdata.txt ``` **Note** Cette commande sert également à ajouter des instances supplémentaires au cluster. Tous les conteneurs déployés dans le cluster sont placés sur cet AWS Outposts. # Bonnes pratiques en matière d’images de conteneurs Amazon ECS Une image de conteneur est un ensemble d'instructions expliquant comment créer le conteneur. Une image de conteneur contient le code de votre application et toutes les dépendances dont le code d'application a besoin pour s'exécuter. Les dépendances des applications incluent les packages de code source sur lesquels repose le code de votre application, un environnement d'exécution de langage pour les langages interprétés et les packages binaires sur lesquels repose votre code lié dynamiquement. Suivez ces directives lors de la conception et de la création de vos images de conteneur : + Complétez vos images de conteneur en stockant toutes les dépendances de l'application sous forme de fichiers statiques à l'intérieur de l'image de conteneur. Si vous modifiez quelque chose dans l’image de conteneur, créez une autre image de conteneur avec les modifications. + Exécutez un seul processus de candidature dans un conteneur. La durée de vie du conteneur est aussi longue que le processus de l'application. Amazon ECS remplace les processus qui ont échoué et détermine où lancer le processus de remplacement. Une image complète rend le déploiement global plus résilient. + Faites en sorte que votre application gère le signal `SIGTERM`. Lorsque Amazon ECS arrête une tâche, il envoie d’abord un signal SIGTERM à la tâche pour informer l’application qu’elle doit se terminer et s’arrêter. Amazon ECS envoie ensuite un message `SIGKILL`. Lorsque les applications ignorent le signal `SIGTERM`, le service Amazon ECS doit attendre avant d’envoyer le signal `SIGKILL` pour mettre fin au processus. Vous devez déterminer le temps nécessaire à votre application pour terminer son travail et vous assurer que vos applications gèrent le signal `SIGTERM`. Le traitement des signaux de l’application doit empêcher celle-ci d’accepter de nouvelles tâches et terminer celles en cours, ou enregistrer les tâches inachevées dans un espace de stockage externe lorsque leur exécution prend trop de temps. + Configurez des applications conteneurisées pour écrire des journaux dans `stdout` et `stderr`. Le découplage de la gestion des journaux de votre code d’application vous offre la flexibilité nécessaire pour ajuster la gestion des journaux au niveau de l’infrastructure. La modification de votre système de journalisation en est un exemple. Au lieu de modifier vos services, de créer et de déployer une nouvelle image de conteneur, vous pouvez ajuster les paramètres. + Utilisez des balises pour gérer les versions des images de vos conteneurs. Les images de conteneurs sont stockées dans un registre de conteneurs. Chaque image d'un registre est identifiée par une balise. Une balise est appelée `latest`. Cette balise est dirigée vers la dernière version de l'image du conteneur de l'application, comme `HEAD` dans un référentiel git. Nous vous recommandons d'utiliser uniquement la balise `latest` à des fins de test. Il est recommandé de baliser les images des conteneurs avec une balise unique pour chaque compilation. Nous vous recommandons de baliser vos images en utilisant le git SHA pour la validation git qui a été utilisée pour créer l'image. Vous n'avez pas besoin de créer une image de conteneur pour chaque validation. Toutefois, nous vous recommandons de créer une nouvelle image de conteneur chaque fois que vous publiez une validation de code spécifique dans l'environnement de production. Nous vous recommandons également de baliser l'image avec une balise correspondant à la validation git du code contenu dans l'image. Si vous avez balisé l'image avec la validation git, vous pouvez trouver plus rapidement la version du code exécutée par l'image. Nous vous recommandons également d'activer les balises d'image immuables dans Amazon Elastic Container Registry. Avec ce paramètre, vous ne pouvez pas modifier l'image du conteneur vers laquelle pointe une balise. Au lieu de cela, Amazon ECR impose qu’une nouvelle image soit téléchargée vers une nouvelle balise. Pour plus d'informations, veuillez consulter [Mutabilité d'une étiquette d'image](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-tag-mutability.html) dans le *Guide de l'utilisateur Amazon ECR.* Lorsque vous concevez votre application pour qu'elle s'exécute AWS Fargate, vous devez choisir entre déployer plusieurs conteneurs dans la même définition de tâche ou déployer des conteneurs séparément dans plusieurs définitions de tâches. Si les conditions suivantes sont requises, nous vous recommandons de déployer plusieurs conteneurs dans une définition de tâche unique : + Vos conteneurs partagent le même cycle de vie (autrement dit, ils sont lancés et résiliés conjointement). + Vos conteneurs doivent être exécutés sur le même hôte sous-jacent (autrement dit, un conteneur référence l'autre sur un port localhost). + Vos conteneurs partagent des ressources. + Vos conteneurs partagent des volumes de données. Si ces conditions suivantes ne sont pas requises, nous vous recommandons de déployer des conteneurs distincts dans plusieurs définitions de tâche. Cela vous permet de mettre à l’échelle, d’allouer et de désallouer les conteneurs séparément. # Bonnes pratiques de mise en réseau d’Amazon ECS Les applications modernes sont généralement construites à partir de plusieurs composants distribués qui communiquent entre eux. Par exemple, une application mobile ou Web peut communiquer avec un point de terminaison d’API, et l’API peut être alimentée par plusieurs microservices qui communiquent via Internet. Pour plus d’informations sur les meilleures pratiques en matière de connexion des applications à Internet, consultez la section [Connexion d’applications Amazon ECS à Internet](networking-outbound.md). Pour plus d’informations sur les meilleures pratiques en matière de réception de connexions entrantes vers Amazon ECS depuis Internet, consultez la section [Pratiques exemplaires en matière de réception de connexions entrantes vers Amazon ECS depuis Internet](networking-inbound.md). Pour plus d'informations sur les meilleures pratiques pour connecter Amazon ECS à d'autres AWS services, consultez[Bonnes pratiques pour connecter Amazon ECS aux AWS services depuis votre VPC](networking-connecting-vpc.md). Pour plus d’informations sur les pratiques exemplaires en matière de connexion de services au sein d’un VPC, consultez la section [Pratiques exemplaires en matière de connexion des services Amazon ECS dans un VPC](networking-connecting-services.md). Pour plus d'informations sur les meilleures pratiques en matière de services réseau entre Comptes AWS et VPCs, consultez[Bonnes pratiques pour la mise en réseau des services Amazon ECS entre Comptes AWS et VPCs](networking-connecting-services-crossaccount.md). Pour plus d’informations sur les pratiques exemplaires en matière de services permettant de résoudre les problèmes de réseau, consultez la section [AWS services de résolution des problèmes de réseau Amazon ECS](networking-troubleshooting.md). # Connexion d’applications Amazon ECS à Internet La plupart des applications conteneurisées comportent au moins certains composants qui nécessitent un accès sortant à Internet. Par exemple, le dorsal d’une application mobile nécessite un accès sortant aux notifications push. Amazon Virtual Private Cloud propose deux méthodes principales pour faciliter la communication entre votre VPC et Internet. ## Sous-réseau public et passerelle Internet ![\[Schéma illustrant l’architecture d’un sous-réseau public connecté à une passerelle Internet.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/public-network.png) Lorsque vous utilisez un sous-réseau public comportant une route vers une passerelle Internet, votre application conteneurisée peut être exécutée sur un hôte au sein d’un VPC sur un sous-réseau public. Une adresse IP publique est attribuée à l’hôte qui exécute votre conteneur. Cette adresse IP publique est routable depuis Internet. Pour plus d’informations, consultez [Passerelles Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) dans le *Guide de l’utilisateur Amazon VPC*. Cette architecture réseau facilite la communication directe entre l’hôte qui exécute votre application et les autres hôtes sur Internet. La communication est bidirectionnelle. Cela signifie que non seulement vous pouvez établir une connexion sortante avec n’importe quel autre hôte sur Internet, mais que d’autres hôtes sur Internet peuvent également tenter de se connecter à votre hôte. Par conséquent, vous devez porter une attention particulière à votre groupe de sécurité et à vos règles de pare-feu. Ceci afin de garantir que d’autres hôtes sur Internet ne peuvent pas ouvrir de connexions que vous ne souhaitez pas voir ouvertes. Par exemple, si votre application s’exécute sur Amazon EC2, assurez-vous que le port 22 pour l’accès SSH n’est pas ouvert. Dans le cas contraire, votre instance pourrait recevoir des tentatives de connexion SSH constantes de la part de robots malveillants sur Internet. Ces robots parcourent les adresses IP publiques. Une fois qu’ils ont trouvé un port SSH ouvert, ils tentent de forcer les mots de passe pour essayer d’accéder à votre instance. De ce fait, de nombreuses entreprises limitent l’utilisation des sous-réseaux publics et préfèrent que la plupart, sinon la totalité, de leurs ressources se trouvent dans des sous-réseaux privés. L’utilisation de sous-réseaux publics pour la mise en réseau convient aux applications publiques qui nécessitent une bande passante importante ou une latence minimale. Les cas d’utilisation applicables comprennent les services de streaming vidéo et de jeux vidéo. Cette approche réseau est prise en charge à la fois lorsque vous utilisez Amazon ECS sur Amazon EC2 et lorsque vous l’utilisez sur AWS Fargate. + Amazon EC2 : vous pouvez lancer des instances EC2 sur un sous-réseau public. Amazon ECS utilise ces instances EC2 comme capacité de cluster, et tous les conteneurs exécutés sur les instances peuvent utiliser l’adresse IP publique sous-jacente de l’hôte pour le réseau sortant. Cela s’applique à la fois aux modes réseau `host` et `bridge`. Cependant, le mode `awsvpc` réseau ne fournit pas d'adresses IP publiques ENIs à la tâche. Par conséquent, l’utilisation d’une passerelle Internet n’est pas possible. + Fargate : lorsque vous créez votre service Amazon ECS, spécifiez des sous-réseaux publics pour la configuration réseau de votre service et utilisez l’option **Attribuer une adresse IP publique**. Chaque tâche Fargate est mise en réseau dans le sous-réseau public et possède sa propre adresse IP publique pour une communication directe avec Internet. ## Sous-réseau privé et passerelle NAT ![\[Schéma illustrant l’architecture d’un sous-réseau privé connecté à une passerelle NAT.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/private-network.png) Lorsque vous utilisez un sous-réseau privé et une passerelle NAT, vous pouvez exécuter votre application conteneurisée sur un hôte situé dans un sous-réseau privé. Ainsi, cet hôte possède une adresse IP privée qui est routable au sein de votre VPC, mais qui n’est pas routable depuis Internet. Cela signifie que les autres hôtes du VPC peuvent se connecter à l’hôte à l’aide de son adresse IP privée, mais que les autres hôtes sur Internet ne peuvent pas établir de communications entrantes avec l’hôte. Avec un sous-réseau privé, vous pouvez utiliser une passerelle de traduction d’adresses réseau (NAT) pour autoriser un hôte d’un sous-réseau privé à se connecter à Internet. Les hôtes sur Internet reçoivent une connexion entrante qui semble provenir de l’adresse IP publique de la passerelle NAT située dans un sous-réseau public. La passerelle NAT est chargée de servir de pont entre Internet et le sous-réseau privé. Cette configuration est souvent préférée pour des raisons de sécurité, car elle signifie que votre VPC est protégé contre tout accès direct par des attaquants sur Internet. Pour plus d’informations, veuillez consulter [NAT Gateways (Passerelles NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) dans le *Guide de l’utilisateur Amazon VPC*. Cette approche de réseau privé convient aux scénarios dans lesquels vous souhaitez protéger vos conteneurs d’un accès externe direct. Les scénarios applicables incluent les systèmes de traitement des paiements ou les conteneurs stockant les données utilisateur et les mots de passe. La création et l'utilisation d'une passerelle NAT vous sont facturées dans votre compte. Les tarifs horaires d’utilisation de la passerelle NAT et de traitement des données s’appliquent également. Pour des raisons de redondance, vous devez disposer d’une passerelle NAT dans chaque zone de disponibilité. Ainsi, la perte de disponibilité d’une seule zone de disponibilité ne compromet pas votre connectivité sortante. De ce fait, si votre charge de travail est faible, il peut être plus rentable d’utiliser des sous-réseaux privés et des passerelles NAT. Cette approche réseau est prise en charge à la fois lors de l’utilisation d’Amazon ECS sur Amazon EC2 et lors de son utilisation sur AWS Fargate. + Amazon EC2 : vous pouvez lancer des instances EC2 sur un sous-réseau privé. Les conteneurs qui s’exécutent sur ces hôtes EC2 utilisent le réseau des hôtes sous-jacents, et les requêtes sortantes passent par la passerelle NAT. + Fargate : lorsque vous créez votre service Amazon ECS, spécifiez des sous-réseaux privés pour la configuration réseau de votre service et n’utilisez pas l’option **Attribuer une adresse IP publique**. Chaque tâche Fargate est hébergée dans un sous-réseau privé. Son trafic sortant est acheminé via n’importe quelle passerelle NAT que vous avez associée à ce sous-réseau privé. # Pratiques exemplaires en matière de réception de connexions entrantes vers Amazon ECS depuis Internet Si vous gérez un service public, vous devez accepter le trafic entrant en provenance d’Internet. Par exemple, votre site Web public doit accepter les requêtes HTTP entrantes provenant des navigateurs. Dans ce cas, les autres hôtes sur Internet doivent également établir une connexion entrante avec l’hôte de votre application. Une solution à ce problème consiste à lancer vos conteneurs sur des hôtes situés dans un sous-réseau public doté d’une adresse IP publique. Cependant, nous ne recommandons pas cette solution pour les applications de grande envergure. Pour ces derniers, une meilleure approche consiste à disposer d’une couche d’entrée évolutive située entre Internet et votre application. Pour cette approche, vous pouvez utiliser n’importe lequel des services AWS répertoriés dans cette section comme entrée. ## Application Load Balancer Un Application Load Balancer fonctionne au niveau de la couche application. Il s’agit de la septième couche du modèle OSI (Open Systems Interconnection). Cela rend un Application Load Balancer adapté aux services HTTP publics. Si vous avez un site Web ou une API REST HTTP, un Application Load Balancer est un équilibreur de charge adapté à cette charge de travail. Pour plus d’informations, consultez la section [Qu’est-ce qu’un Application Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) dans le *Guide de l’utilisateur des Application Load Balancer*. ![\[Schéma illustrant l’architecture d’un réseau utilisant un Application Load Balancer.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/alb-ingress.png) Avec cette architecture, vous créez un Application Load Balancer dans un sous-réseau public afin qu’il dispose d’une adresse IP publique et puisse recevoir des connexions entrantes depuis Internet. Lorsque l’Application Load Balancer reçoit une connexion entrante, ou plus précisément une requête HTTP, il ouvre une connexion à l’application à l’aide de son adresse IP privée. Ensuite, il transmet la requête via la connexion interne. Un Application Load Balancer présente les avantages suivants : + Résiliation SSL/TLS : un Application Load Balancer peut garantir une communication HTTPS sécurisée et des certificats pour les communications avec les clients. Il peut éventuellement mettre fin à la connexion SSL au niveau de l’équilibreur de charge afin que vous n’ayez pas à gérer les certificats dans votre propre application. + Routage avancé : un Application Load Balancer peut avoir plusieurs noms d’hôte DNS. Il dispose également de fonctionnalités de routage avancées pour envoyer des requêtes HTTP entrantes vers différentes destinations en fonction de métriques telles que le nom d’hôte ou le chemin de la requête. Cela signifie que vous pouvez utiliser une seule Application Load Balancer comme entrée pour de nombreux services internes différents, voire des microservices sur différents chemins d’une API REST. + Support du gRPC et Websockets : un Application Load Balancer peut gérer bien plus que du HTTP. Il peut également équilibrer la charge des services basés sur le gRPC et le Websocket, avec le support HTTP/2. + Sécurité : un Application Load Balancer permet de protéger votre application contre le trafic malveillant. Il inclut des fonctionnalités telles que l'atténuation de la synchronisation HTTP et est intégré au AWS Web Application Firewall (AWS WAF). AWS WAF peut filtrer davantage le trafic malveillant susceptible de contenir des modèles d'attaque, tels que l'injection SQL ou les scripts intersites. ## Network Load Balancer Un Network Load Balancer fonctionne à la quatrième couche du modèle Open Systems Interconnection (OSI). Il convient aux protocoles non HTTP ou aux scénarios dans lesquels le end-to-end chiffrement est nécessaire, mais il ne possède pas les mêmes fonctionnalités spécifiques au protocole HTTP qu'un Application Load Balancer. Par conséquent, un Network Load Balancer convient parfaitement aux applications qui n’utilisent pas le protocole HTTP. Pour plus d’informations, consultez la section [Qu’est-ce qu’un Network Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) dans le *Guide de l’utilisateur des Network Load Balancer*. ![\[Schéma illustrant l’architecture d’un réseau utilisant un Network Load Balancer.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/nlbingress.png) Lorsqu’un Network Load Balancer est utilisé comme entrée, il fonctionne de la même manière qu’un Application Load Balancer. Cela est dû au fait qu’il est créé dans un sous-réseau public et possède une adresse IP publique accessible sur Internet. Le Network Load Balancer ouvre ensuite une connexion à l’adresse IP privée de l’hôte qui exécute votre conteneur et envoie les paquets du côté public au côté privé. **Fonctionnalités du Network Load Balancer** Étant donné que le Network Load Balancer fonctionne à un niveau inférieur de la pile réseau, il ne possède pas le même ensemble de fonctionnalités que l’Application Load Balancer. Cependant, il présente les caractéristiques importantes suivantes. + End-to-end chiffrement : étant donné qu'un Network Load Balancer fonctionne au niveau de la quatrième couche du modèle OSI, il ne lit pas le contenu des paquets. Cela le rend adapté à l'équilibrage de charge des communications nécessitant un end-to-end chiffrement. + Chiffrement TLS — Outre le end-to-end chiffrement, Network Load Balancer peut également mettre fin aux connexions TLS. Ainsi, vos applications dorsales n’ont pas à implémenter leur propre protocole TLS. + Support UDP : étant donné qu’un Network Load Balancer fonctionne au niveau de la quatrième couche du modèle OSI, il convient aux charges de travail non-HTTP et aux protocoles autres que le protocole TCP. **Fermeture des connexions** Comme le Network Load Balancer ne respecte pas le protocole d’application dans les couches supérieures du modèle OSI, il ne peut pas envoyer de messages de fermeture aux clients utilisant ces protocoles. Contrairement à l’Application Load Balancer, ces connexions doivent être fermées par l’application ou vous pouvez configurer le Network Load Balancer pour fermer les connexions de quatrième couche lorsqu’une tâche est arrêtée ou remplacée. Consultez les paramètres de résiliation de connexion pour les groupes cibles Network Load Balancer dans la [Documentation Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay). Laisser le Network Load Balancer fermer les connexions au niveau de la quatrième couche peut entraîner l’affichage de messages d’erreur indésirables pour les clients, si ceux-ci ne les gèrent pas. Pour plus d'infirmations sur la configuration client recommandée, consultez la bibliothèque Builders [ici](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter). Les méthodes de fermeture des connexions varient selon les applications, mais l’une d’entre elles consiste à s’assurer que le délai d’annulation de l’enregistrement de la cible du Network Load Balancer est plus long que le délai d’expiration de la connexion client. Le client devait d’abord expirer le délai imparti et se reconnecter progressivement à la tâche suivante via le Network Load Balancer, tandis que l’ancienne tâche épuisait lentement tous ses clients. Pour plus d’informations sur le délai d’annulation de l’enregistrement de la cible du Network Load Balancer, consultez la [Documentation du Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay). ## API HTTP Amazon API Gateway Amazon API Gateway convient aux applications HTTP présentant des pics soudains de volumes de requêtes ou de faibles volumes de requêtes. Pour plus d’informations, consultez la section *Qu’est-ce qu’Amazon API Gateway ?* dans le [Guide du développeur API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html). ![\[Schéma illustrant l’architecture d’un réseau à l’aide d’API Gateway.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/apigateway-ingress.png) Le modèle de tarification pour Application Load Balancer et Network Load Balancer inclut un tarif horaire afin de maintenir les équilibreurs de charge disponibles pour accepter les connexions entrantes à tout moment. En revanche, API Gateway facture chaque requête séparément. Cela signifie que si aucune demande n’est reçue, il n’y a pas de frais. En cas de forte charge de trafic, un Application Load Balancer ou un Network Load Balancer peut traiter un plus grand volume de requêtes à un prix par requête inférieur à celui d’API Gateway. Cependant, si vous avez globalement peu de requêtes ou si vous connaissez des périodes de faible trafic, le prix cumulé pour l’utilisation de l’API Gateway devrait être plus rentable que de payer un tarif horaire pour maintenir un équilibreur de charge sous-utilisé. L’API Gateway peut également mettre en cache les réponses de l’API, ce qui peut entraîner une baisse des taux de requêtes du dorsal. Les fonctions API Gateway utilisent un lien VPC qui permet au service AWS géré de se connecter aux hôtes du sous-réseau privé de votre VPC à l'aide de son adresse IP privée. Il peut détecter ces adresses IP privées en consultant les enregistrements de découverte de AWS Cloud Map services gérés par Amazon ECS Service Discovery. API Gateway prend en charge les fonctionnalités ci-dessous. + Le fonctionnement d’API Gateway est similaire à un équilibreur de charge, mais possède des fonctionnalités supplémentaires propres à la gestion des API + L'API Gateway fournit des fonctionnalités supplémentaires concernant l'autorisation des clients, les niveaux d'utilisation et les request/response modifications. Pour de plus amples informations, consultez la section [Fonctionnalité d’Amazon API Gateway](https://aws.amazon.com//api-gateway/features/). + L’API Gateway peut prendre en charge les points de terminaison de passerelle d’API périphériques, régionaux et privés. Les points de terminaison Edge sont disponibles via une CloudFront distribution gérée. Les points de terminaison régionaux et privés sont tous deux locaux à une région. + Résiliation SSL/TLS + Routage de différents chemins HTTP vers différents microservices dorsaux Outre les fonctionnalités précédentes, API Gateway prend également en charge l’utilisation d’autorisateurs Lambda personnalisés que vous pouvez utiliser pour protéger votre API contre toute utilisation non autorisée. Pour plus d'informations, consultez [Field Notes : basé sur un conteneur sans serveur avec APIs Amazon ECS et Amazon API Gateway](https://aws.amazon.com/blogs/architecture/field-notes-serverless-container-based-apis-with-amazon-ecs-and-amazon-api-gateway/). # Bonnes pratiques pour connecter Amazon ECS aux AWS services depuis votre VPC Pour qu’Amazon ECS fonctionne correctement, l’agent de conteneur Amazon ECS exécuté sur chaque hôte doit communiquer avec le plan de contrôle Amazon ECS. Si vous stockez vos images de conteneur dans Amazon ECR, les hôtes Amazon EC2 doivent communiquer avec le point de terminaison du service Amazon ECR et avec Amazon S3, où les couches d’images sont stockées. Si vous utilisez d'autres AWS services pour votre application conteneurisée, tels que les données persistantes stockées dans DynamoDB, vérifiez que ces services disposent également de la prise en charge réseau nécessaire. ## Passerelle NAT L'utilisation d'une passerelle NAT est le moyen le plus simple de garantir que vos tâches Amazon ECS peuvent accéder à d'autres AWS services. Pour plus d’informations sur cette approche, consultez la section [Sous-réseau privé et passerelle NAT](networking-outbound.md#networking-private-subnet). ![\[Schéma illustrant l’architecture d’un réseau utilisant une passerelle NAT.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/natgateway.png) L’utilisation de cette approche présente les inconvénients suivants : + Vous ne pouvez pas limiter les destinations avec lesquelles la passerelle NAT peut communiquer. Vous ne pouvez pas non plus limiter les destinations vers lesquelles votre niveau dorsal peut communiquer sans interrompre toutes les communications sortantes de votre VPC. + Les passerelles NAT facturent chaque Go de données qui transite par elle. Si vous utilisez la passerelle NAT pour l’une des opérations suivantes, chaque Go de bande passante vous est facturé : + Téléchargement de fichiers volumineux à partir d’Amazon S3 + Exécution d’un volume élevé de requêtes de base de données vers DynamoDB + Extraction d’une image d’Amazon ECR De plus, les passerelles NAT prennent en charge une bande passante de 5 Gbit/s et s’adaptent automatiquement jusqu’à 45 Gbit/s. Si vous effectuez un routage via une seule passerelle NAT, les applications qui nécessitent des connexions à très haut débit peuvent se heurter à des contraintes réseau. Pour contourner le problème, vous pouvez répartir votre charge de travail sur plusieurs sous-réseaux et attribuer à chaque sous-réseau sa propre passerelle NAT. ## AWS PrivateLink AWS PrivateLink fournit une connectivité privée entre VPCs les AWS services et vos réseaux locaux sans exposer votre trafic à l'Internet public. Un point de terminaison de VPC permet des connexions privées entre votre VPC et les services AWS pris en charge, ainsi que les services de point de terminaison de VPC. Le trafic entre votre VPC et les autres services ne quitte pas le réseau Amazon. Un point de terminaison VPC ne nécessite pas de passerelle Internet, de passerelle privée virtuelle, de périphérique NAT, de connexion VPN ou Direct Connect de connexion. Les instances Amazon EC2 dans votre VPC ne nécessitent pas d’adresses IP publiques pour communiquer avec les ressources du service. Le schéma suivant montre comment fonctionne la communication avec les AWS services lorsque vous utilisez des points de terminaison VPC au lieu d'une passerelle Internet. AWS PrivateLink fournit des interfaces réseau élastiques (ENIs) à l'intérieur du sous-réseau, et les règles de routage VPC sont utilisées pour envoyer toute communication au nom d'hôte du service via l'ENI, directement au service de destination. AWS Ce trafic n’a plus besoin d’utiliser la passerelle NAT ou la passerelle Internet. ![\[Schéma illustrant l'architecture d'un réseau utilisant AWS PrivateLink\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/endpointaccess-multiple.png) Voici quelques-uns des points de terminaison de VPC courants utilisés avec le service Amazon ECS. + [Points de terminaison de passerelle pour Amazon S3](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html) + [Point de terminaison de VPC DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html) + [Point de terminaison Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) + [Point de terminaison Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) De nombreux autres AWS services prennent en charge les points de terminaison VPC. Si vous utilisez intensivement un service AWS , vous devez consulter la documentation spécifique à ce service et savoir comment créer un point de terminaison de VPC pour ce trafic. # Pratiques exemplaires en matière de connexion des services Amazon ECS dans un VPC À l’aide des tâches Amazon ECS dans un VPC, vous pouvez diviser les applications monolithiques en parties distinctes qui peuvent être déployées et mises à l’échelle indépendamment dans un environnement sécurisé. Cette architecture est appelée architecture orientée services (SOA) ou microservices. Cependant, il peut être difficile de s’assurer que toutes ces parties, à la fois à l’intérieur et à l’extérieur d’un VPC, peuvent communiquer entre elles. Il existe plusieurs approches pour faciliter la communication, qui présentent toutes des avantages et des inconvénients différents. ## Utilisation de Service Connect Nous recommandons Service Connect, qui fournit une configuration Amazon ECS pour la découverte de service, la connectivité et la surveillance du trafic. Avec Service Connect, vos applications peuvent utiliser des noms abrégés et des ports standard pour se connecter aux services du même cluster ou d'autres clusters, y compris VPCs au sein de la même région. Pour plus d’informations, consultez la section [Amazon ECS Service Connect](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html). Lorsque vous utilisez Service Connect, Amazon ECS gère toutes les étapes de la découverte de services : création des noms susceptibles d’être découverts, gestion dynamique des entrées pour chaque tâche au démarrage et à l’arrêt des tâches, exécution d’un agent dans chaque tâche configuré pour découvrir les noms. Votre application peut rechercher les noms en utilisant les fonctionnalités standard pour les noms DNS et en établissant des connexions. Si votre application le fait déjà, vous n’avez pas besoin de modifier votre application pour utiliser Service Connect. ![\[Schéma illustrant l’architecture d’un réseau utilisant Service Connect.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/serviceconnect.png) **Les modifications ne se produisent que lors des déploiements** Vous fournissez la configuration complète dans chaque définition de service et de tâche. Amazon ECS gère les modifications apportées à cette configuration lors de chaque déploiement de service, afin de garantir que toutes les tâches d’un déploiement se comportent de la même manière. Par exemple, un problème courant avec le DNS en tant que découverte de service est le contrôle d’une migration. Si vous modifiez un nom DNS pour qu’il pointe vers les nouvelles adresses IP de remplacement, le délai TTL maximal peut être nécessaire avant que tous les clients commencent à utiliser le nouveau service. Avec Service Connect, le déploiement du client met à jour la configuration en remplaçant les tâches du client. Vous pouvez configurer le disjoncteur de déploiement et toute autre configuration de déploiement pour affecter les modifications de Service Connect de la même manière que pour tout autre déploiement. ## Utilisation de la découverte de service Une autre approche de service-to-service communication est la communication directe utilisant la découverte de services. Dans cette approche, vous pouvez utiliser l'intégration de la découverte de AWS Cloud Map services avec Amazon ECS. À l'aide de la découverte de services, Amazon ECS synchronise la liste des tâches lancées avec AWS Cloud Map, qui conserve un nom d'hôte DNS qui correspond aux adresses IP internes d'une ou de plusieurs tâches provenant de ce service en particulier. D’autres services au sein d’Amazon VPC peuvent utiliser ce nom d’hôte DNS pour envoyer le trafic directement vers un autre conteneur en utilisant son adresse IP interne. Pour de plus amples informations, consultez [Découverte de service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html). ![\[Schéma illustrant l’architecture d’un réseau utilisant la découverte de service.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/servicediscovery.png) Dans le schéma précédent, il existe trois services. `service-a-local` possède un conteneur et communique avec `service-b-local`, qui possède deux conteneurs. `service-b-local` doit également communiquer avec `service-c-local`, qui possède un conteneur. Chaque conteneur de ces trois services peut utiliser les noms DNS internes de AWS Cloud Map pour rechercher les adresses IP internes d'un conteneur auprès du service en aval avec lequel il doit communiquer. Cette approche de service-to-service communication permet une faible latence. À première vue, c’est également simple, car il n’y a aucun composant supplémentaire entre les conteneurs. Le trafic passe directement d’un conteneur à l’autre. Cette approche convient lorsque vous utilisez le mode réseau `awsvpc`, où chaque tâche possède sa propre adresse IP unique. La plupart des logiciels ne prennent en charge que l’utilisation d’enregistrements DNS `A`, qui se résolvent directement en adresses IP. Lorsque vous utilisez le mode réseau `awsvpc`, l’adresse IP de chaque tâche est un enregistrement `A`. Toutefois, si vous utilisez le mode réseau `bridge`, plusieurs conteneurs peuvent partager la même adresse IP. En outre, les mappages de ports dynamiques entraînent l’attribution aléatoire de numéros de port aux conteneurs sur cette adresse IP unique. À ce stade, un enregistrement `A` ne suffit plus pour la découverte de services. Vous devez également utiliser un enregistrement `SRV`. Ce type d’enregistrement permet de suivre à la fois les adresses IP et les numéros de port, mais nécessite que vous configuriez les applications de manière appropriée. Certaines applications prédéfinies que vous utilisez peuvent ne pas prendre en charge les enregistrements `SRV`. Un autre avantage du mode réseau `awsvpc` est que vous disposez d’un groupe de sécurité unique pour chaque service. Vous pouvez configurer ce groupe de sécurité pour autoriser les connexions entrantes provenant uniquement des services en amont spécifiques qui doivent communiquer avec ce service. Le principal inconvénient de la service-to-service communication directe utilisant la découverte de services est que vous devez implémenter une logique supplémentaire pour effectuer de nouvelles tentatives et faire face aux échecs de connexion. Les enregistrements DNS ont une période time-to-live (TTL) qui contrôle la durée pendant laquelle ils sont mis en cache. Il faut un certain temps pour que l’enregistrement DNS soit mis à jour et que le cache expire afin que vos applications puissent récupérer la dernière version de l’enregistrement DNS. Il se peut donc que votre application finisse par résoudre l’enregistrement DNS pour qu’il pointe vers un autre conteneur qui n’existe plus. Votre application doit gérer les nouvelles tentatives et avoir une logique lui permettant d’ignorer les mauvais dorsaux. ## Utilisation d’un équilibreur de charge interne Une autre approche de service-to-service communication consiste à utiliser un équilibreur de charge interne. Un équilibreur de charge interne existe entièrement à l’intérieur de votre VPC et n’est accessible qu’aux services situés à l’intérieur de votre VPC. ![\[Schéma illustrant l’architecture d’un réseau utilisant un équilibreur de charge interne.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/loadbalancer-internal.png) L’équilibreur de charge maintient une haute disponibilité en déployant des ressources redondantes dans chaque sous-réseau. Lorsqu’un conteneur du `serviceA` doit communiquer avec un conteneur du `serviceB`, il ouvre une connexion avec l’équilibreur de charge. L’équilibreur de charge ouvre ensuite une connexion vers un conteneur du `service B`. L’équilibreur de charge sert de lieu centralisé pour gérer toutes les connexions entre chaque service. Si un conteneur du `serviceB` s’arrête, l’équilibreur de charge peut le retirer du groupe. L’équilibreur de charge effectue également des surveillances de l’état par rapport à chaque cible en aval de son pool et peut automatiquement supprimer les mauvaises cibles du groupe jusqu’à ce qu’elles redeviennent saines. Les applications n’ont plus besoin de connaître le nombre de conteneurs en aval. Ils ouvrent simplement leurs connexions à l’équilibreur de charge. Cette approche est avantageuse pour tous les modes de réseau. L’équilibreur de charge peut suivre les adresses IP des tâches en mode réseau `awsvpc`, ainsi que les combinaisons plus avancées d’adresses IP et de ports en mode réseau `bridge`. Il répartit le trafic de manière uniforme entre toutes les combinaisons d’adresses IP et de ports, même si plusieurs conteneurs sont hébergés sur la même instance Amazon EC2, mais uniquement sur des ports différents. Le seul inconvénient de cette approche est son coût. Pour être hautement disponible, l’équilibreur de charge doit disposer de ressources dans chaque zone de disponibilité. Cela entraîne des coûts supplémentaires en raison des frais généraux liés au paiement de l’équilibreur de charge et à la quantité de trafic qui passe par l’équilibreur de charge. Cependant, vous pouvez réduire les frais généraux en faisant en sorte que plusieurs services partagent un équilibreur de charge. Cela convient particulièrement aux services REST qui utilisent un Application Load Balancer. Vous pouvez créer des règles de routage basées sur les chemins qui acheminent le trafic vers différents services. Par exemple, `/api/user/*` peut être acheminé vers un conteneur faisant partie du service `user`, alors que `/api/order/*` peut être acheminé vers le service `order` associé. Avec cette approche, vous ne payez que pour un Application Load Balancer et vous disposez d’une URL cohérente pour votre API. Cependant, vous pouvez répartir le trafic entre différents microservices sur le dorsal. # Bonnes pratiques pour la mise en réseau des services Amazon ECS entre Comptes AWS et VPCs Si vous faites partie d'une organisation composée de plusieurs équipes et divisions, vous déployez probablement des services de manière indépendante VPCs dans un environnement partagé Compte AWS ou dans VPCs des services associés à plusieurs personnes Comptes AWS. Quelle que soit la manière dont vous déployez vos services, nous vous recommandons de compléter vos composants réseau pour faciliter l'acheminement du trafic entre eux VPCs. Pour cela, plusieurs AWS services peuvent être utilisés pour compléter vos composants réseau existants. + AWS Transit Gateway — Vous devez d'abord envisager ce service réseau. Ce service sert de hub central pour le routage de vos connexions entre Amazon VPCs et Comptes AWS les réseaux locaux. Pour plus d’informations, consultez la section [Qu’est-ce qu’une passerelle de transit ?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) dans le *Guide des passerelles de transit Amazon VPC*. + Support Amazon VPC et VPN : vous pouvez utiliser ce service pour créer des connexions site-to-site VPN afin de connecter des réseaux locaux à votre VPC. Pour plus d'informations, voir [Qu'est-ce que c'est AWS Site-to-Site VPN ?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) dans le *guide de AWS Site-to-Site VPN l'utilisateur*. + Amazon VPC — Vous pouvez utiliser le peering Amazon VPC pour vous aider à en connecter plusieurs VPCs, que ce soit dans le même compte ou entre plusieurs comptes. Pour plus d’informations, consultez [Qu’est-ce que l’appairage de VPC ?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) dans le *Guide d’appairage de VPC Amazon*. + Partagé VPCs  : vous pouvez utiliser un VPC et des sous-réseaux VPC sur plusieurs comptes. AWS Pour plus d'informations, consultez la section [Travailler avec le partage VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) dans le guide de l'*utilisateur Amazon VPC*. # AWS services de résolution des problèmes de réseau Amazon ECS Les services et fonctionnalités suivants peuvent vous aider à mieux comprendre les configurations de votre réseau et de vos services. Vous pouvez utiliser ces informations pour résoudre les problèmes de mise en réseau et optimiser vos services. ## CloudWatch Informations sur les conteneurs CloudWatch Container Insights collecte, agrège et résume les métriques et les journaux de vos applications conteneurisées et de vos microservices. Les métriques incluent l’utilisation des ressources telles que l’UC, la mémoire, le disque et le réseau. Ils sont disponibles dans des tableaux de bord CloudWatch automatiques. Pour plus d'informations, consultez la section [Configuration de Container Insights sur Amazon ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS.html) dans le *guide de CloudWatch l'utilisateur Amazon*. ## AWS X-Ray AWS X-Ray est un service de suivi que vous pouvez utiliser pour collecter des informations sur les requêtes réseau effectuées par votre application. Vous pouvez utiliser le SDK pour instrumenter votre application et capturer les délais et les codes de réponse du trafic entre vos services, et entre vos services et les points de terminaison des services. AWS Pour plus d'informations, veuillez consulter la rubrique [Présentation de AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) dans le *Guide du développeur AWS X-Ray *. Vous pouvez également explorer AWS X-Ray des graphiques illustrant la manière dont vos services sont en réseau les uns avec les autres. Vous pouvez également les utiliser pour explorer des statistiques agrégées sur les performances de chaque service-to-service lien. Enfin, vous pouvez approfondir une transaction spécifique pour voir comment les segments représentant des appels réseau sont associés à cette transaction en particulier. Vous pouvez utiliser ces fonctionnalités pour identifier s’il existe un goulot d’étranglement réseau ou si un service spécifique de votre réseau ne fonctionne pas comme prévu. ## Journaux de flux VPC Vous pouvez utiliser les journaux de flux Amazon VPC pour analyser les performances du réseau et résoudre les problèmes de connectivité. Lorsque les journaux de flux VPC sont activés, vous pouvez capturer un journal de toutes les connexions de votre VPC. Il s'agit notamment des connexions aux interfaces réseau associées à Elastic Load Balancing, Amazon RDS, aux passerelles NAT et à d'autres AWS services clés que vous pourriez utiliser. Pour plus d’informations, consultez [Journaux de flux VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) dans le *Guide de l’utilisateur Amazon VPC*. ## Conseils d’optimisation du réseau Il existe quelques paramètres que vous pouvez affiner afin d’optimiser votre réseau. ### nofile ulimit Si vous vous attendez à ce que votre application génère un trafic élevé et gère de nombreuses connexions simultanées, vous devez tenir compte du quota système pour le nombre de fichiers autorisés. Lorsqu’un grand nombre de sockets réseau sont ouverts, chacun doit être représenté par un descripteur de fichier. Si votre quota de descripteurs de fichiers est trop faible, cela limitera vos sockets réseau. Cela entraîne des échecs de connexion ou des erreurs. Vous pouvez mettre à jour le quota spécifique au conteneur pour le nombre de fichiers dans la définition de tâche Amazon ECS. Si vous utilisez Amazon EC2 (au lieu de AWS Fargate), vous devrez peut-être également ajuster ces quotas sur votre instance Amazon EC2 sous-jacente. ### sysctl net Une autre catégorie de paramètres réglables est celle des paramètres réseau `sysctl`. Vous devez vous référer aux paramètres spécifiques de la distribution Linux de votre choix. La plupart de ces paramètres ajustent la taille des tampons de lecture et d’écriture. Cela peut être utile dans certaines situations lors de l’exécution d’instances Amazon EC2 à grande échelle contenant de nombreux conteneurs. # Optimisation de l’heure de lancement des tâches Amazon ECS Afin d’accélérer le lancement de vos tâches, tenez compte des recommandations suivantes. + **Mettre en cache les images de conteneurs et les instances binpack** Si vous utilisez EC2, vous pouvez configurer le comportement d’extraction de l’agent de conteneur Amazon ECS pour `ECS_IMAGE_PULL_BEHAVIOR` : `prefer-cached`. L’image est extraite à distance s’il n’y a pas d’image mise en cache. Dans le cas contraire, l'image mise en cache sur l'instance est utilisée. Le nettoyage d’image automatique est désactivé pour le conteneur afin de garantir que l’image mise en cache ne soit pas supprimée. Cela réduit le temps d’extraction des images pour les lancements ultérieurs. L’effet de la mise en cache est encore plus important lorsque vous avez une densité de tâches élevée dans vos instances de conteneur, que vous pouvez configurer à l’aide de la stratégie de placement `binpack`. La mise en cache des images de conteneur est particulièrement avantageuse pour les charges de travail basées sur Windows qui comportent généralement des images de conteneur de grande taille (des dizaines GBs). Lorsque vous utilisez la stratégie de placement `binpack`, vous pouvez également envisager d’utiliser la jonction Elastic Network Interface (ENI) pour placer davantage de tâches en mode réseau `awsvpc` sur chaque instance de conteneur. La jonction ENI augmente le nombre de tâches que vous pouvez exécuter en mode `awsvpc`. Par exemple, une instance c5.large qui peut prendre en charge l’exécution simultanée de seulement 2 tâches peut exécuter jusqu’à 10 tâches avec la jonction ENI. + **Choix d’un mode réseau optimal** Bien que le mode `awsvpc` réseau soit idéal dans de nombreux cas, ce mode réseau peut intrinsèquement augmenter la latence de lancement des tâches, car pour chaque tâche en `awsvpc` mode, les flux de travail Amazon ECS doivent fournir et associer un ENI en invoquant Amazon APIs EC2, ce qui ajoute un surcoût de plusieurs secondes au lancement de vos tâches. En revanche, l’un des principaux avantages de l’utilisation du mode réseau `awsvpc` est que chaque tâche possède un groupe de sécurité qui autorise ou refuse le trafic. Cela signifie que vous disposez d’une plus grande flexibilité pour contrôler les communications entre les tâches et les services à un niveau plus détaillé. Si la vitesse de déploiement est votre priorité, vous pouvez envisager d’utiliser le mode `bridge` pour accélérer le lancement des tâches. Pour de plus amples informations, veuillez consulter [Allocation d’une interface réseau à une tâche Amazon ECS](task-networking-awsvpc.md). + **Suivez le cycle de vie de lancement de vos tâches pour identifier les opportunités d’optimisation** Il est souvent difficile de savoir combien de temps prend le démarrage de votre application. Le lancement de votre image de conteneur, l’exécution de scripts de démarrage et d’autres configurations lors du démarrage de l’application peuvent prendre un temps surprenant. Vous pouvez utiliser le point de terminaison des métadonnées de tâche pour publier des métriques afin de suivre le temps de démarrage de l’application à partir de `StartedAt` dans la réponse des métadonnées du conteneur jusqu’à l’heure `StartedAt` de votre tâche ou service. Grâce à ces données, vous pouvez comprendre comment votre application contribue au temps de lancement total et identifier les domaines dans lesquels vous pouvez réduire les frais inutiles spécifiques à l’application et optimiser les images de vos conteneurs. Pour de plus amples informations, veuillez consulter [Pratiques exemplaires en matière d’autoscaling et de gestion des capacités Amazon ECS](capacity-availability.md). + **Choix d’un type d’instance optimal (pour EC2)** Le choix du type d’instance approprié dépend de la réserve de ressources (par exemple, UC, mémoire) que vous configurez pour votre tâche. Par conséquent, lors du dimensionnement de l’instance, vous pouvez calculer le nombre de tâches pouvant être placées sur une seule instance. Un exemple simple de tâche bien placée est l’hébergement de 4 tâches nécessitant 0,5 vCPU et 2 Go de réserves de mémoire dans une instance m5.large (prenant en charge 2 vCPU et 8 Go de mémoire). Les réserves de cette définition de tâche tirent pleinement parti des ressources de l’instance. # Exploitation d’Amazon ECS à grande échelle Lorsque vous commencez à exploiter Amazon ECS à grande échelle, réfléchissez à la manière dont les quotas de service et les limitations d'API pour Amazon ECS et ceux Services AWS qui s'intègrent à Amazon ECS peuvent vous affecter. **Topics** + [Quotas de service Amazon ECS et seuils de limitation d’API](operating-at-scale-service-quotas-best-practice.md) + [Gestion des problèmes de limitation d’Amazon ECS](operating-at-scale-dealing-with-throttles.md) # Quotas de service Amazon ECS et seuils de limitation d’API Amazon ECS s'intègre à plusieurs d'entre eux Services AWS, notamment Elastic Load Balancing et Amazon EC2. AWS Cloud Map Grâce à cette intégration fine, Amazon ECS inclut plusieurs fonctionnalités telles que l’équilibrage de charge des services, la découverte de service, la mise en réseau des tâches et l’autoscaling de cluster. Amazon ECS et l'autre solution Services AWS qu'il intègre à tous les systèmes maintiennent les quotas de service et les limites de débit des API afin de garantir des performances et une utilisation cohérentes. Ces quotas de service empêchent également l’allocation accidentelle de ressources supérieures à celles nécessaires et protègent contre les actions malveillantes susceptibles d’augmenter votre facture. En vous familiarisant avec vos quotas de service et les limites de débit des AWS API, vous pouvez planifier le dimensionnement de vos charges de travail sans vous soucier d'une dégradation inattendue des performances. Pour plus d’informations, consultez les sections [Quotas de service Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html) et [Limitation des requêtes pour l’API Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html). Lorsque vous effectuez une mise à l’échelle de vos charges de travail sur Amazon ECS, prenez en compte le quota de service suivant. Pour savoir comment demander une augmentation des quotas de service, consultez la section [Gestion de votre Amazon ECS et de vos quotas de AWS Fargate service dans le AWS Management Console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas-manage.html). + AWS Fargate possède des quotas qui limitent le nombre de tâches exécutées simultanément dans chacune d'elles Région AWS. Il existe des quotas pour les tâches à la demande et Fargate Spot sur Amazon ECS. Chaque quota de service inclut également tous les pods Amazon EKS que vous utilisez sur Fargate. Pour de plus amples informations, consultez la section [Quotas de service AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/service-quotas.html#service-quotas-fargate) dans le *Guide de l’utilisateur Amazon Elastic Container Service pour AWS Fargate*. + Pour les tâches exécutées sur des instances Amazon EC2, le nombre maximal d’instances Amazon EC2 que vous pouvez enregistrer pour chaque cluster est de 5 000. Si vous utilisez l’autoscaling de cluster Amazon ECS avec un fournisseur de capacité de groupe Auto Scaling, ou si vous gérez vous-même les instances Amazon EC2 pour votre cluster, ce quota peut devenir un obstacle au déploiement. Si vous avez besoin de plus de capacité, vous pouvez créer d’autres clusters ou demander une augmentation de quota de service. + Si vous utilisez l’autoscaling de cluster Amazon ECS avec un fournisseur de capacité de groupe Auto Scaling, tenez compte du quota `Tasks in the PROVISIONING state per cluster` lors du dimensionnement de vos services. Ce quota est le nombre maximum de tâches dans l’état `PROVISIONING` pour chaque cluster pour lesquelles les fournisseurs de capacité peuvent augmenter la capacité. Lorsque vous lancez un grand nombre de tâches simultanément, vous pouvez facilement atteindre ce quota. Par exemple, si vous déployez simultanément des dizaines de services, chacun comportant des centaines de tâches. Dans ce cas, le fournisseur de capacité doit lancer de nouvelles instances de conteneur pour placer les tâches lorsque la capacité du cluster est insuffisante. Pendant que le fournisseur de capacité lance des instances Amazon EC2 supplémentaires, le planificateur de service Amazon ECS continuera probablement à lancer des tâches en parallèle. Toutefois, cette activité peut être limitée en raison d’une capacité de cluster insuffisante. Le planificateur de service Amazon ECS met en œuvre une stratégie de ralentissement et de limitation exponentielle pour réessayer de placer des tâches lorsque de nouvelles instances de conteneur sont lancées. Par conséquent, les délais de déploiement ou de réduction horizontale peuvent être plus lents. Pour éviter cette situation, vous pouvez planifier vos déploiements de service de l’une des façons suivantes. Déployez un grand nombre de tâches qui ne nécessitent pas d’augmentation de la capacité du cluster, ou conservez une capacité de cluster disponible pour le lancement de nouvelles tâches. En plus de prendre en compte le quota de service Amazon ECS lors du dimensionnement de vos charges de travail, tenez également compte du quota de service pour Services AWS les autres services intégrés à Amazon ECS. La section suivante décrit en détail les principales limites de débit pour chaque service et fournit des recommandations pour faire face aux éventuels problèmes de limitation. ## Elastic Load Balancing Vous pouvez configurer vos services Amazon ECS pour utiliser Elastic Load Balancing afin de répartir le trafic de manière uniforme entre les tâches. Pour plus d’informations sur le choix d’un équilibreur de charge, consultez la section [Utilisation de l’équilibrage de charge pour distribuer le trafic d’un service Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html). ### Quotas de service Elastic Load Balancing Lorsque vous mettez à l’échelle vos charges de travail, tenez compte des quotas du service Elastic Load Balancing suivants. La plupart des quotas de service Elastic Load Balancing sont ajustables, et vous pouvez demander une augmentation dans la console Service Quotas. **Application Load Balancer** Lorsque vous utilisez un Application Load Balancer, selon votre cas d’utilisation, vous devrez peut-être demander une augmentation de quota pour : + Le quota `Targets per Application Load Balancer`, qui correspond au nombre de cibles derrière votre Application Load Balancer. + Le quota `Targets per Target Group per Region`, qui correspond au nombre de cibles derrière vos groupes cibles. Pour plus d’informations, consultez la section [Quotas pour vos Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html). **Network Load Balancer** Le nombre de cibles que vous pouvez enregistrer auprès d’un Network Load Balancer est soumis à des limites plus strictes. Lorsque vous utilisez un Network Load Balancer, vous souhaiterez souvent activer le support entre zones, ce qui implique des limites de mise à l’échelle supplémentaires sur les `Targets per Availability Zone Per Network Load Balancer`, qui correspond au nombre maximum de cibles par zone de disponibilité pour chaque Network Load Balancer. Pour plus d’informations, consultez la section [Quotas pour vos Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-limits.html). ### Limitation de l’API Elastic Load Balancing Lorsque vous configurez un service Amazon ECS pour utiliser un équilibreur de charge, les surveillances de l’état du groupe cible doivent réussir avant que le service ne soit considéré comme sain. Pour effectuer ces surveillances de l’état, Amazon ECS invoque les opérations de l’API Elastic Load Balancing en votre nom. Si vous avez configuré un grand nombre de services avec des équilibreurs de charge dans votre compte, vous risquez de constater un ralentissement des déploiements de service en raison d’une limitation potentielle spécifique aux opérations `RegisterTarget`, `DeregisterTarget` et `DescribeTargetHealth` de l’API Elastic Load Balancing. En cas de limitation, des erreurs de limitation apparaissent dans les messages d’événements de votre service Amazon ECS. Si vous êtes confronté à une limitation d' AWS Cloud Map API, vous pouvez nous contacter Support pour obtenir des conseils sur la manière d'augmenter vos limites de limitation AWS Cloud Map d'API. Pour plus d’informations sur la surveillance et le dépannage de telles erreurs de limitation, consultez la section [Gestion des problèmes de limitation.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html) ## Interfaces réseau Elastic Lorsque vos tâches utilisent le mode réseau `awsvpc`, Amazon ECS fournit une interface réseau Elastic (ENI) unique pour chaque tâche. Lorsque vos services Amazon ECS utilisent un équilibreur de charge Elastic Load Balancing, ces interfaces réseau sont également enregistrées en tant que cibles pour le groupe cible approprié défini dans le service. ### Quotas de service de l’interface réseau Elastic Lorsque vous exécutez des tâches utilisant le mode réseau `awsvpc`, une interface réseau Elastic unique est associée à chaque tâche. Si ces tâches doivent être atteintes via Internet, attribuez une adresse IP publique à l’interface réseau Elastic pour ces tâches. Lorsque vous mettez vos charges de travail Amazon ECS à l’échelle, tenez compte de ces deux quotas importants : + Le `Network interfaces per Region` quota qui est le nombre maximum d'interfaces réseau dans et Région AWS pour votre compte. + Le quota `Elastic IP addresses per Region`, qui correspond au nombre maximum d’adresses IP élastiques dans une Région AWS. Ces deux quotas de service sont ajustables et vous pouvez demander une augmentation depuis votre console Service Quotas pour ces derniers. Pour plus d’informations, consultez la section [Quotas de service Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-enis). Pour les charges de travail Amazon ECS hébergées sur des instances Amazon EC2, lorsque vous exécutez des tâches en mode réseau `awsvpc`, tenez compte du quota de service `Maximum network interfaces`, qui correspond au nombre maximum d’instances réseau pour chaque instance Amazon EC2. Ce quota limite le nombre de tâches que vous pouvez placer sur une instance. Vous ne pouvez pas ajuster le quota et il n’est pas disponible dans la console Service Quotas. Pour de plus amples informations, consultez la section [Adresses IP par interface réseau et par type d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) dans le *Guide de l’utilisateur Amazon EC2*. Bien que vous ne puissiez pas modifier le nombre d’interfaces réseau qui peuvent être attachées à des instances Amazon EC2, vous pouvez utiliser la fonctionnalité de jonction d’interface réseau Elastic pour augmenter le nombre d’interfaces réseau disponibles. Par exemple, par défaut, une instance `c5.large` peut avoir jusqu’à trois interfaces réseau. L'interface réseau principale de l'instance est considérée comme une interface réseau. Ainsi, vous pouvez attacher deux interfaces réseau supplémentaires à l’instance. Dans la mesure où chaque tâche utilisant le mode réseau `awsvpc` nécessite une interface réseau, vous ne pouvez généralement exécuter que deux tâches sur ce type d’instance. Cela peut entraîner une sous-utilisation de la capacité de votre cluster. Si vous activez la jonction d’interface réseau Elastic, vous pouvez augmenter la densité de l’interface réseau afin de placer un plus grand nombre de tâches sur chaque instance. Lorsque la jonction est activée, une instance `c5.large` peut avoir jusqu’à 12 interfaces réseau. L’instance de conteneur a alors une interface réseau principale et Amazon ECS crée et attache une interface réseau « de jonction » à l’instance de conteneur. Par conséquent, avec cette configuration, vous pouvez exécuter 10 tâches sur l’instance au lieu des 2 tâches par défaut. Pour de plus amples informations, consultez la section [Jonction d’interface réseau Elastic](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html). ### Limitation de l’API d’interface réseau Elastic Lorsque vous exécutez des tâches qui utilisent le mode `awsvpc` réseau, Amazon ECS s'appuie sur le système Amazon APIs EC2 suivant. Chacun d'entre eux APIs a des limites d'API différentes. Pour plus d’informations, consultez la section [Limitation des requêtes pour l’API Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html). + CreateNetworkInterface + AttachNetworkInterface + DetachNetworkInterface + DeleteNetworkInterface + DescribeNetworkInterfaces + DescribeVpcs + DescribeSubnets + DescribeSecurityGroups + DescribeInstances Si les appels d’API Amazon EC2 sont limités pendant les flux de travail d’allocation d’interface réseau Elastic, le planificateur de service Amazon ECS réessaie automatiquement avec des interruptions exponentielles. Ces tentatives automatiques peuvent parfois entraîner un retard dans le lancement des tâches, ce qui ralentit la vitesse de déploiement. En cas de limitation de l’API, le message `Operations are being throttled. Will try again later.` apparaît sur vos messages d’événement de service. Si vous respectez régulièrement les limites d'API Amazon EC2, vous pouvez nous contacter Support pour obtenir des conseils sur la manière d'augmenter vos limites de limitation d'API. Pour plus d’informations sur la surveillance et la résolution de ces erreurs de limitation, consultez la section [Gestion des problèmes de limitation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html). ## AWS Cloud Map Amazon ECS Service Discovery permet AWS Cloud Map APIs de gérer les espaces de noms de vos services Amazon ECS. Si vos services comportent un grand nombre de tâches, tenez compte des recommandations suivantes. Pour de plus amples informations, consultez la section [Considérations en matière de découverte de service Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html#service-discovery-considerations). ### AWS Cloud Map quotas de service Lorsque les services Amazon ECS sont configurés pour utiliser la découverte de services, le `Tasks per service` quota, qui est le nombre maximum de tâches pour le service, est affecté par le quota de AWS Cloud Map `Instances per service` service, qui est le nombre maximum d'instances pour ce service. En particulier, le quota de AWS Cloud Map service réduit le nombre de tâches que vous pouvez exécuter à un maximum de 1 000 tâches par service. Vous ne pouvez pas modifier le quota AWS Cloud Map . Pour plus d’informations, consultez [Quotas de service AWS Cloud Map](https://docs.aws.amazon.com/general/latest/gr/cloud_map.html). ### AWS Cloud Map Limitation de l'API Amazon ECS appelle le`ListInstances`, `GetInstancesHealthStatus``RegisterInstance`, et `DeregisterInstance` AWS Cloud Map APIs en votre nom. Elles aident à la découverte de services et effectuent des surveillances de l’état lorsque vous lancez une tâche. Lorsque plusieurs services utilisant la découverte de services comportant un grand nombre de tâches sont déployés en même temps, cela peut entraîner le dépassement des limites de limitation des AWS Cloud Map API. Dans ce cas, vous verrez probablement le message suivant : `Operations are being throttled. Will try again later` dans votre service Amazon ECS, des messages d'événement indiquant un ralentissement du déploiement et de la vitesse de lancement des tâches. AWS Cloud Map ne documente pas les limites de limitation pour ceux-ci. APIs Si vous êtes confronté à un ralentissement dû à ces derniers, vous pouvez nous contacter Support pour obtenir des conseils sur l'augmentation des limites de limitation de vos API. Pour plus de recommandations sur la surveillance et le dépannage de telles erreurs de limitation, consultez la section [Gestion des problèmes de limitation.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html) # Gestion des problèmes de limitation d’Amazon ECS Les erreurs de limitation sont classées en deux grandes catégories : la limitation synchrone et la limitation asynchrone. ## Limitation synchrone En cas de limitation synchrone, vous recevez immédiatement une réponse d’erreur d’Amazon ECS. Cette catégorie apparaît généralement lorsque vous appelez Amazon ECS APIs lors de l'exécution de tâches ou de la création de services. Pour de plus amples informations sur la limitation impliquée et les limites d’accélération pertinentes, consultez la section [Limitation de requête pour l’API Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html). Lorsque votre application lance des demandes d'API, par exemple à l'aide du SDK AWS CLI ou d'un AWS SDK, vous pouvez remédier à la limitation des API. Pour ce faire, vous pouvez soit concevoir l’architecture de votre application de manière à gérer les erreurs, soit implémenter une stratégie de backoff exponentiel et d’instabilité avec une logique de nouvelle tentative pour les appels d’API. Pour de plus amples informations, consultez la section [Délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/). Si vous utilisez un AWS SDK, la logique de nouvelle tentative automatique est intégrée et configurable. ## Limitation asynchrone La régulation asynchrone se produit en raison de flux de travail asynchrones dans lesquels Amazon ECS CloudFormation ou Amazon pourrait APIs appeler en votre nom pour provisionner des ressources. Il est important de savoir lesquels Amazon ECS AWS APIs invoque en votre nom. Par exemple, l’API `CreateNetworkInterface` est invoquée pour les tâches qui utilisent le mode réseau `awsvpc`, et l’API `DescribeTargetHealth` est invoquée lors de l’exécution des surveillances de l’état pour les tâches enregistrées sur un équilibreur de charge. Lorsque vos charges de travail atteignent une taille considérable, ces opérations d’API peuvent être limitées. En d'autres termes, ils peuvent être suffisamment limités pour dépasser les limites imposées par Amazon ECS ou par celui Service AWS qui est appelé. Par exemple, si vous déployez des centaines de services, chacun comportant simultanément des centaines de tâches qui utilisent le mode réseau `awsvpc`, Amazon ECS invoque des opérations API Amazon EC2 telles que `CreateNetworkInterface` et des opérations API Elastic Load Balancing telles que `RegisterTarget` ou `DescribeTargetHealth` pour enregistrer respectivement l’interface réseau élastique et l’équilibreur de charge. Ces appels d’API peuvent dépasser les limites de l’API, ce qui entraîne des erreurs de limitation. Voici un exemple d’erreur de limitation d’Elastic Load Balancing incluse dans le message d’événement de service. ``` { "userIdentity":{ "arn":"arn:aws:sts::111122223333:assumed-role/AWSServiceRoleForECS/ecs-service-scheduler", "eventTime":"2022-03-21T08:11:24Z", "eventSource":"elasticloadbalancing.amazonaws.com", "eventName":" DescribeTargetHealth ", "awsRegion":"us-east-1", "sourceIPAddress":"ecs.amazonaws.com", "userAgent":"ecs.amazonaws.com", "errorCode":"ThrottlingException", "errorMessage":"Rate exceeded", "eventID":"0aeb38fc-229b-4912-8b0d-2e8315193e9c" } } ``` Lorsque ces appels d’API partagent des limites avec le trafic d’autres API de votre compte, il peut être difficile de les surveiller, même s’ils sont émis sous forme d’événements de service. ## Surveillance de la limitation Il est important d’identifier quelles requêtes d’API sont limitées et qui les émet. Vous pouvez utiliser AWS CloudTrail lequel contrôle la régulation et s'intègre à CloudWatch Amazon Athena et Amazon. EventBridge Vous pouvez configurer CloudTrail pour envoyer des événements spécifiques à CloudWatch Logs. CloudWatch Logs : log insights, analyse et analyse les événements. Cela permet d’identifier les détails des événements de limitation, tels que l’utilisateur ou le rôle IAM qui a effectué l’appel et le nombre d’appels d’API effectués. Pour plus d'informations, consultez la section [Surveillance des fichiers CloudTrail journaux à l'aide de CloudWatch journaux](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html). Pour plus d'informations sur CloudWatch Logs Insights et des instructions sur la façon d'interroger les fichiers journaux, consultez la section [Analyse des données des CloudWatch journaux avec Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html). Amazon Athena vous permet de créer des requêtes et d’analyser des données à l’aide du langage SQL standard. Par exemple, vous pouvez créer une table Athena pour analyser CloudTrail les événements. Pour plus d'informations, voir [Utilisation de la CloudTrail console pour créer une table Athena pour les CloudTrail journaux](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#create-cloudtrail-table-ct). Après avoir créé une table Athena, vous pouvez utiliser des requêtes SQL telles que la suivante pour examiner les erreurs `ThrottlingException`. Remplacez le *user-input* par vos valeurs. ``` select eventname, errorcode,eventsource,awsregion, useragent,COUNT(*) count FROM cloudtrail_table-name where errorcode = 'ThrottlingException' AND eventtime between '2024-09-24T00:00:08Z' and '2024-09-23T23:15:08Z' group by errorcode, awsregion, eventsource, useragent, eventname order by count desc; ``` Amazon ECS envoie également des notifications d'événements à Amazon EventBridge. Il existe des événements de modification de l’état des ressources et des événements d’action de service. Ils incluent des événements de limitation des API tels que `ECS_OPERATION_THROTTLED` et `SERVICE_DISCOVERY_OPERATION_THROTTLED`. Pour de plus amples informations, veuillez consulter [Événements d’action d’un service Amazon ECS](ecs_service_events.md). Ces événements peuvent être consommés par un service, par exemple AWS Lambda pour effectuer des actions en réponse. Pour de plus amples informations, veuillez consulter [Gestion des événements Amazon ECS](ecs_cwet_handling.md). Si vous exécutez des tâches autonomes, certaines opérations API telles que `RunTask` sont asynchrones et les opérations de répétition ne sont pas automatiquement effectuées. Dans de tels cas, vous pouvez utiliser des services tels que EventBridge l'intégration pour réessayer des opérations limitées ou AWS Step Functions ayant échoué. Pour plus d’informations, consultez la section [Gestion d’une tâche de conteneur (Amazon ECS, Amazon SNS)](https://docs.aws.amazon.com/step-functions/latest/dg/sample-project-container-task-notification.html). ## CloudWatch À utiliser pour surveiller l'étranglement CloudWatch propose une surveillance de l'utilisation de l'API sur l'espace de `Usage` noms sous **By AWS Resource**. Ces métriques sont enregistrées avec le type d'**API** et le nom de la métrique **CallCount**. Vous pouvez créer des alarmes qui démarreront chaque fois que ces mesures atteignent un certain seuil. Pour de plus amples informations, consultez la section [Visualisation de vos quotas de service et définition des alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html). CloudWatch propose également la détection des anomalies. Cette fonctionnalité utilise le machine learning pour analyser et établir des bases de référence en fonction du comportement particulier de la métrique sur laquelle vous l’avez activée. En cas d'activité inhabituelle de l'API, vous pouvez utiliser cette fonctionnalité avec des CloudWatch alarmes. Pour plus d'informations, consultez la section [Utilisation de la détection des CloudWatch anomalies](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html). En surveillant les erreurs de régulation de manière proactive, vous pouvez les contacter Support pour augmenter les limites de régulation pertinentes et également recevoir des conseils pour les besoins spécifiques de votre application. # Pratiques exemplaires en matière d’autoscaling et de gestion des capacités Amazon ECS Vous pouvez exécuter des charges de travail d’applications conteneurisées de toutes tailles sur Amazon ECS. Cela inclut des environnements de test minimaux et des environnements de production de grande envergure qui fonctionnent à l’échelle mondiale. Avec Amazon ECS, comme tous les AWS services, vous ne payez que pour ce que vous utilisez. Lorsque vous élaborez votre application de manière appropriée, vous pouvez réduire les coûts en ne consommant que les ressources dont vous avez besoin au moment où vous en avez besoin. Les recommandations suivantes vous montrent comment exécuter vos charges de travail Amazon ECS afin d’atteindre vos objectifs de niveau de service tout en fonctionnant de manière rentable. **Topics** + [Détermination de la taille d’une tâche pour Amazon ECS](capacity-tasksize-best-practice.md) + [Optimisation de l’autoscaling d’un service Amazon ECS](capacity-autoscaling-best-practice.md) + [Capacité et disponibilité d’Amazon ECS](capacity-availability-best-practice.md) + [Capacité de cluster Amazon ECS](capacity-cluster-best-practice.md) + [Choix de la taille des tâches Fargate pour Amazon ECS](fargate-task-size-best-practice.md) + [Accélération de l’allocation des capacités des clusters Amazon ECS avec les fournisseurs de capacité sur Amazon EC2](capacity-cluster-speed-up-ec2-best-practice.md) # Détermination de la taille d’une tâche pour Amazon ECS L’un des choix les plus importants lorsque vous déployez des conteneurs sur Amazon ECS concerne la taille de vos conteneurs et de vos tâches. La taille de vos conteneurs et de vos tâches est essentielle pour la mise à l’échelle et la planification des capacités. Amazon ECS utilise deux métriques de ressources pour la capacité : l’UC et la mémoire. Amazon ECS mesure l’UC en unités de 1/1 024 d’un vCPU complet (1 024 unités équivalant à 1 vCPU entier). Amazon ECS mesure la mémoire en mégaoctets. Dans la définition de votre tâche, vous pouvez déclarer des réserves et des limites de ressources. Lorsque vous déclarez une réserve, vous déclarez la quantité minimale de ressources requise par une tâche. Votre tâche reçoit au moins la quantité de ressources que vous demandez. Votre application peut utiliser plus d’UC ou de mémoire que la réserve que vous déclarez. Cependant, cette capacité est soumise aux limites que vous avez également déclarées. L’utilisation d’une quantité supérieure à la réserve est appelée éclatement (bursting). L’éclatement signifie que votre application utilise plus de ressources que ce que vous avez réservé, mais reste dans les limites que vous avez déclarées. Amazon ECS garantit les réserves. Par exemple, si vous utilisez des instances Amazon EC2 pour fournir de la capacité, Amazon ECS ne place aucune tâche sur une instance dans laquelle il ne peut pas honorer la réserve. Une limite est la quantité maximale d’unités d’UC ou de mémoire que votre conteneur ou votre tâche peut utiliser. Si votre conteneur essaie d’utiliser plus d’UC que cette limite, Amazon ECS le limite. Si votre conteneur essaie d’utiliser plus de mémoire que cette limite, Amazon ECS l’arrête. Choisir ces valeurs peut s’avérer difficile. Les valeurs les mieux adaptées à votre application dépendent dans une large mesure des besoins en ressources de votre application. Le test de charge de votre application est la clé d’une planification réussie des besoins en ressources. Les tests de charge vous aident à mieux comprendre les exigences de votre application. ## Applications sans état Pour les applications sans état qui sont mises à l’échelle horizontalement, telles qu’une application située derrière un équilibreur de charge, nous vous recommandons de déterminer d’abord la quantité de mémoire consommée par votre application lorsqu’elle traite des requêtes. Pour ce faire, vous pouvez utiliser des outils traditionnels tels que `ps` ou `top`. Vous pouvez également utiliser des solutions de surveillance telles que CloudWatch Container Insights. Lorsque vous déterminez une réserve d’UC, réfléchissez à la manière dont vous souhaitez mettre votre application à l’échelle en fonction de vos besoins métier. Vous pouvez utiliser des réserves d’UC plus petites, telles que 256 unités d’UC (soit 1/4 de vCPU), pour procéder à une augmentation horizontale précise tout en minimisant les coûts. Mais ils risquent de ne pas se mettre à l’échelle assez rapidement pour répondre à des pics de demande importants. Vous pouvez utiliser des réserves d’UC plus importantes pour procéder à une augmentation ou à une réduction horizontale plus rapidement. Cela vous permet de faire face plus rapidement aux pics de demande. Cependant, les réserves d’UCs plus importantes coûtent plus cher. ## Autres applications Pour les applications qui ne sont pas mises à l’échelle horizontalement, telles que les travailleurs individuels ou les serveurs de base de données, la capacité disponible et le coût sont vos principaux facteurs à prendre en compte. Choisissez la quantité de mémoire et d’UC en fonction des tests de charge qui indiquent que vous avez besoin pour gérer le trafic et atteindre votre objectif de niveau de service. Amazon ECS garantit que votre application est placée sur un hôte doté d’une capacité adéquate. # Optimisation de l’autoscaling d’un service Amazon ECS Un service Amazon ECS est un ensemble géré de tâches. Chaque service est associé à une définition de tâche, à un nombre de tâches souhaité et à une stratégie de placement facultative. L’autoscaling d’un service Amazon ECS fonctionne via le service Application Auto Scaling. Application Auto Scaling utilise CloudWatch les métriques comme source pour le dimensionnement des métriques. Il utilise également des CloudWatch alarmes pour définir des seuils indiquant quand il faut étendre ou dédimensionner votre service. Vous indiquez les seuils de mise à l’échelle. Vous pouvez définir une cible métrique, appelée *mise à l’échelle du suivi de cible*. Vous pouvez également spécifier des seuils, appelés *mise à l’échelle par étapes*. Une fois que vous avez configuré Application Auto Scaling, celui-ci calcule en permanence le nombre de tâches souhaité pour le service. Il indique également à Amazon ECS lorsque le nombre de tâches souhaité doit changer, soit en l’augmentant, soit en le réduisant horizontalement. Pour utiliser efficacement l’autoscaling du service, vous devez choisir une métrique de mise à l’échelle appropriée. Dans les sections suivantes, nous expliquons comment choisir une métrique. ## Caractérisation de votre application Pour dimensionner correctement une application, vous devez connaître les conditions dans lesquelles vous devez soit augmenter, soit réduire horizontalement votre application. En substance, vous devez augmenter horizontalement votre application si la demande prévue dépasse la capacité disponible. À l’inverse, vous pouvez réduire horizontalement votre application pour réduire les coûts lorsque les ressources dépassent la demande. ### Identification d’une métrique d’utilisation Pour effectuer une mise à l’échelle efficace, vous devez identifier une métrique indiquant l’utilisation ou la saturation. Cette métrique doit présenter les propriétés suivantes pour être utile à la mise à l’échelle. + La métrique doit être corrélée à la demande. Lorsque vous maintenez les ressources stables mais que la demande change, la valeur de la métrique doit également changer. La métrique doit augmenter ou diminuer lorsque la demande augmente ou diminue. + La valeur de la métrique doit évoluer proportionnellement à la capacité. Lorsque la demande reste constante, l’ajout de ressources supplémentaires doit entraîner une modification proportionnelle de la valeur de la métrique. Ainsi, le doublement du nombre de tâches devrait entraîner une diminution de 50 % de la métrique. Le meilleur moyen d’identifier une métrique d’utilisation consiste à effectuer des tests de charge dans un environnement de préproduction tel qu’un environnement intermédiaire. Les solutions de test de charge commerciales et open source sont largement disponibles. Ces solutions peuvent généralement générer une charge synthétique ou simuler le trafic utilisateur réel. Pour démarrer le processus de test de charge, vous devez d’abord créer des tableaux de bord pour les indicateurs d’utilisation de votre application. Ces indicateurs incluent l'utilisation du processeur, l'utilisation de la mémoire, I/O les opérations, la profondeur des I/O files d'attente et le débit du réseau. Vous pouvez collecter ces statistiques avec un service tel que CloudWatch Container Insights. Vous pouvez également les collecter en utilisant Amazon Managed Service for Prometheus avec Amazon Managed Grafana. Au cours de ce processus, veillez à collecter et à représenter graphiquement les métriques relatives aux temps de réponse ou aux taux d’achèvement des tâches de votre application. Lorsque vous effectuez un test de charge, commencez par un faible taux de requêtes ou d’insertion de tâches. Maintenez ce débit pendant plusieurs minutes afin de permettre à votre application de prendre la température. Ensuite, augmentez lentement le taux et maintenez-le stable pendant quelques minutes. Répétez ce cycle en augmentant le taux à chaque fois jusqu'à ce que les délais de réponse ou de traitement de votre demande soient trop lents pour atteindre vos objectifs de niveau de service ()SLOs. Pendant le test de charge, examinez chacune des métriques d’utilisation. Les indicateurs qui augmentent en fonction de la charge sont les meilleurs candidats pour vous servir de meilleurs indicateurs d’utilisation. Identifiez ensuite la ressource qui atteint la saturation. Dans le même temps, examinez également les métriques d’utilisation afin de déterminer laquelle se stabilise en premier à un niveau élevé. Vous pouvez également examiner laquelle atteint le pic, puis bloque votre application en premier. Par exemple, si l’utilisation de l’UC augmente de 0 % à 70-80 % à mesure que vous ajoutez de la charge, puis qu’elle reste à ce niveau une fois que vous ajoutez encore plus de charge, on peut affirmer sans risque de se tromper que l’UC est saturé. Selon l’architecture de l’UC, il se peut qu’il n’atteigne jamais 100 %. Supposons, par exemple, que l’utilisation de la mémoire augmente à mesure que vous ajoutez de la charge, puis que votre application se bloque soudainement lorsqu’elle atteint la limite de mémoire de la tâche ou de l’instance Amazon EC2. Dans ce cas, il est probable que la mémoire ait été entièrement consommée. Plusieurs ressources peuvent être consommées par votre application. Par conséquent, choisissez la métrique qui représente la ressource qui s’épuise en premier. Enfin, essayez à nouveau le test de charge après avoir doublé le nombre de tâches ou d’instances Amazon EC2. Supposons que l’indicateur clé augmente ou diminue de moitié par rapport au taux précédent. Si tel est le cas, la métrique est proportionnelle à la capacité. Il s’agit d’un bon indicateur d’utilisation pour l’autoscaling. Examinons maintenant ce scénario hypothétique. Supposons que vous soumettiez une application à un test de charge et que vous constatiez le résultat suivant : l’utilisation de l’UC atteint finalement 80 % à 100 requêtes par seconde. Lorsque vous ajoutez de la charge, l’utilisation de l’UC n’augmente plus. Cependant, cela ralentit la réponse de votre application. Ensuite, vous exécutez à nouveau le test de charge, en doublant le nombre de tâches tout en maintenant le taux à sa valeur maximale précédente. Si vous constatez que l’utilisation moyenne de l’UC tombe à environ 40 %, l’utilisation moyenne de l’UC est un bon candidat pour une métrique de mise à l’échelle. D’un autre côté, si l’utilisation de l’UC reste à 80 % après l’augmentation du nombre de tâches, l’utilisation moyenne de l’UC n’est pas une bonne métrique de mise à l’échelle. Dans ce cas, vous devrez effectuer des recherches supplémentaires afin de trouver une métrique appropriée. ### Modèles d’application et propriétés de mise à l’échelle courants Vous pouvez exécuter des logiciels de toutes sortes sur AWS. De nombreuses charges de travail sont développées en interne, tandis que d’autres sont basées sur des logiciels open source populaires. Quelle que soit leur origine, nous avons observé certains modèles de conception courants pour les services. La manière dont vous effectuez une mise à l’échelle efficace dépend en grande partie du modèle. #### Serveur efficace lié à lUC Le serveur efficace lié à l’UC n’utilise pratiquement aucune ressource autre que l’UC et le débit réseau. Chaque requête peut être traitée par l’application seule. Les requêtes ne dépendent pas d’autres services tels que les bases de données. L'application peut traiter des centaines de milliers de demandes simultanées et peut en utiliser plusieurs efficacement CPUs pour ce faire. Chaque requête est traitée soit par un thread dédié avec une faible surcharge de mémoire, soit par une boucle d’événements asynchrone qui s’exécute sur chaque UC qui traite les requêtes. Chaque réplica de l’application est également capable de traiter une requête. La seule ressource susceptible d’être épuisée avant l’UC est la bande passante du réseau. Dans les services liés à l’UC, l’utilisation de la mémoire, même au débit maximal, ne représente qu’une fraction des ressources disponibles. Vous pouvez utiliser l’autoscaling basée sur l’UC pour ce type d’application. L’application bénéficie d’une flexibilité maximale en termes de mise à l’échelle. Vous pouvez le redimensionner verticalement en lui fournissant des instances Amazon EC2 ou Fargate v plus grandes. CPUs Et vous pouvez également la mettre à l’échelle horizontalement en ajoutant d’autres réplicas. L’ajout de réplicas supplémentaires, ou le doublement de la taille de l’instance, réduit de moitié l’utilisation moyenne de l’UC par rapport à la capacité. Si vous utilisez la capacité Amazon EC2 pour cette application, pensez à la placer sur des instances optimisées pour le calcul, telles que la famille d’instances `c5` ou `c6g` #### Serveur efficace lié à la mémoire Le serveur efficace lié à la mémoire alloue une quantité importante de mémoire par requête. En cas de simultanéité maximale, mais pas nécessairement de débit, la mémoire est épuisée avant que les ressources d’UC ne soient épuisées. La mémoire associée à une requête est libérée lorsque celle-ci prend fin. Des requêtes supplémentaires peuvent être acceptées dans la limite de la mémoire disponible. Vous pouvez utiliser l’autoscaling basé sur la mémoire pour ce type d’application. L’application bénéficie d’une flexibilité maximale en termes de mise à l’échelle. Vous pouvez la mettre à l’échelle verticalement en lui fournissant des ressources de mémoire Amazon EC2 ou Fargate plus importantes. Et vous pouvez également la mettre à l’échelle horizontalement en ajoutant d’autres réplicas. L’ajout de réplicas supplémentaires ou le doublement de la taille de l’instance peut réduire de moitié l’utilisation moyenne de la mémoire par rapport à la capacité. Si vous utilisez la capacité Amazon EC2 pour cette application, pensez à la placer sur des instances optimisées pour la mémoire, telles que la famille d’instances `r5` ou `r6g`. Certaines applications limitées en mémoire ne libèrent pas la mémoire associée à une requête lorsqu’elle se termine, de sorte qu’une réduction de la simultanéité n’entraîne pas une réduction de la mémoire utilisée. Pour cela, nous vous déconseillons d’utiliser la mise à l’échelle basée sur la mémoire. #### Le serveur basé sur les travailleurs Le serveur basé sur les travailleurs traite une requête pour chaque thread de travail individuel l’une après l’autre. Les threads de travail peuvent être des threads légers, tels que des threads POSIX. Il peut également s’agir de threads plus lourds, tels que des processus UNIX. Quel que soit le type de thread, il existe toujours un nombre maximal de connexions simultanées que l’application peut prendre en charge. Généralement, la limite de simultanéité est définie proportionnellement aux ressources de mémoire disponibles. Si la limite de simultanéité est atteinte, l’application place des requêtes supplémentaires dans une file d’attente du backlog. Si la file d’attente du backlog est débordée, l’application rejette immédiatement les requêtes entrantes supplémentaires. Les applications courantes qui correspondent à ce modèle incluent le serveur Web Apache et Gunicorn. La simultanéité des requêtes est généralement le meilleur indicateur pour dimensionner cette application. Étant donné qu’il existe une limite de simultanéité pour chaque réplica, il est important de procéder à une augmentation horizontale avant que la limite moyenne ne soit atteinte. Le meilleur moyen d'obtenir des mesures de simultanéité des demandes est de demander à votre application de les communiquer à CloudWatch. Chaque réplica de votre application peut publier le nombre de requêtes simultanées sous forme de métrique personnalisée à une fréquence élevée. Nous recommandons de régler la fréquence au moins une fois par minute. Une fois que plusieurs rapports ont été collectés, vous pouvez utiliser la simultanéité moyenne comme métrique de mise à l’échelle. Vous calculez cette métrique en divisant la simultanéité totale par le nombre de réplicas. Par exemple, si la simultanéité totale est de 1 000 et que le nombre de réplicas est de 10, la simultanéité moyenne est de 100. Si votre application se trouve derrière un Application Load Balancer, vous pouvez également utiliser la métrique `ActiveConnectionCount` de l’équilibreur de charge comme facteur dans la métrique de mise à l’échelle. Vous devez diviser la métrique `ActiveConnectionCount` par le nombre de réplicas pour obtenir une valeur moyenne. Vous devez utiliser la valeur moyenne pour la mise à l’échelle, par opposition à la valeur de comptage brute. Pour que cette conception fonctionne de manière optimale, l’écart type de la latence de réponse doit être faible à des taux de requêtes bas. Nous recommandons que, pendant les périodes de faible demande, la plupart des requêtes soient traitées dans un délai court et qu’il n’y ait pas beaucoup de requêtes dont le traitement prend beaucoup plus de temps que la moyenne. Le temps de réponse moyen devrait être proche du 95e centile du temps de réponse. Dans le cas contraire, des dépassements de files d’attente pourraient en résulter. Cela entraîne des erreurs. Nous vous recommandons de fournir des réplicas supplémentaires si nécessaire pour atténuer le risque de débordement. #### Serveur en attente Le serveur en attente effectue un certain traitement pour chaque requête, mais son fonctionnement dépend fortement d’un ou de plusieurs services en aval. Les applications de conteneurs font souvent un usage intensif des services en aval tels que les bases de données et autres services d’API. La réponse de ces services peut prendre un certain temps, en particulier dans les scénarios de haute capacité ou de concurrence élevée. En effet, ces applications ont tendance à utiliser peu de ressources d’UC et à utiliser leur simultanéité maximale en termes de mémoire disponible. Le service en attente convient soit au modèle de serveur limité à la mémoire, soit au modèle de serveur basé sur le travailleur, selon la conception de l’application. Si la simultanéité de l’application n’est limitée que par la mémoire, l’utilisation moyenne de la mémoire doit être utilisée comme métrique de mise à l’échelle. Si la simultanéité de l’application est basée sur une limite de travail, la simultanéité moyenne doit être utilisée comme métrique de mise à l’échelle. #### Le serveur basé sur Java Si votre serveur basé sur Java est lié à l’UC et s’adapte proportionnellement aux ressources d’UC, il convient peut-être au modèle de serveur efficace lié à l’UC. Si tel est le cas, l’utilisation moyenne de l’UC peut être appropriée comme métrique de mise à l’échelle. Cependant, de nombreuses applications Java ne sont pas liées à l’UC, ce qui les rend difficiles à mettre à l’échelle. Pour de meilleures performances, nous vous recommandons d’allouer autant de mémoire que possible au segment de machine virtuelle Java (JVM). Les versions récentes de la JVM, y compris la mise à jour 191 ou ultérieure de Java 8, définissent automatiquement la taille du tas aussi grande que possible pour tenir dans le conteneur. Cela signifie qu’en Java, l’utilisation de la mémoire est rarement proportionnelle à l’utilisation des applications. À mesure que le taux de requêtes et la simultanéité augmentent, l’utilisation de la mémoire reste constante. Pour cette raison, nous ne recommandons pas de dimensionner les serveurs Java en fonction de l’utilisation de la mémoire. Au lieu de cela, nous recommandons généralement une mise à l’échelle en fonction de l’utilisation de l’UC. Dans certains cas, les serveurs basés sur Java rencontrent un épuisement de la mémoire avant d’épuiser l’UC. Si votre application risque de s’épuiser en cas de forte simultanéité, le nombre moyen de connexions constitue la meilleure métrique de mise à l’échelle. Si votre application est susceptible de s’épuiser en tas à haut débit, le taux de requêtes moyen est la meilleure métrique de mise à l’échelle. #### Serveurs qui utilisent d’autres environnements d’exécution avec récupérateur de mémoire De nombreuses applications serveur sont basées sur des environnements d’exécution qui effectuent le récupérateur de mémoire, tels que .NET et Ruby. Ces applications serveur peuvent correspondre à l’un des modèles décrits précédemment. Cependant, comme pour Java, nous ne recommandons pas de dimensionner ces applications en fonction de la mémoire, car l’utilisation moyenne de la mémoire observée n’est souvent pas corrélée au débit ou à la simultanéité. Pour ces applications, nous vous recommandons une mise à l’échelle en fonction de l’utilisation de l’UC si l’application est liée à l’UC. Dans le cas contraire, nous vous recommandons d’effectuer une mise à l’échelle en fonction du débit moyen ou de la simultanéité moyenne, en fonction des résultats de vos tests de charge. #### Processeurs de tâches De nombreuses charges de travail impliquent un traitement de tâches asynchrone. Il s’agit notamment des applications qui ne reçoivent pas de requêtes en temps réel, mais qui s’abonnent à une file d’attente pour recevoir des tâches. Pour ces types d’applications, la métrique de mise à l’échelle appropriée est presque toujours la profondeur de la file d’attente. La croissance des files d’attente indique que le travail en attente dépasse la capacité de traitement, tandis qu’une file d’attente vide indique qu’il y a plus de capacité que de travail à effectuer. AWS les services de messagerie, tels qu'Amazon SQS et Amazon Kinesis Data Streams, fournissent des CloudWatch métriques qui peuvent être utilisées pour le dimensionnement. Pour Amazon SQS, `ApproximateNumberOfMessagesVisible` c’est la meilleure métrique. Pour Kinesis Data Streams, pensez à utiliser la métrique `MillisBehindLatest` publiée par la bibliothèque client Kinesis (KCL). Cette métrique doit être moyennée pour tous les consommateurs avant d’être utilisée à des fins de mise à l’échelle. # Capacité et disponibilité d’Amazon ECS La disponibilité des applications est essentielle pour garantir une expérience sans erreur et minimiser le temps de latence des applications. La disponibilité dépend du fait de disposer de ressources accessibles et d'une capacité suffisante pour répondre à la demande. AWS fournit plusieurs mécanismes pour gérer la disponibilité. Pour les applications que vous hébergez sur Amazon ECS, il s'agit notamment de l'autoscaling et des zones de disponibilité (AZs). L’autoscaling gère le nombre de tâches ou d’instances en fonction des métriques que vous définissez, tandis que les zones de disponibilité vous permettent d’héberger votre application dans des emplacements isolés, mais géographiquement proches. Comme pour la taille des tâches, la capacité et la disponibilité présentent certains compromis que vous devez prendre en compte. Idéalement, la capacité devrait être parfaitement adaptée à la demande. Il y aurait toujours juste assez de capacité pour traiter les demandes et traiter les tâches afin d'atteindre les objectifs de niveau de service (SLOs), notamment une faible latence et un faible taux d'erreur. La capacité ne devrait jamais être trop élevée, ce qui entraînerait des coûts excessifs, ni trop faible, ce qui entraînerait des temps de latence et des taux d’erreur élevés. L’autoscaling est un processus latent. Tout d'abord, vous CloudWatch devez recevoir des métriques en temps réel. Ensuite, il CloudWatch faut les agréger pour les analyser, ce qui peut prendre plusieurs minutes en fonction de la granularité de la métrique. CloudWatch compare les indicateurs aux seuils d'alarme pour identifier une pénurie ou un excès de ressources. Pour éviter toute instabilité, vous devez configurer les alarmes de manière à ce que le seuil défini soit dépassé pendant quelques minutes avant que l’alarme ne se déclenche. Il faut également du temps pour configurer de nouvelles tâches et mettre fin à des tâches qui ne sont plus nécessaires. En raison de ces retards potentiels dans le système, vous devez conserver une certaine marge de manœuvre en allouant des ressources supplémentaires.. La surallocation peut aider à faire face à des pics de demande à court terme. Cela permet également à votre application de répondre à des requêtes supplémentaires sans atteindre la saturation. À titre de pratique exemplaire, vous pouvez définir votre objectif de mise à l’échelle entre 60 et 80 % d’utilisation. Cela permet à votre application de mieux gérer les pics de demande alors que de la capacité supplémentaire est encore en cours d’allocation. Une autre raison pour laquelle nous vous recommandons de surprovisionner est de pouvoir réagir rapidement aux défaillances de la zone de disponibilité. AWS recommande que les charges de travail de production soient traitées à partir de plusieurs zones de disponibilité. En effet, en cas de défaillance d’une zone de disponibilité, les tâches exécutées dans les zones de disponibilité restantes peuvent toujours répondre à la demande. Si votre application s’exécute dans deux zones de disponibilité, vous devez doubler le nombre normal de tâches. Cela vous permet de fournir une capacité immédiate en cas de panne potentielle. Si votre application s’exécute dans trois zones de disponibilité, nous vous recommandons d’exécuter 1,5 fois le nombre normal de tâches. C’est-à-dire, exécutez trois tâches pour deux qui sont nécessaires au service ordinaire. ## Maximisation de la vitesse de mise à l’échelle L’autoscaling est un processus réactif dont l’effet prend du temps. Cependant, il existe des moyens de minimiser le temps nécessaire pour augmenter horizontalement. **Minimisez la taille de l’image.** Le téléchargement et la décompression des images volumineuses à partir d’un référentiel d’images prennent plus de temps. Par conséquent, réduire la taille des images réduit le temps nécessaire au démarrage d’un conteneur. Pour réduire la taille de l’image, vous pouvez suivre ces recommandations spécifiques : + Si vous pouvez créer un binaire statique ou utiliser Golang, créez votre image `FROM` scratch et n’incluez que votre application binaire dans l’image résultante. + Utilisez des images de base minimisées provenant de fournisseurs de distribution en amont, tels qu’Amazon Linux ou Ubuntu. + N’incluez aucun artefact de construction dans votre image finale. L’utilisation de versions en plusieurs étapes peut y contribuer. + Dans la mesure du possible, compactez les étapes `RUN`. Chaque étape `RUN` crée une nouvelle couche d’image, ce qui entraîne un aller-retour supplémentaire pour télécharger la couche. Une étape `RUN` comportant plusieurs commandes jointes par `&&` comporte moins de couches qu’une étape comportant plusieurs étapes `RUN`. + Si vous souhaitez inclure des données, telles que des données d’inférence ML, dans votre image finale, incluez uniquement les données nécessaires pour démarrer et commencer à desservir le trafic. Si vous récupérez des données à la demande depuis Amazon S3 ou un autre système de stockage sans affecter le service, stockez plutôt vos données dans ces emplacements. **Gardez vos images au plus proche.** Plus la latence du réseau est élevée, plus le téléchargement de l’image prend du temps. Hébergez vos images dans un référentiel situé dans la même AWS région que celle dans laquelle se trouve votre charge de travail. Amazon ECR est un référentiel d’images hautes performances disponible dans toutes les régions dans lesquelles Amazon ECS est disponible. Évitez d’utiliser Internet ou un lien VPN pour télécharger des images de conteneurs. L’hébergement de vos images dans la même région améliore la fiabilité globale. Il atténue le risque de problèmes de connectivité réseau et de disponibilité dans une autre région. Vous pouvez également implémenter la réplication entre régions Amazon ECR pour y parvenir. **Réduisez les seuils de surveillance de l’état de l’équilibreur de charge.** Les équilibreurs de charge effectuent une surveillance de l’état avant d’envoyer du trafic à votre application. La configuration de la surveillance de l’état par défaut pour un groupe cible peut prendre 90 secondes ou plus. Pendant ce temps, l’équilibreur de charge vérifie l’état et reçoit les requêtes. La réduction de l’intervalle entre les surveillances de l’état et du nombre de seuils peut permettre à votre application d’accepter le trafic plus rapidement et de réduire la charge sur les autres tâches. **Tenez compte des performances de démarrage à froid.** Certaines applications utilisent des environnements d'exécution tels que la compilation Java Perform Just-In-Time (JIT). Le processus de compilation, au moins lorsqu’il démarre, peut montrer les performances de l’application. Une solution consiste à réécrire les parties critiques de votre charge de travail en termes de latence dans des langages qui n’affectent pas les performances de démarrage à froid. **Utilisez la mise à l’échelle par étapes, et non des politiques de mise à l’échelle du suivi de cible.** Vous disposez de plusieurs options d'Application Auto Scaling pour les tâches Amazon ECS. Le suivi des cibles est le mode le plus simple à utiliser. Il vous suffit de définir une valeur cible pour une métrique, telle que l'utilisation moyenne du processeur. Ensuite, l'autoscaler gère automatiquement le nombre de tâches nécessaires pour atteindre cette valeur. Grâce à la mise à l'échelle par étapes, vous pouvez réagir plus rapidement aux variations de la demande, car vous définissez les seuils spécifiques pour vos métriques de mise à l'échelle et le nombre de tâches à ajouter ou à supprimer lorsque les seuils sont dépassés. Et surtout, vous pouvez réagir très rapidement aux variations de la demande en réduisant la durée pendant laquelle une alarme de seuil est franchie. Pour plus d'informations, consultez [Scalabilité automatique de service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) dans le *Guide du développeur Amazon Elastic Container Service*. Si vous utilisez des instances Amazon EC2 pour fournir de la capacité de cluster, tenez compte des recommandations suivantes : **Utilisez des instances Amazon EC2 de plus grande taille et des volumes Amazon EBS plus rapides.** Vous pouvez améliorer les vitesses de téléchargement et de préparation des images en utilisant une instance Amazon EC2 plus grande et un volume Amazon EBS plus rapide. Au sein d’une famille d’instances Amazon EC2 donnée, le débit maximal du réseau et d’Amazon EBS augmente à mesure que la taille de l’instance augmente (par exemple, de `m5.xlarge` à `m5.2xlarge`). En outre, vous pouvez également personnaliser les volumes Amazon EBS pour augmenter leur débit et leurs IOPS. Par exemple, si vous utilisez des volumes `gp2`, utilisez des volumes plus importants offrant un débit de base supérieur. Si vous utilisez des volumes `gp3`, spécifiez le débit et les IOPS lorsque vous créez le volume. **Utilisez le mode réseau en pont pour les tâches exécutées sur les instances Amazon EC2.** Les tâches qui utilisent le mode réseau `bridge` sur Amazon EC2 démarrent plus rapidement que celles qui utilisent le mode réseau `awsvpc`. Lorsque le mode réseau `awsvpc` est utilisé, Amazon ECS attache une interface réseau Elastic (ENI) à l’instance avant de lancer la tâche. Cela introduit une latence supplémentaire. Il existe cependant plusieurs compromis à faire lors de l’utilisation d’un réseau de ponts. Ces tâches ne disposent pas de leur propre groupe de sécurité, ce qui a des répercussions sur l’équilibrage de charge. Pour plus d’informations, consultez la section [Suppression de votre équilibreur de charge](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html) dans le *Guide de l’utilisateur Elastic Load Balancing*. ## Gestion des pics de demande Certaines applications subissent des pics soudains et importants en termes de demande. Cela se produit pour diverses raisons : un événement d’actualité, une grosse vente, un événement médiatique ou tout autre événement qui devient viral et entraîne une augmentation rapide et significative du trafic en très peu de temps. Si cela n’est pas planifié, la demande peut rapidement dépasser les ressources disponibles. La meilleure façon de gérer les pics de demande est de les anticiper et de planifier en conséquence. La mise à l’échelle automatique pouvant prendre du temps, nous vous recommandons de faire évoluer votre application avant que le pic de demande ne commence. Pour de meilleurs résultats, nous recommandons d’élaborer un plan d’affaires impliquant une étroite collaboration entre les équipes utilisant un calendrier partagé. L’équipe chargée de planifier l’événement doit travailler en étroite collaboration avec l’équipe chargée de l’application à l’avance. Cela donne à cette équipe suffisamment de temps d’établir une planification claire. Ils peuvent planifier la capacité nécessaire pour augmenter horizontalement avant l’événement et la réduire horizontalement après l’événement. Pour plus d’informations, voir [Mise à l’échelle planifiée](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) dans le *Guide de l’utilisateur Application Auto Scaling.*. Si vous disposez d’un plan de support Entreprise, veillez également à collaborer avec votre responsable de compte technique (TAM). Votre TAM peut vérifier vos quotas de service et s’assurer que tous les quotas nécessaires sont augmentés avant le début de l’événement. De cette façon, vous n’atteignez aucun quota de service par accident. Ils peuvent également vous aider en préchauffant des services, tels que les équilibreurs de charge, afin de garantir le bon déroulement de votre événement. Il est plus difficile de gérer les pics de demande imprévus. Les pics imprévus, s’ils sont d’une amplitude suffisante, peuvent rapidement faire en sorte que la demande dépasse la capacité. Cela peut également dépasser la capacité de réaction de l’autoscaling. La meilleure façon de se préparer à des pics imprévus est de surallouer les ressources. Vous devez disposer de suffisamment de ressources pour répondre à la demande maximale de trafic prévue à tout moment. Le maintien d’une capacité maximale en prévision de pics de demande imprévus peut s’avérer coûteux. Pour atténuer l’impact sur les coûts, trouvez une métrique avancée ou un événement qui permet de prédire qu’un pic de demande important est imminent. Si la métrique ou l’événement fournit un préavis significatif de manière fiable, lancez le processus d’augmentation horizontale immédiatement lorsque l’événement se produit ou lorsque la métrique dépasse le seuil spécifique que vous avez défini. Si votre application est sujette à des pics de demande soudains et imprévus, envisagez d’ajouter un mode haute performance à votre application qui sacrifie les fonctionnalités non critiques tout en préservant les fonctionnalités cruciales pour le client. Supposons, par exemple, que votre application puisse passer de la génération de réponses personnalisées coûteuses à la diffusion d’une page de réponse statique. Dans ce scénario, vous pouvez augmenter le débit de manière significative sans devoir dimensionner l’application. Enfin, vous pouvez envisager de dissocier les services monolithiques afin de mieux faire face aux pics de demande. Si votre application est un service monolithique coûteux à exécuter et lent à adapter, vous pourriez être en mesure d’extraire ou de réécrire des éléments critiques en termes de performances et de les exécuter en tant que services distincts. Ces nouveaux services peuvent ensuite être étendus indépendamment des composants moins critiques. Le fait de disposer de la flexibilité nécessaire pour augmenter horizontalement les fonctionnalités critiques en termes de performances séparément des autres parties de votre application peut à la fois réduire le temps nécessaire pour augmenter la capacité et contribuer à réduire les coûts. # Capacité de cluster Amazon ECS Vous pouvez fournir de la capacité à un cluster Amazon ECS de plusieurs manières. Par exemple, vous pouvez lancer des instances Amazon EC2 et les enregistrer auprès du cluster au démarrage à l’aide de l’agent de conteneur Amazon ECS. Cependant, cette méthode peut s’avérer difficile, car vous devez gérer vous-même la mise à l’échelle. Par conséquent, nous vous recommandons d’utiliser les fournisseurs de capacité Amazon ECS. Les fournisseurs de capacités gèrent la mise à l’échelle des ressources pour vous. Il existe trois types de fournisseurs de capacité : Amazon EC2, Fargate et Fargate Spot. Pour plus d’informations sur les fournisseurs de capacité Fargate, consultez la section [Clusters Amazon ECS pour les charges de travail Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html) et, pour les charges de travail EC2, consultez la section [Clusters Amazon ECS pour les charges de travail EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html). Les fournisseurs de capacité Fargate et Fargate Spot prennent en charge le cycle de vie des tâches Fargate pour vous. Fargate fournit une capacité à la demande et Fargate Spot fournit une capacité Spot. Lorsque vous lancez une tâche, Amazon ECS met à votre disposition une ressource Fargate. Cette ressource Fargate est fournie avec les unités de mémoire et d’UC qui correspondent directement aux limites de niveau de tâche que vous avez déclarées dans votre définition de tâche. Chaque tâche reçoit sa propre ressource Fargate, ce qui crée une relation 1:1 entre la tâche et les ressources de calcul. Les tâches exécutées sur Fargate Spot sont susceptibles d’être interrompues. Les interruptions surviennent après un avertissement de deux minutes. Elles se produisent pendant les périodes de forte demande. Fargate Spot convient parfaitement aux charges de travail tolérantes aux interruptions, telles que les tâches par lots, les environnements de développement ou de préparation. Ils sont également adaptés à tout autre scénario où une haute disponibilité et une faible latence ne sont pas requises. Vous pouvez exécuter des tâches Fargate Spot parallèlement à des tâches Fargate à la demande. En les utilisant ensemble, vous bénéficiez d’une capacité « de débordement » pour l’allocation à moindre coût. Amazon ECS peut également gérer la capacité de l’instance Amazon EC2 pour vos tâches. Chaque fournisseur de capacité Amazon EC2 est associé à un groupe Amazon EC2 Auto Scaling que vous spécifiez. Lorsque vous utilisez le fournisseur de capacité Amazon EC2, l’autoscaling de cluster maintient la taille du groupe Amazon EC2 Auto Scaling afin de garantir que toutes les tâches planifiées peuvent être placées. # Choix de la taille des tâches Fargate pour Amazon ECS Pour les définitions de AWS Fargate tâches, vous devez spécifier le processeur et la mémoire au niveau de la tâche, et vous n'avez pas besoin de prendre en compte les frais généraux. Vous pouvez également spécifier l'UC et la mémoire au niveau du conteneur pour les tâches Fargate. Toutefois, cette opération n'est pas obligatoire. Les limites de ressources doivent être supérieures ou égales à toutes les réserves que vous avez déclarées. Dans la plupart des cas, vous pouvez les définir en fonction de la somme des réserves de chacun des conteneurs déclarés dans votre définition de tâche. Ensuite, arrondissez le nombre à la taille Fargate la plus proche. Pour plus d’informations sur les tailles disponibles, consultez la section [UC et mémoire de la tâche.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-size). # Accélération de l’allocation des capacités des clusters Amazon ECS avec les fournisseurs de capacité sur Amazon EC2 Les clients qui exécutent Amazon ECS sur Amazon EC2 peuvent tirer parti de l[’autoscaling de cluster (CAS, Cluster Auto Scaling) Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html) pour gérer la mise à l’échelle des groupes Amazon EC2 Auto Scaling (ASG, Auto Scaling groups). Avec le CAS, vous pouvez configurer Amazon ECS pour mettre automatiquement votre ASG à l’échelle et vous concentrer uniquement sur l’exécution de vos tâches. Amazon ECS veillera à ce que l’ASG évolue en fonction des besoins, sans qu’aucune autre intervention ne soit requise. Les fournisseurs de capacité Amazon ECS vous permettent de gérer l’infrastructure de votre cluster en s’assurant qu’il y a suffisamment d’instances de conteneur pour répondre aux demandes de votre application. Pour en savoir plus sur le fonctionnement du CAS Amazon ECS, consultez le billet de blog [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/). Comme le CAS repose sur une intégration CloudWatch basée sur l'intégration avec ASG pour ajuster la capacité du cluster, il présente une latence inhérente associée à la publication des CloudWatch métriques, `CapacityProviderReservation` au temps nécessaire pour que la métrique franchisse les CloudWatch alarmes (haute et faible) et au temps nécessaire au préchauffage d'une instance Amazon EC2 récemment lancée. Vous pouvez prendre les mesures suivantes pour améliorer la réactivité du CAS et accélérer les déploiements : ## Mise à l’échelle par étapes du fournisseur de capacités Les fournisseurs de capacité Amazon ECS finiront par fournir grow/shrink les instances de conteneur répondant aux exigences de votre application. Le nombre minimum d’instances qu’Amazon ECS lancera est fixé à une par défaut. Cela peut allonger la durée de vos déploiements si plusieurs instances sont nécessaires pour placer vos tâches en attente. Vous pouvez augmenter la [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) en utilisant l’API Amazon ECS pour augmenter le nombre minimum d’instances qu’Amazon ECS fait évoluer ou non à la fois. Une [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) trop faible peut limiter le nombre d’instances de conteneur pouvant être mises à l’échelle horizontale, ce qui peut ralentir vos déploiements. **Note** Cette configuration n'est actuellement disponible qu'en utilisant le [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)ou [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs. ## Durée de préinitialisation de l’instance La période de préchauffage de l'instance est la période après laquelle une instance Amazon EC2 récemment lancée peut contribuer CloudWatch aux métriques du groupe Auto Scaling. Une fois la période de préchauffage spécifiée expirée, l’instance est prise en compte dans les métriques agrégées de l’ASG, et le CAS procède à sa prochaine itération de calculs pour estimer le nombre d’instances requises. La valeur par défaut [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)est de 300 secondes, que vous pouvez configurer à une valeur inférieure en utilisant le [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)ou [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs pour une mise à l'échelle plus réactive. ## Capacité de réserve Si votre fournisseur de capacité ne dispose d’aucune instance de conteneur pour placer des tâches, il doit accroître (augmenter horizontalement) la capacité du cluster en lançant des instances Amazon EC2 à la volée, puis attendre leur démarrage avant de pouvoir y lancer des conteneurs. Cela peut réduire considérablement la vitesse de lancement des tâches. Vous avez deux options. Dans ce cas, le fait de disposer d’une capacité Amazon EC2 disponible déjà lancée et prête à exécuter des tâches augmentera la vitesse de lancement effective des tâches. Vous pouvez utiliser la configuration de `Target Capacity` pour indiquer que vous souhaitez conserver de la capacité de réserve dans vos clusters. Par exemple, en définissant `Target Capacity` sur 80 %, vous indiquez que votre cluster a besoin de 20 % de capacité de réserve à tout moment. Cette capacité de réserve peut permettre le lancement immédiat de toutes les tâches autonomes, garantissant ainsi que les lancements de tâches ne sont pas ralentis. L’inconvénient de cette approche est l’augmentation potentielle des coûts liés au maintien de la capacité de réserve des clusters. Une autre approche que vous pouvez envisager consiste à augmenter la marge de manœuvre de votre service, et non celle du fournisseur de capacité. Cela signifie qu’au lieu de réduire la configuration de `Target Capacity` pour lancer de la capacité de réserve, vous pouvez augmenter le nombre de réplicas dans votre service en modifiant la métrique de mise à l’échelle du suivi de cible ou les seuils de mise à l’échelle par étapes de l’autoscaling du service. Notez que cette approche ne sera utile que pour les charges de travail complexes, mais n’aura aucun effet lorsque vous déployez de nouveaux services et que vous passez de 0 à N tâches pour la première fois. Pour plus d’informations sur les politiques de mise à l’échelle associées, consultez les sections [Politiques de mise à l’échelle du suivi de cible](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) ou [Politiques de mise à l’échelle par étapes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html). # Accès aux fonctionnalités d’Amazon ECS avec les paramètres du compte Vous pouvez accéder aux paramètres de compte Amazon ECS pour activer ou désactiver des fonctions spécifiques. Pour chaque Région AWS, vous pouvez accepter ou refuser chaque paramètre de compte au niveau du compte ou pour un utilisateur ou un rôle spécifique. Vous pouvez choisir d'activer ou de désactiver des fonctions spécifiques si l'une des options suivantes vous concerne : + Un utilisateur ou un rôle peut accepter ou refuser des paramètres de compte spécifiques pour son compte individuel. + Un utilisateur ou un rôle peut définir le paramètre d'acceptation et de refus par défaut pour tous les utilisateurs du compte. + L’utilisateur racine ou un utilisateur disposant de privilèges d’administrateur peut choisir d’accepter ou de refuser un rôle ou un utilisateur spécifique sur le compte. Si le paramètre de compte de l'utilisateur root est modifié, cela modifie également le paramètre par défaut de tous les utilisateurs et rôles pour lesquels aucun paramètre de compte individuel n'a été sélectionné. **Note** Les utilisateurs fédérés héritent du paramètre de compte de l'utilisateur root et ne peuvent pas avoir de paramètres de compte définis séparément pour leur compte. Les paramètres de compte suivants sont disponibles. Vous devez activer et désactiver séparément chaque paramètre de votre compte. | Nom de la ressource | En savoir plus | | --- | --- | | containerInsights | [Container Insights](#container-insights-setting) | | serviceLongArnFormat`taskLongArnFormat` `containerInstanceLongArnFormat` | [Amazon Resource Names (ARNs) et IDs](#ecs-resource-ids) | | tagResourceAuthorization | [Autorisation de balisage](#tag-resources-setting) | | fargateFIPSMode | [AWS Fargate Conformité à la norme fédérale de traitement de l'information (FIPS-140)](#fips-setting) | | fargateTaskRetirementWaitPeriod | [AWS Fargate temps d'attente pour la retraite des tâches](#fargate-retirement-wait-time) | | fargateEventWindows | [AWS Fargate suppressions de tâches à l'aide des fenêtres d'événements EC2](#fargate-event-windows) | | guardDutyActivate | [Surveillance du temps d'exécution ( GuardDuty intégration Amazon)](#guard-duty-integration) | | dualStackIPv6 | [IPv6 VPC à double pile](#dual-stack-setting) | | awsvpcTrunking | [Augmentation des interfaces réseau des instances de conteneur Linux](#vpc-trunking-setting) | | defaultLogDriverMode | [Mode de pilote du journal par défaut](#default-log-driver-mode) | ## Amazon Resource Names (ARNs) et IDs Lorsque des ressources Amazon ECS sont créées, chacune d'elles se voit affecter un Amazon Resource Name (ARN) et un identificateur de ressource (ID) uniques. Si vous utilisez un outil de ligne de commande ou l'API Amazon ECS pour travailler avec Amazon ECS, des ressources ARNs ou IDs sont requises pour certaines commandes. Par exemple, si vous utilisez la AWS CLI commande [stop-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/stop-task.html) pour arrêter une tâche, vous devez spécifier l'ARN ou l'ID de la tâche dans la commande. Amazon ECS a introduit un nouveau format pour Amazon Resource Names (ARNs) et une nouvelle ressource IDs pour les services, les tâches et les instances de conteneur Amazon ECS. L'état d'acceptation de chaque type de ressource détermine le format Amazon Resource Name (ARN) utilisé par la ressource. Vous devez accepter le nouveau format ARN afin d'utiliser des fonctions telles que le balisage des ressources pour ce type de ressource. Vous pouvez accepter ou refuser le nouveau nom Amazon Resource Name (ARN) et les ID de ressource dépend de la région. Actuellement, il est activé par défaut pour tout nouveau compte. Vous pouvez accepter ou refuser le nouveau format d'Amazon Resource Name (ARN) et d'ID de ressource à tout moment. Une fois que vous avez activé cette option, toutes les nouvelles ressources que vous créez utilisent le nouveau format. **Note** Un ID de ressource ne change pas une fois qu'il a été créé. Par conséquent, le fait d'accepter ou de refuser le nouveau format n'affecte pas votre ressource IDs existante. Les sections suivantes décrivent les modifications des formats d'ARN et d'ID de ressource. Pour plus d'informations sur la transition vers les nouveaux formats, consultez la [FAQ sur Amazon Elastic Container Service](https://aws.amazon.com/ecs/faqs/). **Format Amazon Resource Name (ARN)** Certaines ressources ont un nom convivial, comme par exemple un service nommé `production`. Dans d'autres cas, vous devez définir une ressource à l'aide du format Amazon Resource Name (ARN). Le nouveau format ARN des tâches, services et instances de conteneur Amazon ECS inclut le nom du cluster. Pour de plus amples informations sur le nouveau format ARN, consultez [Modification des paramètres de compte Amazon ECS](ecs-modifying-longer-id-settings.md). Le tableau suivant présente le format actuel et le nouveau format pour chaque type de ressource : | Type de ressource | ARN | | --- | --- | | Instance de conteneur | `arn:aws:ecs:region:aws_account_id:container-instance/container-instance-id` actuel Nouveau : `arn:aws:ecs:region:aws_account_id:container-instance/cluster-name/container-instance-id` | | Amazon ECS service | `arn:aws:ecs:region:aws_account_id:service/service-name` actuel Nouveau : `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name` | | Tâches Amazon ECS | `arn:aws:ecs:region:aws_account_id:task/task-id` actuel Nouveau : `arn:aws:ecs:region:aws_account_id:task/cluster-name/task-id` | **Longueur des ID de ressource** Un ID de ressource est constitué d'une combinaison unique de lettres et de chiffres. Les nouveaux formats d'ID de ressource incluent des formats plus courts IDs pour les tâches Amazon ECS et les instances de conteneur. Le format d'ID de ressource actuel comporte 36 caractères. Les nouveaux IDs sont dans un format de 32 caractères qui n'inclut aucun trait d'union. Pour de plus amples informations sur le nouveau format d'ID de ressource, consultez [Modification des paramètres de compte Amazon ECS](ecs-modifying-longer-id-settings.md). La valeur par défaut est `enabled`. Seules les ressources lancées après l'acceptation recevront le nouveau format d'ARN et d'ID de ressource. Toutes les ressources existantes ne sont pas affectées. Pour que les services et les tâches Amazon ECS passent aux nouveaux formats d'ARN et d'ID de ressource, vous devez recréer les services et les tâches. Pour faire passer une instance de conteneur au nouveau format d'ARN et d'ID de ressource, il est nécessaire de la vider et de lancer et d'enregistrer une nouvelle instance de conteneur sur le cluster. **Note** Les tâches lancées par un service Amazon ECS ne peuvent recevoir le nouveau format d'ARN et d'ID de ressource que si le service a été créé à compter du 16 novembre 2018 et si l'utilisateur qui a créé le service a accepté le nouveau format pour les tâches. ## Calendrier relatif au format ARN et de l'ID de ressource Le calendrier prévoyant des créneaux d'activation/rejet du nouveau format d'Amazon Resource Name (ARN) et d'ID de ressource pour les ressources Amazon ECS a pris fin le 1er avril 2021. Le nouveau format est activé par défaut pour tout nouveau compte. Toutes les nouvelles ressources créées reçoivent le nouveau format et vous ne pouvez plus vous désinscrire. ## Container Insights Le 2 décembre 2024, AWS a publié Container Insights avec une observabilité améliorée pour Amazon ECS. Cette version prend en charge une observabilité améliorée pour les clusters Amazon ECS utilisant les instances gérées Amazon ECS Fargate et EC2. Une fois que vous avez configuré Container Insights avec observabilité améliorée sur Amazon ECS, Container Insights collecte automatiquement des données télémétriques d’infrastructure détaillées depuis le niveau du cluster jusqu’au niveau du conteneur dans votre environnement et affiche vos données dans des tableaux de bord qui vous présentent diverses métriques et dimensions. Vous pouvez ensuite utiliser ces out-of-the-box tableaux de bord sur la console Container Insights pour mieux comprendre l'état et les performances de vos conteneurs, et pour atténuer les problèmes plus rapidement en identifiant les anomalies. Nous vous recommandons d’utiliser Container Insights avec observabilité améliorée à la place de Container Insights, car il fournit une visibilité détaillée de votre environnement de conteneurs, réduisant ainsi le délai moyen de résolution. Pour plus d’informations, consultez la section [Métriques Amazon ECS Container Insights avec observabilité améliorée](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-enhanced-observability-metrics-ECS.html) dans le *Guide de l’utilisateur Amazon CloudWatch *. La valeur par défaut du paramètre du compte `containerInsights` est `disabled`. ### Container Insights avec observabilité améliorée Utilisez la commande suivante pour activer Container Insights avec observabilité améliorée. Réglez le paramètre du compte `containerInsights` sur `enhanced`. ``` aws ecs put-account-setting --name containerInsights --value enhanced ``` Exemple de sortie ``` { "setting": { "name": "containerInsights", "value": "enhanced", "principalArn": "arn:aws:iam::123456789012:johndoe", "type": user } } ``` Une fois que vous avez défini ce paramètre de compte, tous les nouveaux clusters utilisent automatiquement Container Insights avec observabilité améliorée. Utilisez la commande `update-cluster-settings` pour ajouter Container Insights avec observabilité améliorée à un cluster existant, ou pour mettre à niveau un cluster de Container Insights à Container Insights avec observabilité améliorée. ``` aws ecs update-cluster-settings --cluster cluster-name --settings name=containerInsights,value=enhanced ``` Vous pouvez également utiliser la console pour configurer Container Insights avec observabilité améliorée. Pour de plus amples informations, veuillez consulter [Modification des paramètres de compte Amazon ECS](ecs-modifying-longer-id-settings.md). ### Container Insights Lorsque vous définissez le paramètre de compte `containerInsights` sur `enabled`, tous les nouveaux clusters ont Container Insights activé par défaut. Vous pouvez modifier les clusters existants en utilisant `update-cluster-settings`. Pour utiliser Container Insights, définissez le paramètre du compte `containerInsights` sur `enabled`. Utilisez la commande suivante pour activer Container Insights. ``` aws ecs put-account-setting --name containerInsights --value enabled ``` Exemple de sortie ``` { "setting": { "name": "containerInsights", "value": "enabled", "principalArn": "arn:aws:iam::123456789012:johndoe", "type": user } } ``` Lorsque vous définissez le paramètre de compte `containerInsights` sur `enabled`, tous les nouveaux clusters ont Container Insights activé par défaut. Utilisez la commande `update-cluster-settings` pour ajouter Container Insights à un cluster existant. ``` aws ecs update-cluster-settings --cluster cluster-name --settings name=containerInsights,value=enabled ``` Vous pouvez également utiliser la console pour configurer Container Insights. Pour de plus amples informations, veuillez consulter [Modification des paramètres de compte Amazon ECS](ecs-modifying-longer-id-settings.md). ## AWS Fargate Conformité à la norme fédérale de traitement de l'information (FIPS-140) Fargate prend en charge la norme Federal Information Processing Standard (FIPS-140), qui spécifie les exigences de sécurité pour les modules cryptographiques qui protègent des informations sensibles. Il s'agit de la norme gouvernementale en vigueur aux États-Unis et au Canada, applicable aux systèmes qui doivent être conformes à la loi sur la gestion de la sécurité des informations fédérales (FISMA) ou au programme fédéral de gestion des risques et des autorisations (FedRAMP). Le nom de la ressource est `fargateFIPSMode`. La valeur par défaut est `disabled`. Vous devez activer la conformité à la norme Federal Information Processing Standard (FIPS-140) sur Fargate. Pour de plus amples informations, veuillez consulter [AWS Fargate Norme fédérale de traitement de l'information (FIPS-140)](ecs-fips-compliance.md). **Important** Le paramètre de compte `fargateFIPSMode` ne peut être modifié qu'à l'aide de l'API Amazon ECS ou de la AWS CLI. Pour de plus amples informations, veuillez consulter [Modification des paramètres de compte Amazon ECS](ecs-modifying-longer-id-settings.md). Exécutez `put-account-setting-default` avec l'option `fargateFIPSMode` définie à `enabled`. Pour plus d'informations, [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)consultez le manuel *Amazon Elastic Container Service API Reference*. + Vous pouvez utiliser la commande suivante pour activer la conformité à la norme FIPS-140. ``` aws ecs put-account-setting-default --name fargateFIPSMode --value enabled ``` Exemple de sortie ``` { "setting": { "name": "fargateFIPSMode", "value": "enabled", "principalArn": "arn:aws:iam::123456789012:root", "type": user } } ``` Vous pouvez exécuter `list-account-settings` pour afficher l'état actuel de conformité à la norme FIPS-140. Utilisez l'option `effective-settings` pour afficher les paramètres au niveau du compte. ``` aws ecs list-account-settings --effective-settings ``` ## Autorisation de balisage Amazon ECS introduit l'autorisation de balisage pour la création de ressources. Les utilisateurs doivent disposer des autorisations d’étiquetage pour les actions qui créent la ressource, telles que `ecsCreateCluster`. Lorsque vous créez une ressource et que vous spécifiez des balises pour cette ressource, AWS effectue une autorisation supplémentaire pour vérifier qu'il existe des autorisations pour créer des balises. Par conséquent, vous devez octroyer des autorisations explicites d'utiliser l'action `ecs:TagResource`. Pour de plus amples informations, veuillez consulter [Octroi de l'autorisation de baliser les ressources lors de la création](supported-iam-actions-tagging.md). Pour activer l'autorisation de balisage, exécutez `put-account-setting-default` avec l'option `tagResourceAuthorization` définie sur `on`. Pour plus d'informations, [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)consultez le manuel *Amazon Elastic Container Service API Reference*. Vous pouvez exécuter `list-account-settings` pour afficher l'état actuel de l'autorisation de balisage. + Vous pouvez utiliser la commande suivante pour activer l’autorisation d’étiquetage. ``` aws ecs put-account-setting-default --name tagResourceAuthorization --value on --region region ``` Exemple de sortie ``` { "setting": { "name": "tagResourceAuthorization", "value": "on", "principalArn": "arn:aws:iam::123456789012:root", "type": user } } ``` Une fois l’adhésion effectuée, vous devez configurer les autorisations appropriées pour permettre aux utilisateurs d’étiqueter les ressources lors de leur création. Pour de plus amples informations, veuillez consulter [Octroi de l'autorisation de baliser les ressources lors de la création](supported-iam-actions-tagging.md). Vous pouvez exécuter `list-account-settings` pour afficher l'état actuel de l'autorisation de balisage. Utilisez l'option `effective-settings` pour afficher les paramètres au niveau du compte. ``` aws ecs list-account-settings --effective-settings ``` ## Chronologie des autorisations de balisage Vous pouvez vérifier si l'autorisation de balisage est active en exécutant `list-account-settings` pour afficher la valeur `tagResourceAuthorization`. Lorsque la valeur est égale à `on`, cela signifie que l'autorisation de balisage est active. Pour plus d'informations, [list-account-settings](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-account-settings.html)consultez le manuel *Amazon Elastic Container Service API Reference*. Voici les dates importantes concernant l'autorisation de balisage. + 18 avril 2023 : introduction de l'autorisation de balisage. Tous les comptes nouveaux et existants doivent adhérer pour utiliser la fonctionnalité. Vous pouvez choisir d’activer l’autorisation d’étiquetage. En adhérant, vous devez octroyer les autorisations appropriées. + 9 février 2024 – 6 mars 2024 : l’autorisation d’étiquetage est activée par défaut pour tous les nouveaux comptes et les comptes existants non concernés. Vous pouvez activer ou désactiver les paramètres du compte `tagResourceAuthorization` pour vérifier votre politique IAM. AWS a notifié les comptes concernés. Pour désactiver la fonctionnalité, exécutez `put-account-setting-default` avec l’option `tagResourceAuthorization` définie sur `off`. + 7 mars 2024 : si vous avez activé l’autorisation d’étiquetage, vous ne pouvez plus désactiver les paramètres du compte. Nous vous recommandons de terminer le test de votre politique IAM avant cette date. + 29 mars 2024 : tous les comptes utilisent l’autorisation d’étiquetage. Le paramètre au niveau du compte ne sera plus disponible dans la console Amazon ECS ou l’ AWS CLI. ## AWS Fargate temps d'attente pour la retraite des tâches AWS envoie des notifications lorsque des tâches Fargate s'exécutent sur une version de la plateforme dont la révision est marquée pour être supprimée. Pour de plus amples informations, veuillez consulter [Retrait et maintenance des tâches pour AWS Fargate sur Amazon ECS](task-maintenance.md). AWS est responsable de l'application des correctifs et de la maintenance de l'infrastructure sous-jacente de AWS Fargate. Lorsqu'il est AWS déterminé qu'une mise à jour de sécurité ou d'infrastructure est nécessaire pour une tâche Amazon ECS hébergée sur Fargate, les tâches doivent être arrêtées et de nouvelles tâches lancées pour les remplacer. Vous pouvez configurer la période d'attente avant que les tâches ne soient retirées pour être corrigées. Vous avez la possibilité de mettre la tâche hors service immédiatement, d’attendre 7 jours calendaires ou d’attendre 14 jours calendaires. Ce paramètre se trouve au niveau du compte. Vous pouvez configurer l'heure à laquelle Fargate commence le retrait des tâches. Le délai d'attente par défaut est de 7 jours. Pour les charges de travail qui nécessitent l'application immédiate des mises à jour, choisissez le paramètre immédiat (`0`). Si vous avez besoin de plus de temps, configurez l'`7`option ou `14` day. Nous vous recommandons de choisir une période d'attente plus courte afin de pouvoir accéder plus rapidement aux nouvelles versions de plateforme. Configurez la période d’attente en exécutant `put-account-setting-default` ou `put-account-setting` en tant qu’utilisateur racine ou utilisateur administratif. Utilisez l'option `fargateTaskRetirementWaitPeriod` pour le `name` et l'option `value` définie sur l'une des valeurs suivantes : + `0`- AWS envoie la notification et commence immédiatement à supprimer les tâches concernées. + `7`- AWS envoie la notification et attend 7 jours calendaires avant de commencer à supprimer les tâches concernées. Il s’agit de l’option par défaut. + `14` : AWS envoie la notification et attend 14 jours calendaires avant de commencer à retirer les tâches concernées. Pour plus d'informations, consultez [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)et consultez le [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)manuel *Amazon Elastic Container Service API Reference*. Vous pouvez exécuter la commande suivante afin de définir le délai d’attente à 14 jours. ``` aws ecs put-account-setting-default --name fargateTaskRetirementWaitPeriod --value 14 ``` Exemple de sortie ``` { "setting": { "name": "fargateTaskRetirementWaitPeriod", "value": "14", "principalArn": "arn:aws:iam::123456789012:root", "type: user" } } ``` Vous pouvez exécuter `list-account-settings` pour afficher le temps d'attente actuel pour retirer la tâche Fargate. Utilisez l'option `effective-settings`. ``` aws ecs list-account-settings --effective-settings ``` ## AWS Fargate suppressions de tâches à l'aide des fenêtres d'événements EC2 AWS est responsable de l'application des correctifs et de la maintenance de l'infrastructure sous-jacente pour AWS Fargate. Quand AWS détermine qu'une mise à jour de sécurité ou d'infrastructure est nécessaire pour une tâche Amazon ECS hébergée sur Fargate, les tâches doivent être arrêtées et de nouvelles tâches lancées pour les remplacer. En activant ce paramètre de compte, AWS Fargate vous utiliserez les fenêtres d'événements EC2 pour déterminer l'heure et le jour auxquels vos tâches seront supprimées. Notez qu'il s'agit d'une activation unique pour un compte. Pour activer l'utilisation des fenêtres d'événements EC2 pour les mises hors service de tâches Fargate, vous pouvez utiliser la commande CLI suivante : ``` aws ecs put-account-setting-default --name fargateEventWindows --value enabled ``` Il s'agit d'un paramètre au niveau du compte. Vous pouvez associer les fenêtres d'événements EC2 aux tâches Fargate au niveau du compte, du cluster et du service à l'aide des balises d'instance suivantes : + `aws:ecs:serviceArn`: pour les tâches de service + `aws:ecs:clusterArn`: pour les tâches appartenant à un cluster + `aws:ecs:fargateTask`: défini sur true pour cibler toutes les tâches Fargate du compte Pour en savoir plus sur le fonctionnement des [fenêtres d'événements Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) pour vos tâches Amazon ECS exécutées sur Fargate, consultez [Étape 1 : définir le temps d'attente des tâches ou utiliser les fenêtres d'événements Amazon EC2](prepare-task-retirement.md#prepare-task-retirement-set-time) ## Augmentation des interfaces réseau des instances de conteneur Linux Les tâches Amazon ECS qui utilisent le mode réseau `awsvpc` reçoivent chacune leur propre interface réseau Elastic (ENI), qui est attachée à l’instance de conteneur qui l’héberge. Le nombre d'interfaces réseau qui peuvent être attachées à des instances Amazon EC2 est limité par défaut et l'interface réseau principale est considérée comme l'une d'elles. Par exemple, par défaut, jusqu'à trois `c5.large` instances peuvent être ENIs associées. L'interface réseau principale de l'instance compte pour une seule, vous pouvez donc en attacher deux autres ENIs à l'instance. Dans la mesure où chaque tâche utilisant le mode réseau `awsvpc` nécessite une ENI, vous ne pouvez généralement exécuter que deux tâches sur ce type d’instance. Amazon ECS prend en charge le lancement d’instances de conteneur avec une augmentation de la densité ENI et utilisant des types d’instances Amazon EC2 pris en charge. Lorsque vous utilisez ces types d'instances et que vous activez le paramètre du `awsvpcTrunking` compte, d'autres ENIs sont disponibles sur les instances de conteneur récemment lancées. Cette configuration vous permet de placer plus de tâches sur chaque instance de conteneur. Par exemple, une instance `c5.large` dotée du paramètre `awsvpcTrunking` dispose d’une limite ENI augmentée à douze. L'instance de conteneur a alors une interface réseau principale. Amazon ECS crée et attache une interface réseau « tronc » à l'instance de conteneur. Par conséquent, cette configuration vous permet de lancer dix tâches sur l'instance de conteneur au lieu des deux tâches actuellement possibles. ## Surveillance du temps d'exécution ( GuardDuty intégration Amazon) Runtime Monitoring est un service intelligent de détection des menaces qui protège les charges de travail exécutées sur les instances de conteneur Fargate et EC2 en AWS surveillant en permanence les journaux et l'activité réseau afin d'identifier les comportements malveillants ou non autorisés. Le `guardDutyActivate` paramètre est en lecture seule dans Amazon ECS et indique si la surveillance du temps d'exécution est activée ou désactivée par votre administrateur de sécurité sur votre compte Amazon ECS. GuardDuty contrôle les paramètres de ce compte en votre nom. Pour plus d’informations, consultez la section [Protection des charges de travail Amazon ECS à l’aide de la surveillance d’exécution](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-guard-duty-integration.html). Vous pouvez exécuter `list-account-settings` pour afficher le paramètre GuardDuty d'intégration actuel. ``` aws ecs list-account-settings ``` Exemple de sortie ``` { "setting": { "name": "guardDutyActivate", "value": "on", "principalArn": "arn:aws:iam::123456789012:doej", "type": aws-managed" } } ``` ## IPv6 VPC à double pile Amazon ECS permet de fournir aux tâches une IPv6 adresse en plus de l' IPv4 adresse privée principale. Pour que les tâches reçoivent une IPv6 adresse, elles doivent utiliser le mode `awsvpc` réseau, être lancées dans un VPC configuré pour le mode double pile et le paramètre du `dualStackIPv6` compte doit être activé. Pour plus d’informations sur les autres exigences, consultez les sections [Utilisation d'un VPC en mode double pile](task-networking-awsvpc.md#task-networking-vpc-dual-stack) pour la capacité EC2, [Utilisation d'un VPC en mode double pile](managed-instances-awsvpc-mode.md#managed-instance-networking-vpc-dual-stack) pour la capacité des instances gérées Amazon ECS et [Utilisation d'un VPC en mode double pile](fargate-task-networking.md#fargate-task-networking-vpc-dual-stack) pour la capacité Fargate. **Important** Le paramètre de compte `dualStackIPv6` ne peut être modifié qu'à l'aide de l'API Amazon ECS ou de la AWS CLI. Pour de plus amples informations, veuillez consulter [Modification des paramètres de compte Amazon ECS](ecs-modifying-longer-id-settings.md). Si une tâche était en cours d'exécution en mode `awsvpc` réseau dans un sous-réseau IPv6 activé entre le 1er octobre 2020 et le 2 novembre 2020, le paramètre de `dualStackIPv6` compte par défaut dans la région dans laquelle la tâche s'exécutait est`disabled`. Si cette condition n'est pas remplie, le paramètre de compte par défaut `dualStackIPv6` dans la région est `enabled`. La valeur par défaut est `disabled`. ## Mode de pilote du journal par défaut Amazon ECS prend en charge la définition d’un mode de livraison par défaut des messages de journal depuis un conteneur vers le pilote de journal choisi. Le mode de livraison affecte la stabilité de l’application lorsque le flux de journaux depuis le conteneur vers le pilote de journal est interrompu. Le paramètre `defaultLogDriverMode` prend en charge deux valeurs : `blocking` et `non-blocking`. Pour plus d'informations sur ces modes de livraison, consultez le [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)manuel *Amazon Elastic Container Service API Reference*. Si vous ne spécifiez aucun mode de livraison dans la `logConfiguration` de votre définition conteneur, le mode que vous spécifiez à l’aide de ce paramètre de compte sera utilisé par défaut. Le mode de livraison par défaut est `non-blocking`. **Note** Le 25 juin 2025, Amazon ECS a modifié le mode par défaut du pilote de journalisation, passant de `blocking` à `non-blocking` afin de privilégier la disponibilité des tâches plutôt que la journalisation. Pour continuer à utiliser le mode `blocking` après cette modification, effectuez l’une des opérations suivantes : Définissez l’option `mode` dans votre définition de conteneur `logConfiguration` sur `blocking`. Réglez le paramètre du compte `defaultLogDriverMode` sur `blocking`. Pour définir un mode de pilote de journal par défaut sur `blocking`, vous pouvez exécuter la commande suivante. ``` aws ecs put-account-setting-default --name defaultLogDriverMode --value "blocking" ``` # Affichage de vos paramètres de compte Amazon ECS à l’aide de la console Affichez les paramètres de votre compte dans la console pour déterminer les fonctionnalités auxquelles vous avez accès. **Important** Les paramètres`dualStackIPv6`,`fargateFIPSMode`, `fargateTaskRetirementWaitPeriod` et du `fargateEventWindows` compte ne peuvent être consultés ou modifiés qu'à l'aide du AWS CLI. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la barre de navigation en haut de l'écran, sélectionnez la région pour laquelle vous souhaitez afficher vos paramètres de compte. 1. Dans la page de navigation, choisissez **Account Settings** (Paramètres du compte). # Modification des paramètres de compte Amazon ECS Modifiez les paramètres de votre compte pour accéder aux fonctionnalités d’Amazon ECS. Le `guardDutyActivate` paramètre est en lecture seule dans Amazon ECS et indique si la surveillance du temps d'exécution est activée ou désactivée par votre administrateur de sécurité sur votre compte Amazon ECS. GuardDuty contrôle les paramètres de ce compte en votre nom. Pour plus d’informations, consultez la section [Protection des charges de travail Amazon ECS à l’aide de la surveillance d’exécution](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-guard-duty-integration.html). **Important** Les paramètres`dualStackIPv6`,`fargateFIPSMode`, `fargateTaskRetirementWaitPeriod` et du `fargateEventWindows` compte ne peuvent être consultés ou modifiés qu'à l'aide du AWS CLI. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la barre de navigation en haut de l'écran, sélectionnez la région pour laquelle vous souhaitez afficher vos paramètres de compte. 1. Dans la page de navigation, choisissez **Account Settings** (Paramètres du compte). 1. Choisissez **Mettre à jour**. 1. **(Facultatif) Pour augmenter ou diminuer le nombre de tâches que vous pouvez exécuter en mode réseau awsvpc pour chaque instance EC2, sous **AWSVPCTrunking, sélectionnez Trunking**. AWSVPC ** 1. (Facultatif) Pour utiliser ou arrêter d'utiliser CloudWatch Container Insights par défaut pour les clusters, sous **Observabilité de CloudWatch Container Insights**, choisissez l'une des options suivantes : + Pour utiliser Container Insights avec observabilité améliorée, choisissez **Container Insights avec observabilité améliorée**. + Pour utiliser Container Insights, choisissez **Container Insights**. + Pour arrêter d’utiliser Container Insights, choisissez **Désactivé**. 1. Pour activer ou désactiver l’autorisation d’étiquetage, sous **Autorisation d’étiquetage des ressources**, sélectionnez ou désélectionnez **Autorisation d’étiquetage des ressources**. 1. (Facultatif) Pour configurer un mode pilote de journal par défaut lorsqu’aucun mode de livraison de journal n’est défini dans la `logConfiguration` d’un conteneur sous **Mode pilote de journal par défaut**, choisissez l’une des options suivantes : + Pour définir le mode pilote de journal par défaut sur `blocking`, choisissez **Blocage**. + Pour définir le mode pilote de journal par défaut sur `non-blocking`, choisissez **Non bloquant**. 1. Sélectionnez **Enregistrer les modifications**. 1. Dans l'écran de confirmation, choisissez **Confirm** (Confirmer) pour enregistrer la sélection. ## Étapes suivantes Si vous avez activé Container Insights avec observabilité améliorée ou Container Insights, vous pouvez éventuellement mettre à jour vos clusters existants pour utiliser cette fonctionnalité. Pour de plus amples informations, veuillez consulter [Mise à jour d’un cluster Amazon ECS.](update-cluster-v2.md). # Restauration des paramètres par défaut du compte Amazon ECS Vous pouvez utiliser le AWS Management Console pour rétablir les paramètres par défaut de votre compte Amazon ECS. L'option **Revert to account default** (Restaurer la valeur par défaut du compte) n'est disponible que lorsque les paramètres de votre compte ne sont plus les paramètres par défaut. 1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2). 1. Dans la barre de navigation en haut de l'écran, sélectionnez la région pour laquelle vous souhaitez afficher vos paramètres de compte. 1. Dans la page de navigation, choisissez **Account Settings** (Paramètres du compte). 1. Choisissez **Mettre à jour**. 1. Choisissez **Revert to account default** (Restaurer la valeur par défaut du compte). 1. Dans l'écran de confirmation, choisissez **Confirm** (Confirmer) pour enregistrer la sélection. # Gestion des paramètres du compte Amazon ECS à l'aide du AWS CLI Vous pouvez gérer les paramètres de votre compte à l'aide de l'API Amazon ECS, AWS CLI ou SDKs. Les paramètres`dualStackIPv6`,`fargateFIPSMode`, `fargateTaskRetirementWaitPeriod` et du `fargateEventWindows` compte ne peuvent être consultés ou modifiés qu'à l'aide de ces outils. **Note** Vous pouvez utiliser des points de terminaison de service à double pile pour interagir avec Amazon ECS à partir de AWS CLI SDKs, et de l'API Amazon ECS via les deux IPv4 et. IPv6 Pour de plus amples informations, veuillez consulter [Utilisation des points de terminaison à double pile Amazon ECS](dual-stack-endpoint.md). Pour plus d'informations sur les actions d'API disponibles pour les définitions de tâches, veuillez consulter [Actions relatives à la configuration du compte](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/OperationList-query-account.html) dans la *Référence de l'API Amazon Elastic Container Service* (langue française non garantie). Utilisez l'une des commandes suivantes pour modifier les paramètres de compte par défaut pour tous les utilisateurs ou rôles de votre compte. Ces modifications s'appliquent à l'ensemble du AWS compte, sauf si un utilisateur ou un rôle remplace explicitement ces paramètres pour lui-même. + [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html) (AWS CLI) ``` aws ecs put-account-setting-default --name serviceLongArnFormat --value enabled --region us-east-2 ``` Vous pouvez également utiliser cette commande pour modifier d'autres paramètres de compte. Pour ce faire, remplacez le paramètre `name` par le paramètre de compte correspondant. + [ECSAccountRéglage de l'écriture](https://docs.aws.amazon.com/powershell/latest/reference/items/Write-ECSAccountSetting.html) (AWS Tools for Windows PowerShell) ``` Write-ECSAccountSettingDefault -Name serviceLongArnFormat -Value enabled -Region us-east-1 -Force ``` **Pour modifier les paramètres de compte pour votre compte utilisateur (AWS CLI)** Utilisez l'une des commandes suivantes pour modifier les paramètres de compte pour votre utilisateur . Si vous utilisez ces commandes en tant qu'utilisateur root, ces modifications s'appliquent à l'ensemble du compte AWS , à moins qu'un utilisateur ou un rôle remplace explicitement ces paramètres pour lui-même. + [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) (AWS CLI) ``` aws ecs put-account-setting --name serviceLongArnFormat --value enabled --region us-east-1 ``` Vous pouvez également utiliser cette commande pour modifier d'autres paramètres de compte. Pour ce faire, remplacez le paramètre `name` par le paramètre de compte correspondant. + [ECSAccountRéglage de l'écriture](https://docs.aws.amazon.com/powershell/latest/reference/items/Write-ECSAccountSetting.html) (AWS Tools for Windows PowerShell) ``` Write-ECSAccountSetting -Name serviceLongArnFormat -Value enabled -Force ``` **Pour modifier les paramètres de compte pour un utilisateur ou un rôle spécifique (AWS CLI)** Utilisez l'une des commandes suivantes et spécifiez dans la requête l'ARN d'un utilisateur, d'un rôle ou de l'utilisateur root pour modifier les paramètres de compte pour un utilisateur ou un rôle spécifique. + [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) (AWS CLI) ``` aws ecs put-account-setting --name serviceLongArnFormat --value enabled --principal-arn arn:aws:iam::aws_account_id:user/principalName --region us-east-1 ``` Vous pouvez également utiliser cette commande pour modifier d'autres paramètres de compte. Pour ce faire, remplacez le paramètre `name` par le paramètre de compte correspondant. + [ECSAccountRéglage de l'écriture](https://docs.aws.amazon.com/powershell/latest/reference/items/Write-ECSAccountSetting.html) (AWS Tools for Windows PowerShell) ``` Write-ECSAccountSetting -Name serviceLongArnFormat -Value enabled -PrincipalArn arn:aws:iam::aws_account_id:user/principalName -Region us-east-1 -Force ``` # Rôles IAM pour Amazon ECS Un rôle IAM est une identité IAM que vous pouvez créer dans votre compte et qui dispose d’autorisations spécifiques. Dans Amazon ECS, vous pouvez créer des rôles pour accorder des autorisations à des ressources Amazon ECS telles que des conteneurs ou des services. Les rôles requis par Amazon ECS dépendent de la définition de tâche, du type de lancement et des fonctionnalités que vous utilisez. Utilisez le tableau suivant pour déterminer quels rôles IAM vous avez besoin pour Amazon ECS. | Role | Définition | En cas de besoin | En savoir plus | | --- | --- | --- | --- | | Rôle d'exécution de tâche | Ce rôle permet à Amazon ECS d'utiliser d'autres AWS services en votre nom. | Votre tâche est hébergée sur AWS Fargate ou sur une instance externe et : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/ecs-iam-role-overview.html) Votre tâche est hébergée sur une instance Amazon EC2 AWS Fargate ou sur une instance Amazon EC2 et : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/ecs-iam-role-overview.html) | [Rôle IAM d'exécution de tâche Amazon ECS](task_execution_IAM_role.md) | | Rôle de tâche | Ce rôle permet au code de votre application (sur le conteneur) d'utiliser d'autres AWS services. | Votre application accède à d'autres AWS services, tels qu'Amazon S3. | [rôle IAM de tâche Amazon ECS](task-iam-roles.md) | | Rôle de l'instance de conteneur | Ce rôle permet à vos instances EC2 ou à vos instances externes de s’enregistrer auprès du cluster. | Votre tâche est hébergée sur des instances Amazon EC2 ou sur une instance externe. | [Rôle IAM d'instance de conteneur Amazon ECS](instance_IAM_role.md) | | Rôle Amazon ECS Anywhere | Ce rôle permet à vos instances externes d'y accéder AWS APIs. | Votre tâche est hébergée sur des instances externes. | [Rôle IAM Amazon ECS Anywhere](iam-role-ecsanywhere.md) | | Rôles d’infrastructure Amazon ECS pour les équilibreurs de charge | Ce rôle permet à Amazon ECS de gérer les ressources de l'équilibreur de charge dans vos clusters en votre nom pour les blue/green déploiements. | Vous souhaitez utiliser les blue/green déploiements Amazon ECS. | [Rôle IAM d’infrastructure Amazon ECS pour les équilibreurs de charge](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) | | CodeDeploy Rôle Amazon ECS | Ce rôle permet CodeDeploy de mettre à jour vos services. | Vous utilisez le type de déploiement CodeDeploy bleu/vert pour déployer des services. | [Rôle CodeDeploy IAM d'Amazon ECS](codedeploy_IAM_role.md) | | EventBridge Rôle Amazon ECS | Ce rôle permet EventBridge de mettre à jour vos services. | Vous utilisez les EventBridge règles et les objectifs pour planifier vos tâches. | [Rôle EventBridge IAM d'Amazon ECS](CWE_IAM_role.md) | | rôle d’infrastructure Amazon ECS | Ce rôle permet à Amazon ECS de gérer les ressources d’infrastructure de vos clusters. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/ecs-iam-role-overview.html) | [Rôle IAM d’infrastructure Amazon ECS](infrastructure_IAM_role.md) | | Profil d’instance | Ce rôle permet aux instances gérées Amazon ECS d’assumer le rôle d’infrastructure en toute sécurité. | Vous utilisez des instances gérées Amazon ECS dans vos clusters. | [Profil d’instance des instances gérées Amazon ECS](managed-instances-instance-profile.md) |