Amazon ECS on Amazon Fargate
Amazon Fargate is a technology that you can use with Amazon ECS to run containers
When you run your tasks and services with the Fargate launch type, 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 see Launch types.
Fargate offers platform versions for Amazon Linux 2 and Microsoft Windows 2019 Server Full and Core editions. Unless otherwise specified, the information on this page applies to all Fargate platforms.
This topic describes the different components of Fargate tasks and services, and calls out special considerations for using Fargate with Amazon ECS.
For information about the Regions that support Linux containers on Fargate, see Supported Regions for Linux containers on Amazon Fargate.
For information about the Regions that support Windows containers on Fargate, see Supported Regions for Windows containers on Amazon Fargate.
Tasks and services
After you have your Amazon ECS task definitions for Amazon Fargate prepared, there are some decisions to make when creating your service.
Task networking
Amazon ECS tasks for Amazon Fargate require the awsvpc
network
mode, which provides each task with an elastic network interface. When you run a
task or create a service with this network mode, you must specify one or more
subnets to attach the network interface and one or more security groups to apply to
the network interface.
If you are using public subnets, decide whether to provide a public IP address for the network interface. For a Fargate task in a public subnet to pull container images, a public IP address needs to be assigned to the task's elastic network interface, with a route to the internet or a NAT gateway that can route requests to the internet. For a Fargate task in a private subnet to pull container images, you need a NAT gateway in the subnet to route requests to the internet. When you host your container images in Amazon ECR, you can configure Amazon ECR to use an interface VPC endpoint. In this case, the task's private IPv4 address is used for the image pull. For more information about Amazon ECR interface endpoints, see Amazon ECR interface VPC endpoints (Amazon PrivateLink) in the Amazon Elastic Container Registry User Guide.
The following is an example of the networkConfiguration section for a Fargate service:
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [ "sg-12345678
" ],
"subnets": [ "subnet-12345678
" ]
}
}
Fargate Spot
Amazon ECS capacity providers enable you to use both Amazon Fargate and Fargate Spot capacity with your Amazon ECS tasks.
Windows containers on Amazon Fargate cannot use the Fargate Spot capacity provider.
Linux tasks with the ARM64 architecture don't support the Fargate Spot capacity provider.
With Fargate Spot you can run interruption tolerant Amazon ECS tasks at a discounted rate compared to the Amazon Fargate price. Fargate Spot runs tasks on spare compute capacity. When Amazon needs the capacity back, your tasks will be interrupted with a two-minute warning. For more information, see Amazon Fargate capacity providers.
Service load balancing
Your Amazon ECS service on Amazon Fargate can optionally be configured to use Elastic Load Balancing to distribute traffic evenly across the tasks in your service.
Amazon ECS services on Amazon Fargate support the Application Load Balancer and Network 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 Load balancer types.
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 Service load balancing.
Using a Network Load Balancer to route UDP traffic to your Amazon ECS on Amazon 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.
Amazon Fargate usage metrics correspond to Amazon service quotas. You can configure alarms that alert you when your usage approaches a service quota. For more information about Amazon Fargate service quotas, see Amazon Fargate service quotas.
For more information about Amazon Fargate usage metrics, see Amazon Fargate usage metrics in the Amazon Elastic Container Service User Guide for Amazon Fargate.
Task maintenance
When Amazon determines that a security or infrastructure update is needed for an Amazon ECS task hosted on Amazon Fargate, the tasks need to be stopped and new tasks launched to replace them. For more information, see Task maintenance in the Amazon Elastic Container Service User Guide for Amazon Fargate.
The following table describes these scenarios.
Task type | Issue | Action |
---|---|---|
Standalone task |
Host issue |
A task retirement notice is sent using your Amazon Health Dashboard |
Security vulnerability |
A task retirement notice is sent using your Amazon Health Dashboard |
|
Service task |
Host issue |
The task is stopped by Amazon and the service scheduler will launch a new task in an attempt to maintain the service's desired count. No notification is sent. |
Security vulnerability |
A task retirement notice is sent using your Amazon Health Dashboard |
Savings plans
Savings Plans are a pricing model that offer significant savings on Amazon usage. You commit to a consistent amount of usage, in USD per hour, for a term of 1 or 3 years, and receive a lower price for that usage. For more information, see the Savings Plans User Guide.
To create a Savings Plan for your Amazon Fargate usage, use the Compute Savings Plans type. To get started, see Getting started with Savings Plans in the Savings Plans User Guide.
Lazy loading container images using Seekable OCI (SOCI)
Amazon ECS tasks on Fargate that use Linux platform version 1.4.0
can use
Seekable OCI (SOCI) to help start tasks faster.
With SOCI, containers only spend a few seconds on the image pull before
they can start, providing time for environment setup and application
instantiation while the image is downloaded in the background.
This is called lazy loading. When Fargate starts an Amazon ECS task, Fargate automatically detects
if a SOCI index exists for an image in the task and starts the container without waiting
for the entire image to be downloaded.
For containers that run without SOCI indexes, container images are downloaded completely before the container is started. This behavior is the same on all other platform versions of Fargate and on the Amazon ECS-optimized AMI on Amazon EC2 instances.
Seekable OCI indexes
Seekable OCI (SOCI) is an open source technology developed by Amazon that can launch
containers faster by lazily loading the container image. SOCI works by creating an index
(SOCI Index) of the files within an existing container image. This index helps to launch
containers faster, providing the capability to extract an
individual file from a container image before downloading the entire image.
The SOCI index must be stored as an artifact in the same repository as the image
within the container registry. You should only use SOCI indices from trusted sources,
as the index is the authoritative source for the contents of the image.
For more information, see Introducing Seekable OCI for lazy loading container
images
Considerations
If you want Fargate to use a SOCI index to lazily load container images in a task, consider the following:
-
Only tasks that run on Linux platform version
1.4.0
can use SOCI indexes. Tasks that run Windows containers on Fargate aren't supported. -
Tasks that run on X86_64 or ARM64 CPU architecture are supported. Linux tasks with the ARM64 architecture do not support the Fargate Spot capacity provider.
-
Container images in the task definition must have SOCI indexes in the same container registry as the image.
-
Container images in the task definition must be stored in a compatible image registry. The following lists the compatible registries:
-
Amazon ECR private registries.
-
-
Only container images that use gzip compression or are not compressed are supported. Container images that use zstd compression aren't supported.
-
We recommend that you try lazy loading with container images greater than 250 MiB compressed in size. You are less likely to see a reduction in the time to load smaller images.
-
Because lazy loading can change how long your tasks take to start, you might need to change various timeouts like the health check grace period for Elastic Load Balancing.
-
If you want to prevent a container image from being lazy loaded, delete the SOCI index from the container registry. If a container image in the task doesn't meet one of the considerations, that container image is downloaded by the default method.
Creating a Seekable OCI index
To create SOCI indexes, first you create the index of the files in
the container image. To do this, you can use the open
source CLI tool awslabs/soci-snapshotter
Note
For the SOCI index to be created for an image, the image must exist in the
containerd image store on the computer running soci-snapshotter
.
If the image is in the Docker image store, the image can't be found.
Verifying that a task used lazy loading
To verify that a task was lazily loaded using SOCI, check the task
metadata endpoint from inside the task. When you query the task metadata endpoint
version 4, there is a Snapshotter
field in the default path for the
container that you are querying from. Additionally, there are
Snapshotter
fields for each container in the /task
path.
The default value for this field is overlayfs
,
and this field is set to soci
if SOCI is used. For more information, see Task metadata endpoint version 4 in the Amazon Elastic Container Service User Guide for Amazon Fargate.
Windows containers on Amazon Fargate considerations
Windows containers on Amazon Fargate supports the following operating systems:
-
Windows Server 2019 Full
-
Windows Server 2019 Core
-
Windows Server 2022 Full
-
Windows Server 2022 Core
Amazon handles the operating system license management, so you do not need any additional Microsoft Windows Server licenses.
Windows containers on Amazon Fargate supports the awslogs driver. For more information, see Using the awslogs log driver.
Your tasks can run either Linux containers or Windows containers. If you need run both container types, you must create separate tasks.
The following features are not supported on Windows containers on Fargate:
-
Group managed service accounts (gMSA)
-
Amazon FSx
-
ENI trunking
-
App Mesh service and proxy integration for tasks
-
Firelens log router integration for tasks
-
EFS volumes
-
The following task definition parameters:
-
maxSwap
-
swappiness
-
-
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 Bind mounts.