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 AWS Fargate pour Amazon ECS
AWS Fargate est une technologie que vous pouvez utiliser avec Amazon ECS pour exécuter des [conteneurs](https://aws.amazon.com/containers/) sans avoir à gérer des serveurs ou des clusters d'instances Amazon EC2. Avec AWS Fargate, vous n'avez plus besoin d'allouer, de configurer ou de mettre à l'échelle des clusters de machines virtuelles pour exécuter des conteneurs. Vous n'avez plus à choisir de types de serveurs, décider quand mettre à l'échelle vos clusters ni optimiser les packs de clusters.
Lorsque vous exécutez vos tâches et services avec Fargate, vous packagez votre application dans des conteneurs, spécifiez les exigences en matière d’UC et de mémoire, définissez les politiques de mise en réseau et les politiques IAM, puis lancez l’application. Chaque tâche Fargate possède sa propre limite d'isolement et ne partage pas le noyau sous-jacent, les ressources de processeur, les ressources de mémoire ou l'interface réseau Elastic avec une autre tâche. Vous configurez vos définitions de tâches pour Fargate en définissant le paramètre de définition de tâche `requiresCompatibilities` sur `FARGATE`. Pour de plus amples informations, veuillez consulter [Capacity](task_definition_parameters.md#requires_compatibilities).
Fargate propose des versions de plateforme pour Amazon Linux 2 (version de plateforme 1.3.0), le système d’exploitation Bottlerocket (version de plateforme 1.4.0) et Microsoft Windows 2019 Server Full et Core Editions. Sauf indication contraire, les informations s’appliquent à toutes les plateformes Fargate.
Pour de plus amples informations sur les Régions qui prennent en charge les conteneurs Linux sur Fargate, veuillez consulter [Conteneurs Linux sur AWS Fargate](AWS_Fargate-Regions.md#linux-regions).
Pour de plus amples informations sur les Régions qui prennent en charge les conteneurs Windows sur Fargate, veuillez consulter [Conteneurs Windows sur AWS Fargate](AWS_Fargate-Regions.md#windows-regions).
## Procédures
Pour plus d’informations sur la manière de démarrer avec la console, consultez la section :
+ [Création d’une tâche Amazon ECS Linux pour Fargate](getting-started-fargate.md)
+ [Création d’une tâche Windows Amazon ECS pour Fargate](Windows_fargate-getting_started.md)
Pour plus d'informations sur la façon de commencer à utiliser le AWS CLI, voir :
+ [Création d'une tâche Linux Amazon ECS pour le Fargate avec AWS CLI](ECS_AWSCLI_Fargate.md)
+ [Création d'une tâche Windows Amazon ECS pour le Fargate avec AWS CLI](ECS_AWSCLI_Fargate_windows.md)
## Fournisseurs de capacité
Les fournisseurs de capacité suivants sont disponibles :
+ Fargate
+ Fargate Spot : exécutez des tâches Amazon ECS tolérantes aux interruptions à un tarif réduit par rapport au prix AWS Fargate. Fargate Spot exécute les tâches sur la capacité de calcul de réserve. Lorsque vous aurez AWS besoin de retrouver votre capacité, vos tâches seront interrompues par un avertissement de deux minutes. Pour de plus amples informations, veuillez consulter [Clusters Amazon ECS pour Fargate](fargate-capacity-providers.md).
## Définitions de tâche
Les tâches Fargate ne prennent pas en charge tous les paramètres de définition de tâche Amazon ECS disponibles. Certains paramètres ne sont pas du tout pris en charge, tandis que d'autres se comportent différemment pour les tâches Fargate. Pour de plus amples informations, veuillez consulter [UC et mémoire au niveau de la tâche](fargate-tasks-services.md#fargate-tasks-size).
## Versions de plateforme
AWS Les versions de la plate-forme Fargate sont utilisées pour faire référence à un environnement d'exécution spécifique pour l'infrastructure de tâches Fargate. Il s'agit d'une combinaison de la version Kernel et de la version d'exécution du conteneur. Vous sélectionnez une version de plateforme lorsque vous exécutez une tâche ou lorsque vous créez un service pour gérer un certain nombre de tâches identiques.
De nouvelles révisions des versions de plateforme sont publiées au fil de l'évolution de l'environnement d'exécution, par exemple si des mises à jour, de nouvelles fonctionnalités, des corrections de bugs ou des mises à jour de sécurité sont apportées au noyau ou au système d'exploitation. Une version de plateforme Fargate est mise à jour en effectuant une nouvelle révision de la version de plateforme. Chaque tâche s'exécute sur une révision de version de plateforme au cours de son cycle de vie. Si vous souhaitez utiliser la dernière version de plateforme, vous devez démarrer une nouvelle tâche. Une nouvelle tâche exécutée sur Fargate s'exécute toujours sur la dernière version de plateforme, ce qui garantit que les tâches sont toujours lancées sur une infrastructure sécurisée et corrigée.
Si un problème de sécurité affectant une version de plate-forme existante est détecté, AWS crée une nouvelle révision corrigée de la version de plate-forme et met fin aux tâches exécutées sur la version vulnérable. Dans certains cas, vous pouvez être averti que la résiliation de vos tâches sur Fargate a été planifiée. Pour de plus amples informations, veuillez consulter [Retrait et maintenance des tâches pour AWS Fargate sur Amazon ECS](task-maintenance.md).
Pour de plus amples informations, veuillez consulter [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md).
## Équilibrage de charge des services
Vous pouvez configurer votre service Amazon ECS service sur AWS Fargate de manière à utiliser Elastic Load Balancing pour répartir uniformément le trafic entre les tâches de votre service.
Les services Amazon ECS sur AWS Fargate prennent en charge les types d’équilibreurs de charge Application Load Balancer, Network Load Balancer et Gateway Load Balancer. Les équilibreurs de charge d'application sont utilisés pour acheminer le trafic HTTP/HTTPS (ou couche 7). Les équilibreurs de charge Network Load Balancer permettent d'acheminer le trafic TCP ou UDP (ou couche 4). Pour de plus amples informations, veuillez consulter [Utilisation de l’équilibrage de charge pour répartir le trafic des services Amazon ECS](service-load-balancing.md).
De même, lorsque vous créez des groupes cible pour ces services, vous devez choisir le type de cible `ip`, et non `instance`. Cela est dû au fait que les tâches qui utilisent le mode réseau `awsvpc` sont associées à une interface réseau Elastic et non à une instance Amazon EC2. Pour de plus amples informations, veuillez consulter [Utilisation de l’équilibrage de charge pour répartir le trafic des services Amazon ECS](service-load-balancing.md).
L'utilisation d'un Network Load Balancer pour acheminer le trafic UDP vers votre Amazon ECS sur les tâches AWS Fargate n'est prise en charge que lors de l'utilisation de la plateforme version 1.4 ou ultérieure.
## Métriques d’utilisation
Vous pouvez utiliser les statistiques CloudWatch d'utilisation pour obtenir une visibilité sur l'utilisation des ressources de votre compte. Utilisez ces indicateurs pour visualiser l'utilisation actuelle de vos services sur CloudWatch des graphiques et des tableaux de bord.
AWS Fargate les métriques d'utilisation correspondent aux quotas AWS de service. Vous pouvez configurer des alarmes qui vous alertent lorsque votre utilisation approche d’un quota de service. Pour plus d’informations sur les quotas de service AWS Fargate, consultez la section [Points de terminaison et quotas Amazon ECS](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html) dans la *Référence générale d'Amazon Web Services*.
Pour plus d'informations sur les mesures AWS Fargate d'utilisation, consultez la section [Mesures AWS Fargate d'utilisation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-fargate-usage.html).
# Considérations relatives à la sécurité d’Amazon ECS concernant l’utilisation de Fargate
Nous recommandons aux clients qui recherchent une isolation forte pour leurs tâches d’utiliser Fargate. Fargate exécute chaque tâche dans un environnement de virtualisation matérielle. Cela garantit que ces charges de travail conteneurisées ne partagent pas les interfaces réseau, le stockage éphémère Fargate, l’UC ou la mémoire avec d’autres tâches. Pour plus d'informations, consultez [la section Présentation de la sécurité de AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf).
# Pratiques exemplaires en matière de sécurité Fargate dans Amazon ECS
Nous vous recommandons de prendre en compte les bonnes pratiques ci-dessous lorsque vous utilisez AWS Fargate. Pour obtenir des conseils supplémentaires, consultez [la section Présentation de la sécurité de AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf).
## AWS KMS À utiliser pour chiffrer le stockage éphémère pour Fargate
Votre stockage éphémère doit être chiffré à l'aide de clés gérées par le client AWS KMS ou de vos propres clés. Pour les tâches hébergées sur Fargate à l’aide de la version de plateforme `1.4.0` ou ultérieure, chaque tâche bénéficie de 20 Gio de stockage éphémère. Pour plus d’informations, consultez la section [Clé gérée par le client (CMK)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html). Vous pouvez augmenter la quantité totale de stockage éphémère, jusqu'à un maximum de 200 Gio, en spécifiant le paramètre `ephemeralStorage` dans votre définition de tâche. Pour les tâches lancées le 28 mai 2020 ou plus tard, le stockage éphémère est chiffré à l’aide d’un algorithme de chiffrement AES-256 avec une clé de chiffrement gérée par Fargate.
Pour plus d’informations, consultez la section [Options de stockage pour les tâches Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html).
**Exemple : lancement d’une tâche sur la version de plateforme Fargate 1.4.0 avec chiffrement du stockage éphémère**
La commande suivante lancera une tâche Amazon ECS sur la version de plateforme Fargate 1.4. Cette tâche étant lancée dans le cadre du cluster, elle utilise les 20 Gio de stockage éphémère qui sont automatiquement soumis au chiffrement.
```
aws ecs run-task --cluster clustername \
--task-definition taskdefinition:version \
--count 1
--launch-type "FARGATE" \
--platform-version 1.4.0 \
--network-configuration "awsvpcConfiguration={subnets=[subnetid],securityGroups=[securitygroupid]}" \
--region region
```
## Fonctionnalité SYS\$1PTRACE pour le suivi des appels système du noyau avec Fargate
La configuration par défaut des fonctionnalités Linux ajoutées ou supprimées de votre conteneur est fournie par Docker.
Les tâches lancées sur Fargate ne prennent en charge que l'ajout de la capacité du noyau `SYS_PTRACE`.
La vidéo suivante montre comment utiliser cette fonctionnalité via le projet Sysdig [Falco](https://github.com/falcosecurity/falco).
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/OYGKjmFeLqI)
Le code décrit dans la vidéo précédente se trouve GitHub [ici](https://github.com/paavan98pm/ecs-fargate-pv1.4-falco).
## Utilisez Amazon GuardDuty avec Fargate Runtime Monitoring
Amazon GuardDuty est un service de détection des menaces qui aide à protéger vos comptes, vos conteneurs, vos charges de travail et les données de votre AWS environnement. À l'aide de modèles d'apprentissage automatique (ML) et de capacités de détection des anomalies et des menaces, vous surveillez GuardDuty en permanence les différentes sources de journaux et l'activité d'exécution afin d'identifier et de hiérarchiser les risques de sécurité potentiels et les activités malveillantes dans votre environnement.
La surveillance du temps d'exécution GuardDuty protège les charges de travail exécutées sur Fargate en AWS surveillant en permanence l'activité des journaux et du réseau afin d'identifier les comportements malveillants ou non autorisés. Runtime Monitoring utilise un agent de GuardDuty sécurité léger et entièrement géré qui analyse le comportement sur l'hôte, tel que l'accès aux fichiers, l'exécution des processus et les connexions réseau. Cela couvre des problèmes tels que l’escalade des privilèges, l’utilisation d’identifiants exposés ou la communication avec des adresses IP et des domaines malveillants, ainsi que la présence de logiciels malveillants sur vos instances Amazon EC2 et vos charges de travail conteneurisées. Pour plus d'informations, consultez la section [Surveillance du temps GuardDuty d'exécution](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) dans le *guide de GuardDuty l'utilisateur*.
# Considérations relatives à la sécurité Fargate pour Amazon ECS
Chaque tâche dispose d'une capacité d'infrastructure dédiée, car Fargate exécute chaque charge de travail dans un environnement virtuel isolé. Les charges de travail exécutées sur Fargate ne partagent pas les interfaces réseau, le stockage éphémère, le processeur ou la mémoire avec d'autres tâches. Vous pouvez exécuter plusieurs conteneurs au sein d'une même tâche, notamment des conteneurs d'applications et des conteneurs sidecar, ou simplement des sidecars. Un *sidecar* est un conteneur qui s'exécute parallèlement à un conteneur d'application dans une tâche Amazon ECS. Alors que le conteneur d'applications exécute le code de base de l'application, les processus exécutés dans des sidecars peuvent enrichir l'application. Les sidecars vous aident à séparer les fonctions de l'application dans des conteneurs dédiés, ce qui facilite la mise à jour de certaines parties de votre application.
Les conteneurs qui font partie de la même tâche partagent les ressources pour le type de lancement Fargate, car ces conteneurs s’exécutent toujours sur le même hôte et partagent les ressources de calcul. Ces conteneurs partagent également le stockage éphémère fourni par Fargate. Les conteneurs Linux d'une tâche partagent des espaces de noms réseau, notamment l'adresse IP et les ports réseau. À l'intérieur d'une tâche, les conteneurs appartenant à la tâche peuvent communiquer entre eux via l'hôte local.
L'environnement d'exécution de Fargate vous empêche d'utiliser certaines fonctionnalités du contrôleur prises en charge sur les instances EC2. Tenez compte des éléments suivants lorsque vous concevez des charges de travail qui s'exécutent sur Fargate :
+ Aucun conteneur ou accès privilégié : les fonctionnalités telles que les conteneurs ou l'accès privilégié ne sont actuellement pas disponibles sur Fargate. Cela affectera les cas d'utilisation tels que l'exécution de Docker dans Docker.
+ Accès limité aux fonctionnalités de Linux : l'environnement dans lequel les conteneurs s'exécutent sur Fargate est verrouillé. Les fonctionnalités Linux supplémentaires, telles que CAP\$1SYS\$1ADMIN et CAP\$1NET\$1ADMIN, sont limitées afin d'empêcher une escalade des privilèges. Fargate prend en charge l'ajout de la fonctionnalité Linux [CAP\$1SYS\$1PTRACE](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params) aux tâches afin de permettre aux outils d'observabilité et de sécurité déployés dans le cadre de la tâche de surveiller l'application conteneurisée.
+ Aucun accès à l'hôte sous-jacent : ni les clients ni AWS les opérateurs ne peuvent se connecter à un hôte exécutant les charges de travail des clients. Vous pouvez utiliser ECS Exec pour exécuter des commandes dans ou obtenir un shell vers un conteneur s'exécutant sur Fargate. Vous pouvez utiliser ECS Exec pour collecter des informations de diagnostic pour le débogage. Fargate empêche également les conteneurs d'accéder aux ressources de l'hôte sous-jacent, telles que le système de fichiers, les périphériques, la mise en réseau et l'environnement d'exécution du conteneur.
+ Mise en réseau : vous pouvez utiliser les groupes de sécurité et ACLs le réseau pour contrôler le trafic entrant et sortant. Les tâches Fargate reçoivent une adresse IP depuis le sous-réseau configuré de votre VPC.
# Versions de plateforme Fargate pour Amazon ECS
AWS Les versions de la plate-forme Fargate sont utilisées pour faire référence à un environnement d'exécution spécifique pour l'infrastructure de tâches Fargate. Il s'agit d'une combinaison de la version Kernel et de la version d'exécution du conteneur. Vous sélectionnez une version de plateforme lorsque vous exécutez une tâche ou lorsque vous créez un service pour gérer un certain nombre de tâches identiques.
De nouvelles révisions des versions de plateforme sont publiées au fil de l'évolution de l'environnement d'exécution, par exemple si des mises à jour, de nouvelles fonctionnalités, des corrections de bugs ou des mises à jour de sécurité sont apportées au noyau ou au système d'exploitation. Une version de plateforme Fargate est mise à jour en effectuant une nouvelle révision de la version de plateforme. Chaque tâche s'exécute sur une révision de version de plateforme au cours de son cycle de vie. Si vous souhaitez utiliser la dernière version de plateforme, vous devez démarrer une nouvelle tâche. Une nouvelle tâche exécutée sur Fargate s'exécute toujours sur la dernière version de plateforme, ce qui garantit que les tâches sont toujours lancées sur une infrastructure sécurisée et corrigée.
Si un problème de sécurité affectant une version de plate-forme existante est détecté, AWS crée une nouvelle révision corrigée de la version de plate-forme et met fin aux tâches exécutées sur la version vulnérable. Dans certains cas, vous pouvez être averti que la résiliation de vos tâches sur Fargate a été planifiée. Pour de plus amples informations, veuillez consulter [Retrait et maintenance des tâches pour AWS Fargate sur Amazon ECS](task-maintenance.md).
La version de plateforme est spécifiée lors de l’exécution d’une tâche ou du déploiement d’un service.
Tenez compte des éléments suivants lorsque vous spécifiez une version de plateforme :
+ Vous pouvez spécifier un numéro de version spécifique, par exemple `1.4.0` ou `LATEST`.
La **DERNIÈRE** version de plateforme Linux est `1.4.0`.
La **DERNIÈRE** version de plateforme Windows est `1.0.0`.
+ Si vous souhaitez mettre à jour la version de plateforme d'un service, créez un déploiement. Par exemple, supposons que vous ayez un service qui exécute des tâches sur la version de plateforme Linux `1.3.0`. Pour modifier le service afin d’exécuter des tâches sur la version de plateforme Linux `1.4.0`, mettez à jour votre service et spécifiez une nouvelle version de plateforme. Vos tâches sont redéployées avec la dernière version de plateforme et la dernière révision de la version de plateforme. Pour de plus amples informations sur les déploiements, veuillez consulter [Services Amazon ECS](ecs_services.md).
+ Si votre service est mis à l'échelle sans que la version de plateforme soit mise à jour, ces tâches reçoivent la version de plateforme spécifiée dans le déploiement actuel de ce service. Par exemple, supposons que vous ayez un service qui exécute des tâches sur la version de plateforme Linux `1.3.0`. Si vous augmentez le nombre souhaité de services, le planificateur de services lance les nouvelles tâches en utilisant la dernière version de plateforme, révision de la version de plateforme `1.3.0`.
+ Les nouvelles tâches s’exécutent toujours sur la dernière révision d’une version de plateforme. Cela garantit que les tâches sont toujours exécutées sur une infrastructure sécurisée et mise à jour.
+ Les numéros de version de plateforme pour les conteneurs Linux et les conteneurs Windows sur Fargate sont indépendants. Par exemple, le comportement, les fonctionnalités et les logiciels utilisés dans la version de plateforme `1.0.0` pour les conteneurs Windows sur Fargate ne sont pas comparables à ceux de la version de plateforme `1.0.0` pour les conteneurs Linux sur Fargate.
+ Ce qui suit s’applique aux versions de plateforme Windows Fargate.
Les images de conteneur Microsoft Windows Server doivent être créées à partir d'une version spécifique de Windows Server. Vous devez sélectionner la même version de Windows Server dans la `platformFamily` lorsque vous exécutez une tâche ou créez un service correspondant à l'image du conteneur Windows Server. En outre, vous pouvez fournir une correspondance `operatingSystemFamily` dans la définition de tâche afin d'éviter que les tâches ne soient exécutées sur la mauvaise version de Windows. Pour plus d'informations, veuillez consulter [Correspondance de la version d'hôte de conteneur avec les versions des images de conteneur](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility#matching-container-host-version-with-container-image-versions) sur le site Web de Microsoft Learn.
# Migration vers la version de plateforme Linux 1.4.0 sur Amazon ECS
Tenez compte des éléments suivants lors de la migration de vos tâches Amazon ECS sur Fargate à partir de la version `1.0.0`, `1.1.0`, `1.2.0` ou `1.3.0` de la plateforme vers la version `1.4.0`. Il est recommandé de vérifier que votre tâche fonctionne correctement sur la version de plateforme `1.4.0` avant de procéder à la migration des tâches.
+ Le comportement du trafic réseau entrant et sortant entre les tâches a été mis à jour. À partir de la version de plateforme 1.4.0, toutes les tâches Amazon ECS sur Fargate reçoivent une interface réseau Elastic (appelée ENI de tâche) unique et tout le trafic réseau transite par cette ENI au sein de votre VPC. Le trafic est visible dans les journaux de flux de votre VPC. Pour de plus amples informations, veuillez consulter [Options de mise en réseau des tâches Amazon ECS pour Fargate](fargate-task-networking.md).
+ Si vous utilisez des points de terminaison de VPC d’interface, tenez compte des éléments suivants.
+ Pour les images de conteneur hébergées avec Amazon ECR, vous avez besoin des points de terminaison suivants. Pour plus d'informations, consultez [Points de terminaison d'un VPC d'interface Amazon ECR (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) dans le *Guide de l'utilisateur Amazon Elastic Container Registry*.
+ **com.amazonaws. *region*.ecr.dkr Point de terminaison VPC** Amazon ECR
+ **com.amazonaws. *region*.ecr.api Point de terminaison VPC** Amazon ECR
+ Point de terminaison de la passerelle Amazon S3
+ Lorsque votre définition de tâche fait référence aux secrets Secrets Manager pour récupérer des données sensibles pour vos conteneurs, vous devez créer les points de terminaison de VPC d’interface pour Secrets Manager. Pour de plus amples informations, veuillez consulter [Utilisation de Secrets Manager avec des points de terminaison de VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html) dans le *Guide de l'utilisateur AWS Secrets Manager *.
+ Lorsque votre définition de tâche fait référence aux paramètres du magasin de paramètres Systems Manager pour récupérer des données sensibles pour vos conteneurs, vous devez créer les points de terminaison de VPC d’interface pour Systems Manager. Pour plus d’informations, consultez la section [Amélioration de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) dans le *Guide de l’utilisateur AWS Systems Manager *.
+ Le groupe de sécurité pour l’interface réseau Elastic (ENI) associé à votre tâche a besoin des règles du groupe de sécurité pour autoriser le trafic entre la tâche et les points de terminaison de VPC.
# Journal des modifications de la version de plateforme Linux Fargate
Les versions de plateforme Linux suivantes sont proposées. Pour obtenir des informations sur l'obsolescence des versions de plateforme, consultez [AWS Version obsolète de la plateforme Fargate Linux](platform-versions-retired.md).
## 1.4.0
Voici le journal des modifications de la version `1.4.0` de la plateforme.
+ Depuis le 5 novembre 2020, toute nouvelle tâche Amazon ECS lancée sur Fargate en utilisant la version `1.4.0` de la plateforme peut utiliser les fonctions suivantes :
+ Lorsque vous utilisez Secrets Manager pour stocker des données sensibles, vous pouvez injecter une clé JSON spécifique ou une version spécifique d'un secret en tant que variable d'environnement ou dans une configuration de journal. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md).
+ Spécifiez les variables d'environnement en bloc à l'aide du paramètre de définition de conteneur `environmentFiles`. Pour de plus amples informations, veuillez consulter [Transmission d’une variable d’environnement individuelle à un conteneur Amazon ECS](taskdef-envfiles.md).
+ Les tâches exécutées dans un VPC et un sous-réseau activé pour IPv6 se verront attribuer à la fois une IPv4 adresse privée et une adresse. IPv6 Pour plus d’informations, consultez la section [Options de mise en réseau des tâches Amazon ECS pour Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html).
+ Le point de terminaison de métadonnées de tâche version 4 fournit des métadonnées supplémentaires sur votre tâche et conteneur, y compris le type de lancement de tâche, l'Amazon Resource Name (ARN) du conteneur, ainsi que le pilote de journal et les options de pilote de journal utilisés. Lors de l'interrogation du point de terminaison `/stats`, vous recevez également des statistiques de débit réseau pour vos conteneurs. Pour plus d’informations, consultez la section [Point de terminaison des métadonnées de tâche, version 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html).
+ Depuis le 30 juillet 2020, toute nouvelle tâche Amazon ECS lancée sur Fargate en utilisant la version `1.4.0` de la plateforme peut acheminer le trafic UDP à l'aide d'un Network Load Balancer vers Amazon ECS sur les tâches Fargate. Pour de plus amples informations, veuillez consulter [Utilisation de l’équilibrage de charge pour répartir le trafic des services Amazon ECS](service-load-balancing.md).
+ À compter du 28 mai 2020, toute nouvelle tâche Amazon ECS lancée sur Fargate à l'aide de la `1.4.0` version de la plateforme verra son stockage éphémère chiffré à l'aide d'un algorithme de chiffrement AES-256 utilisant une clé de chiffrement propriétaire. AWS Pour plus d’informations, consultez [Stockage éphémère des tâches Fargate pour Amazon ECS](fargate-task-storage.md) et [Options de stockage pour les tâches Amazon ECS](using_data_volumes.md).
+ Ajout de la prise en charge de l'utilisation des volumes de système de fichiers Amazon EFS pour le stockage des tâches permanentes. Pour de plus amples informations, veuillez consulter [Utilisation des volumes Amazon EFS avec Amazon ECS](efs-volumes.md).
+ Le stockage des tâches éphémères est désormais d'au moins 20 Go pour chaque tâche. Pour de plus amples informations, veuillez consulter [Stockage éphémère des tâches Fargate pour Amazon ECS](fargate-task-storage.md).
+ Le comportement du trafic réseau entrant et sortant entre les tâches a été mis à jour. À partir de la version 1.4.0 de la plateforme, toutes les tâches Fargate reçoivent une interface réseau Elastic unique (appelée ENI de tâche), et tout le trafic réseau passe par cette ENI au sein du VPC et vous est accessible via les journaux de vos flux VPC. Pour plus d’informations sur la mise en réseau pour le type de lancement Amazon EC2, consultez la section [Options de mise en réseau des tâches Amazon ECS pour EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). Pour plus d’informations sur la mise en réseau pour Fargate, consultez la section [Options de mise en réseau des tâches Amazon ECS pour Fargate](fargate-task-networking.md).
+ Tâche : ENIs ajouter un support pour les cadres jumbo. Les interfaces réseau sont configurées avec une unité de transmission maximale (MTU), qui correspond à la taille de la charge utile la plus élevée possible dans une seule trame. Plus la MTU est importante, plus la charge utile de l'application peut s'intégrer dans une seule trame. Cela réduit les frais généraux par trame et augmente l'efficacité. La prise en charge des trames jumbo limite la surcharge lorsque le chemin réseau entre votre tâche et la destination prend en charge les trames jumbo, telles que tout le trafic qui reste dans votre VPC.
+ CloudWatch Container Insights inclura des mesures de performance réseau pour les tâches Fargate. Pour de plus amples informations, veuillez consulter [Surveillance des conteneurs Amazon ECS au moyen de Container Insights avec observabilité améliorée](cloudwatch-container-insights.md).
+ Ajout de la prise en charge du point de terminaison de métadonnées de tâche version 4, qui fournit des informations supplémentaires pour vos tâches Fargate, y compris les statistiques réseau pour la tâche et la zone de disponibilité dans laquelle la tâche s'exécute. Pour plus d’informations, consultez [Point de terminaison des métadonnées de tâches Amazon ECS version 4](task-metadata-endpoint-v4.md) et [Point de terminaison des métadonnées de tâches Amazon ECS version 4 pour les tâches sur Fargate](task-metadata-endpoint-v4-fargate.md).
+ Ajout de la prise en charge du paramètre `SYS_PTRACE` Linux dans les définitions de conteneur. Pour de plus amples informations, veuillez consulter [Paramètres Linux](task_definition_parameters.md#container_definition_linuxparameters).
+ L'agent de conteneur Fargate remplace l'agent de conteneur Amazon ECS pour toutes les tâches Fargate. Généralement, cette modification ne devrait pas avoir d'effet sur la façon dont vos tâches s'exécutent.
+ L'environnement d'exécution du conteneur utilise maintenant Containerd au lieu de Docker. Dans la plupart des cas, cette modification ne devrait pas avoir d'effet sur la façon dont vos tâches s'exécutent. Vous remarquerez que certains messages d'erreur provenant de l'environnement d'exécution du conteneur mentionnent de moins en moins Docker et de en plus des erreurs générales. Pour plus d’informations, consultez la section [Messages d’erreur liés aux tâches Amazon ECS arrêtées](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html).
+ Basée sur Amazon Linux 2.
# AWS Version obsolète de la plateforme Fargate Linux
**Important**
Nous mettrons fin au support de PV 1.3.0 à Fargate le 30 juin 2026. À compter du 15 juin 2026, nous ferons de la version 1.3.0 de la plateforme une version retirée. À ce moment-là, vous ne serez pas en mesure de lancer de nouvelles tâches ou de créer de services configurés avec la version de plateforme 1.3.0, mais vos tâches existantes continueront de s’exécuter. Le 30 juin 2026, nous mettrons fin à toutes les tâches en cours d'exécution restantes configurées avec la version 1.3.0 de la plateforme.
Pour plus d’informations sur la migration vers la version de plateforme 1.4, consultez la section [Migration vers la version de plateforme Linux 1.4.0 sur Amazon ECS](platform-version-migration.md).
Le tableau suivant répertorie les versions de la plate-forme Linux que AWS Fargate a déconseillées ou dont l'obsolescence a été planifiée. Ces versions de plateforme restent disponibles jusqu'à la date d'obsolescence publiée.
Une *date de mise à jour forcée* est fournie pour chaque version de plateforme dont l'obsolescence est programmée. À la date de mise à jour forcée, tout service utilisant la version de plateforme `LATEST` qui est indiquée comme une version dont l'obsolescence est programmée sera mise à jour à l'aide de l'option Forcer le nouveau déploiement. Lorsque le service est mis à jour à l'aide de l'option Forcer le nouveau déploiement, toutes les tâches exécutées sur une version de plateforme dont l'obsolescence est programmée sont arrêtées et de nouvelles tâches sont lancées à l'aide de la version de plateforme que la balise `LATEST` indique à ce moment. Les tâches ou services autonomes avec un jeu de version de plateforme explicite ne sont pas affectés par la date de mise à jour forcée.
Pour plus d’informations sur la migration vers la dernière version de plateforme, consultez la section [Migration vers la version de plateforme Linux 1.4.0 sur Amazon ECS](platform-version-migration.md).
Une fois qu’une version de plateforme atteint sa *date d’obsolescence*, la version de plateforme ne sera plus disponible pour de nouvelles tâches ou services. Toutes les tâches ou services autonomes qui utilisent explicitement une version de plateforme obsolète continueront d'utiliser cette version de plateforme jusqu'à ce que les tâches soient arrêtées. Après la date d'obsolescence, une version de plateforme obsolète ne recevra plus de mises à jour de sécurité ou de corrections de bugs.
| Version de plateforme | Date de mise à jour forcée | Date d'obsolescence |
| --- | --- | --- |
| 1.0.0 | 26 octobre 2020 | 14 décembre 2020 |
| 1.1.0 | 26 octobre 2020 | 14 décembre 2020 |
| 1.2.0 | 26 octobre 2020 | 14 décembre 2020 |
| 1.3.0 | | 15 juin 2026 |
Pour obtenir des informations sur les versions de plateforme actuelles, consultez [Versions de plateforme Fargate pour Amazon ECS](platform-fargate.md).
## Journal des modifications des versions obsolètes de Fargate Linux
### 1.3.0
Voici le journal des modifications de la version `1.3.0` de la plateforme.
+ Depuis le 30 septembre 2019, toute nouvelle tâche Fargate lancée prend en charge le pilote de journal `awsfirelens`. Configurez le FireLens pour qu'Amazon ECS utilise les paramètres de définition des tâches pour acheminer les journaux vers un AWS service ou une destination du réseau de AWS partenaires (APN) à des fins de stockage et d'analyse des journaux. Pour de plus amples informations, veuillez consulter [Envoyer les journaux Amazon ECS à un AWS service ou AWS Partner](using_firelens.md).
+ Ajout du recyclage de tâche pour les tâches Fargate, qui est le processus d'actualisation des tâches qui font partie d'un service Amazon ECS service. Pour plus d'informations, consultez [la section Retrait et maintenance des tâches pour AWS Fargate sur Amazon ECS.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-maintenance.html)
+ Depuis le 27 mars 2019, toute nouvelle tâche Fargate lancée peut utiliser des paramètres de définition de tâche supplémentaires qui vous permettent de définir une configuration proxy, des dépendances de démarrage et d'arrêt de conteneurs, ainsi qu'une valeur de temporisation d'arrêt et de démarrage par conteneur. Pour plus d’informations, consultez [Configuration du proxy](task_definition_parameters.md#proxyConfiguration), [Dépendances du conteneur](task_definition_parameters.md#container_definition_dependson) et [Temporisations de conteneurs](task_definition_parameters.md#container_definition_timeout).
+ À compter du 2 avril 2019, toute nouvelle tâche Fargate lancée prend en charge l'injection de données sensibles dans vos conteneurs en stockant vos données sensibles dans des secrets AWS Secrets Manager AWS Systems Manager ou dans des paramètres Parameter Store, puis en les référençant dans la définition de votre conteneur. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md).
+ Depuis le 1er mai 2019, toute nouvelle tâche Fargate lancée prend en charge le référencement des données sensibles dans la configuration de journal d'un conteneur à l'aide du paramètre de définition de conteneur `secretOptions`. Pour de plus amples informations, veuillez consulter [Transmission de données sensibles vers un conteneur Amazon ECS](specifying-sensitive-data.md).
+ Depuis le 1er mai 2019, toute nouvelle tâche Fargate lancée prend en charge le pilote de journal `splunk` en plus du pilote de journal `awslogs`. Pour de plus amples informations, veuillez consulter [Stockage et journalisation](task_definition_parameters.md#container_definition_storage).
+ À compter du 9 juillet 2019, toutes les nouvelles tâches Fargate lancées CloudWatch seront prises en charge par Container Insights. Pour de plus amples informations, veuillez consulter [Surveillance des conteneurs Amazon ECS au moyen de Container Insights avec observabilité améliorée](cloudwatch-container-insights.md).
+ Depuis le 3 décembre 2019, le fournisseur de capacité Fargate Spot est pris en charge. Pour de plus amples informations, veuillez consulter [Clusters Amazon ECS pour Fargate](fargate-capacity-providers.md).
+ Basée sur Amazon Linux 2.
### 1.2.0
Voici le journal des modifications de la version `1.2.0` de la plateforme.
**Note**
La version de plateforme `1.2.0` n’est plus disponible. Pour obtenir des informations sur l'obsolescence des versions de plateforme, consultez [AWS Version obsolète de la plateforme Fargate Linux](#platform-versions-retired).
+ Ajout du support pour l'authentification du registre privé à l'aide de AWS Secrets Manager. Pour de plus amples informations, veuillez consulter [Utilisation d'images autres que des AWS conteneurs dans Amazon ECS](private-auth.md).
### 1.1.0
Voici le journal des modifications de la version `1.1.0` de la plateforme.
**Note**
La version de plateforme `1.1.0` n’est plus disponible. Pour obtenir des informations sur l'obsolescence des versions de plateforme, veuillez consulter [AWS Version obsolète de la plateforme Fargate Linux](#platform-versions-retired).
+ Ajout de la prise en charge du point de terminaison des métadonnées de tâches Amazon ECS. Pour de plus amples informations, veuillez consulter [Métadonnées de tâches Amazon ECS disponibles pour les tâches sur Fargate](fargate-metadata.md).
+ Ajout de la prise en charge des surveillances de l'état Docker dans les définitions de conteneur. Pour de plus amples informations, veuillez consulter [Surveillance de l'état](task_definition_parameters.md#container_definition_healthcheck).
+ Ajout de la prise en charge de la découverte de service Amazon ECS service. Pour de plus amples informations, veuillez consulter [Utilisation de la découverte de service pour connecter les services Amazon ECS avec des noms DNS](service-discovery.md).
### 1.0.0
Voici le journal des modifications de la version `1.0.0` de la plateforme.
**Note**
La version de plateforme `1.0.0` n’est plus disponible. Pour obtenir des informations sur l'obsolescence des versions de plateforme, veuillez consulter [AWS Version obsolète de la plateforme Fargate Linux](#platform-versions-retired).
+ Basée sur Amazon Linux 2017.09.
+ Première version.
# Journal des modifications de la version de plateforme Windows Fargate
Les versions de plateforme pour les conteneurs Windows suivantes sont proposées.
## 1.0.0
Voici le journal des modifications de la version `1.0.0` de la plateforme.
+ Version initiale pour la prise en charge des systèmes d'exploitation Microsoft Windows Server suivants :
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
# Considérations sur les conteneurs Windows sur Fargate pour Amazon ECS
Voici les différences et les considérations à prendre en compte lorsque vous exécutez des conteneurs Windows sur AWS Fargate.
Si vous devez exécuter des tâches sur des conteneurs Linux et Windows, vous devez créer des définitions de tâches distinctes pour chaque système d’exploitation.
AWS gère la gestion des licences du système d'exploitation, vous n'avez donc pas besoin de licences Microsoft Windows Server supplémentaires.
Les conteneurs Windows sur AWS Fargate sont compatibles avec les systèmes d'exploitation suivants :
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
Les conteneurs Windows de AWS Fargate prennent en charge le pilote awslogs. Pour de plus amples informations, veuillez consulter [Envoyez les journaux Amazon ECS à CloudWatch](using_awslogs.md).
Les fonctionnalités suivantes ne sont pas prises en charge sur les conteneurs Windows sur Fargate :
+ Amazon FSx
+ Jonction ENI
+ g MSAs pour Windows Containers
+ Les intégrations du service App Mesh et du proxy pour les tâches
+ L'intégration du routeur journal Firelens pour les tâches
+ Les volumes EFS
+ Volumes EBS
+ Les paramètres de définition de tâche suivants :
+ `maxSwap`
+ `swappiness`
+ `environmentFiles`
+ Le fournisseur de capacités Fargate Spot
+ Les volumes d'images
L'option Dockerfile `volume` est ignorée. Au lieu de cela, utilisez des montages liés dans votre définition de tâche. Pour de plus amples informations, veuillez consulter [Utilisation de montages liés avec Amazon ECS](bind-mounts.md).
+ Les paramètres d’UC et de mémoire au niveau des tâches sont ignorés pour les conteneurs Windows. Nous vous recommandons de spécifier des ressources de niveau conteneur pour les conteneurs Windows.
+ Mémoire pour la tâche
+ Réservation de mémoire sur les conteneurs
+ Politiques de redémarrage relatives aux conteneurs
+ Vous ne pouvez pas mettre à jour la famille de plateformes d’un service.
# Comportement d’extraction d’image de conteneur Linux sur Fargate pour Amazon ECS
Chaque tâche Fargate s’exécute sur sa propre instance à usage unique et à locataire unique. Lorsque vous exécutez des conteneurs Linux sur Fargate, les images de conteneurs ou les couches d’images de conteneurs ne sont pas mises en cache sur l’instance. Par conséquent, pour chaque image de conteneur définie dans la tâche, l’image de conteneur complète doit être extraite du registre d’images de conteneur pour chaque tâche Fargate. Le temps nécessaire pour extraire les images est directement corrélé au temps nécessaire pour démarrer une tâche Fargate.
Tenez compte des points suivants pour optimiser le temps d’extraction de l’image.
**Proximité des images du conteneur**
Pour réduire le temps nécessaire au téléchargement des images du conteneur, localisez les données le plus près possible du calcul. Le transfert d'une image de conteneur sur Internet ou sur Internet Régions AWS peut avoir un impact sur le temps de téléchargement. Nous vous recommandons de stocker l’image du conteneur dans la même région que celle où la tâche sera exécutée. Si vous stockez l’image du conteneur dans Amazon ECR, utilisez un point de terminaison de VPC d’interface pour réduire davantage le temps d’extraction de l’image. Pour de plus amples informations, consultez la section [Points de terminaison de VPC d’interface (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) dans le *Guide de l’utilisateur Amazon VPC*.
**Réduction de la taille de l’image du conteneur**
La taille d’une image de conteneur a un impact direct sur le temps de téléchargement. La réduction de la taille de l’image du conteneur ou du nombre de couches de l’image du conteneur peut réduire le temps nécessaire au téléchargement d’une image. Les images de base légères (telles que l’image de conteneur minimale Amazon Linux 2023) peuvent être nettement plus petites que celles basées sur des images de base de système d’exploitation traditionnelles. Pour plus d'informations sur l'image minimale, consultez la section [Image de conteneur AL2023 minimale](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html) dans le *guide de l'utilisateur Amazon Linux 2023*.
**Algorithmes de compression alternatifs**
Les couches d’images de conteneurs sont souvent compressées lorsqu’elles sont transférées vers un registre d’images de conteneurs. La compression de la couche d’image du conteneur réduit la quantité de données qui doivent être transférées sur le réseau et stockées dans le registre des images du conteneur. Une fois qu’une couche d’image de conteneur a été téléchargée sur une instance par le moteur d’exécution du conteneur, cette couche est décompressée. L'algorithme de compression utilisé et la quantité de v CPUs disponible à l'exécution ont un impact sur le temps nécessaire pour décompresser l'image du conteneur. Sur Fargate, vous pouvez augmenter la taille de la tâche ou tirer parti de l’algorithme de compression zstd, plus performant, pour réduire le temps de décompression. Pour plus d'informations, consultez [zstd](https://github.com/facebook/zstd) on. GitHub Pour plus d'informations sur la façon d'implémenter les images pour Fargate, [consultez la section AWS Fargate Réduction des temps de démarrage avec les images de conteneur compressées zstd](https://aws.amazon.com/blogs/containers/reducing-aws-fargate-startup-times-with-zstd-compressed-container-images/).
**Chargement différé d’images de conteneurs**
Pour les images de conteneur de grande taille (> 250 Mo), il peut être préférable de procéder à un chargement différé plutôt que de télécharger l’intégralité de l’image. Sur Fargate, vous pouvez utiliser Seekable OCI (SOCI) pour procéder au chargement différé d’une image de conteneur à partir d’un registre d’images de conteneur. Pour plus d'informations, consultez les sections [soci-snapshotter](https://github.com/awslabs/soci-snapshotter) on GitHub et [Lazy loading container images using Seekable](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-soci-images) OCI (SOCI).
# Comportement d’extraction d’image de conteneur relatif aux conteneurs Windows sur Fargate pour Amazon ECS
Fargate Windows met en cache l’image de base Server Core fournie par Microsoft pour le mois en cours et le mois précédent. Ces images correspondent au KB/Build nombre de patchs mis à jour chaque Patch Tuesday. Par exemple, le 9 avril 2024, Microsoft a publié KB5036896 (17763.5696) pour Windows Server 2019. Le mois précédent, KB le 12 mars 2024 était KB5035849 (17763.5576). Ainsi, pour les plateformes `WINDOWS_SERVER_2019_CORE` et `WINDOWS_SERVER_2019_FULL`, les images de conteneurs suivantes ont été mises en cache :
+ `mcr.microsoft.com/windows/servercore:ltsc2019`
+ ` mcr.microsoft.com/windows/servercore:10.0.17763.5696`
+ `mcr.microsoft.com/windows/servercore:10.0.17763.5576`
De plus, le 9 avril 2024, Microsoft a publié KB5036909 (20348.2402) pour Windows Server 2022. Le mois précédent KB le 12 mars 2024 était KB5035857 (20348,2340). Ainsi, pour les plateformes `WINDOWS_SERVER_2022_CORE` et `WINDOWS_SERVER_2022_FULL`, les images de conteneurs suivantes ont été mises en cache :
+ `mcr.microsoft.com/windows/servercore:ltsc2022`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2402`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2340`
# Stockage éphémère des tâches Fargate pour Amazon ECS
Une fois provisionnée, chaque tâche Amazon ECS hébergée sur des conteneurs Linux AWS Fargate reçoit le stockage éphémère suivant pour les montages liés. Ils peuvent être montés et partagés entre les conteneurs en utilisant les paramètres `volumes`, `mountPoints` et `volumesFrom` dans la définition de tâche. Cela n'est pas pris en charge pour les conteneurs Windows sur AWS Fargate.
## Versions de la plateforme de conteneurs Linux Fargate
### Version 1.4.0 ou ultérieure
Par défaut, les tâches Amazon ECS sur Fargate utilisant la version `1.4.0` ou ultérieure de la plateforme reçoivent un minimum de 20 Gio de stockage éphémère. La quantité totale de stockage éphémère peut être augmentée, jusqu'à un maximum de 200 Gio. Vous pouvez effectuer cette opération en spécifiant le paramètre `ephemeralStorage` dans votre définition de tâche.
Les images de conteneur extraites, compressées et non compressées de la tâche sont stockées sur le stockage éphémère. Pour déterminer la quantité totale de stockage éphémère que votre tâche doit utiliser, vous devez soustraire la quantité de stockage utilisée par votre image de conteneur de la quantité totale de stockage éphémère alloué à votre tâche.
Pour les tâches utilisant la version `1.4.0` ou ultérieure de la plateforme qui sont lancées le 28 mai 2020 ou plus tard, le stockage éphémère est chiffré à l'aide d'un algorithme de chiffrement AES-256. Cet algorithme utilise une AWS clé de chiffrement propre, ou vous pouvez créer votre propre clé gérée par le client. Pour plus d'informations, consultez la section [Clés gérées par le client pour le AWS Fargate stockage éphémère](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html).
Pour les tâches utilisant la version `1.4.0` ou ultérieure de la plateforme qui sont lancées le 18 novembre 2022 ou plus tard, l'utilisation du stockage éphémère est signalée sur le point de terminaison des métadonnées de la tâche. Dans le cadre de vos tâches, vos applications peuvent interroger le point de terminaison des métadonnées des tâches, version 4, pour connaître la taille réservée au stockage éphémère et la quantité utilisée.
En outre, la taille réservée au stockage éphémère et la quantité utilisée sont envoyées à Amazon CloudWatch Container Insights si vous activez Container Insights.
**Note**
Fargate réserve de l'espace sur le disque. Il n'est utilisé que par Fargate. Vous n'êtes pas facturé pour cela. Cela n'apparaît pas dans ces statistiques. Toutefois, vous pouvez voir ce stockage supplémentaire dans d'autres outils tels que `df`.
### Version 1.3.0 ou antérieure
Pour les tâches Amazon ECS sur Fargate utilisant la version `1.3.0` ou antérieure de la plateforme, chaque tâche reçoit le magasin éphémère suivant.
+ 10 Go de stockage de couche Docker
**Note**
Ce volume inclut les artefacts d'image de conteneur compressée et non compressée.
+ 4 Go supplémentaires pour les montages de volume. Ils peuvent être montés et partagés entre les conteneurs en utilisant les paramètres `volumes`, `mountPoints` et `volumesFrom` dans la définition de tâche.
## Versions de la plateforme de conteneur Windows Fargate
### Version 1.0.0 ou ultérieure
Par défaut, les tâches Amazon ECS sur Fargate utilisant la version `1.0.0` ou ultérieure de la plateforme reçoivent un minimum de 20 Gio de stockage éphémère. La quantité totale de stockage éphémère peut être augmentée, jusqu'à un maximum de 200 Gio. Vous pouvez effectuer cette opération en spécifiant le paramètre `ephemeralStorage` dans votre définition de tâche.
Les images de conteneur extraites, compressées et non compressées de la tâche sont stockées sur le stockage éphémère. Pour déterminer la quantité totale de stockage éphémère que votre tâche doit utiliser, vous devez soustraire la quantité de stockage utilisée par votre image de conteneur de la quantité totale de stockage éphémère alloué à votre tâche.
Pour de plus amples informations, veuillez consulter [Utilisation de montages liés avec Amazon ECS](bind-mounts.md).
# Clés gérées par le client pour le stockage AWS Fargate éphémère pour Amazon ECS
AWS Fargate prend en charge les clés gérées par le client pour chiffrer les données relatives aux tâches Amazon ECS stockées dans un stockage éphémère afin d'aider les clients sensibles aux réglementations à respecter leurs politiques de sécurité internes. Les clients continuent de bénéficier des avantages sans serveur de Fargate, tout en offrant une meilleure visibilité sur le chiffrement du stockage autogéré aux auditeurs de conformité. Bien que Fargate dispose par défaut d’un chiffrement du stockage éphémère géré par Fargate, les clients peuvent également utiliser leurs propres clés autogérées pour chiffrer les données sensibles telles que les informations financières ou médicales.
Vous pouvez importer vos propres clés AWS KMS ou créer des clés dans AWS KMS. Ces clés autogérées sont stockées AWS KMS et exécutent des actions de AWS KMS cycle de vie standard telles que la rotation, la désactivation et la suppression. Vous pouvez vérifier l'accès aux clés et leur utilisation dans CloudTrail les journaux.
Par défaut, la clé KMS prend en charge 50 000 autorisations par clé. Fargate utilise une AWS KMS seule subvention par tâche clé gérée par le client, ce qui lui permet de prendre en charge jusqu'à 50 000 tâches simultanées pour une clé. Si vous souhaitez augmenter ce nombre, vous pouvez demander une augmentation de limite, qui est approuvée sur une case-by-case base régulière.
Fargate ne facture aucun supplément pour l’utilisation des clés gérées par le client. Le prix standard ne vous est facturé que pour l'utilisation des AWS KMS clés pour le stockage et les demandes d'API.
**Topics**
+ [Création d’une clé de chiffrement pour le stockage éphémère Fargate pour Amazon ECS](fargate-create-storage-key.md)
+ [Gestion des AWS KMS clés pour le stockage éphémère Fargate pour Amazon ECS](fargate-managing-kms-key.md)
# Création d’une clé de chiffrement pour le stockage éphémère Fargate pour Amazon ECS
Créer une clé gérée par le client pour le chiffrement des données stockées dans le stockage éphémère Fargate.
**Note**
Le chiffrement du stockage éphémère Fargate avec des clés gérées par le client n’est pas disponible pour les clusters de tâches Windows.
Le chiffrement du stockage éphémère Fargate avec des clés gérées par le client n’est pas disponible sur les `platformVersions` antérieures à la version `1.4.0`.
Fargate réserve de l’espace sur un espace de stockage éphémère qui n’est utilisé que par Fargate, et cet espace ne vous est pas facturé. L’allocation peut différer des tâches de clés non gérées par le client, mais l’espace total reste le même. Vous pouvez visualiser cette modification dans des outils tels que `df`.
Les clés multirégion ne sont pas prises en charge pour le stockage éphémère Fargate.
Les alias de clé KMS ne sont pas pris en charge pour le stockage éphémère Fargate.
Pour créer une clé gérée par le client (CMK) afin de chiffrer le stockage éphémère pour Fargate in, procédez comme suit. AWS KMS
1. Accédez au fichier [https://console.aws.amazon.com/km.](https://console.aws.amazon.com/kms)
1. Suivez les instructions de la section [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le [Guide du développeur AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
1. Lorsque vous créez votre AWS KMS clé, assurez-vous de fournir les autorisations d'opération AWS KMS pertinentes pour le service Fargate dans les politiques clés. Les opérations d’API suivantes doivent être autorisées dans la politique pour pouvoir utiliser votre clé gérée par le client avec vos ressources de cluster Amazon ECS.
+ `kms:GenerateDataKeyWithoutPlainText`‐ Appelez `GenerateDataKeyWithoutPlainText` pour générer une clé de données cryptée à partir de la AWS KMS clé fournie.
+ `kms:CreateGrant` : ajoute un octroi à une clé gérée par le client. Accorde un accès de contrôle à une AWS KMS clé spécifiée, ce qui permet d'autoriser les opérations requises par Amazon ECS Fargate. Pour plus d’informations à propos de l’[Utilisation des octrois](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html), consultez le [Guide du développeur AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). Cela permet à Amazon ECS Fargate d’effectuer les opérations suivantes :
+ Appelez `Decrypt` pour AWS KMS obtenir la clé de chiffrement permettant de déchiffrer les données de stockage éphémères.
+ Configurer un principal sortant pour permettre au service de `RetireGrant`.
+ `kms:DescribeKey` : fournit les détails de la clé gérée par le client pour permettre à Amazon ECS de valider la clé si elle est symétrique et activée.
L'exemple suivant montre une politique de AWS KMS clé que vous devez appliquer à la clé cible pour le chiffrement. Pour utiliser les exemples d’instructions de politique, remplacez les *user input placeholders* informations par les vôtres. Comme toujours, configurez uniquement les autorisations dont vous avez besoin, mais vous devrez AWS KMS fournir des autorisations à au moins un utilisateur pour éviter les erreurs.
```
{
"Sid": "Allow generate data key access for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:GenerateDataKeyWithoutPlaintext"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow grant creation permission for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:CreateGrant"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow describe key permission for cluster operator - CreateCluster and UpdateCluster.",
"Effect": "Allow",
"Principal": { "AWS":"arn:aws:iam::customerAccountId:role/customer-chosen-role" },
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
}
```
Les tâches Fargate utilisent les clés de contexte de chiffrement `aws:ecs:clusterAccount` et `aws:ecs:clusterName` pour les opérations cryptographiques effectuées avec la clé. Les clients doivent ajouter ces autorisations pour restreindre l'accès à un and/or groupe de comptes spécifique. Utilisez le nom du cluster et non l’ARN lorsque vous spécifiez le cluster.
Consultez [Contexte de chiffrement](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) dans le [AWS KMS guide du développeur](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) pour en savoir plus.
Lors de la création ou de la mise à jour d’un cluster, vous avez la possibilité d’utiliser la clé de condition `fargateEphemeralStorageKmsKeyId`. Cette clé de condition permet aux clients d’exercer un contrôle plus précis sur les politiques IAM. Les mises à jour de configuration `fargateEphemeralStorageKmsKeyId` ne prennent effet que sur les nouveaux déploiements de service.
L'exemple suivant montre comment autoriser les clients à n'accorder des autorisations qu'à un ensemble spécifique de AWS KMS clés approuvées.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ecs:fargate-ephemeral-storage-kms-key": "arn:aws:kms:us-west-2:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
}
}
]
}
```
------
Voici un exemple de refus des tentatives de suppression de AWS KMS clés déjà associées à un cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"Null": {
"ecs:fargate-ephemeral-storage-kms-key": "true"
}
}
}
}
```
------
Les clients peuvent voir si leurs tâches non gérées ou leurs tâches de service sont chiffrées à l'aide de la clé à l'aide des `describe-services` commandes AWS CLI `describe-tasks``describe-cluster`, ou.
Pour plus d’informations, consultez la section [Clés de condition pour AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html) dans le [Guide du développeur AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
------
#### [ AWS Management Console ]
1. Ouvrez la console à la [https://console.aws.amazon.com/ecs/version 2](https://console.aws.amazon.com/ecs/v2).
1. Choisissez **Clusters** dans la navigation de gauche et **Créer un cluster** en haut à droite ou choisissez un cluster existant. Pour un cluster existant, choisissez **Mettre à jour le cluster** en haut à droite.
1. Dans la section **Chiffrement** du flux de travail, vous aurez la possibilité de sélectionner votre AWS KMS clé sous **Stockage géré et Stockage éphémère** **Fargate**. Vous pouvez également choisir de **créer une AWS KMS clé** à partir d'ici.
1. Choisissez **Créer** une fois que vous avez fini de créer votre cluster ou **Mettre à jour**, si vous mettiez à jour un cluster existant.
------
#### [ AWS CLI ]
Voici un exemple de création d'un cluster et de configuration de votre stockage éphémère Fargate à l'aide AWS CLI du (remplacez *red* les valeurs par les vôtres) :
```
aws ecs create-cluster --cluster clusterName \
--configuration '{"managedStorageConfiguration":{"fargateEphemeralStorageKmsKeyId":"arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"}}'
{
"cluster": {
"clusterArn": "arn:aws:ecs:us-west-2:012345678901:cluster/clusterName",
"clusterName": "clusterName",
"configuration": {
"managedStorageConfiguration": {
"fargateEphemeralStorageKmsKeyId": "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
},
"status": "ACTIVE",
"registeredContainerInstancesCount": 0,
"runningTasksCount": 0,
"pendingTasksCount": 0,
"activeServicesCount": 0,
"statistics": [],
"tags": [],
"settings": [],
"capacityProviders": [],
"defaultCapacityProviderStrategy": []
},
"clusterCount": 5
}
```
------
#### [ CloudFormation ]
Voici un exemple de modèle de création d'un cluster et de configuration de votre stockage éphémère Fargate à l'aide CloudFormation du (remplacez *red* les valeurs par les vôtres) :
```
AWSTemplateFormatVersion: 2010-09-09
Resources:
MyCluster:
Type: AWS::ECS::Cluster
Properties:
ClusterName: "clusterName"
Configuration:
ManagedStorageConfiguration:
FargateEphemeralStorageKmsKeyId: "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
------
# Gestion des AWS KMS clés pour le stockage éphémère Fargate pour Amazon ECS
Après avoir créé ou importé votre AWS KMS clé pour chiffrer votre stockage éphémère Fargate, vous le gérez de la même manière que n'importe quelle autre clé. AWS KMS
**Rotation automatique des AWS KMS touches**
Vous pouvez activer la rotation automatique des clés ou les faire pivoter manuellement. La rotation automatique des clés fait pivoter la clé pour vous chaque année en générant du nouveau matériel cryptographique pour la clé. AWS KMS enregistre également toutes les versions précédentes du matériel cryptographique, de sorte que vous serez en mesure de déchiffrer toutes les données qui utilisaient les versions de clé antérieures. Aucun matériau pivoté ne sera supprimé AWS KMS tant que vous n'aurez pas supprimé la clé.
La rotation automatique des clés est facultative et peut être activée ou désactivée à tout moment.
**Désactivation ou révocation des clés AWS KMS**
Si vous désactivez une clé d'entrée gérée par le client AWS KMS, cela n'a aucun impact sur l'exécution des tâches et celles-ci continuent de fonctionner tout au long de leur cycle de vie. Si une nouvelle tâche utilise la clé désactivée ou révoquée, elle échoue, car elle ne peut pas accéder à la clé. Vous devez définir une CloudWatch alarme ou une alarme similaire pour vous assurer qu'une clé désactivée ne soit jamais nécessaire pour déchiffrer des données déjà chiffrées.
**Supprimer des AWS KMS clés**
La suppression de clés doit toujours être envisagée en dernier recours et ne doit être effectuée que si vous êtes certain que la clé supprimée ne sera plus jamais nécessaire. Les nouvelles tâches qui tentent d'utiliser la clé supprimée échoueront car elles ne pourront pas y accéder. AWS KMS conseille de désactiver une clé au lieu de la supprimer. Si vous pensez qu'il est nécessaire de supprimer une clé, nous vous suggérons de la désactiver d'abord et de configurer une CloudWatch alarme pour vous assurer qu'elle n'est pas nécessaire. Si vous supprimez une clé, vous AWS KMS disposez d'au moins sept jours pour changer d'avis.
**Audit de l'accès aux AWS KMS clés**
Vous pouvez utiliser CloudTrail les journaux pour vérifier l'accès à votre AWS KMS clé. Vous pouvez vérifier les AWS KMS opérations `CreateGrant``GenerateDataKeyWithoutPlaintext`, et`Decrypt`. Ces opérations affichent également le `aws:ecs:clusterAccount` et dans le `aws:ecs:clusterName` cadre de `EncryptionContext` la connexion CloudTrail.
Voici des exemples d' CloudTrail événements pour`GenerateDataKeyWithoutPlaintext`,`GenerateDataKeyWithoutPlaintext (DryRun)`, `CreateGrant``CreateGrant (DryRun)`, et `RetireGrant` (remplacez les *red* valeurs par les vôtres).
------
#### [ GenerateDataKeyWithoutPlaintext ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"numberOfBytes": 64,
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxxxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ GenerateDataKeyWithoutPlaintext (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"dryRun": true,
"numberOfBytes": 64,
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"retiringPrincipal": "ec2.us-west-2.amazonaws.com"
},
"responseElements": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"dryRun": true,
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ RetireGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "AWS Internal"
},
"eventTime": "2024-04-20T18:37:38Z",
"eventSource": "kms.amazonaws.com",
"eventName": "RetireGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": null,
"responseElements": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"additionalEventData": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
# Retrait et maintenance des tâches pour AWS Fargate sur Amazon ECS
AWS est responsable de la maintenance de l'infrastructure sous-jacente de AWS Fargate. AWS détermine à quel moment une révision de version de plate-forme doit être remplacée par une nouvelle révision de l'infrastructure. C'est ce que l'on appelle la retraite des tâches. AWS envoie une notification de retrait de tâche lorsqu'une révision de version de plateforme est supprimée. Nous mettons régulièrement à jour les versions de nos plateformes prises en charge pour introduire une nouvelle révision contenant des mises à jour du logiciel d’exécution Fargate et des dépendances sous-jacentes telles que le système d’exploitation et l’environnement d’exécution du conteneur. Une fois qu’une nouvelle version est disponible, nous mettons hors service l’ancienne version afin de garantir que toutes les charges de travail des clients s’exécutent sur la version la plus récente de la version de plateforme Fargate. Lorsqu'une révision est retirée, toutes les tâches exécutées sur cette révision sont arrêtées.
Les tâches Amazon ECS peuvent être classées en tant que tâches de service ou tâches autonomes. Les tâches de service sont déployées dans le cadre d’un service et planifiées par le planificateur Amazon ECS. Pour de plus amples informations, veuillez consulter [Services Amazon ECS](ecs_services.md). Les tâches autonomes sont des tâches démarrées par l'`RunTask`API Amazon ECS, soit directement, soit par un planificateur externe, telles que les tâches planifiées (lancées par Amazon EventBridge), AWS Batch ou. AWS Step Functions Aucune action n’est requise de votre part en réponse à la mise hors service de vos tâches de service, car le planificateur Amazon ECS remplace automatiquement les tâches.
Pour les tâches autonomes, il se peut que vous deviez effectuer une manipulation supplémentaire en réponse à la mise hors service des tâches. Pour de plus amples informations, veuillez consulter [Amazon ECS peut-il gérer automatiquement des tâches autonomes ?](#task-retirement-standalone-tasks).
Pour les tâches de service, il n'est pas nécessaire de prendre des mesures pour les supprimer, sauf si vous souhaitez remplacer ces tâches au AWS préalable. Lorsque le planificateur Amazon ECS arrête les tâches, il utilise le paramètre `maximumPercent` et lance une nouvelle tâche afin de maintenir le nombre souhaité pour le service. Suivez les pratiques exemplaires pour minimiser l’impact de la mise hors service des tâches. La valeur par défaut du paramètre `maximumPercent` pour un service utilisant le planificateur de service RÉPLICA est de 200 %. Par conséquent, lorsqu'il AWS Fargate commence à retirer des tâches, Amazon ECS planifie d'abord une nouvelle tâche, puis attend qu'elle soit exécutée avant de retirer une ancienne tâche. Lorsque vous définissez la valeur de `maximumPercent` sur 100 %, Amazon ECS arrête d’abord la tâche, puis la remplace.
Pour le retrait d'une tâche autonome, AWS arrête la tâche à la date de retrait de la tâche ou après cette date. Amazon ECS ne lance pas de tâche de remplacement lorsqu’une tâche est arrêtée. Si vous souhaitez que ces tâches continuent de s’exécuter, vous devez arrêter les tâches en cours d’exécution et lancer une tâche de remplacement avant l’heure indiquée dans la notification. Nous recommandons donc aux clients de surveiller l'état des tâches autonomes et, si nécessaire, d'implémenter une logique pour remplacer les tâches interrompues.
Lorsqu'une tâche est arrêtée dans l'un des scénarios ci-dessus, vous pouvez exécuter `describe-tasks`. La `stoppedReason` de la réponse est `ECS is performing maintenance on the underlying infrastructure hosting the task`.
La maintenance des tâches s’applique lorsqu’une nouvelle version de plateforme doit être remplacée par une nouvelle révision. En cas de problème avec un hôte Fargate sous-jacent, Amazon ECS remplace l’hôte sans préavis de mise hors service de tâche.
## Aperçu des avis de mise hors service de tâches
Lorsqu' AWS une révision de version de plate-forme doit être supprimée, nous identifions toutes les tâches en cours d'exécution sur cette révision de version de plate-forme dans toutes les régions.
L’illustration suivante montre le cycle de vie d’une révision de version de plateforme Fargate, depuis le lancement d’une nouvelle révision à la mise hors service de la révision de plateforme.
![\[Diagramme illustrant le cycle de vie de la mise hors service des tâches Fargate.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/fargate-task-retirement.png)
Les informations suivantes fournissent des détails.
+ Après le lancement d’une nouvelle révision de la version de plateforme, toutes les nouvelles tâches sont planifiées sur cette révision.
+ Les tâches existantes qui ont été planifiées et exécutées restent dans la version dans laquelle elles ont été initialement placées pendant toute la durée de la tâche et ne sont pas migrées vers la nouvelle révision.
+ Les nouvelles tâches, par exemple dans le cadre d’une mise à jour d’un service ou de la mise hors service d’une tâche Fargate, sont placées sur la dernière version de plateforme disponible au moment du lancement.
Les notifications de retrait de tâches sont envoyées via le tableau de AWS Health bord ainsi que par e-mail à l'adresse e-mail enregistrée et incluent les informations suivantes :
+ Date de retrait de la tâche : la tâche est arrêtée à cette date ou après.
+ Pour les tâches autonomes, IDs les tâches.
+ Pour les tâches de service, l'ID du cluster sur lequel le service s'exécute et IDs celui du service.
+ Les prochaines étapes que vous devez suivre.
En règle générale, nous envoyons une notification pour chaque tâche de service et chaque tâche autonome dans chaque Région AWS. Toutefois, dans certains cas, vous pouvez recevoir plusieurs événements pour chaque type de tâche, par exemple lorsqu’un trop grand nombre de tâches dépassent les limites fixées par nos mécanismes de notification pour être mises hors service.
Vous pouvez identifier les tâches planifiées pour le retrait en procédant ainsi :
+ Le Tableau de bord Health
AWS Health les notifications peuvent être envoyées via Amazon EventBridge vers un système de stockage d'archives tel qu'Amazon Simple Storage Service, effectuer des actions automatisées telles que l'exécution d'une AWS Lambda fonction, ou vers d'autres systèmes de notification tels qu'Amazon Simple Notification Service. Pour plus d'informations, consultez la section [Surveillance AWS Health des événements avec Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). Pour un exemple de configuration permettant d'envoyer des notifications à Amazon Chime, Slack ou Microsoft Teams, consultez le référentiel [AWS Health Aware](https://github.com/aws-samples/aws-health-aware) sur. GitHub
Voici un exemple d' EventBridge événement.
```
{
"version": "0",
"id": "3c268027-f43c-0171-7425-1d799EXAMPLE",
"detail-type": "AWS Health Event",
"source": "aws.health",
"account": "123456789012",
"time": "2023-08-16T23:18:51Z",
"region": "us-east-1",
"resources": [
"cluster|service",
"cluster|service"
],
"detail": {
"eventArn": "arn:aws:health:us-east-1::event/ECS/AWS_ECS_TASK_PATCHING_RETIREMENT/AWS_ECS_TASK_PATCHING_RETIREMENT_test1",
"service": "ECS",
"eventScopeCode": "ACCOUNT_SPECIFIC",
"communicationId": "7988399e2e6fb0b905ddc88e0e2de1fd17e4c9fa60349577446d95a18EXAMPLE",
"lastUpdatedTime": "Wed, 16 Aug 2023 23:18:52 GMT",
"eventRegion": "us-east-1",
"eventTypeCode": "AWS_ECS_TASK_PATCHING_RETIREMENT",
"eventTypeCategory": "scheduledChange",
"startTime": "Wed, 16 Aug 2023 23:18:51 GMT",
"endTime": "Fri, 18 Aug 2023 23:18:51 GMT",
"eventDescription": [
{
"language": "en_US",
"latestDescription": "\\nA software update has been deployed to Fargate which includes CVE patches or other critical patches. No action is required on your part. All new tasks launched automatically uses the latest software version. For existing tasks, your tasks need to be restarted in order for these updates to apply. Your tasks running as part of the following ECS Services will be automatically updated beginning Wed, 16 Aug 2023 23:18:51 GMT.\\n\\nAfter Wed, 16 Aug 2023 23:18:51 GMT, the ECS scheduler will gradually replace these tasks, respecting the deployment settings for your service. Typically, services should see little to no interruption during the update and no action is required. When AWS stops tasks, AWS uses the minimum healthy percent (1) and launches a new task in an attempt to maintain the desired count for the service. By default, the minimum healthy percent of a service is 100 percent, so a new task is started first before a task is stopped. Service tasks are routinely replaced in the same way when you scale the service or deploy configuration changes or deploy task definition revisions. If you would like to control the timing of this restart you can update the service before Wed, 16 Aug 2023 23:18:51 GMT, by running the update-service command from the ECS command-line interface specifying force-new-deployment for services using Rolling update deployment type. For example:\\n\\n$ aws ecs update-service -service service_name \\\n--cluster cluster_name -force-new-deployment\\n\\nFor services using Blue/Green deployment type with AWS CodeDeploy:\\nPlease refer to create-deployment document (2) and create new deployment using same task definition revision.\\n\\nFor further details on ECS deployment types, please refer to ECS Deployment Developer Guide (1).\\nFor further details on Fargate's update process, please refer to the AWS Fargate User Guide (3).\\nIf you have any questions or concerns, please contact AWS Support (4).\\n\\n(1) https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html\\n(2) https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html\\n(3) https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-maintenance.html\\n(4) https://aws.amazon.com/support\\n\\nA list of your affected resources(s) can be found in the 'Affected resources' tab in the 'Cluster/ Service' format in the AWS Health Dashboard. \\n\\n"
}
],
"affectedEntities": [
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c23333"
},
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c25555"
}
}
]
}
}
```
+ E-mail
Un e-mail est envoyé à l'adresse e-mail enregistrée pour l' Compte AWS identifiant.
Pour plus d’informations sur la manière de préparer la mise hors service d’une tâche, consultez la section[Préparez-vous à la AWS suppression des tâches Fargate sur Amazon ECS](prepare-task-retirement.md).
## Puis-je refuser la mise hors service d’une tâche ?
Non. Dans le cadre du modèle de responsabilité AWS partagée, AWS est responsable de la gestion et de la maintenance de l'infrastructure sous-jacente pour AWS Fargate. Cela inclut l’exécution de mises à jour périodiques de la plateforme pour garantir la sécurité et la stabilité. Ces mises à jour sont automatiquement appliquées par les clients AWS et ne peuvent pas s'y soustraire. Il s'agit d'un avantage clé de l'utilisation d'une AWS Fargate par rapport à l'exécution de vos charges de travail sur des instances EC2, la responsabilité de la maintenance de la plate-forme sous-jacente étant prise en charge par. AWS Ce modèle vous permet de vous concentrer sur vos applications plutôt que sur la maintenance de l’infrastructure. En appliquant automatiquement ces mises à jour de la plateforme, AWS vous êtes en mesure de maintenir l' up-to-dateenvironnement Fargate et de le sécuriser, sans qu'aucune action ne soit requise de votre part en tant que client. Cela permet de fournir un environnement conteneurisé fiable et sécurisé pour exécuter vos charges de travail sur Fargate.
## Puis-je recevoir des notifications de retrait de tâches par le biais d'autres AWS services ?
AWS envoie une notification de retrait de tâche au Tableau de bord Health et au contact e-mail principal sur le Compte AWS. Tableau de bord Health Il fournit un certain nombre d'intégrations dans d'autres AWS services, notamment EventBridge. Vous pouvez l'utiliser EventBridge pour automatiser la visibilité des notifications (par exemple, transférer le message vers un ChatOps outil). Pour plus d’informations, consultez la section [Présentation de la solution : capture des notifications de mise hors service de tâches](https://aws.amazon.com/blogs/containers/improving-operational-visibility-with-aws-fargate-task-retirement-notifications/).
## Puis-je modifier la mise hors service d’une tâche une fois qu’elle a été planifiée ?
Non. Le calendrier est basé sur le temps d'attente pour la cessation des tâches, qui est par défaut de 7 jours. Si vous avez besoin de plus de temps, vous pouvez choisir de configurer le délai d’attente à 14 jours. Pour de plus amples informations, veuillez consulter [Étape 2 : capturer les notifications de mise hors service de tâche pour alerter les équipes et prendre des mesures](prepare-task-retirement.md#prepare-task-retirement-capture-task-events).
Depuis le 18/12/2025, Amazon ECS vous permet de configurer les fenêtres d'[événements Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) pour vos tâches Fargate. Si vous avez besoin d'un contrôle précis sur le moment exact des interruptions de tâches, par exemple en les planifiant le week-end pour éviter toute interruption pendant les heures ouvrables, vous pouvez configurer les fenêtres d'événements Amazon EC2 pour vos tâches, services ou clusters, voir. [É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) Notez que la modification apportée à cette configuration s'applique aux mises à la retraite qui seront planifiées dans le futur. Les mises hors service prévues actuellement ne sont pas concernées. En outre, lorsque vous configurez une fenêtre d'événements Amazon EC2 pour vos tâches Fargate, elle a priorité sur la configuration du temps d'attente pour la mise hors service des tâches. Si vous avez d'autres préoccupations, contactez Support.
## Comment Amazon ECS gère-t-il les tâches faisant partie d’un service ?
Pour les tâches de service, il n'est pas nécessaire de prendre des mesures en réponse à la suppression des tâches, sauf si vous souhaitez remplacer ces tâches au AWS préalable. Lorsque le planificateur Amazon ECS arrête les tâches, il utilise le pourcentage minimum sain et lance une nouvelle tâche afin de maintenir le nombre souhaité pour le service. Afin de minimiser l’impact de la mise hors service des tâches Fargate, les charges de travail doivent être déployées conformément aux pratiques exemplaires Amazon ECS. Par exemple, lors du déploiement d'une application sans état en tant que service Amazon ECS, tel qu'un serveur Web ou API, les clients doivent déployer plusieurs répliques de tâches et définir la valeur minimumHealthyPercent à 100 %. La valeur par défaut pour le pourcentage minimum sain est 100 %. Par conséquent, lorsque Fargate commence à mettre des tâches hors service, Amazon ECS planifie d’abord une nouvelle tâche et attend qu’elle soit exécutée, avant de mettre une ancienne tâche hors service. Les tâches de service sont systématiquement remplacées dans le cadre de la mise hors service des tâches, de la même manière que lorsque vous adaptez le service, déployez des modifications de configuration ou déployez des révisions de définition de tâches. Pour plus d’informations sur la mise hors service d’une définition de tâche, consultez la section [Préparez-vous à la AWS suppression des tâches Fargate sur Amazon ECS](prepare-task-retirement.md).
## Amazon ECS peut-il gérer automatiquement des tâches autonomes ?
Non. AWS ne peut pas créer de tâche de remplacement pour les tâches autonomes démarrées par `RunTask` des tâches planifiées (par exemple via le EventBridge planificateur) ou. AWS Batch AWS Step Functions Amazon ECS ne gère que les tâches faisant partie d’un service.
## Résolution des problèmes de disponibilité du service pendant la mise hors service d’une tâche
Si Amazon ECS ne peut pas démarrer une tâche de remplacement pendant la mise hors service d’une tâche, la disponibilité de votre service peut être affectée. Cela peut être dû à une configuration client incorrecte, telle que :
+ Rôles IAM manquants ou configurés de façon incorrecte
+ Capacité insuffisante dans les sous-réseaux cibles
+ Mauvaises configurations des groupes de sécurité
+ Erreurs de définition des tâches
Lorsqu’Amazon ECS ne peut pas lancer de tâches de remplacement, les tâches mises hors service sont arrêtées sans remplacement, ce qui réduit la capacité disponible de votre service et peut entraîner une interruption du service. Surveillez le nombre de tâches de votre service et les CloudWatch indicateurs Amazon pour vous assurer que les tâches de remplacement sont lancées avec succès lors des événements de mise hors service.
# Préparez-vous à la AWS suppression des tâches Fargate sur Amazon ECS
Afin d’être prêt à la mise hors service de tâche, effectuez les opérations suivantes :
1. Définissez la période d'attente pour la suppression des tâches ou utilisez les fenêtres d'événements Amazon EC2.
1. Capturez les notifications de mise hors service de tâche pour avertir les membres de l’équipe.
1. Vous pouvez vous assurer que toutes les tâches de vos services sont exécutées sur la dernière version de la plateforme en mettant à jour le service avec l'option de déploiement forcé. Cette étape est facultative.
## Étape 1 : définir le temps d'attente des tâches ou utiliser les fenêtres d'événements Amazon EC2
Vous disposez de deux options de paramètres de compte pour configurer l'heure à laquelle Fargate commence à supprimer des tâches : et. `fargateTaskRetirementWaitPeriod` `fargateEventWindows`
**Utilisation des paramètres fargateTaskRetirement WaitPeriod 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*.
**Utilisation des paramètres fargateEventWindows du compte**
Depuis le 18/12/2025, Amazon ECS vous permet de configurer les fenêtres d'[événements Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) pour vos tâches Fargate. Si vous avez besoin d'un contrôle précis sur le moment exact des interruptions de tâches, par exemple en les planifiant le week-end pour éviter toute interruption pendant les heures ouvrables, vous pouvez configurer les fenêtres d'événements Amazon EC2 pour vos tâches, services ou clusters.
Lorsque vous utilisez des fenêtres d'événements, Fargate veille à ce que vos tâches soient exécutées pendant au moins 3 jours avant d'être supprimées dans la prochaine fenêtre disponible, sauf si elles sont interrompues par des actions initiées par l'utilisateur ou par des événements de santé critiques tels que la dégradation du matériel sous-jacent.
Réglez le paramètre du compte `fargateEventWindows` sur `enabled`. Vous pouvez utiliser l'une des options suivantes APIs : `put-account-setting-default` ou `put-account-setting` en tant qu'utilisateur root ou en tant qu'utilisateur administratif.
Chaque fenêtre d'événements Amazon EC2 doit être ouverte au moins 4 heures par semaine, et chaque plage horaire doit être d'au moins 2 heures. Pour les clusters et les services de grande taille, nous recommandons de configurer des fenêtres d'événements de longue durée (8 heures ou plus) ou de plages de temps plus fréquentes qui se produisent au moins une fois tous les 3 jours. Vous pouvez consulter plus en détail les considérations relatives aux fenêtres d'événements Amazon EC2 dans le [guide de l'utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html#event-windows-considerations) pour AWS Fargate garantir que vos tâches s'exécutent pendant au moins 3 jours avant d'être supprimées, sauf si elles sont interrompues par des actions initiées par l'utilisateur ou par des événements de santé critiques tels que la dégradation du matériel sous-jacent.
**Important**
Il est préférable de remplacer les tâches dans la fenêtre d'événements. Si vous remarquez que des tâches sont supprimées en dehors des fenêtres de vos événements, envisagez d'en prolonger la durée (8 heures ou plus) ou d'augmenter la fréquence (au moins une fois tous les 3 jours).
Pour appliquer les fenêtres d'événements Amazon EC2 aux mises hors service de vos tâches Fargate :
+ Réglez le paramètre du compte `fargateEventWindows` sur `enabled`. Vous pouvez utiliser l'une des options suivantes APIs : `put-account-setting-default` ou `put-account-setting` en tant qu'utilisateur root ou en tant qu'utilisateur administratif. Notez qu'il s'agit d'une activation ponctuelle pour l'utilisation de la fonctionnalité de fenêtres d'événements Amazon EC2 pour vos tâches Fargate.
+ Créez une fenêtre d'événement Amazon EC2 via la console AWS ou l'interface de ligne de commande AWS. Pour créer une fenêtre d'événements à l'aide de la CLI, utilisez l'`create-instance-event-window`API EC2 avec des plages de temps ou des expressions cron. Prenez note du contenu `InstanceEventWindowId` de la réponse.
```
aws ec2 create-instance-event-window \
--time-range StartWeekDay=monday,StartHour=2,EndWeekDay=wednesday,EndHour=8 \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
Vous pouvez également utiliser des expressions cron lors de la création de fenêtres d'événements EC2.
```
aws ec2 create-instance-event-window \
--cron-expression "* 21-23 * * 2,3" \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
+ Vous pouvez ensuite associer la fenêtre d'événements à des services spécifiques, à des clusters ou à toutes les tâches de votre compte à l'aide de l'`associate-instance-event-window`API EC2.
+ Pour les tâches de service ECS
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=your-service-arn}]"
```
+ Pour les clusters ECS
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=your-cluster-arn}]"
```
+ Pour associer une fenêtre d'événements à toutes les tâches du compte
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]"
```
Vous pouvez utiliser plusieurs paires clé-valeur pour associer une fenêtre d'événements à plusieurs services ou clusters.
Fargate choisira la fenêtre d'événements pour chaque tâche dans l'ordre suivant :
+ Si une fenêtre d'événements est associée au service de la tâche, elle sera utilisée. Cela ne s'applique pas aux tâches autonomes ou non gérées.
+ Si une fenêtre d'événements est associée au cluster de la tâche, elle sera utilisée.
+ Si une fenêtre d'événements est définie pour toutes les tâches Fargate, elle sera utilisée.
+ Le `fargateTaskRetirementWaitPeriod` paramètre sera utilisé si aucune des fenêtres d'événements ne correspond à la tâche.
**Configuration des fenêtres d'événements pour la maintenance des tâches de Fargate**
Prenons le cas où vous exécutez plusieurs services ECS sur Fargate avec des exigences de disponibilité différentes. Vous voulez avoir un contrôle précis sur les abandons de tâches. Vous pouvez configurer plusieurs fenêtres d'événements comme suit :
+ **Maintenance par défaut pour toutes les tâches Fargate** : créez une fenêtre d'événements pour la maintenance de routine pendant les heures creuses (de 12 h à 4 h du matin tous les jours) et associez-la à toutes les tâches Fargate à l'aide de la balise. ` aws:ecs:fargateTask`
+ **Maintenance du cluster de développement uniquement le week-end** : pour un cluster de développement dont les services peuvent tolérer des interruptions le week-end, créez une fenêtre de week-end de 24 heures (samedi et dimanche, toute la journée) et associez-la au cluster à l'aide de la `aws:ecs:clusterArn` balise associée à l'ARN de votre cluster.
+ **Période restreinte pour les services critiques : pour un service** de traitement des paiements essentiel nécessitant une disponibilité élevée en semaine, limitez la maintenance aux heures du week-end tôt le matin (samedi et dimanche, de minuit à 4 h) et associez-le au service spécifique en utilisant le tag associé à l'ARN de votre service. `aws:ecs:serviceArn`
Avec cette configuration, le service de paiement utilise sa fenêtre spécifique réservée au week-end, les services et tâches du cluster de développement utilisent la fenêtre de 24 heures du week-end, et toutes les autres tâches Fargate utilisent la fenêtre de maintenance quotidienne par défaut.
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*.
## Étape 2 : capturer les notifications de mise hors service de tâche pour alerter les équipes et prendre des mesures
En cas de retrait imminent d'une tâche, AWS envoie une notification de retrait de tâche au AWS Health tableau de bord et au contact e-mail principal sur le Compte AWS. Le AWS Health tableau de bord propose un certain nombre d'intégrations dans d'autres AWS services, notamment Amazon EventBridge. Vous pouvez l'utiliser EventBridge pour créer des automatisations à partir d'une notification de retrait de tâche, par exemple en augmentant la visibilité du prochain retrait en transférant le message vers un ChatOps outil. AWS Health Aware est une ressource qui montre la puissance du AWS Health tableau de bord et montre comment les notifications peuvent être distribuées au sein d'une organisation. Vous pouvez transférer une notification de mise hors service de tâche vers une application de chat, telle que Slack.
L’illustration suivante présente une vue d’ensemble de la solution.
![\[Schéma illustrant la solution Fargate permettant de capturer les notifications de mise hors service de tâche Fargate.\]](http://docs.aws.amazon.com/fr_fr/AmazonECS/latest/developerguide/images/fargate-task-retirement-solution.png)
Les informations suivantes fournissent des détails.
+ Fargate envoie la notification de mise hors service de la tâche au tableau de bord AWS Health .
+ Le AWS Health tableau de bord envoie un e-mail au contact e-mail principal sur le Compte AWS, et le notifie EventBridge.
+ EventBridge possède une règle qui capture la notification de départ à la retraite.
La règle qui recherche les événements avec le type de détail de l’événement : `"AWS Health Event" and the Event Detail Type Code: "AWS_ECS_TASK_PATCHING_RETIREMENT"`
+ La règle déclenche une fonction Lambda qui transmet les informations à Slack à l’aide d’un Webhook entrant Slack. Pour plus d’informations, consultez la section [Webhooks entrants](https://slack.com/marketplace/A0F7XDUAZ-incoming-webhooks).
Pour un exemple de code, consultez [Capture des notifications de retrait de AWS Fargate tâches](https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications/tree/main) sur Github.
## Étape 3 : contrôler le remplacement des tâches
Vous ne pouvez pas contrôler le moment exact de la mise hors service d’une tâche, mais vous pouvez définir un temps d’attente. Si vous souhaitez contrôler le remplacement des tâches selon votre propre calendrier, vous pouvez enregistrer l’avis de mise hors service d’une tâche afin de comprendre d’abord la date de mise hors service de la tâche. Vous pouvez ensuite redéployer votre service pour lancer des tâches de remplacement, ainsi que pour remplacer toutes les tâches autonomes. Pour les services utilisant un déploiement continu, vous devez mettre à jour le service à l’aide de `update-service` avec l’option `force-deployment` avant l’heure de début de la mise hors service.
L’exemple suivant `update-service` utilise l’option `force-deployment`.
```
aws ecs update-service —-service service_name \
--cluster cluster_name \
--force-new-deployment
```
Pour les services qui utilisent le blue/green déploiement, vous devez créer un nouveau déploiement dans AWS CodeDeploy. Pour plus d’informations sur la façon de créer le déploiement, consultez la section [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) dans la *Référence AWS Command Line Interface *.
# Régions prises en charge pour Amazon ECS sur AWS Fargate
Vous pouvez utiliser les tableaux suivants pour vérifier le support régional pour les conteneurs Linux sur AWS Fargate et les conteneurs Windows sur Fargate. AWS
## Conteneurs Linux sur AWS Fargate
Les conteneurs Linux Amazon ECS activés AWS Fargate sont pris en charge dans les versions suivantes Régions AWS. La zone de disponibilité prise en charge IDs est indiquée le cas échéant.
| Nom de la région | Région |
| --- | --- |
| USA Est (Ohio) | us-east-2 |
| USA Est (Virginie du Nord) | us-east-1 |
| USA Ouest (Californie du Nord) | us-west-1 (`usw1-az1` et `usw1-az3` uniquement) |
| USA Ouest (Oregon) | us-west-2 |
| Canada (Centre) | ca-central-1 |
| Canada-Ouest (Calgary) | ca-west-1 |
| Mexique (Centre) | mx-central-1 |
| Afrique (Le Cap) | af-south-1 |
| Asie-Pacifique (Hong Kong) | ap-east-1 |
| Asie-Pacifique (Mumbai) | ap-south-1 |
| Asie-Pacifique (Tokyo) | ap-northeast-1 (`apne1-az1`, `apne1-az2` et `apne1-az4` uniquement) |
| Asie-Pacifique (Séoul) | ap-northeast-2 |
| Asie-Pacifique (Osaka) | ap-northeast-3 |
| Asie-Pacifique (Hyderabad) | ap-south-2 |
| Asie-Pacifique (Singapour) | ap-southeast-1 |
| Asie-Pacifique (Sydney) | ap-southeast-2 |
| Asie-Pacifique (Thaïlande) | ap-southeast-7 |
| Asie-Pacifique (Jakarta) | ap-southeast-3 |
| Asie-Pacifique (Melbourne) | ap-southeast-4 |
| Asie-Pacifique (Malaisie) | ap-southeast-5 |
| Canada (Centre) | ca-central-1 |
| Canada-Ouest (Calgary) | ca-west-1 |
| Chine (Pékin) | cn-north-1 (`cnn1-az1` et `cnn1-az2` uniquement) |
| Chine (Ningxia) | cn-northwest-1 |
| Europe (Francfort) | eu-central-1 |
| Europe (Zurich) | eu-central-2 |
| Europe (Irlande) | eu-west-1 |
| Europe (Londres) | eu-west-2 |
| Europe (Paris) | eu-west-3 |
| Europe (Milan) | eu-south-1 |
| Europe (Espagne) | eu-south-2 |
| Europe (Stockholm) | eu-north-1 |
| Amérique du Sud (São Paulo) | sa-east-1 |
| Israël (Tel Aviv) | il-central-1 |
| Moyen-Orient (Bahreïn) | me-south-1 |
| Moyen-Orient (EAU) | me-central-1 |
| AWS GovCloud (USA Est) | us-gov-east-1 |
| AWS GovCloud (US-Ouest) | us-gov-west-1 |
## Conteneurs Windows sur AWS Fargate
Les conteneurs Windows Amazon ECS activés AWS Fargate sont pris en charge dans les versions suivantes Régions AWS. La zone de disponibilité prise en charge IDs est indiquée le cas échéant.
| Nom de la région | Région |
| --- | --- |
| USA Est (Ohio) | us-east-2 |
| USA Est (Virginie du Nord) | us-east-1 (`use1-az1`, `use1-az2`, `use1-az4`, `use1-az5` et `use1-az6` uniquement) |
| USA Ouest (Californie du Nord) | us-west-1 (`usw1-az1` et `usw1-az3` uniquement) |
| USA Ouest (Oregon) | us-west-2 |
| Afrique (Le Cap) | af-south-1 |
| Asie-Pacifique (Hong Kong) | ap-east-1 |
| Asie-Pacifique (Mumbai) | ap-south-1 |
| Asie-Pacifique (Hyderabad) | ap-south-2 |
| Asie-Pacifique (Osaka) | ap-northeast-3 |
| Asie-Pacifique (Séoul) | ap-northeast-2 |
| Asie-Pacifique (Singapour) | ap-southeast-1 |
| Asie-Pacifique (Sydney) | ap-southeast-2 |
| Asie-Pacifique (Melbourne) | ap-southeast-4 |
| Asie-Pacifique (Malaisie) | ap-southeast-5 |
| Asie-Pacifique (Tokyo) | ap-northeast-1 (`apne1-az1`, `apne1-az2` et `apne1-az4` uniquement) |
| Canada (Centre) | ca-central-1 (`cac1-az1` et `cac1-az2` uniquement) |
| Canada-Ouest (Calgary) | ca-west-1 |
| Chine (Pékin) | cn-north-1 (`cnn1-az1` et `cnn1-az2` uniquement) |
| Chine (Ningxia) | cn-northwest-1 |
| Europe (Francfort) | eu-central-1 |
| Europe (Zurich) | eu-central-2 |
| Europe (Irlande) | eu-west-1 |
| Europe (Londres) | eu-west-2 |
| Europe (Paris) | eu-west-3 |
| Europe (Milan) | eu-south-1 |
| Europe (Espagne) | eu-south-2 |
| Europe (Stockholm) | eu-north-1 |
| Amérique du Sud (São Paulo) | sa-east-1 |
| Israël (Tel Aviv) | il-central-1 |
| Moyen-Orient (EAU) | me-central-1 |
| Moyen-Orient (Bahreïn) | me-south-1 |