ECS

Amazon Elastic Container Service (ECS) is AWS’s container orchestrator. It runs and manages containers on AWS compute, registers them with load balancers as they come and go, and gives each one its own IAM identity. There is no control plane to run and no charge for it — you pay for the capacity underneath.

For how ECS compares with Amazon EKS, see AWS Container Services.

Task definitions, tasks and services

• A task definition is the specification: which images, how much CPU and memory, environment and secrets, log configuration, networking mode, and the IAM roles the containers run under.
• A task is one running instance of that specification. If the definition contains a web container and a Redis sidecar, one task is both of them, scheduled together, sharing a network namespace.
• A service keeps a specified number of tasks running, replaces any that fail, registers them with a target group, and applies the deployment strategy when the task definition changes.

Run a task directly for one-off or batch work. Use a service for anything that should still be running tomorrow.

Capacity options

ECS on AWS Fargate

AWS supplies the host. You declare CPU and memory per task and pay for it by the second; there is nothing to provision, patch or scale. Best for services that do not need anything specific from the host, and for variable load where an owned fleet would sit idle. The trade-offs are a higher price per vCPU-hour, a fixed menu of CPU/memory combinations, and no host access. See Fargate.

ECS on Amazon EC2

You register EC2 instances as container instances and ECS places tasks on them. This gives you the instance type, GPUs and other accelerators, local NVMe, privileged containers, custom AMIs and kernel parameters, and placement strategies and constraints for controlling where tasks land. It is usually cheaper per unit of work at high steady utilisation, particularly with Spot or a Savings Plan, and it costs you the patching, scaling and security of the fleet. Cluster capacity providers scale the underlying Auto Scaling group to match task demand.

Amazon ECS Anywhere

Extends ECS to your own hardware — on-premises virtual machines, bare metal or edge devices — using the EXTERNAL launch type. The control plane stays in AWS, so orchestration, monitoring and IAM work the same way across cloud and on-premises. Useful where data residency, latency or existing hardware investment keeps a workload off AWS. You retain full responsibility for the infrastructure. See ECS Anywhere.

Deciding

Factor	Fargate	EC2	Anywhere
Control over the host	None	High	Total
Operational overhead	Lowest	Moderate	Highest
Cost profile	Best on variable load	Best on steady high utilisation	Your own hardware, plus a per-instance ECS charge
Scaling	Per task, immediate	Requires capacity planning	Bounded by your own capacity
Specific hardware	No	Yes	Yes

Sizing a service for rolling deployments

Rolling updates are governed by two settings, and their interaction with the Availability Zone count is the thing that catches people out.

• Minimum healthy percent is the floor on RUNNING tasks during a deployment, as a percentage of the desired count, rounded up. It is what allows the scheduler to stop old tasks.
• Maximum percent is the ceiling on total tasks, which is what allows it to start new ones before stopping old ones.

With maximum percent at 100 the scheduler cannot launch a replacement first — it must stop a task to make room. So a deployment only progresses while the number of running healthy tasks is above the minimum healthy floor.

Now add an Availability Zone failure. Three tasks spread one per zone, with minimum healthy percent at 50%, gives a floor of ⌈3 × 0.5⌉ = 2 running tasks. Lose a zone and exactly 2 tasks are running — at the floor, so no task can be stopped and the deployment stalls. Six tasks across three zones gives a floor of 3, and a zone outage leaves 4 running, so the deployment proceeds.

The general rule: for a service that must deploy during a zonal outage, size it so that (tasks remaining after losing one zone) is strictly greater than (minimum healthy percent × desired count). Raising maximum percent above 100 relaxes this, at the cost of briefly running extra capacity. Capacity headroom for the requests themselves is a separate, and usually easier, calculation.