One of the first AWS services most developers learn is Amazon EC2.
Soon after, they encounter AWS Lambda.
Since both are compute services, one obvious question comes to mind:
Why does AWS offer two different ways to run code?
Initially, I assumed the biggest difference was pricing.
As I learned more, I realized the distinction goes much deeper.
EC2 and Lambda represent two different approaches to running applications, each solving different kinds of problems.
This article summarizes the mental model that helped me understand both services.
What Is a Compute Service?
A compute service provides the processing power required to run your application.
Whether you're hosting a web application, processing uploaded files, or responding to API requests, somewhere there must be a machine executing your code.
AWS provides several compute services, but two of the most common are:
- Amazon EC2
- AWS Lambda
Although both execute code, they do so in very different ways.
Understanding Amazon EC2
Amazon EC2 (Elastic Compute Cloud) is an AWS service that allows you to create virtual machines on demand.
One misconception I had early on was using the terms Amazon EC2 and EC2 Instance interchangeably.
They're related, but they are not the same thing.
Conceptually:
Amazon EC2 (AWS Service)
│
▼
EC2 Instance (Virtual Machine)
│
▼
Operating System
│
▼
Your Application
Amazon EC2 is the service.
An EC2 Instance is the virtual machine created by that service.
Inside the instance, you install an operating system such as Ubuntu, Amazon Linux, or Windows Server.
Your application then runs inside that operating system.
Where Does the Virtual Machine Come From?
AWS owns physical servers inside its data centres.
A hypervisor running on those servers creates multiple isolated virtual machines.
Conceptually:
Physical Server
│
Hypervisor
│
├── EC2 Instance
├── EC2 Instance
├── EC2 Instance
└── ...
Customers never interact with the hypervisor directly.
AWS manages it, allowing developers to focus only on the virtual machines they launch.
Why Do People Say "SSH into the EC2"?
This is simply shorthand.
When someone says:
"SSH into the EC2."
they actually mean:
"SSH into the operating system running inside the EC2 Instance."
Likewise, when someone says:
"Deploy it on EC2."
they usually mean:
"Deploy it on an EC2 Instance."
Understanding this terminology made AWS documentation much easier for me to follow.
Understanding AWS Lambda
AWS Lambda follows a completely different model.
Instead of creating and managing a virtual machine, you upload only your code.
Whenever an event occurs—such as an HTTP request, an S3 upload, or a message arriving in an SQS queue—AWS automatically provisions the infrastructure required to execute that function.
Once execution finishes, the compute environment is released.
As developers, we don't manage operating systems or servers.
We simply write the function.
Understanding the Pricing Model
One of the biggest differences between EC2 and Lambda is how they are billed.
With Amazon EC2, compute resources are reserved for your instance while it is running.
Whether the application receives one request or one million requests, the virtual machine continues to exist until you stop or terminate it.
You are primarily paying for keeping those compute resources available.
An analogy that helped me understand this was renting a flat.
You pay rent for as long as you occupy it, whether you're inside or away.
Lambda works differently.
You are charged only when your function executes.
The cost depends mainly on:
- The number of invocations
- The execution duration
- The memory allocated to the function
If nobody invokes the function, there is effectively no compute charge.
A useful analogy is taking a taxi.
You pay only while you're travelling.
No journey means no fare.
EC2 vs Lambda
| Amazon EC2 | AWS Lambda |
|---|---|
| Creates a virtual machine | Executes individual functions |
| You manage the operating system | AWS manages the infrastructure |
| Compute resources remain available while the instance is running | Compute resources are allocated only during execution |
| Well suited for long-running applications | Well suited for event-driven workloads |
| Full control over the server | Focus primarily on application code |
Neither approach is universally better.
They simply solve different problems.
When Might You Choose EC2?
EC2 is often a good fit when:
- You need full control over the operating system.
- Your application runs continuously.
- You host databases or web servers.
- You require custom software installations.
- Long-running background services are involved.
When Might You Choose Lambda?
Lambda is often a good fit when:
- Applications respond to events.
- Workloads are short-lived.
- Infrastructure management should be minimized.
- Traffic is unpredictable.
- You want to focus primarily on business logic.
Final Thoughts
One lesson that stood out while learning AWS was that understanding services individually isn't enough.
Building a mental model of how they fit into larger systems is much more valuable.
Amazon EC2 isn't simply "a server."
It is a service that creates virtual machines.
AWS Lambda isn't "cheaper EC2."
It is a different execution model designed around event-driven computing.
Once I understood those distinctions, choosing between them became much less about comparing features and much more about selecting the right tool for the problem I was trying to solve.
Top comments (0)