Container Deployment Using AWS ECS, Kubernetes vs ECS

You build a Docker image, push it to a registry… and then what?

Running a container on your laptop is easy. Running hundreds of them in production — keeping them healthy, scaling them during traffic spikes, rolling out updates without downtime, and recovering from failures — is where the real challenge begins.

That’s why services like Amazon ECS, AWS Fargate, and Kubernetes exist. But here’s the confusing part: they’re often compared as if they’re the same thing. They’re not.

In this blog, we’ll connect the dots from the ground up — why ECS was introduced, where Fargate fits into the picture, how it differs from Kubernetes, and more importantly, how to choose the right approach instead of just following what’s popular.

Before ECS, Fargate, and Kubernetes

Let’s say you’ve built a simple Python API.

You package it into a Docker image.

python app
 ↓
docker build
 ↓
my-app:latest

Great. Your application is now containerized.

Now comes the real question…

How do you actually run it in production?

Sure, you can start it with:

docker run my-app

And for a personal project, that might be enough.

But production has a habit of asking uncomfortable questions.

What if?

• The container crashes?
• You need 10 copies?
• Traffic suddenly increases?
• You want zero downtime deployments?
• One server dies?
• You need load balancing?
• Secrets management?
• Service discovery?
• Auto scaling?

Docker doesn’t solve these problems.

Docker only knows:

“Run this container.”

Something else has to manage containers.

That “something else” is called a container orchestrator.

The truth is, Docker was never designed to solve these problems.

Docker has one primary responsibility:

Take a container image and run it.

That’s it.

Everything beyond that — keeping containers alive, replacing failed ones, distributing traffic, scaling, networking, service discovery, rolling updates, and managing infrastructure — is someone else’s job.

And that’s exactly why container orchestration exists.

Services like Amazon ECS, AWS Fargate, and Kubernetes were built to answer a simple question:

“How do we run containers reliably in production?”

What is a Container Orchestrator?

A container orchestrator is an automated tool that manages the deployment, scaling, networking, and lifecycle of containerized applications across a cluster of servers

For example:

“I want 5 backend containers running at all times.”

Its job is:

Desired State

"I want 5 backend containers"

        ↓

Orchestrator

        ↓

Makes Reality Match Desired State

If one dies:

Desired: 5

Running: 4

↓

Launch another

No human involved.

The orchestrator notices that the actual state no longer matches the desired state and immediately takes action to fix it.

That’s the core idea behind every container orchestrator — whether it’s Amazon ECS, Kubernetes, or another platform.

Kubernetes

Kubernetes is the most popular orchestrator.

Kubernetes (often shortened to K8s) is an open-source software tool that automatically runs, scales, and manages containerized computer applications across a group of servers

Suppose you tell Kubernetes:

“Keep 5 instances of my application running.”

Internally, it keeps checking whether reality matches your request

Desired State
Replicas: 5

Kubernetes continuously checks reality.

Current: 5
✓ Nothing to do

If one crashes:

Current: 4
↓
Start new Pod
↓
Current: 5

You don’t have to monitor it. You don’t have to SSH into a server. You don’t even have to run another command.

Kubernetes continuously watches your application and automatically brings it back to the state you asked for.

We will deep dive into kubernetes and it’s components another day.

ECS

AWS thought:

Kubernetes is powerful…

…but also complicated.

So AWS created ECS.

Instead of exposing every Kubernetes concept, ECS simplifies things.

ECS Terminology, Why ECS?

Kubernetes has:

Deployment

↓

ReplicaSet

↓

Pods (A Pod is a wrapper around one or more containers.)

↓

Containers

A **ReplicaSet is a core Kubernetes controller designed to maintain a stable set of identical Pod replicas running at any given time.** It guarantees application availability by automatically replacing failed, crashed, or deleted Pods.

Example:

Replicas = 5,

Currently Running = 4, So

ReplicaSet says: Create one more pod

ECS has:

Service

↓

Tasks

↓

Containers

Much simpler.

ECS Core Components

1. Cluster:

Think of it as a group of machines.

Cluster

├── Machine A (Either EC2 Instance or Fargate Capacity)
├── Machine B
├── Machine C

Those machines can be:

• EC2 Instance
• Fargate Capacity

It provides the infrastructure where Tasks run and manages:

• Compute resources
• Networking
• Memory allocation
• Container scheduling

A Cluster can contain:

• EC2 instances
• Fargate resources
• Or both together depending on the deployment setup

2. Task Definition

A Task Definition is a JSON blueprint that defines how containers should run in Amazon ECS.

It includes details such as:

• Docker image to use
• CPU and memory allocation
• Port mappings
• Environment variables
• Storage configuration
• IAM role permissions

It can define multiple containers.

Why do we define multiple containers in a single Task Definition?

Because sometimes multiple processes are so tightly coupled (like App Container, Log Collector, and Monitoring Agent) that they should always run together.

Think of a Task as one logical application, even if that application consists of multiple containers.

For example:

Task Definition (Blueprint)

├── App Container
├── Log Collector
└── Monitoring Agent

3. Task

A Task is a running instance of Task Definition.

Key Points

• One Task Definition (Blueprint) can create multiple Tasks, Using a blueprint we can start ’n’ number of tasks.
• A Task can run one or more containers depending on Task Defination, As a Task Definition can have one or more containers.
• Tasks can run independently or as part of a Service

Task Definition (Blueprint)

├── App Container
├── Log Collector
└── Monitoring Agent
        │
        ▼
Create Task
        │
        ▼
Running Task

├── App Container
├── Log Collector
└── Monitoring Agent

4. Service

An ECS Service maintains the desired number of running Tasks and is commonly used for long-running applications like web servers and APIs.

Main responsibilities:

• Maintains desired Task count
• Replaces failed Tasks automatically
• Supports load balancing
• Enables auto scaling
• Handles rolling updates and deployments

Working of ECS

Amazon ECS runs your Docker containers on AWS infrastructure and takes care of placing, scaling, monitxoring, and keeping them available. You define how your application should run, and ECS automatically launches containers on either EC2 instances or AWS Fargate, continuously ensuring the desired number of application instances stays running.

Fargate: Where does Fargate fit?

ECS is not where your containers run.

ECS decides what should run.

Something still has to provide the actual compute.

There are two options: AWS Ec2 or Fargate

AWS Fargate is a serverless compute engine for containers that allows you to run Docker containers without provisioning, managing, or scaling the underlying EC2 servers. You simply define the CPU, memory, networking, and container image, and AWS automatically provides and manages the required infrastructure.

Where to Go Next?

If you enjoyed this guide, here are some great next steps:

• Want to learn how containers scale? → Read about AWS EC2 & Auto Scaling
• Curious about serverless containers? → Dive into AWS Fargate
• Want to master Kubernetes? → Explore Kubernetes in Depth
• Wondering how containers communicate? → Learn Container Networking (VPC, ALB, Service Discovery)
• Interested in production deployments? → Read about Monitoring, CI/CD & Deployment Strategies