BeginnerIn-depth4 min readUpdated 2 Oct 2026

What is the difference between EC2 and Lambda, and when would you pick each?

SHORT ANSWER

EC2 gives you a virtual server that you run and manage, billed while it is running. Lambda runs your function only when an event arrives, scales automatically and bills per request and execution time. Pick Lambda for short, spiky, event-driven work; pick EC2 for long-running, steady or highly customised workloads.

Explain it simply

EC2 is like renting a flat. It is yours all month. You can arrange the furniture any way you like, but you pay rent even on days you are out, and you fix the leaking tap yourself.

Lambda is like booking a cab. You call it only when you need to go somewhere, pay for that ride, and never think about servicing the car. But you cannot live in a cab, and every ride has a time limit.

With EC2 you choose the operating system, install software, patch it and keep it running. With Lambda you upload a function, say which event should start it (an HTTP request, a file landing in S3, a message in a queue), and AWS handles the servers, scaling and patching.

Example

A college fest website has two jobs:

text

Job 1: Resize every photo students upload.
  - Happens in bursts after each event, idle the rest of the day.
  - Each resize takes 2 seconds.
  -> Lambda, triggered by "file uploaded to S3".

Job 2: Run a video-processing service that keeps a GPU busy for hours.
  - Long jobs, needs special drivers and a GPU.
  -> EC2 (a GPU instance type).

How it works

EC2 (Elastic Compute Cloud)

You pick an instance type (CPU, memory, GPU), an AMI (the machine image) and storage.
The server keeps running until you stop it. You are billed for the time it runs.
You handle OS updates, scaling (usually with an Auto Scaling group) and monitoring.

Lambda

You write a handler function in a supported runtime (Node.js, Python, Java and others) or package it as a container image.
An event invokes it. AWS creates execution environments as needed and runs many copies in parallel when traffic spikes.
A single invocation can run for at most 15 minutes.
You pay for the number of requests and the compute time used, so idle time costs nothing.
The first request on a new environment can be slower because AWS must start it. This is called a cold start.

Real-world use

Lambda: sending an OTP email after signup, processing UPI payment webhooks, resizing images, running a nightly cleanup job on a schedule, small APIs behind API Gateway.
EC2: a game server that keeps connections open, a legacy app that needs a specific OS setup, machine learning training, a database you want to tune yourself, or any service with steady high traffic all day where an always-on server is cheaper.

Common mistakes

Putting a long task (say, a 40-minute report) in Lambda. It hits the 15-minute limit.
Assuming Lambda is always cheaper. For constant heavy traffic, always-on servers can cost less.
Keeping state in Lambda's memory or local disk and expecting it next time. Each invocation may land on a fresh environment, so store state in a database or S3.
Running one big EC2 instance with no backup, then losing the app when that instance fails.

What to say in the interview

"EC2 is a virtual server I manage: I choose the OS and size, and I pay while it runs. Lambda is serverless: I deploy a function, it runs on events, scales automatically and I pay per request and execution time, with a 15-minute limit per invocation. I'd choose Lambda for short, event-driven or spiky work like webhooks and file processing. I'd choose EC2 for long-running processes, steady heavy traffic, special hardware like GPUs, or when I need full control of the machine. Cold starts and the time limit are the main Lambda trade-offs."

Follow-up questions

What is a cold start and how can you reduce it?
Where would you store state if your Lambda function needs it between calls?
Where do containers on ECS or Fargate fit between EC2 and Lambda?
How would you scale EC2 for a sale-day traffic spike?

Go deeper

Read these once the basics above feel easy.

Cold starts are larger for heavy runtimes and big deployment packages. Keeping packages small, initialising clients outside the handler so warm environments reuse them, and using provisioned concurrency for latency-sensitive paths all help. Reserved concurrency caps how many copies of a function can run, which protects a downstream database from being flooded.

#aws #ec2 #lambda #serverless #compute