AWS Builder Center

Builder Center

AWS Containers Explained: ECR, ECS, Fargate, and EKS

AWS Containers Explained: ECR, ECS, Fargate, and EKS

Learn how AWS container services work together—from storing images in Amazon ECR to orchestrating workloads with ECS or EKS and running containers on AWS Fargate. This practical guide covers core concepts, architecture patterns, service comparisons, and how to choose the right option for your application.

Hemanth G

Final Year CSE Student | Cloud & DevOps Enthusiast | AWS | Salesforce | Linux

AWS Containers Explained: ECR, ECS, Fargate, and EKS

Subtitle: A practical guide to storing, orchestrating, and running containers on AWS.
Description: Understand how AWS container services work together—from storing images in Amazon ECR to orchestrating workloads with ECS or EKS and running containers on AWS Fargate.
Tags:  Containers  ·  Amazon ECS  ·  Amazon EKS  ·  AWS Fargate  ·  Amazon ECR 

Containers have changed how modern applications are packaged and deployed. They help developers run applications consistently across laptops, testing environments, CI/CD pipelines, and production.
AWS provides several container services, each with a different responsibility:
ECR stores images. ECS orchestrates containers. Fargate runs containers without managing servers. EKS runs Kubernetes on AWS.


Why Containers?

With traditional deployments, applications are installed directly on servers. Developers must configure the operating system, runtime versions, libraries, environment variables, and application code.
This often creates the classic problem:
“It works on my machine.”
Containers solve this by packaging an application with its code and dependencies into a portable image. The same image can run on a developer laptop, an EC2 instance, ECS, or EKS.
Containers are popular because they provide:
  • Consistent deployments.
  • Faster startup than virtual machines.
  • Easier scaling.
  • Better application isolation.
  • A standard artifact for CI/CD.
However, containers alone do not manage scheduling, networking, scaling, or infrastructure. AWS container services provide those capabilities.


EC2 to Containers

Amazon EC2 provides virtual machines in the cloud. You can install Docker on an EC2 instance and run containers there.
EC2 instance
└── Docker
    ├── Container A
    ├── Container B
    └── Container C
This approach works, but you still manage:
  • EC2 instances.
  • Operating system patches.
  • Docker installation.
  • Capacity planning.
  • Container scheduling.
  • Failed hosts and scaling.
As the number of containers grows, this becomes difficult to operate manually. AWS provides ECS and EKS for container orchestration, while Fargate provides serverless compute for containers.


Amazon ECR

What is ECR?

Amazon Elastic Container Registry, or Amazon ECR, is a managed container image registry. It stores Docker and OCI-compatible images in repositories .[ docs.aws.amazon ]
A typical ECR image reference looks like this:
123456789012.dkr.ecr.ap-south-1.amazonaws.com/orders-api:v1.0
It contains:
  • AWS account ID.
  • AWS Region.
  • Repository name.
  • Image tag.

Why use ECR?

ECR provides a private, AWS-integrated location for container images. ECS and EKS can pull images from ECR using IAM permissions.
The most important point is:
ECR stores images; it does not run containers.
Think of ECR as a warehouse. ECS or EKS retrieves an image from the warehouse and runs it.

How developers push images to ECR

A simplified workflow looks like this:
docker build -t orders-api:v1 .

docker tag orders-api:v1 \
  123456789012.dkr.ecr.ap-south-1.amazonaws.com/orders-api:v1

aws ecr get-login-password --region ap-south-1 | \
  docker login --username AWS --password-stdin \
  123456789012.dkr.ecr.ap-south-1.amazonaws.com

docker push \
  123456789012.dkr.ecr.ap-south-1.amazonaws.com/orders-api:v1
The general process is:
  1. Build the container image.
  1. Create an ECR repository.
  1. Authenticate Docker to ECR.
  1. Tag the image with the ECR repository URI.
  1. Push the image.
A repository stores related images, while tags identify versions:
orders-api:v1.0
orders-api:v1.1
orders-api:latest
For production, use immutable tags such as release numbers or Git commit IDs instead of relying only on  latest .

When should I use ECR?

Use ECR when you need to:
  • Store private container images.
  • Integrate images with ECS or EKS.
  • Add image scanning and lifecycle policies.
  • Control image access using IAM.
  • Support a CI/CD deployment pipeline.


