4 Containers on AWS: ECS, Fargate, and EKS

Images and running containers

Containers package an application together with the runtime, libraries, and other files it needs. A container image is the packaged, read-only template; a container is a running instance of that image. Images are commonly built from a Dockerfile and stored in a container registry such as Amazon Elastic Container Registry (Amazon ECR), from which a compute service retrieves the image and runs it.

ECS building blocks

Amazon ECS is AWS’s container orchestration service. Its building blocks describe what to run, how to run it, and how to maintain the workload:

• A task definition specifies which images to run and settings such as CPU, memory, ports, networking, and logging. It can describe one or more containers that work together.

• A task is a running instance of a task definition. It can run by itself for work that should complete, such as a batch job, or run as part of a service.

• An ECS service keeps a specified number of tasks running. If a service configured for three tasks loses one unexpectedly, ECS attempts to start a replacement.

• An ECS cluster is a logical grouping for tasks, services, and their compute capacity. That capacity can come from Amazon EC2 instances or AWS Fargate.

For example, a web application image can be pushed to ECR, then referenced in an ECS task definition that exposes the application’s port. An ECS service in a cluster can be configured with a desired count of two tasks, which ECS schedules and maintains on the selected compute capacity.

Choosing EC2 or Fargate

ECS handles orchestration, but using ECS does not by itself mean AWS manages every server that runs the containers. With ECS on EC2, you provide and manage the EC2 instances that supply capacity, including choices about instance types and scaling. This gives you more control over the underlying hosts.

AWS Fargate is a serverless compute engine for containers that works with ECS and Amazon EKS. You specify resources for tasks or pods, and AWS manages the underlying server infrastructure. Fargate is useful when you want to run containers without provisioning or maintaining container host instances. You still configure and operate application-level concerns, including images, networking, permissions, and scaling.

EKS and Kubernetes workloads

Amazon EKS is AWS’s managed Kubernetes service. Choose EKS when Kubernetes is the orchestration platform you need. AWS manages the Kubernetes control plane; workloads run on compute capacity such as managed or self-managed nodes, or on Fargate where supported.

Kubernetes uses workload terms that differ from ECS:

• A Pod is Kubernetes’ deployable unit and contains one or more closely related containers.

• A Deployment declares the desired number and version of application pods and manages their rollout and replacement.

• A Kubernetes Service provides a stable way to reach a set of pods over the network. It does not mean the same thing as an ECS service.

• A Kubernetes cluster includes the control plane and the compute resources on which workloads run.

Workload flow and platform choice

The broad workflow is similar in ECS and EKS: build a container image, put it in a registry such as ECR, describe the desired workload, and let the orchestrator place and manage it.

• Choose ECS for AWS-native container orchestration without adopting Kubernetes.

• Choose EKS when Kubernetes compatibility, tooling, or operating practices are important.

• Choose Fargate with either platform when you want AWS to manage the underlying compute hosts rather than managing EC2 nodes yourself.

In brief, an image is the packaged application and a container is a running image. ECS task definitions describe containers, tasks are running instances of those definitions, services maintain a desired number of tasks, and clusters group workloads and capacity. EKS provides managed Kubernetes, where pods, deployments, and Kubernetes services organize workloads; Fargate supplies serverless container compute for ECS and EKS.