Containers

Containers are the default shape for a long-running service on AWS. Running one here involves two decisions, made independently.

Which orchestrator places the containers. Amazon ECS is AWS’s own scheduler: fewer concepts, native integration with load balancers, IAM and CloudWatch, and nothing to run yourself. Amazon EKS is managed Kubernetes: portable, enormously extensible, and correspondingly more to learn and operate. The service comparison sets the two side by side in detail.

Which capacity model runs them. Either EC2 instances you own and patch, or AWS Fargate, where AWS supplies the host and bills per task or pod. Both orchestrators support both models, and one cluster can mix them.

Two more services complete the picture:

• Amazon ECR stores the images, scans them for vulnerabilities and enforces the lifecycle and signing rules around them.
• AWS Batch queues containerised jobs rather than running services, and provisions capacity on ECS, EKS or Fargate to drain the queue.

If you have no existing Kubernetes investment and no requirement to run the same manifests elsewhere, start with ECS on Fargate: it has the fewest parts that can break and no cluster fee. Move to EC2 capacity when you need specific hardware or the utilisation maths turns against you, and to EKS when portability, an existing Kubernetes estate or the Kubernetes ecosystem is worth the operational cost.

Scaling containers in AWS covers how each of these services actually adds and removes capacity, which is where the practical differences show up.