AWS Container Services: ECS, EKS, and Fargate
Separating ECS, EKS, Fargate, and ECR into two layers - orchestration and compute engine - and working out how to choose between them.
Contents
ECS, EKS, and Fargate are combinations of an orchestrator and a compute engine that decide where and how containers run.
Orchestrator and compute engine are different layers
AWS container services divide into orchestration and an image registry. Amazon ECS and Amazon EKS handle orchestration, and Amazon ECR handles image storage. ECS stands for Elastic Container Service, EKS for Elastic Kubernetes Service, and ECR for Elastic Container Registry.
AWS Fargate sits alongside these as a separate compute engine. Fargate is a serverless compute engine usable from both ECS and EKS, so choosing an orchestrator still leaves the execution base to be chosen. "ECS or EKS" and "Fargate or EC2" are therefore questions at different layers.
- Amazon ECS: an orchestrator built on AWS-native APIs with a small set of concepts.
- Amazon EKS: managed Kubernetes, compatible with the open source ecosystem.
- Amazon ECR: a registry that stores and distributes container images.
The registry is independent of the orchestrator, so ECR is used alongside either ECS or EKS.
How ECS and EKS differ
ECS works with a small number of concepts: clusters, services, and task definitions. A task definition is the specification for running containers, and a service is the unit that keeps those tasks running long term. With few concepts, the learning curve is shallow.
EKS provides Kubernetes as a managed service. AWS operates the control plane (API server, etcd, scheduler), and the user manages only the worker nodes and the pods on them. Compatibility with open source Kubernetes makes moving to another cloud easier.
The fork between the two services is standards versus operational burden.
| Criterion | Amazon ECS | Amazon EKS |
|---|---|---|
| Standard | AWS-native API | Kubernetes (open source) |
| Learning curve | Low | High |
| Flexibility | Moderate | Very high |
| Multi-cloud | AWS only | Possible |
| Fits | Teams centered on AWS | Teams with Kubernetes experience |
If the goal is to ship quickly inside AWS, ECS costs less effort. If the Kubernetes ecosystem or multi-cloud portability matters, EKS is the fit.
Fargate and EC2
Choosing an orchestrator still leaves the base the containers actually run on. The options are EC2 instances and Fargate, and Fargate is the serverless compute engine available from both ECS and EKS.
On Fargate you do not provision, patch, or scale servers yourself, and you pay per container. Operational burden drops, but fine-grained host-level control goes with it. Kernel parameters, GPUs, or special instance types call for EC2.
| Criterion | EC2 | Fargate |
|---|---|---|
| Operational burden | Manage nodes directly | No server management |
| Level of control | Fine-grained down to the host | Per container |
| Billing | Per instance | Per task resources |
| Fits | Special hardware, tuning | Fast operation, variable load |
Choose EC2 when control is needed, Fargate when the operational load should go away. Mixing both in one cluster is also possible.
ECS Express Mode
Running a production service on ECS normally means wiring together a VPC, subnets, security groups, an ALB, target groups, and IAM. ECS Express Mode, announced at re:Invent 2025, reduces that to a container image and IAM roles.
ALB stands for Application Load Balancer, which distributes traffic by HTTP path and host. Given an image, Express Mode creates the following resources automatically.
- ECS cluster, task definition, and service
- An ALB shared by several services, with HTTPS, a domain, and a certificate
- Autoscaling policies and least-privilege security groups
- Alarms that detect a 4XX/5XX spike and roll back automatically
The key point is that the ALB is shared rather than created per service. A single ALB routes to several services by host header, and as announced in 2025 it groups up to 25 of them. The fixed cost of one ALB (roughly 16 dollars a month, estimated) is saved for each additional service, so the more small microservices there are, the larger the saving.
Recent EKS additions
re:Invent 2025 added platform operations, control plane performance, and network observability features to EKS.
EKS Capabilities are managed add-ons in which AWS operates platform tools such as Argo CD, ACK, and KRO directly. ACK stands for AWS Controllers for Kubernetes and KRO for Kube Resource Orchestrator. These tools run in an AWS-owned account rather than on user worker nodes, so their API servers and UIs are not exposed directly in the user VPC.
The flagship example, Managed Argo CD, offers the GitOps tool as a managed service. GitOps is a deployment style in which the desired state written in Git is applied to the cluster automatically. AWS takes on operations such as the highly available Redis setup and repo-server scaling, which shrinks the attack surface. Pricing is an hourly charge per cluster plus a charge proportional to the number of applications (roughly 0.0277 dollars per hour plus 0.00136 dollars per app, estimated).
Provisioned Control Plane reserves control plane capacity in advance so API server performance stays steady through traffic spikes. The idea parallels EBS Provisioned IOPS. The standard tier scales in reaction to load, the provisioned tier reserves capacity ahead of it, and switching between them happens without downtime.
| Item | Standard | Provisioned |
|---|---|---|
| Scaling | Reactive | Preemptive |
| Cost | Included in the base | Additional charge per tier |
| Workloads it fits | General web and microservices | Large-scale AI, batch, multi-tenant |
The feature suits environments with a very large node count in a single cluster or frequent pod creation and deletion. It also keeps the control plane from becoming a bottleneck in training jobs that launch thousands of GPU pods at once.
Enhanced Network Observability traces pod-level networking with eBPF. eBPF is a Linux technology that runs code safely in the kernel to observe traffic. It provides service maps, flow tables, and fine-grained metrics. Signals such as DNS latency and TCP retransmissions separate network problems from server load.
ECR and image signing
Amazon ECR is a managed registry that stores and distributes container images. It offers IAM-based access control, vulnerability scanning on push, and immutable tags that prevent tag overwrites. Cross-region replication and pull-through caching of external registries are also supported.
In 2025 Managed Image Signing was added for supply chain security. When an image is pushed to ECR, AWS Signer signs it automatically, and the signature is verified at deployment to block untrusted images.
| Item | Previously (Cosign, Notation) | ECR managed signing |
|---|---|---|
| Signing tool | Installed separately on the client | Automatic on push |
| Key management | Run your own PKI | AWS Signer generates, stores, rotates |
| Setup | Requires pipeline configuration | Console or a single API call |
It amounts to moving a signing pipeline previously built with Cosign or Notation onto a managed service. AWS taking over key management and rotation reduces operational burden.
How to choose
Pick the orchestrator first, then fill in the compute engine and image trust on top of it.
- Ship quickly inside AWS with less to operate → ECS, and Express Mode where possible
- Need the Kubernetes ecosystem, multi-cloud, or fine-grained control → EKS
- Want to avoid node operations → Fargate; need special hardware or tuning → EC2
- Need guaranteed image provenance → ECR Managed Image Signing
For heavy traffic or AI training, where control plane load is high, add the EKS Provisioned Control Plane. When network faults have to be identified quickly, turn on Enhanced Network Observability.
Summary
AWS container services come down to two layers of choice: orchestration (ECS, EKS) with a registry (ECR), and a compute engine (Fargate, EC2). ECS is quick because it has few concepts, EKS is strong on the Kubernetes ecosystem and portability, and Fargate removes node operations entirely. Express Mode and EKS Capabilities, both added in 2025, take on deployment convenience and platform operations. Provisioned Control Plane and Managed Image Signing add performance guarantees and supply chain security. The decision narrows to three questions: whether standards matter, how much operational load should go away, and what scale has to be sustained.