# Architect for AWS Fargate for Amazon ECS AWS Fargate AWS Fargate is a technology that you can use with Amazon ECS to run [containers](https://aws.amazon.com/containers/) without having to manage servers or clusters of Amazon EC2 instances. With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing. When you run your tasks and services with Fargate, you package your application in containers, specify the CPU and memory requirements, define networking and IAM policies, and launch the application. Each Fargate task has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task. You configure your task definitions for Fargate by setting the `requiresCompatibilities` task definition parameter to `FARGATE`. For more information, see [Capacity](task_definition_parameters.md#requires_compatibilities). Fargate offers platform versions for Amazon Linux 2 (platform version 1.3.0), Bottlerocket operating system (platform version 1.4.0), and Microsoft Windows 2019 Server Full and Core editions.Unless otherwise specified, the information applies to all Fargate platforms. For information about the Regions that support Linux containers on Fargate, see [Linux containers on AWS Fargate](AWS_Fargate-Regions.md#linux-regions). For information about the Regions that support Windows containers on Fargate, see [Windows containers on AWS Fargate](AWS_Fargate-Regions.md#windows-regions). ## Walkthroughs For information about how to get started using the console, see: + [Learn how to create an Amazon ECS Linux task for Fargate](getting-started-fargate.md) + [Learn how to create an Amazon ECS Windows task for Fargate](Windows_fargate-getting_started.md) For information about how to get started using the AWS CLI, see: + [Creating an Amazon ECS Linux task for the Fargate with the AWS CLI](ECS_AWSCLI_Fargate.md) + [Creating an Amazon ECS Windows task for the Fargate with the AWS CLI](ECS_AWSCLI_Fargate_windows.md) ## Capacity providers The following capacity providers are available: + Fargate + Fargate Spot - Run interruption tolerant Amazon ECS tasks at a discounted rate compared to the AWS Fargate price. Fargate Spot runs tasks on spare compute capacity. When AWS needs the capacity back, your tasks will be interrupted with a two-minute warning. For more information, see [Amazon ECS clusters for Fargate](fargate-capacity-providers.md). ## Task definitions Fargate tasks don't support all of the Amazon ECS task definition parameters that are available. Some parameters aren't supported at all, and others behave differently for Fargate tasks. For more information, see [Task CPU and memory](fargate-tasks-services.md#fargate-tasks-size). ## Platform versions AWS Fargate platform versions are used to refer to a specific runtime environment for Fargate task infrastructure. It is a combination of the kernel and container runtime versions. You select a platform version when you run a task or when you create a service to maintain a number of identical tasks. New revisions of platform versions are released as the runtime environment evolves, for example, if there are kernel or operating system updates, new features, bug fixes, or security updates. A Fargate platform version is updated by making a new platform version revision. Each task runs on one platform version revision during its lifecycle. If you want to use the latest platform version revision, then you must start a new task. A new task that runs on Fargate always runs on the latest revision of a platform version, ensuring that tasks are always started on secure and patched infrastructure. If a security issue is found that affects an existing platform version, AWS creates a new patched revision of the platform version and retires tasks running on the vulnerable revision. In some cases, you may be notified that your tasks on Fargate have been scheduled for retirement. For more information, see [Task retirement and maintenance for AWS Fargate on Amazon ECS](task-maintenance.md). For more information see [Fargate platform versions for Amazon ECS](platform-fargate.md). ## Service load balancing Your Amazon ECS service on AWS Fargate can optionally be configured to use Elastic Load Balancing to distribute traffic evenly across the tasks in your service. Amazon ECS services on AWS Fargate support the Application Load Balancer, Network Load Balancer, and Gateway Load Balancer load balancer types. Application Load Balancers are used to route HTTP/HTTPS (or layer 7) traffic. Network Load Balancers are used to route TCP or UDP (or layer 4) traffic. For more information, see [Use load balancing to distribute Amazon ECS service traffic](service-load-balancing.md). When you create a target group for these services, you must choose `ip` as the target type, not `instance`. This is because tasks that use the `awsvpc` network mode are associated with an elastic network interface, not an Amazon EC2 instance. For more information, see [Use load balancing to distribute Amazon ECS service traffic](service-load-balancing.md). Using a Network Load Balancer to route UDP traffic to your Amazon ECS on AWS Fargate tasks is only supported when using platform version 1.4 or later. ## Usage metrics You can use CloudWatch usage metrics to provide visibility into your accounts usage of resources. Use these metrics to visualize your current service usage on CloudWatch graphs and dashboards. AWS Fargate usage metrics correspond to AWS service quotas. You can configure alarms that alert you when your usage approaches a service quota. For more information about AWS Fargate service quotas, [Amazon ECS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html) in the *Amazon Web Services General Reference*.. For more information about AWS Fargate usage metrics, see [AWS Fargate usage metrics](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-fargate-usage.html). # Amazon ECS security considerations for when to use Fargate Security considerations for when to use Fargate We recommend that customers looking for strong isolation for their tasks use Fargate. Fargate runs each task in a hardware virtualization environment. This ensures that these containerized workloads do not share network interfaces, Fargate ephemeral storage, CPU, or memory with other tasks. For more information, see [Security Overview of AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf). # Fargate security best practices in Amazon ECS Fargate security best practices We recommend that you take into account the following best practices when you use AWS Fargate. For additional guidance, see [Security overview of AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf). ## Use AWS KMS to encrypt ephemeral storage for Fargate You should have your ephemeral storage encrypted by either AWS KMS or your own customer managed keys. For tasks that are hosted on Fargate using platform version `1.4.0` or later, each task receives 20 GiB of ephemeral storage. For more information, see [customer managed key (CMK)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html). You can increase the total amount of ephemeral storage, up to a maximum of 200 GiB, by specifying the `ephemeralStorage` parameter in your task definition. For such tasks that were launched on May 28, 2020 or later, the ephemeral storage is encrypted with an AES-256 encryption algorithm using an encryption key managed by Fargate. For more information, see [Storage options for Amazon ECS tasks](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html). **Example: Launching an task on Fargate platform version 1.4.0 with ephemeral storage encryption** The following command will launch a task on Fargate platform version 1.4. Because this task is launched as part of the cluster, it uses the 20 GiB of ephemeral storage that's automatically encrypted. ``` 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 ``` ## SYS\$1PTRACE capability for kernel syscall tracing with Fargate The default configuration of Linux capabilities that are added or removed from your container are provided by Docker. Tasks that are launched on Fargate only support adding the `SYS_PTRACE` kernel capability. The following video shows how to use this feature through the Sysdig [Falco](https://github.com/falcosecurity/falco) project. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/OYGKjmFeLqI/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/OYGKjmFeLqI) The code discussed in the previous video can be found on GitHub [here](https://github.com/paavan98pm/ecs-fargate-pv1.4-falco). ## Use Amazon GuardDuty with Fargate Runtime Monitoring Amazon GuardDuty is a threat detection service that helps protect your accounts, containers, workloads, and the data within your AWS environment. Using machine learning (ML) models, and anomaly and threat detection capabilities, GuardDuty continuously monitors different log sources and runtime activity to identify and prioritize potential security risks and malicious activities in your environment. Runtime Monitoring in GuardDuty protects workloads running on Fargate by continuously monitoring AWS log and networking activity to identify malicious or unauthorized behavior. Runtime Monitoring uses a lightweight, fully managed GuardDuty security agent that analyzes on-host behavior, such as file access, process execution, and network connections. This covers issues including escalation of privileges, use of exposed credentials, or communication with malicious IP addresses, domains, and the presence of malware on your Amazon EC2 instances and container workloads. For more information, see [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) in the *GuardDuty User Guide*. # Fargate security considerations for Amazon ECS Fargate security considerations Each task has a dedicated infrastructure capacity because Fargate runs each workload on an isolated virtual environment. Workloads that run on Fargate do not share network interfaces, ephemeral storage, CPU, or memory with other tasks. You can run multiple containers within a task including application containers and sidecar containers, or simply sidecars. A *sidecar* is a container that runs alongside an application container in an Amazon ECS task. While the application container runs core application code, processes running in sidecars can augment the application. Sidecars help you segregate application functions into dedicated containers, making it easier for you to update parts of your application. Containers that are part of the same task share resources for Fargate launch type because these containers will always run on the same host and share compute resources. These containers also share the ephemeral storage provided by Fargate. Linux containers in a task share network namespaces, including the IP address and network ports. Inside a task, containers that belong to the task can inter-communicate over localhost. The runtime environment in Fargate prevents you from using certain controller features that are supported on EC2 instances. Consider the following when you architect workloads that run on Fargate: + No privileged containers or access - Features such as privileged containers or access are currently unavailable on Fargate. This will affect uses cases such as running Docker in Docker. + Limited access to Linux capabilities - The environment in which containers run on Fargate is locked down. Additional Linux capabilities, such as CAP\$1SYS\$1ADMIN and CAP\$1NET\$1ADMIN, are restricted to prevent a privilege escalation. Fargate supports adding the [CAP\$1SYS\$1PTRACE](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params) Linux capability to tasks to allow observability and security tools deployed within the task to monitor the containerized application. + No access to the underlying host - Neither customers nor AWS operators can connect to a host running customer workloads. You can use ECS exec to run commands in or get a shell to a container running on Fargate. You can use ECS exec to help collect diagnostic information for debugging. Fargate also prevents containers from accessing the underlying host’s resources, such as the file system, devices, networking, and container runtime. + Networking - You can use security groups and network ACLs to control inbound and outbound traffic. Fargate tasks receive an IP address from the configured subnet in your VPC. # Fargate platform versions for Amazon ECS Fargate platform versions AWS Fargate platform versions are used to refer to a specific runtime environment for Fargate task infrastructure. It is a combination of the kernel and container runtime versions. You select a platform version when you run a task or when you create a service to maintain a number of identical tasks. New revisions of platform versions are released as the runtime environment evolves, for example, if there are kernel or operating system updates, new features, bug fixes, or security updates. A Fargate platform version is updated by making a new platform version revision. Each task runs on one platform version revision during its lifecycle. If you want to use the latest platform version revision, then you must start a new task. A new task that runs on Fargate always runs on the latest revision of a platform version, ensuring that tasks are always started on secure and patched infrastructure. If a security issue is found that affects an existing platform version, AWS creates a new patched revision of the platform version and retires tasks running on the vulnerable revision. In some cases, you may be notified that your tasks on Fargate have been scheduled for retirement. For more information, see [Task retirement and maintenance for AWS Fargate on Amazon ECS](task-maintenance.md). You specify the platform version when you run a task, or deploy a service. Consider the following when specifying a platform version: + You can specify a a specific version number, for example `1.4.0`, or `LATEST`. The **LATEST** Linux platform version is `1.4.0`. The **LATEST** Windows platform version is `1.0.0`. + If you want to update the platform version for a service, create a deployment. For example, assume that you have a service that runs tasks on the Linux platform version `1.3.0`. To change the service to run tasks on the Linux platform version `1.4.0`, you update your service and specify a new platform version. Your tasks are redeployed with the latest platform version and the latest platform version revision. For more information about deployments, see [Amazon ECS services](ecs_services.md). + If your service is scaled up without updating the platform version, those tasks receive the platform version that was specified on the service's current deployment. For example, assume that you have a service that runs tasks on the Linux platform version `1.3.0`. If you increase the desired count of the service, the service scheduler starts the new tasks using the latest platform version revision of platform version `1.3.0`. + New tasks always run on the latest revision of a platform version. This ensures tasks are always on secured and patched infrastructure. + The platform version numbers for Linux containers and Windows containers on Fargate are independent. For example, the behavior, features, and software used in platform version `1.0.0` for Windows containers on Fargate aren't comparable to those of platform version `1.0.0` for Linux containers on Fargate. + The following applies to Fargate Windows platform versions. Microsoft Windows Server container images must be created from a specific version of Windows Server. You must select the same version of Windows Server in the `platformFamily` when you run a task or create a service that matches the Windows Server container image. Additionally, you can provide a matching `operatingSystemFamily` in the task definition to prevent tasks from being run on the wrong Windows version. For more information, see [Matching container host version with container image versions](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility#matching-container-host-version-with-container-image-versions) on the Microsoft Learn website. # Migrating to Linux platform version 1.4.0 on Amazon ECS Migrating to Linux platform version 1.4.0 Consider the following when migrating your Amazon ECS on Fargate tasks from platform version `1.0.0`, `1.1.0`, `1.2.0`, or `1.3.0` to platform version `1.4.0`. It is best practice to confirm your task works properly on platform version `1.4.0` before you migrate the tasks. + The network traffic behavior to and from tasks has been updated. Starting with platform version 1.4.0, all Amazon ECS on Fargate tasks receive a single elastic network interface (referred to as the task ENI) and all network traffic flows through that ENI within your VPC. The traffic is visible to you through your VPC flow logs. For more information see [Amazon ECS task networking options for Fargate](fargate-task-networking.md). + If you use interface VPC endpoints, consider the following. + For container images hosted with Amazon ECR, you need the following endpoints. For more information, see [Amazon ECR interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) in the *Amazon Elastic Container Registry User Guide*. + **com.amazonaws.*region*.ecr.dkr** Amazon ECR VPC endpoint + **com.amazonaws.*region*.ecr.api** Amazon ECR VPC endpoint + Amazon S3 gateway endpoint + When your task definition references Secrets Manager secrets to retrieve sensitive data for your containers, you must create the interface VPC endpoints for Secrets Manager. For more information, see [Using Secrets Manager with VPC Endpoints](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html) in the *AWS Secrets Manager User Guide*. + When your task definition references Systems Manager Parameter Store parameters to retrieve sensitive data for your containers, you must create the interface VPC endpoints for Systems Manager. For more information, see [Improve the security of EC2 instances by using VPC endpoints for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) in the *AWS Systems Manager User Guide*. + The security group for the Elastic Network Interface (ENI) associated with your task needs the security group rules to allow traffic between the task and the VPC endpoints. # Fargate Linux platform version change log Linux Platform version change log The following are the available Linux platform versions. For information about platform version deprecation, see [AWS Fargate Linux platform version deprecation](platform-versions-retired.md). ## 1.4.0 The following is the changelog for platform version `1.4.0`. + Beginning on November 5, 2020, any new Amazon ECS task launched on Fargate using platform version `1.4.0` will be able to use the following features: + When using Secrets Manager to store sensitive data, you can inject a specific JSON key or a specific version of a secret as an environment variable or in a log configuration. For more information, see [Pass sensitive data to an Amazon ECS container](specifying-sensitive-data.md). + Specify environment variables in bulk using the `environmentFiles` container definition parameter. For more information, see [Pass an individual environment variable to an Amazon ECS container](taskdef-envfiles.md). + Tasks run in a VPC and subnet enabled for IPv6 will be assigned both a private IPv4 address and an IPv6 address. For more information, see [Amazon ECS task networking options for Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html). + The task metadata endpoint version 4 provides additional metadata about your task and container including the task launch type, the Amazon Resource Name (ARN) of the container, and the log driver and log driver options used. When querying the `/stats` endpoint you also receive network rate stats for your containers. For more information, see [Task metadata endpoint version 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html). + Beginning on July 30, 2020, any new Amazon ECS task launched on Fargate using platform version `1.4.0` will be able to route UDP traffic using a Network Load Balancer to their Amazon ECS on Fargate tasks. For more information, see [Use load balancing to distribute Amazon ECS service traffic](service-load-balancing.md). + Beginning on May 28, 2020, any new Amazon ECS task launched on Fargate using platform version `1.4.0` will have its ephemeral storage encrypted with an AES-256 encryption algorithm using an AWS owned encryption key. For more information, see [Fargate task ephemeral storage for Amazon ECS](fargate-task-storage.md) and [Storage options for Amazon ECS tasks](using_data_volumes.md). + Added support for using Amazon EFS file system volumes for persistent task storage. For more information, see [Use Amazon EFS volumes with Amazon ECS](efs-volumes.md). + The ephemeral task storage has been increased to a minimum of 20 GB for each task. For more information, see [Fargate task ephemeral storage for Amazon ECS](fargate-task-storage.md). + The network traffic behavior to and from tasks has been updated. Starting with platform version 1.4.0, all Fargate tasks receive a single elastic network interface (referred to as the task ENI) and all network traffic flows through that ENI within your VPC and will be visible to you through your VPC flow logs. For more information about networking for the Amazon EC2 launch type, see [Amazon ECS task networking options for EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). For more information about networking for the Fargate, see [Amazon ECS task networking options for Fargate](fargate-task-networking.md). + Task ENIs add support for jumbo frames. Network interfaces are configured with a maximum transmission unit (MTU), which is the size of the largest payload that fits within a single frame. The larger the MTU, the more application payload can fit within a single frame, which reduces per-frame overhead and increases efficiency. Supporting jumbo frames will reduce overhead when the network path between your task and the destination supports jumbo frames, such as all traffic that remains within your VPC. + CloudWatch Container Insights will include network performance metrics for Fargate tasks. For more information, see [Monitor Amazon ECS containers using Container Insights with enhanced observability](cloudwatch-container-insights.md). + Added support for the task metadata endpoint version 4 which provides additional information for your Fargate tasks, including network stats for the task and which Availability Zone the task is running in. For more information, see [Amazon ECS task metadata endpoint version 4](task-metadata-endpoint-v4.md) and [Amazon ECS task metadata endpoint version 4 for tasks on Fargate](task-metadata-endpoint-v4-fargate.md). + Added support for the `SYS_PTRACE` Linux parameter in container definitions. For more information, see [Linux parameters](task_definition_parameters.md#container_definition_linuxparameters). + The Fargate container agent replaces the use of the Amazon ECS container agent for all Fargate tasks. Usually, this change does not have an effect on how your tasks run. + The container runtime is now using Containerd instead of Docker. Most likely, this change does not have an effect on how your tasks run. You will notice that some error messages that originate with the container runtime changes from mentioning Docker to more general errors. For more information, see [Amazon ECS stopped task error messages](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html). + Based on Amazon Linux 2. # AWS Fargate Linux platform version deprecation Linux platform version deprecation **Important** We are ending support for PV 1.3.0 in Fargate on June 30, 2026. Starting June 15, 2026, we will make the platform version 1.3.0 as Retired. At that time, you will not be able to launch new tasks or create new services configured with platform version 1.3.0, but your existing tasks will continue running. On June 30, 2026, we will terminate all the remaining running tasks configured with platform version 1.3.0. For information about how to migrate to platform version 1.4, see [Migrating to Linux platform version 1.4.0 on Amazon ECS](platform-version-migration.md). The following table lists Linux platform versions that AWS Fargate has deprecated or have been scheduled for deprecation. These platform versions remain available until the published deprecation date. A *force update date* is provided for each platform version scheduled for deprecation. On the force update date, any service using the `LATEST` platform version that is pointed to a platform version that is scheduled for deprecation will be updated using the force new deployment option. When the service is updated using the force new deployment option, all tasks running on a platform version scheduled for deprecation are stopped and new tasks are launched using the platform version that the `LATEST` tag points to at that time. Standalone tasks or services with an explicit platform version set are not affected by the force update date. For information about how to migrate to latest platform version, see [Migrating to Linux platform version 1.4.0 on Amazon ECS](platform-version-migration.md). After a platform version reaches the *deprecation date*, the platform version will no longer be available for new tasks or services. Any standalone tasks or services which explicitly use a deprecated platform version will continue using that platform version until the tasks are stopped. After the deprecation date, a deprecated platform version will no longer receive any security updates or bug fixes. | Platform version | Force update date | Deprecation date | | --- | --- | --- | | 1.0.0 | October 26, 2020 | December 14, 2020 | | 1.1.0 | October 26, 2020 | December 14, 2020 | | 1.2.0 | October 26, 2020 | December 14, 2020 | | 1.3.0 | | June 15, 2026 | For information about current platform versions, see [Fargate platform versions for Amazon ECS](platform-fargate.md). ## Deprecated Fargate Linux versions change log ### 1.3.0 The following is the changelog for platform version `1.3.0`. + Beginning on Sept 30, 2019, any new Fargate task that is launched supports the `awsfirelens` log driver. Configure the FireLens for Amazon ECS to use task definition parameters to route logs to an AWS service or AWS Partner Network (APN) destination for log storage and analytics. For more information, see [Send Amazon ECS logs to an AWS service or AWS Partner](using_firelens.md). + Added task recycling for Fargate tasks, which is the process of refreshing tasks that are a part of an Amazon ECS service. For more information, [Task retirement and maintenance for AWS Fargate on Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-maintenance.html). + Beginning on March 27, 2019, any new Fargate task that is launched can use additional task definition parameters that you use to define a proxy configuration, dependencies for container startup and shutdown as well as a per-container start and stop timeout value. For more information, see [Proxy configuration](task_definition_parameters.md#proxyConfiguration), [Container dependency](task_definition_parameters.md#container_definition_dependson), and [Container timeouts](task_definition_parameters.md#container_definition_timeout). + Beginning on April 2, 2019, any new Fargate task that is launched supports injecting sensitive data into your containers by storing your sensitive data in either AWS Secrets Manager secrets or AWS Systems Manager Parameter Store parameters and then referencing them in your container definition. For more information, see [Pass sensitive data to an Amazon ECS container](specifying-sensitive-data.md). + Beginning on May 1, 2019, any new Fargate task that is launched supports referencing sensitive data in the log configuration of a container using the `secretOptions` container definition parameter. For more information, see [Pass sensitive data to an Amazon ECS container](specifying-sensitive-data.md). + Beginning on May 1, 2019, any new Fargate task that is launched supports the `splunk` log driver in addition to the `awslogs` log driver. For more information, see [Storage and logging](task_definition_parameters.md#container_definition_storage). + Beginning on July 9, 2019, any new Fargate tasks that is launched supports CloudWatch Container Insights. For more information, see [Monitor Amazon ECS containers using Container Insights with enhanced observability](cloudwatch-container-insights.md). + Beginning on December 3, 2019, the Fargate Spot capacity provider is supported. For more information, see [Amazon ECS clusters for Fargate](fargate-capacity-providers.md). + Based on Amazon Linux 2. ### 1.2.0 The following is the changelog for platform version `1.2.0`. **Note** Platform version `1.2.0` is no longer available. For information about platform version deprecation, see [AWS Fargate Linux platform version deprecation](#platform-versions-retired). + Added support for private registry authentication using AWS Secrets Manager. For more information, see [Using non-AWS container images in Amazon ECS](private-auth.md). ### 1.1.0 The following is the changelog for platform version `1.1.0`. **Note** Platform version `1.1.0` is no longer available. For information about platform version deprecation, see [AWS Fargate Linux platform version deprecation](#platform-versions-retired). + Added support for the Amazon ECS task metadata endpoint. For more information, see [Amazon ECS task metadata available for tasks on Fargate](fargate-metadata.md). + Added support for Docker health checks in container definitions. For more information, see [Health check](task_definition_parameters.md#container_definition_healthcheck). + Added support for Amazon ECS service discovery. For more information, see [Use service discovery to connect Amazon ECS services with DNS names](service-discovery.md). ### 1.0.0 The following is the changelog for platform version `1.0.0`. **Note** Platform version `1.0.0` is no longer available. For information about platform version deprecation, see [AWS Fargate Linux platform version deprecation](#platform-versions-retired). + Based on Amazon Linux 2017.09. + Initial release. # Fargate Windows platform version change log Windows platform version change log The following are the available platform versions for Windows containers. ## 1.0.0 The following is the changelog for platform version `1.0.0`. + Initial release for support on the following Microsoft Windows Server operating systems: + Windows Server 2019 Full + Windows Server 2019 Core + Windows Server 2022 Full + Windows Server 2022 Core # Windows containers on Fargate considerations for Amazon ECS The following are the differences and considerations to know when you run Windows containers on AWS Fargate. If you need to run tasks on Linux and Windows containers, then you need to create separate task definitions for each operating system. AWS handles the operating system license management, so you do not need any additional Microsoft Windows Server licenses. Windows containers on AWS Fargate supports the following operating systems: + Windows Server 2019 Full + Windows Server 2019 Core + Windows Server 2022 Full + Windows Server 2022 Core Windows containers on AWS Fargate supports the awslogs driver. For more information, see [Send Amazon ECS logs to CloudWatch](using_awslogs.md). The following features are not supported on Windows containers on Fargate: + Amazon FSx + ENI trunking + gMSAs for Windows Containers + App Mesh service and proxy integration for tasks + Firelens log router integration for tasks + EFS volumes + EBS volumes + The following task definition parameters: + `maxSwap` + `swappiness` + `environmentFiles` + The Fargate Spot capacity provider + Image volumes The Dockerfile `volume` option is ignored. Instead, use bind mounts in your task definition. For more information, see [Use bind mounts with Amazon ECS](bind-mounts.md). + The task-level CPU and memory parameters are ignored for Windows containers. We recommend specifying container-level resources for Windows containers. + memory for task + mermoryReservation on containers + Restart policies on containers + You can't update the platformFamily of a service. # Linux containers on Fargate container image pull behavior for Amazon ECS Linux containers on Fargate container image pull behavior Every Fargate task runs on its own single use, single tenant instance. When you run Linux containers on Fargate, container images or container image layers are not cached on the instance. Therefore, for each container image defined in the task, the whole container image needs to be pulled from the container image registry for each Fargate task. The time it takes to pull the images is directly correlated to the time taken to start an Fargate task. Take the following into account to optimize the image pull time. **Container image proximity** To reduce the time it takes to download container images, locate the data as close to the compute as possible. Pulling a container image over the internet or across AWS Regions might impact the download time. We recommend that you store the container image in the same Region where the task will run. If you store the container image in Amazon ECR, use a VPC interface endpoint to further reduce the image pull time. For more information, see [Amazon ECR interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) in the *Amazon ECR User Guide*. **Container image size reduction** The size of a container image directly impacts the download time. Reducing the size of the container image or the number of container image layers, can reduce the time it takes for an image to download. Lightweight base images (such as the minimal Amazon Linux 2023 container image) can be significantly smaller than those based on traditional operating system base images. For more information about the minimal image, see [AL2023 Minimal container image](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html) in the *Amazon Linux 2023 User Guide*. **Alternative compression algorithms** Container image layers are often compressed when pushed to a container image registry. Compressing the container image layer reduces the amount of data that has to be transferred across the network and stored in the container image registry. After a container image layer has been downloaded to an instance by the container runtime, that layer is decompressed. The compression algorithm used and the amount of vCPUs available to the runtime impact the time it takes to decompress the container image. On Fargate, you can increase the size of the task or leverage the more performant zstd compression algorithm to reduce the time taken for decompression. For more information, see [zstd](https://github.com/facebook/zstd) on GitHub. For information about how to implement the images for Fargate, see [Reducing AWS Fargate Startup Times with zstd Compressed Container Images](https://aws.amazon.com/blogs/containers/reducing-aws-fargate-startup-times-with-zstd-compressed-container-images/). **Lazy Loading container images** For large container images (> 250mb), it might be optimal to lazy load a container image rather than downloading all of the container image. On Fargate, you can use Seekable OCI (SOCI) to lazy load a container image from a container image registry. For more information, see [soci-snapshotter](https://github.com/awslabs/soci-snapshotter) on GitHub and [Lazy loading container images using Seekable OCI (SOCI)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-soci-images). # Windows containers on Fargate container image pull behavior for Amazon ECS Windows containers on Fargate container image pull behavior Fargate Windows caches the most recent month's, and the previous month's, servercore base image provided by Microsoft. These images match the KB/Build number patches updated each Patch Tuesday. For example, on April 9, 2024, Microsoft released KB5036896 (17763.5696) for Windows Server 2019. The previous month KB on March 12, 2024 was KB5035849 (17763.5576). So for the platforms `WINDOWS_SERVER_2019_CORE` and `WINDOWS_SERVER_2019_FULL` the following container images were cached:: + `mcr.microsoft.com/windows/servercore:ltsc2019` + ` mcr.microsoft.com/windows/servercore:10.0.17763.5696` + `mcr.microsoft.com/windows/servercore:10.0.17763.5576` Additionally, on April 9, 2024, Microsoft released KB5036909 (20348.2402) for Windows Server 2022. The previous month KB on March 12, 2024 was KB5035857 (20348.2340). So for the platforms `WINDOWS_SERVER_2022_CORE` and `WINDOWS_SERVER_2022_FULL` the following container images were cached: + `mcr.microsoft.com/windows/servercore:ltsc2022` + `mcr.microsoft.com/windows/servercore:10.0.20348.2402` + `mcr.microsoft.com/windows/servercore:10.0.20348.2340` # Fargate task ephemeral storage for Amazon ECS Fargate task ephemeral storage When provisioned, each Amazon ECS task hosted on Linux containers on AWS Fargate receives the following ephemeral storage for bind mounts. This can be mounted and shared among containers that use the `volumes`, `mountPoints`, and `volumesFrom` parameters in the task definition. This isn't supported for Windows containers on AWS Fargate. ## Fargate Linux container platform versions ### Version 1.4.0 or later By default, Amazon ECS tasks that are hosted on Fargate using platform version `1.4.0` or later receive a minimum of 20 GiB of ephemeral storage. The total amount of ephemeral storage can be increased, up to a maximum of 200 GiB. You can do this by specifying the `ephemeralStorage` parameter in your task definition. The pulled, compressed, and the uncompressed container image for the task is stored on the ephemeral storage. To determine the total amount of ephemeral storage your task has to use, you must subtract the amount of storage your container image uses from the total amount of ephemeral storage your task is allocated. For tasks that use platform version `1.4.0` or later that are launched on May 28, 2020 or later, the ephemeral storage is encrypted with an AES-256 encryption algorithm. This algorithm uses an AWS owned encryption key, or you can create your own customer managed key. For more information, see [Customer managed keys for AWS Fargate ephemeral storage](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html). For tasks that use platform version `1.4.0` or later that are launched on November 18, 2022 or later, the ephemeral storage usage is reported through the task metadata endpoint. Your applications in your tasks can query the task metadata endpoint version 4 to get their ephemeral storage reserved size and the amount used. Additionally, the ephemeral storage reserved size and the amount used are sent to Amazon CloudWatch Container Insights if you turn on Container Insights. **Note** Fargate reserves space on disk. It is only used by Fargate. You aren't billed for it. It isn't shown in these metrics. However, you can see this additional storage in other tools such as `df`. ### Version 1.3.0 or earlier For Amazon ECS on Fargate tasks that use platform version `1.3.0` or earlier, each task receives the following ephemeral storage. + 10 GB of Docker layer storage **Note** This amount includes both compressed and uncompressed container image artifacts. + An additional 4 GB for volume mounts. This can be mounted and shared among containers that use the `volumes`, `mountPoints`, and `volumesFrom` parameters in the task definition. ## Fargate Windows container platform versions ### Version 1.0.0 or later By default, Amazon ECS tasks that are hosted on Fargate using platform version `1.0.0` or later receive a minimum of 20 GiB of ephemeral storage. The total amount of ephemeral storage can be increased, up to a maximum of 200 GiB. You can do this by specifying the `ephemeralStorage` parameter in your task definition. The pulled, compressed, and the uncompressed container image for the task is stored on the ephemeral storage. To determine the total amount of ephemeral storage that your task has to use, you must subtract the amount of storage that your container image uses from the total amount of ephemeral storage your task is allocated. For more information, see [Use bind mounts with Amazon ECS](bind-mounts.md). # Customer managed keys for AWS Fargate ephemeral storage for Amazon ECS Customer managed keys for AWS Fargate ephemeral storage AWS Fargate supports customer managed keys to encrypt data for Amazon ECS tasks stored in ephemeral storage to help regulation-sensitive customers meet their internal security policies. Customers still get the serverless benefit of Fargate, while giving enhanced visibility on self-managed storage encryption to compliance auditors. While Fargate has Fargate-managed ephemeral storage encryption by default, customers can also use their own self-managed keys when encrypting sensitive data like financial or health related information. You can import your own keys into AWS KMS or create the keys in AWS KMS. These self-managed keys are stored in AWS KMS and perform standard AWS KMS lifecycle actions such as rotate, disable, and delete. You can audit key access and usage in CloudTrail logs. By default, KMS key supports 50,000 grants per key. Fargate uses a single AWS KMS grant per customer managed key task, so it supports up to 50,000 concurrent tasks for a key. If you want to increase this number, you can ask for a limit increase, which is approved on a case-by-case basis. Fargate doesn't charge anything extra for using customer managed keys. You're only charged the standard price for using AWS KMS keys for storage and API requests. **Topics** + [ # Create an encryption key for Fargate ephemeral storage for Amazon ECS ](fargate-create-storage-key.md) + [ # Managing AWS KMS keys for Fargate ephemeral storage for Amazon ECS ](fargate-managing-kms-key.md) # Create an encryption key for Fargate ephemeral storage for Amazon ECS Create an encryption key for Fargate ephemeral storage Create a customer managed key to encrypt data stored on Fargate ephemeral storage. **Note** Fargate ephemeral storage encryption with customer managed keys isn't available for Windows task clusters. Fargate ephemeral storage encryption with customer managed keys isn't available on `platformVersions` earlier than `1.4.0`. Fargate reserves space on an ephemeral storage that's only used by Fargate, and you're not billed for the space. Allocation might differ from non-customer managed key tasks, but the total space remains the same. You can view this change in tools like `df`. Multi-Region keys are not supported for Fargate ephemeral storage. KMS key aliases are not supported for Fargate ephemeral storage. To create a customer managed key (CMK) to encrypt ephemeral storage for Fargate in AWS KMS, follow these steps. 1. Navigate to the [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms). 1. Follow the instructions for [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). 1. When creating your AWS KMS key, make sure to provide Fargate service relevant AWS KMS operation permissions in the key policies. The following API operations must be permitted in the policy to use your customer managed key with your Amazon ECS cluster resources. + `kms:GenerateDataKeyWithoutPlainText` ‐ Call `GenerateDataKeyWithoutPlainText` to generate an encrypted data key from the provided AWS KMS key. + `kms:CreateGrant` ‐ Adds a grant to a customer managed key. Grants control access to a specified AWS KMS key, which allows access to grant operations that Amazon ECS Fargate requires. For more information about [Using Grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html), see the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). This allows Amazon ECS Fargate to do the following: + Call `Decrypt` to AWS KMS to get the encryption key to decrypt the ephemeral storage data. + Set up a retiring principal to allow the service to `RetireGrant`. + `kms:DescribeKey` ‐ Provides the customer managed key details to allow Amazon ECS to validate the key if it's symmetric and enabled. The following example shows a AWS KMS key policy that you would apply to the target key for encryption. To use the example policy statements, replace the *user input placeholders* with your own information. As always, only configure the permissions that you need, but you'll need to provide AWS KMS with permissions to at least one user to avoid errors. ``` { "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": "*" } ``` Fargate tasks use the `aws:ecs:clusterAccount` and `aws:ecs:clusterName` encryption context keys for cryptographic operations with the key. Customers should add these permissions to restrict access to a specific account and/or cluster. Use the cluster name and not the ARN when you specify the cluster. For more information, see [Encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) in the [AWS KMS Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). When creating or updating a cluster, you have the option to use the condition key `fargateEphemeralStorageKmsKeyId`. This condition key allows customers to have more granular control of the IAM policies. Updates to the `fargateEphemeralStorageKmsKeyId` configuration only take effect on new service deployments. The following is an example of allowing customers to grant permissions to only a specific set of approved AWS KMS keys. ------ #### [ 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" } } } ] } ``` ------ Next is an example for denying attempts to remove AWS KMS keys that are already associated with a cluster. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": [ "ecs:CreateCluster", "ecs:UpdateCluster" ], "Resource": "*", "Condition": { "Null": { "ecs:fargate-ephemeral-storage-kms-key": "true" } } } } ``` ------ Customers can see if their unmanaged tasks or service tasks are encrypted using the key by using the AWS CLI `describe-tasks`, `describe-cluster`, or `describe-services` commands. For more information, see [Condition keys for AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html) in the [AWS KMS Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). ------ #### [ AWS Management Console ] 1. Open the console at [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Choose **Clusters** in the left navigation and either **Create cluster** in the top right, or choose an existing cluster. For an existing cluster, choose **Update cluster** in the top right. 1. Under the **Encryption** section of the workflow, you'll have the option to select your AWS KMS key under **Managed storage** and **Fargate ephemeral storage**. You can also choose to **Create an AWS KMS key** from here. 1. Choose **Create** once you finish creating your new cluster or **Update**, if you were updating an existing one. ------ #### [ AWS CLI ] The following is an example of creating a cluster and configuring your Fargate ephemeral storage using the AWS CLI (replace the *red* values with your own): ``` 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 ] The following is an example template of creating a cluster and configuring your Fargate ephemeral storage using the CloudFormation (replace the *red* values with your own): ``` 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" ``` ------ # Managing AWS KMS keys for Fargate ephemeral storage for Amazon ECS Managing AWS KMS keys for Fargate ephemeral storage After creating or importing your AWS KMS key to encrypt your Fargate ephemeral storage, you manage it the same way you would any other AWS KMS key. **Automatic rotation of AWS KMS keys** You can enable automatic key rotation or rotate them manually. Automatic key rotation rotates the key for you yearly by generating new cryptographic material for the key. AWS KMS also saves all previous versions of the cryptographic material, so you'll be able to decrypt any data that used the earlier key versions. Any rotated material won't be deleted by AWS KMS until you delete the key. Automatic key rotation is optional and can be enabled or disabled at any time. **Disabling or revoking AWS KMS keys** If you disable a customer managed key in AWS KMS, it doesn't have any impact on running tasks, and they continue to function through their lifecycle. If a new task uses the disabled or revoked key, the task fails since it can't access the key. You should set a CloudWatch alarm or similar to make sure a disabled key is never needed to decrypt already encrypted data. **Deleting AWS KMS keys** Deleting keys should always be a last resort and should only be done if you're certain the deleted key is never needed again. New tasks that try to use the deleted key will fail because they can't access it. AWS KMS advises disabling a key instead of deleting it. If you feel it's necessary to delete a key, we suggest disabling it first and setting a CloudWatch alarm to make sure it isn't needed. If you do delete a key, AWS KMS supplies at least seven days to change your mind. **Auditing AWS KMS key access** You can use CloudTrail logs to audit access to your AWS KMS key. You're able to check the AWS KMS operations `CreateGrant`, `GenerateDataKeyWithoutPlaintext`, and `Decrypt`. These operations also show the `aws:ecs:clusterAccount` and `aws:ecs:clusterName` as part of the `EncryptionContext` logged in CloudTrail. The following are example CloudTrail events for `GenerateDataKeyWithoutPlaintext`, `GenerateDataKeyWithoutPlaintext (DryRun)`, `CreateGrant`, `CreateGrant (DryRun)`, and `RetireGrant` (replace the *red* values with your own). ------ #### [ 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" } ``` ------ # Task retirement and maintenance for AWS Fargate on Amazon ECS Task retirement and maintenance AWS is responsible for maintaining the underlying infrastructure for AWS Fargate. AWS determines when a platform version revision needs to be replaced with a new revision for the infrastructure. This is known as task retirement. AWS sends a task retirement notification when a platform version revision is retired. We routinely update our supported platform versions to introduce a new revision containing updates to the Fargate runtime software and underlying dependencies such as the operating system and container runtime. After a newer revision is made available, we retire the older revision in order to ensure all customer workloads run on the most up to date revision of the Fargate platform version. When a revision is retired, all tasks running on that revision are stopped. Amazon ECS tasks can be categorized as either service tasks or standalone tasks. Service tasks are deployed as part of a service and controlled by the Amazon ECS schedule. For more information, see [Amazon ECS services](ecs_services.md). Standalone tasks are tasks started by the Amazon ECS `RunTask` API, either directly or by an external scheduler such as scheduled tasks (which are started by Amazon EventBridge), AWS Batch, or AWS Step Functions. You do not need to take any actions in response to task retirement for your service tasks because the Amazon ECS scheduler automatically replaces the tasks. For standalone tasks, you may need to perform additional handling in response to task retirement. For more information, see [Can Amazon ECS automatically handle standalone tasks?](#task-retirement-standalone-tasks). For service tasks, you do not need to take any action to task retirement unless you want to replace these tasks before AWS does. When the Amazon ECS scheduler stops the tasks, it uses the `maximumPercent` and launches a new task in an attempt to maintain the desired count for the service. Follow best practices to minimize the impact of task retirement. The default `maximumPercent` value for a service using the REPLICA service scheduler is 200%. Therefore, when AWS Fargate starts retiring tasks, Amazon ECS first schedules a new task, and then waits for it to be running, before retiring an old task. When you set the `maximumPercent` value to 100%, Amazon ECS stops the task first, then replaces it. For standalone task retirement, AWS stops the task on or after the task retirement date. Amazon ECS doesn’t launch a replacement task when a task is stopped. If you need these tasks to continue to run, you need to stop the running tasks and launch a replacement task before the time indicated in the notification. Therefore, we recommend that customers monitor the state of standalone tasks and if required, implement logic to replace the stopped tasks. When a task is stopped in any of the scenarios, you can run `describe-tasks`. The `stoppedReason` in the response is `ECS is performing maintenance on the underlying infrastructure hosting the task`. Task maintenance applies when there is a new platform version revision needs to be replaced with a new revision. If there is an issue with an underlying Fargate host, Amazon ECS replaces the host without a task retirement notice. ## Task retirement notice overview When AWS marks a platform version revision as needing to be retired, we identify all of the tasks that are running on that platform version revision in all Regions. The following illustration shows the lifecycle of a Fargate platform version revision from a new revision launch to the platform revision retirement. ![\[Diagram showing the Fargate task retirement lifecycle.\]](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/images/fargate-task-retirement.png) The following information provides details. + After a new platform version revision is launched, all new tasks are scheduled on this revision. + Existing tasks that have been scheduled and running remain on the revision they were originally placed on for the duration of the task and aren't migrated to the new revision. + New tasks, for example as part of an update to a service or Fargate task retirement, are placed on to latest platform version revision available at the time of launch. Task retirement notifications are sent through AWS Health Dashboard as well as through an email to the registered email address and includes the following information: + The task retirement date - The task is stopped on or after this date. + For standalone tasks, the IDs of the tasks. + For service tasks, the ID of the cluster where the service runs and the IDs of the service. + The next steps you need to take. Typically, we send one notification each for service and standalone tasks in each AWS Region. However, in certain cases you might receive more than one event for each task type, for example when there are too many tasks to be retired that will surpass limits in our notification mechanisms. You can identify tasks scheduled for retirement in the following ways: + The Health Dashboard AWS Health notifications can be sent through Amazon EventBridge to archival storage such as Amazon Simple Storage Service, take automated actions such as run an AWS Lambda function, or other notification systems such as Amazon Simple Notification Service. For more information, see [Monitoring AWS Health events with Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). For sample configuration to send notifications to Amazon Chime, Slack, or Microsoft Teams, see the [AWS Health Aware](https://github.com/aws-samples/aws-health-aware) repository on GitHub. The following is a sample EventBridge event. ``` { "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" } } ] } } ``` + Email An email is sent to the registered email for the AWS account ID. For information about how to prepare for task retirement, see [Prepare for AWS Fargate task retirement on Amazon ECS](prepare-task-retirement.md). ## Can I opt-out of task retirement? No. As part of the AWS shared responsibility model, AWS is responsible for managing and maintaining the underlying infrastructure for AWS Fargate. This includes performing periodic platform updates to ensure security and stability. These updates are automatically applied by AWS and are not something customers can opt-out of. This is a key benefit of using a AWS Fargate compared to running your workloads on EC2 instances, the responsibility for maintaining the underlying platform is handled by AWS. This model allows you to focus on your applications rather than infrastructure maintenance. By automatically applying these platform updates, AWS is able to keep the Fargate environment up-to-date and secure, without any action required from you as the customer. This helps provide a reliable and secure containerized environment for running your workloads on Fargate. ## Can I get task retirement notifications through other AWS services? AWS sends a task retirement notification to the Health Dashboard and to the primary email contact on the AWS account. The Health Dashboard provides a number of integrations into other AWS services, including EventBridge. You can use EventBridge to automate the visibility of the notices (For example. forwarding the message to a ChatOps tool). For more information, see [Solution overview: Capturing task retirement notifications](https://aws.amazon.com/blogs/containers/improving-operational-visibility-with-aws-fargate-task-retirement-notifications/). ## Can I change a task retirement after it is scheduled? No. The schedule is based on the task retirement wait time which has a default of 7 days. If you need more time, you can choose to configure the wait period to 14 days. For more information, see [Step 2: Capture task retirement notifications to alert teams and take actions](prepare-task-retirement.md#prepare-task-retirement-capture-task-events). As of 12/18/2025, Amazon ECS enables you to configure [Amazon EC2 event windows](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) for your Fargate tasks. If you need precise control over the exact timing of task retirements, for example, scheduling them over weekends to avoid disruption during business hours, you can configure Amazon EC2 event windows for your tasks, services, or clusters, see [Step 1: Set the task wait time or use Amazon EC2 event windows](prepare-task-retirement.md#prepare-task-retirement-set-time). Note that the change in this configuration applies to retirements that will be scheduled in the future. Currently scheduled retirements are not impacted. Furthermore, when you configure an Amazon EC2 event window for your Fargate tasks, it takes precedence over your task retirement wait time configuration. If you have any further concerns, contact Support. ## How does Amazon ECS handle tasks that are part of a service? For service tasks, you do not need to take any action in response to task retirement unless you want to replace these tasks before AWS does. When the Amazon ECS scheduler stops the tasks, it uses the minimum healthy percent and launches a new task in an attempt to maintain the desired count for the service. To minimalize the impact of Fargate task retirement, workloads should be deployed following Amazon ECS best practices. For example, when deploying a stateless application as an Amazon ECS service, such as a web or API server, customers should deploy multiple task replicas and set the minimumHealthyPercent to 100%. By default, the minimum healthy percent of a service is 100 percent. Therefore, when Fargate starts retiring tasks, Amazon ECS first schedules a new task and waits for it to be running, before retiring an old task. Service tasks are routinely replaced as part of task retirement in the same way when you scale the service, deploy configuration changes, or deploy task definition revisions. To prepare for the task retirement process, see [Prepare for AWS Fargate task retirement on Amazon ECS](prepare-task-retirement.md). ## Can Amazon ECS automatically handle standalone tasks? No. AWS can't create a replacement task for standalone tasks which are started by `RunTask`, scheduled tasks (for example through EventBridge Scheduler), AWS Batch, or AWS Step Functions. Amazon ECS manages only tasks that are part of a service. ## Troubleshooting service availability during task retirement If Amazon ECS cannot start a replacement task during task retirement, your service availability may be impacted. This can occur due to incorrect customer configuration, such as: + Missing or incorrectly configured IAM roles + Insufficient capacity in the target subnets + Security group misconfigurations + Task definition errors When Amazon ECS cannot launch replacement tasks, the retired tasks are stopped without replacement, reducing your service's available capacity and potentially causing service disruption. Monitor your service's task count and Amazon CloudWatch metrics to ensure replacement tasks are successfully launched during retirement events. # Prepare for AWS Fargate task retirement on Amazon ECS In order to prepare for task retirement, perform the following operations: 1. Set the task retirement wait period or use Amazon EC2 event windows. 1. Capture task retirement notifications to notify team members. 1. You can ensure all your services' tasks run on the latest platform revision by updating the service with the force-deployment option. This step is optional. ## Step 1: Set the task wait time or use Amazon EC2 event windows You have two account settings options to configure the time that Fargate starts task retirements: `fargateTaskRetirementWaitPeriod` and `fargateEventWindows`. **Using fargateTaskRetirementWaitPeriod account setting** You can configure the time that Fargate starts the task retirement. The default wait period is 7 days. For workloads that require immediate application of the updates, choose the immediate setting (`0`). If you need more time, configure the `7`, or `14` day option. We recommend that you choose a shorter waiting period in order to pick up newer platform versions revisions sooner. Configure the wait period by running `put-account-setting-default` or `put-account-setting` as the root user or an administrative user. Use the `fargateTaskRetirementWaitPeriod` option for the `name` and the `value` option set to one of the following values: + `0` - AWS sends the notification, and immediately starts to retire the affected tasks. + `7` - AWS sends the notification, and waits 7 calendar days before starting to retire the affected tasks. This is the default. + `14` - AWS sends the notification, and waits 14 calendar days before starting to retire the affected tasks. For more information, see, [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html) and [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) in the *Amazon Elastic Container Service API Reference*. **Using fargateEventWindows account setting** As of 12/18/2025, Amazon ECS enables you to configure [Amazon EC2 event windows](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) for your Fargate tasks. If you need precise control over the exact timing of task retirements, for example, scheduling them over weekends to avoid disruption during business hours, you can configure Amazon EC2 event windows for your tasks, services, or clusters. When you use event windows, Fargate ensures that your tasks run for at least 3 days before they are retired within the next available window, unless stopped by user-initiated actions or critical health events such as degradation of the underlying hardware. Set the `fargateEventWindows` account setting to `enabled`. You can use one of the following APIs: `put-account-setting-default` or `put-account-setting` as the root user or an administrative user. Each Amazon EC2 event window must be open for at least 4 hours per week, and each time range must be at least 2 hours long. For large clusters and services we recommend configuring event windows with either long durations (8 hours or more) or more frequent time ranges that occur at least once every 3 days. You can further review considerations for Amazon EC2 event windows in the [user guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html#event-windows-considerations) AWS Fargate ensures that your tasks run for at least 3 days before they are retired, unless stopped by user-initiated actions or critical health events such as degradation of the underlying hardware. **Important** Replacement of tasks within event window is best effort. If you notice tasks being retired outside of your event windows, consider expanding the duration (8 hours or more) or increasing frequency (at least once every 3 days). To apply Amazon EC2 event windows to your Fargate task retirements: + Set the `fargateEventWindows` account setting to `enabled`. You can use one of the following APIs: `put-account-setting-default` or `put-account-setting` as the root user or an administrative user. Note that this is a one-time enablement for usage of the Amazon EC2 event windows feature for your Fargate tasks. + Create an Amazon EC2 event window through the AWS console or the AWS CLI. To create an event window using CLI, use EC2 `create-instance-event-window` API with time ranges or cron expressions. Take note of the `InstanceEventWindowId` from the response. ``` 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 ``` Alternatively, you can use cron expressions when creating EC2 event windows. ``` 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 ``` + You can then associate the event window with specific services, clusters or all tasks in your account using EC2 `associate-instance-event-window` API. + For ECS service tasks ``` aws ec2 associate-instance-event-window \ --instance-event-window-id iew-0abcdef1234567890 \ --association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=your-service-arn}]" ``` + For ECS clusters ``` aws ec2 associate-instance-event-window \ --instance-event-window-id iew-0abcdef1234567890 \ --association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=your-cluster-arn}]" ``` + To associate an event window with all tasks in the account ``` aws ec2 associate-instance-event-window \ --instance-event-window-id iew-0abcdef1234567890 \ --association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]" ``` You can use more than one key-value pair to associate an event window with multiple services or clusters. Fargate will choose the event window for each task in the following order: + If there is an event window associated with the task's service, it will be used. This is not applicable for standalone or unmanaged tasks. + If there is an event window associated with the task's cluster, it will be used. + If there is an event window set for all Fargate tasks, it will be used. + The `fargateTaskRetirementWaitPeriod` setting will be used if none of the event windows match with the task. **Configuring event windows for Fargate task maintenance** Consider a case when you are running multiple ECS services on Fargate with different availability requirements. You want precise control over task retirements. You can configure multiple event windows as follows: + **Default maintenance for all Fargate tasks**: Create an event window for routine maintenance during off-peak hours (12AM to 4AM daily) and associate it with all Fargate tasks using the ` aws:ecs:fargateTask` tag. + **Weekend-only maintenance for development cluster**: For a development cluster with services that can tolerate disruption on weekends, create a 24-hour weekend window (Saturday and Sunday, all day) and associate it with the cluster using the `aws:ecs:clusterArn` tag with your cluster ARN. + **Restricted window for mission-critical service**: For a mission-critical payment processing service that requires high uptime during weekdays, restrict maintenance to weekend early morning hours (Saturday and Sunday, 12AM to 4AM) and associate it with the specific service using the `aws:ecs:serviceArn` tag with your service ARN. With this configuration, the payment service uses its specific weekend-only window, the development cluster services and tasks use the weekend 24-hour window, and all other Fargate tasks use the default daily maintenance window. For more information, see, [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html) and [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) in the *Amazon Elastic Container Service API Reference*. ## Step 2: Capture task retirement notifications to alert teams and take actions When there is an upcoming task retirement, AWS sends a task retirement notification to the AWS Health Dashboard, and to the primary email contact on the AWS account. The AWS Health Dashboard provides a number of integrations into other AWS services, including Amazon EventBridge. You can use EventBridge to build automations from a task retirement notification, such as increasing the visibility of the upcoming retirement by forwarding the message to a ChatOps tool. AWS Health Aware is a resource that shows the power of the AWS Health Dashboard and how notifications can be distributed throughout an organization. You can forward a task retirement notification to a chat application, such as Slack. The following illustration shows the solution overview. ![\[Diagram showing the Fargate solution to capture Fargate task retirement notices.\]](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/images/fargate-task-retirement-solution.png) The following information provides details. + Fargate sends the task retirement notification to the AWS Health Dashboard. + The AWS Health Dashboard sends mail to the primary email contact on the AWS account, and notifies EventBridge. + EventBridge has a rule that captures the retirement notification. The rule looking for events with the Event Detail Type: `"AWS Health Event" and the Event Detail Type Code: "AWS_ECS_TASK_PATCHING_RETIREMENT"` + The rule triggers a Lambda function that forwards the information to Slack using a Slack Incoming Webhook. For more information, see [Incoming Webhooks](https://slack.com/marketplace/A0F7XDUAZ-incoming-webhooks). For a code example, see [Capturing AWS Fargate Task Retirement Notifications](https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications/tree/main) on Github. ## Step 3: Control the replacement of tasks You can't control the exact timing of a task retirement, however, you can define a wait time. If you want control over replacing tasks at your own schedule, you can capture the task retirement notice to first understand the task retirement date. You can then redeploy your service to launch replacement tasks, and likewise replace any standalone tasks.For services that use rolling deployment, you update the service using `update-service` with the `force-deployment` option before the retirement start time. The following `update-service` example uses the `force-deployment` option. ``` aws ecs update-service —-service service_name \ --cluster cluster_name \ --force-new-deployment ``` For services that use the blue/green deployment, you need to create a new deployment in AWS CodeDeploy. For information about how to create the deployment, see [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) in the *AWS Command Line Interface Reference*. # Supported Regions for Amazon ECS on AWS Fargate AWS Fargate Regions You can use the following tables to verify the Region support for Linux containers on AWS Fargate and Windows containers on AWS Fargate. ## Linux containers on AWS Fargate Amazon ECS Linux containers on AWS Fargate are supported in the following AWS Regions. The supported Availability Zone IDs are noted when applicable. | Region Name | Region | | --- | --- | | US East (Ohio) | us-east-2 | | US East (N. Virginia) | us-east-1 | | US West (N. California) | us-west-1 (`usw1-az1` & `usw1-az3` only) | | US West (Oregon) | us-west-2 | | Canada (Central) | ca-central-1 | | Canada West (Calgary) | ca-west-1 | | Mexico (Central) | mx-central-1 | | Africa (Cape Town) | af-south-1 | | Asia Pacific (Hong Kong) | ap-east-1 | | Asia Pacific (Mumbai) | ap-south-1 | | Asia Pacific (Tokyo) | ap-northeast-1 (`apne1-az1`, `apne1-az2`, & `apne1-az4` only) | | Asia Pacific (Seoul) | ap-northeast-2 | | Asia Pacific (Osaka) | ap-northeast-3 | | Asia Pacific (Hyderabad) | ap-south-2 | | Asia Pacific (Singapore) | ap-southeast-1 | | Asia Pacific (Sydney) | ap-southeast-2 | | Asia Pacific (Thailand) | ap-southeast-7 | | Asia Pacific (Jakarta) | ap-southeast-3 | | Asia Pacific (Melbourne) | ap-southeast-4 | | Asia Pacific (Malaysia) | ap-southeast-5 | | Canada (Central) | ca-central-1 | | Canada West (Calgary) | ca-west-1 | | China (Beijing) | cn-north-1 (`cnn1-az1` & `cnn1-az2` only) | | China (Ningxia) | cn-northwest-1 | | Europe (Frankfurt) | eu-central-1 | | Europe (Zurich) | eu-central-2 | | Europe (Ireland) | eu-west-1 | | Europe (London) | eu-west-2 | | Europe (Paris) | eu-west-3 | | Europe (Milan) | eu-south-1 | | Europe (Spain) | eu-south-2 | | Europe (Stockholm) | eu-north-1 | | South America (São Paulo) | sa-east-1 | | Israel (Tel Aviv) | il-central-1 | | Middle East (Bahrain) | me-south-1 | | Middle East (UAE) | me-central-1 | | AWS GovCloud (US-East) | us-gov-east-1 | | AWS GovCloud (US-West) | us-gov-west-1 | ## Windows containers on AWS Fargate Amazon ECS Windows containers on AWS Fargate are supported in the following AWS Regions. The supported Availability Zone IDs are noted when applicable. | Region Name | Region | | --- | --- | | US East (Ohio) | us-east-2 | | US East (N. Virginia) | us-east-1 (`use1-az1`, `use1-az2`, `use1-az4`, `use1-az5`, & `use1-az6`only) | | US West (N. California) | us-west-1 (`usw1-az1` & `usw1-az3` only) | | US West (Oregon) | us-west-2 | | Africa (Cape Town) | af-south-1 | | Asia Pacific (Hong Kong) | ap-east-1 | | Asia Pacific (Mumbai) | ap-south-1 | | Asia Pacific (Hyderabad) | ap-south-2 | | Asia Pacific (Osaka) | ap-northeast-3 | | Asia Pacific (Seoul) | ap-northeast-2 | | Asia Pacific (Singapore) | ap-southeast-1 | | Asia Pacific (Sydney) | ap-southeast-2 | | Asia Pacific (Melbourne) | ap-southeast-4 | | Asia Pacific (Malaysia) | ap-southeast-5 | | Asia Pacific (Tokyo) | ap-northeast-1 (`apne1-az1`, `apne1-az2`, & `apne1-az4` only) | | Canada (Central) | ca-central-1 (`cac1-az1` & `cac1-az2` only) | | Canada West (Calgary) | ca-west-1 | | China (Beijing) | cn-north-1 (`cnn1-az1` & `cnn1-az2` only) | | China (Ningxia) | cn-northwest-1 | | Europe (Frankfurt) | eu-central-1 | | Europe (Zurich) | eu-central-2 | | Europe (Ireland) | eu-west-1 | | Europe (London) | eu-west-2 | | Europe (Paris) | eu-west-3 | | Europe (Milan) | eu-south-1 | | Europe (Spain) | eu-south-2 | | Europe (Stockholm) | eu-north-1 | | South America (São Paulo) | sa-east-1 | | Israel (Tel Aviv) | il-central-1 | | Middle East (UAE) | me-central-1 | | Middle East (Bahrain) | me-south-1 |