Day 87 of 90 Days of DevOps Challenge: AWS ECS and EKS Service

Yesterday, on Day 86, I explored AWS CloudTrail, a service that records all API calls and activities happening in your AWS account. It provided me with a clearer understanding of how auditing, compliance, and security monitoring are managed in the cloud.

Today, on Day 87, I’m diving into two of AWS’s container orchestration services, Amazon ECS (Elastic Container Service) and Amazon EKS (Elastic Kubernetes Service). While both help manage containers at scale, they serve different needs and approaches. Let’s break them down.

What is Amazon ECS?

Amazon ECS (Elastic Container Service) is a fully managed container orchestration service from AWS. It helps you deploy, manage, and scale Docker containers on AWS infrastructure without needing to install your own orchestration software like Kubernetes.

In simple words → ECS is the “traffic manager” for your containers: it decides where containers run, how many run, and what happens if one fails.

Key Concepts of ECS

• Cluster – A logical grouping of EC2 instances or Fargate capacity.

• Task Definition – A blueprint of your container (image, CPU/memory, ports, env variables).

• Task – A running container (based on the task definition).

• Service – Ensures the right number of tasks are always running and handles scaling.

Launch Types

• EC2 Launch Type → You manage EC2 instances where containers run.

• Fargate Launch Type → Serverless; AWS runs the compute for you.

Why Use ECS?

Before tools like ECS or Kubernetes, running containers at scale meant manually starting/stopping them, writing scripts for scaling, and dealing with failed containers yourself.

ECS solves these problems by:

• Automatically scheduling containers across compute resources.

• Restarting failed containers.

• Scaling workloads up/down automatically.

• Integrating with AWS services (IAM, ALB, CloudWatch, VPC).

How ECS Works

1. Define your container as a Task Definition.

2. ECS schedules the task onto your Cluster.

3. A Service ensures X tasks are always running.

4. An Application Load Balancer (ALB) routes traffic.

5. CloudWatch monitors metrics and triggers auto-scaling.

Limitations of ECS

• Vendor Lock-In → Works only in AWS.

• Less Portable → If you want multi-cloud or hybrid cloud, ECS is not the best choice.

• Not Kubernetes → If your team already uses Kubernetes, ECS may feel limiting.

Best For

• Teams fully invested in AWS.

• Simple, fast deployment of microservices.

• Those who prefer serverless (with Fargate).

Real-Life Example

An e-commerce startup runs its microservices (cart, payments, users) on ECS. During Black Friday, ECS automatically scales services to handle traffic spikes.

What is EKS?

Amazon EKS (Elastic Kubernetes Service) is AWS’s managed Kubernetes service. It allows you to run Kubernetes clusters in AWS without managing the control plane (the “brain” of Kubernetes).

Kubernetes (K8s) is the most widely used open-source container orchestration platform, but it’s hard to set up and operate. EKS removes that complexity by handling:

• Control plane setup (API server, etcd, controllers)

• High availability across multiple AZs

• Security patches & upgrades

In simple words → EKS gives you Kubernetes without the headaches of running Kubernetes yourself.

Key Concepts of EKS

• Cluster – The Kubernetes environment managed by AWS.

• Nodes – Worker machines (EC2 or Fargate) where pods run.

• Pods – The smallest deployable unit, usually running one container.

• Deployments – Ensure the desired number of pods are running, support rolling updates/rollbacks.

• Services – Expose pods inside or outside the cluster.

• Ingress – Routes external HTTP/HTTPS traffic to services.

• Namespaces – Logical partitions for organizing workloads (e.g., dev, test, prod).

Why Use EKS?

Running Kubernetes on your own means installing master nodes, configuring etcd, managing upgrades, and ensuring HA. EKS solves these challenges by:

• Providing a managed, highly available control plane.

• Offering 100% upstream Kubernetes (no vendor lock-in).

• Integrating seamlessly with AWS services (IAM, VPC, CloudWatch, ALB, ECR).

• Letting you run workloads on EC2, Fargate, or both.

How EKS Works

1. Create an EKS Cluster → AWS provisions the control plane.

2. Add worker nodes (EC2 or Fargate) to the cluster.

3. Deploy applications with Kubernetes manifests (YAML).

4. EKS schedules pods on worker nodes.

5. ALB/NLB routes traffic to the right services.

6. CloudWatch collects logs and metrics.

Limitations of EKS

• Steep learning curve → Kubernetes is complex.

• Cost → Extra $0.10 per hour per cluster.

• Ops overhead → You still manage worker nodes (unless using Fargate).

• Overkill for small/simple apps → ECS is often easier.

Best For

• You already use Kubernetes and want AWS to manage the control plane.

• You want multi-cloud/hybrid portability with standard Kubernetes.

• You’re running large-scale microservices with multiple teams.

• You want access to the Kubernetes ecosystem (Helm, Prometheus).

Real-Life Example

A fintech company runs dozens of microservices on EKS. Teams use namespaces to manage their services, while AWS handles the control plane, ensuring scalability and reliability.

Final Thoughts

ECS and EKS both address the challenge of running containers at scale, but they cater to different needs. ECS is ideal if you prefer simplicity, seamless AWS integration, and minimal overhead in managing orchestration.

On the other hand, EKS is the right fit if you need Kubernetes portability, advanced features, and are comfortable with its added complexity. For DevOps engineers, the choice ultimately comes down to whether you prioritize the simplicity of ECS or the flexibility of EKS.

Tomorrow, on Day 88, I’ll move on to explore AWS CloudFormation, the Infrastructure as Code (IaC) service that automates provisioning and management of AWS resources.