Setting the file. One moment.
Subchapter 31.6
references/ecs-managing-compute.mdMarkdown10 KBView on GitHub
Amazon ECS runs your containers as tasks, and each task needs compute capacity to run on. ECS gives you three ways to provide that capacity: AWS Fargate (serverless), the EC2 launch type backed by Auto Scaling group capacity providers (you manage the EC2 instances), and Amazon ECS Managed Instances (AWS manages the EC2 instances for you). You select capacity per task or service using either a launch type ( or ) or a capacity provider strategy.
FARGATEEC2Amazon ECS Managed Instances is a fully managed compute option for Amazon ECS that enables you to run containerized workloads on the full range of Amazon EC2 instance types while offloading infrastructure management to AWS. With Amazon ECS Managed Instances, you can access specific compute capabilities such as GPU acceleration, particular CPU architectures, high network performance, and specialized instance types, while AWS handles provisioning, scaling, patching, and maintenance of the underlying infrastructure.
You package your application in containers and specify your compute requirements. AWS automatically selects the most cost-optimized general-purpose EC2 instance types that meet your workload needs, or you can specify desired instance attributes (instance types, CPU manufacturers, accelerators, and so on). By default, ECS Managed Instances optimizes utilization by placing multiple smaller tasks on a single larger instance, unlike Fargate which runs each task in its own isolated environment.
Important considerations:
instanceRequirements), associate it with a cluster, and reference it in a capacity provider strategy. A capacity provider strategy can only contain one type of capacity provider — ECS Managed Instances, Auto Scaling group, or Fargate/Fargate_SPOT — not a mix.requiresCompatibilities parameter to include MANAGED_INSTANCES. A task definition can declare both FARGATE and MANAGED_INSTANCES for deployment flexibility, and existing Fargate task definitions using platform version 1.4.0 are compatible.X86_64 and ARM64. Supported network modes are awsvpc and host.capacityOptionType parameter on the instance launch template — valid values are ON_DEMAND, SPOT, and RESERVED, defaulting to ON_DEMAND. Spot uses spare EC2 capacity at reduced cost but can be interrupted with a two-minute notification.scaleInAfter parameter on the capacity provider’s infrastructureOptimization configuration. It defines how many seconds (0–3600) ECS waits before optimizing idle or underutilized instances — a longer delay increases the chance of placing new tasks on existing instances and reduces startup time, while a shorter delay reduces cost. Use null for the default behavior or -1 to disable automatic optimization entirely.See the documentation (opens in a new tab) for more information.
AWS Fargate is a technology that you can use with Amazon ECS to run 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. To use it, set the requiresCompatibilities task definition parameter to include FARGATE (or launch with the FARGATE/FARGATE_SPOT capacity providers).
awsvpc network mode and receive their own elastic network interface. The host network mode, hostPort host bindings, and disableNetworking are not supported.ip target type (not instance) because tasks have their own network interface.privileged) are not supported. For linuxParameters capabilities, the only Linux capability you can add is CAP_SYS_PTRACE.gpu resource requirement is not valid).placementConstraints, links, ipcMode, dnsServers, extraHosts, maxSwap, and swappiness.1.4.0 or later (and Windows 1.0.0 or later), configurable via the ephemeralStorage parameter. The ephemeral storage is encrypted.X86_64 or ARM64; Windows containers require X86_64.awslogs, splunk, and awsfirelens.Fargate task definitions require you to specify CPU and memory at the task level (most workloads only need task-level values; you can optionally also set container-level limits). Fargate allocates resources to match the configuration you request — there is no rounding or implicit default, so you must pick a valid combination. CPU can be expressed in CPU units or vCPUs (for example 1024 or 1 vCPU) and memory in MiB or GB (for example 3072 or 3 GB).
If your task needs more resources than provided, use the EC2 launch type or ECS Managed Instances.
See the documentation (opens in a new tab) for more information, including valid combinations for CPU and memory.
When you use the EC2 launch type, you provide and manage the Amazon EC2 instances (container instances) that your tasks run on. The recommended way to manage this capacity is with Auto Scaling group (ASG) capacity providers, which connect an ECS cluster to an Auto Scaling group so capacity scales with your task demand.
With managed scaling enabled, ECS manages the scale-out and scale-in actions of the Auto Scaling group on your behalf, using a target-tracking scaling policy driven by the CapacityProviderReservation metric. When managed scaling is on, the Auto Scaling group’s desired count can start at 0 and ECS scales it as tasks are placed. If the group can’t scale out to fit the tasks you run, those tasks stay in the PROVISIONING state until capacity is available.
We recommend using managed instance draining, which is on by default, so that EC2 instances are gracefully drained (tasks stopped and rescheduled) before the instance is terminated during scale-in or instance replacement. This avoids disrupting your workloads.
ECS supports Amazon EC2 Auto Scaling warm pools. A warm pool maintains pre-initialized EC2 instances alongside your Auto Scaling group that can quickly join your cluster during scale-out events. Instances in the warm pool have already completed the bootup initialization process and can be kept in a Stopped, Running, or Hibernated state. See the documentation (opens in a new tab) for limitations.
A cluster can contain a mix of Auto Scaling group and Fargate capacity providers, but a single capacity provider strategy can only use one type. You can specify a maximum of 20 capacity providers in a strategy.
See the documentation (opens in a new tab) for more information.
When you use the EC2 launch type, your container instances run from an AMI that includes the Amazon ECS container agent (which registers the instance with your cluster and manages task lifecycle) and a container runtime. AWS publishes Amazon ECS-optimized AMIs preconfigured for this, and you can also build your own custom AMI. Variants are available for Amazon Linux 2023 and Amazon Linux 2, including arm64 (Graviton), GPU, and Neuron (Inferentia/Trainium) flavors. You can retrieve the latest AMI IDs from the Systems Manager Parameter Store.
We recommend the Amazon ECS-optimized Amazon Linux 2023 AMI for new instances, as it receives current security updates and the latest container agent version.
The Amazon ECS-optimized Amazon Linux 2 AMI is being retired, mirroring the EOL of the upstream Amazon Linux 2 operating system. AWS recommends upgrading to Amazon Linux 2023. Check the migration documentation below for the current end-of-life date.
See the migration documentation (opens in a new tab) and the Amazon ECS-optimized Linux AMIs documentation (opens in a new tab) for more information.