Amazon ECS

What is ECS?

Amazon Elastic Container Service, or Amazon ECS, is AWS-native container orchestration.
It manages where containers run, how many replicas are active, and what happens when a container fails.

ECS core concepts

Cluster
└── Service
    ├── Task
    │   └── Container
    └── Task
        └── Container

Cluster

A cluster is a logical group of ECS resources and capacity. It can use EC2 capacity, Fargate capacity, or both.

Task definition

A task definition is a blueprint for running one or more containers. It defines:
  • Container image.
  • CPU and memory.
  • Port mappings.
  • Environment variables.
  • Logging configuration.
  • IAM roles.
  • Health checks.
  • Storage.
For example:
Image: orders-api:v1.0
CPU: 512 units
Memory: 1 GB
Port: 8080

Task

A task is a running instance of a task definition.

Service

An ECS service maintains the desired number of running tasks. If you configure a service with three tasks, ECS attempts to keep three tasks running. If one fails, ECS launches a replacement.[ docs.aws.amazon ]

Scheduling

ECS schedules tasks onto available capacity.
With ECS on EC2, tasks run on EC2 instances that you manage.
With ECS on Fargate, AWS provides the underlying compute capacity. You specify the CPU and memory required for each task.

Networking

ECS tasks commonly use the  awsvpc  network mode. Each task receives its own network interface and private IP address inside your VPC.
A typical design places application tasks in private subnets and controls traffic using security groups.

Load balancing

An application load balancer can route traffic to healthy ECS tasks:
Users
  ↓
Application Load Balancer
  ↓
ECS service
  ├── Task 1
  ├── Task 2
  └── Task 3
ECS can also integrate with service discovery and automatic scaling.

When should I use ECS?

Use ECS when you want:
  • AWS-native container orchestration.
  • Simpler operations than Kubernetes.
  • Integration with IAM, VPC, ECR, CloudWatch, and load balancers.
  • Reliable deployments for APIs, workers, and microservices.


AWS Fargate

What is Fargate?

AWS Fargate is a serverless compute engine for containers. It works with both ECS and EKS. You specify the required CPU, memory, networking, and image; AWS manages the underlying server infrastructure .[ aws.amazon ]
Fargate is not an orchestrator by itself:
  • ECS or EKS decides what should run.
  • Fargate provides the compute capacity.

Why use Fargate?

With ECS on EC2, you manage container hosts. With ECS on Fargate, you do not provision, patch, or scale those hosts.
AWS manages:
  • Physical servers.
  • Host operating systems.
  • Underlying capacity.
  • Container runtime infrastructure.
You manage:
  • Container images.
  • Application code.
  • CPU and memory configuration.
  • VPC networking.
  • Security groups.
  • IAM roles.
  • Secrets.
  • Scaling policies.
  • Logs and monitoring.
Fargate still requires correct subnet, route, and security group configuration.

Example

Suppose an API normally needs three replicas. During a traffic spike, ECS increases the desired count to ten. Fargate launches the additional tasks without requiring your team to add EC2 instances.

When should I use Fargate?

Use Fargate when you want:
  • Containers without managing EC2 servers.
  • Simple deployment and scaling.
  • Less infrastructure maintenance.
  • Task-level isolation.
A common architecture is ECS with Fargate.


Amazon EKS

What is EKS?

Amazon Elastic Kubernetes Service, or Amazon EKS, is AWS’s managed Kubernetes service.
Kubernetes is an open-source platform for deploying and managing containers. You describe the desired state of your application, and Kubernetes works continuously to maintain it.
AWS manages the Kubernetes control plane for EKS.[ docs.aws.amazon ]

Kubernetes concepts

  • Cluster: The Kubernetes environment containing the control plane and compute resources.
  • Pod: The smallest deployable unit, containing one or more containers. [ docs.aws.amazon ]
  • Node: Compute capacity where pods run.
  • Deployment: Defines the desired number and version of application pods.
  • Service: Provides a stable network endpoint for changing pod IP addresses.
A typical Kubernetes flow is
Deployment
    ↓
Pods
    ↓
Kubernetes Service
    ↓
Load Balancer
EKS can run workloads on managed node groups, self-managed EC2 nodes, EKS Auto Mode, or Fargate, depending on the selected architecture.[ docs.aws.amazon ]

