EC2, ECS, EKS, and Lambda: How I Finally Made Sense of Them

adedokun damilare — Wed, 21 Jan 2026 20:49:12 +0000

EC2(Elastic Compute Cloud), ECS(Elastic Container Service), EKS(Elastic Kubernetes Service), and Lambda: How I Finally Made Sense of Them

When I started learning AWS, one thing that really slowed me down was understanding EC2, ECS, EKS, and Lambda. They all sounded like different ways to “run apps,” and most explanations assumed I already knew what I was doing.

I didn’t.

What finally helped me wasn’t memorizing features, but changing how I thought about responsibility.

The Mental Model That Clicked for Me

Instead of asking “Which one is better?”, I started asking:

How much work am I responsible for, and how much does AWS handle for me?

Once I saw these services as different levels of abstraction, everything became clearer.

EC2: Full Control, Full Responsibility

EC2 was the easiest for me to understand at first because it’s basically a virtual server.

You choose the OS, install software, handle updates, and think about scaling and availability. It feels familiar, but it also made me realize how much work “managing servers” actually involves.

EC2 taught me the fundamentals of cloud infrastructure.

ECS: Containers Without the Headache

ECS was my introduction to running containers on AWS without diving into Kubernetes.

What helped me understand ECS was this thought:

“I want to run Docker containers, but I don’t want to manage Kubernetes.”

AWS handles a lot of the orchestration, and I just focus on how my containers should run.

EKS: Kubernetes, With All Its Power (and Complexity)

EKS confused me the longest because it felt similar to ECS.

What finally made it click was realizing that EKS is for Kubernetes users, not beginners trying to avoid it. AWS manages the control plane, but I still need to understand pods, services, and deployments.

Powerful, but definitely not where I’d start.

Lambda: No Servers at All

Lambda forced a complete mindset shift.

There are no servers or containers to manage. You just write code, and AWS runs it when something happens. Once I stopped thinking of Lambda as “an app server” and started seeing it as event-driven code, it made much more sense.

The One-Line Comparison That Helped Me Most

EC2: I manage the server

ECS: I manage containers

EKS: I manage Kubernetes

Lambda: I manage only my code.

What I learned is that these services aren’t competing. They exist to solve different problems at different levels of responsibility.

If you’re new to AWS and feel confused by these names, you’re not alone. I was too. Sometimes understanding AWS isn’t about learning more, it’s about finding the right mental model.

Understanding AWS Regions and Availability Zones (Simple Guide)

adedokun damilare — Wed, 14 Jan 2026 03:41:00 +0000

When I first started using AWS, I kept seeing options for Region and Availability Zone whenever I tried to create resources. At first, I mostly ignored them and selected the default options

Over time, I realized they are not just setup details. They directly affect how fast, reliable, and available your application is.

This post explains AWS Regions and Availability Zones in simple terms and why they matter in real projects.

What Is an AWS Region?

An AWS Region is a physical location where AWS runs its data centers. Each Region is isolated from others for security and reliability.

Examples include:

US East (N. Virginia)
Asia Pacific (Mumbai)
Europe (London)

Whenever you create a resource like EC2 or S3, you must choose a Region. That choice affects:

Latency: closer Regions mean faster response times
Compliance: some data must stay within specific locations
Service availability: not every AWS service exists in every Region

I like to think of a Region as a city where AWS operates its infrastructure.

What Is an Availability Zone?

An Availability Zone is a physically separate data center inside a Region. Each Region has multiple Availability Zones.

For example, in the Mumbai Region:

ap-south-1a
ap-south-1b
ap-south-1c

Each Availability Zone has independent power, networking, and cooling, and failures in one Availability Zone do not affect the others. They are connected using fast, low-latency links.

A simple analogy is multiple buildings in the same city. If one building has an issue, the others keep running.

Regions vs Availability Zones

Region: a large geographical location
Availability Zone: an independent data center inside a Region

In summary,

A Region contains multiple Availability Zones
Availability Zones protect your application from single data center failures

Why This Design Matters

AWS uses Regions and AZs to make applications more reliable and resilient.

Key benefits:

High availability: apps stay online even if one Availability Zone fails
Fault tolerance: traffic can shift automatically during outages
Disaster recovery: multiple Regions protect against large-scale failures
Better performance: closer Regions reduce latency

If you deploy an app in only one Availability Zone and it goes down, your app goes offline. Deploying across multiple Availability Zones allows traffic to keep flowing. This is why services like Elastic Load Balancer and Rational Database Service support Multi-Availability Zone setups by default.

Common Beginner Mistakes

When learning AWS, I noticed a few common mistakes:

Assuming AZs are just logical divisions
Deploying everything in a single AZ
Forgetting to check the selected Region
Expecting services to behave the same in every Region

Understanding these concepts early helps avoid downtime and painful surprises later.

Final Thoughts

Regions and Availability Zones are not optional details you can ignore. They are foundational to how reliable and performant your AWS setup will be. I learned the hard way that choosing defaults without understanding them is an easy way to introduce downtime.

If you are building on AWS, always be intentional about your Region and spread critical workloads across multiple Availability Zones. Once you do, concepts like high availability and disaster recovery stop being abstract ideas and start making practical sense.

DEV Community: adedokun damilare