Why use EKS?

Companies choose EKS when they need:
  • Kubernetes APIs and tools.
  • Helm, operators, and Kubernetes extensions.
  • Portability across cloud and on-premises environments.
  • Advanced scheduling.
  • Existing Kubernetes expertise.
  • A common platform across multiple environments.
EKS reduces control-plane management, but teams still need to understand Kubernetes networking, storage, security, monitoring, upgrades, and capacity.

When should I use EKS?

Use EKS when Kubernetes is a clear requirement.
If your application only needs straightforward container deployment on AWS, ECS may be easier to operate.


ECS, Fargate, and EKS

Area
ECS on EC2
ECS on Fargate
EKS
Control
AWS-native with EC2 control
AWS-native with limited host control
Kubernetes-based
Complexity
Medium
Low to medium
Medium to high
Infrastructure
You manage EC2 instances
AWS manages servers
AWS manages control plane; node management depends on the capacity model
Scaling
Tasks and EC2 capacity
Tasks without managing hosts
Pods and node or serverless capacity
Best for
Host-level customization
Standard container workloads
Kubernetes platforms and portability
Remember:
ECS and EKS orchestrate containers. Fargate provides compute for those containers.


Real-World Architecture

ECS with Fargate

Developer
    ↓
Docker
    ↓
Amazon ECR
    ↓
Amazon ECS
    ↓
AWS Fargate
    ↓
Application Load Balancer
    ↓
Users
The flow is :
  1. The developer builds a container image.
  1. CI/CD pushes it to ECR.
  1. An ECS task definition references the image.
  1. An ECS service maintains multiple tasks.
  1. Fargate runs the tasks.
  1. The load balancer routes traffic to healthy tasks.
Application tasks commonly run in private subnets across multiple availability zones.

EKS architecture

Developer
    ↓
Docker
    ↓
Amazon ECR
    ↓
Kubernetes Deployment
    ↓
Pods on EKS nodes or Fargate
    ↓
Kubernetes Service
    ↓
AWS Load Balancer
    ↓
Users
The image in ECR can remain unchanged. The main difference is the orchestration layer:
ECS
EKS
Task definition
Deployment
Task
Pod
ECS service
Kubernetes Service
ECS scheduler
Kubernetes scheduler


Which One Should I Choose?

Need maximum VM control?
    ├── Yes → EC2
    └── No
         ↓
Need AWS-native orchestration?
    ├── Yes → ECS
    │          ├── Manage servers → ECS on EC2
    │          └── Avoid servers → ECS on Fargate
    └── No
         ↓
Need Kubernetes?
    ├── Yes → EKS
    └── No → Start with ECS

Choose EC2 when

You need host-level access, custom operating systems, special hardware, or maximum infrastructure control.

Choose ECS when

You want a simple AWS-native platform for APIs, workers, and microservices.

Choose Fargate when

You want ECS or EKS without managing container hosts.

Choose EKS when

You need Kubernetes compatibility, portability, advanced scheduling, or an existing Kubernetes platform.
Do not choose EKS only because Kubernetes is popular. Kubernetes is powerful, but it also introduces additional platform responsibilities.


Key Takeaways

  1. ECR stores images. It is a registry, not a runtime.
  1. ECS orchestrates containers. Its main concepts are clusters, task definitions, tasks, and services.
  1. Fargate runs containers without managing servers. ECS or EKS still provides the orchestration layer.
  1. EKS runs Kubernetes on AWS. AWS manages the control plane, while your team manages Kubernetes workloads.
  1. Choose the simplest service that meets your needs. EC2 provides control, ECS provides AWS-native orchestration, Fargate removes server management, and EKS provides Kubernetes.

Practical best practices

  • Use least-privilege IAM roles.
  • Keep application tasks in private subnets where possible.
  • Scan images and avoid storing secrets inside them.
  • Use immutable image tags instead of relying only on  latest .
  • Configure health checks, logs, and metrics.
  • Scale using meaningful signals such as CPU, memory, requests, or queue depth.
  • Monitor resource sizing and supporting AWS costs.> ECR → Store container images> ECS → Orchestrate containers> Fargate → Run containers without managing servers
EKS → Run Kubernetes on AWS
# containers# amazon-ecs# amazon-eks# aws-fargate# amazon-ecr
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article