EC2 vs Lambda: When to Use Each (With a Real Example)

Short answer: use EC2 for work that runs continuously and needs a full server environment. Use Lambda for short tasks that fire when something happens, do their job, and stop.

That is the rule. But the reason people still get this wrong — in interviews and on the SAA-C03 exam — is that they learn the two services as separate feature lists instead of as answers to different problems.

So let me show you both inside one real system.

The system we will use

Imagine a live-event ticketing platform. A major artist announces a tour and millions of people hit the site at once. Two very different kinds of work happen in that system:

1. Serving the application — customers browsing events, filtering by city, loading seat maps. This runs constantly, all day, for everyone on the site.
2. Sending the confirmation email — after a purchase succeeds, take the order details, format an email, send it. A couple of seconds of work, then finished.

Those are not the same shape of problem. And that is exactly why the architecture uses both services.

EC2: the virtual computer

EC2 stands for Elastic Compute Cloud. Strip away the branding and it is a virtual computer running in an AWS data centre. You choose how powerful it is, how much memory it has, the operating system, and what software is installed. It is your machine — you just do not physically own it.

In our ticketing platform, EC2 instances are where the application code runs. When a customer taps a concert in Manchester, the request lands on one of these servers, the application works out what they are asking for, fetches the data, and returns it.

Key characteristics:

• Always running. The server sits there ready and waiting, whether or not anyone is using it.
• You pay for uptime. Busy or idle, a running instance costs money.
• Full control. Your OS, your runtime, your configuration, your background processes.
• Scaling is something you configure. Auto Scaling adds and removes instances based on load — but you have to set that up.

That last point matters. EC2 does not scale by itself. You pair it with an Auto Scaling group and a load balancer, and that combination handles the launch-day spike.

Lambda: code without a server to manage

Lambda works completely differently. There is nothing running until something triggers it.

You write the code for what should happen. Lambda runs that code when there is work to do. When it finishes, it stops. If nobody is buying tickets at 3am, Lambda is not running and costs absolutely nothing.

In our platform, Lambda is triggered by messages arriving on the purchase queue. When a purchase message lands, Lambda runs the reservation logic, attempts the database update, and if the seat is successfully reserved, formats the confirmation email and calls SES to deliver it.

Key characteristics:

• Nothing runs until triggered. An event invokes it — a queue message, an API call, a file upload, a schedule.
• You pay per execution. Billed on invocations and duration. Idle costs nothing.
• Scaling is automatic. A thousand simultaneous events means a thousand concurrent executions. There is no Auto Scaling group to configure.
• No OS control. You supply code and configuration. AWS handles everything underneath.

The direct comparison

How to actually decide

Four questions get you to the right answer almost every time.

1. How long does the work run?

Lambda has a maximum execution duration per invocation. If a single unit of work can exceed it — a large batch job, a long video transcode, a lengthy data migration — Lambda is the wrong tool, or the job needs breaking into smaller pieces.

Our confirmation email takes seconds. Perfect for Lambda. Serving the application is continuous. Wrong shape entirely.

2. How predictable is the traffic?

This is where the cost argument actually lives, and where most "Lambda is cheaper" claims fall apart.

• Spiky or intermittent — Lambda wins. You pay nothing during the quiet hours. A workload running a few minutes an hour is dramatically cheaper serverless.
• Steady and high volume — EC2 usually wins, especially with Reserved Instances or Savings Plans. If a workload is busy 24/7, per-invocation pricing stops being a bargain.

There is no universal answer. The crossover depends on how much of the day your workload is genuinely active.

3. Do you need control over the environment?

Specific OS configuration? A particular runtime version Lambda does not support? Background daemons? Persistent connections? Specialised hardware?

That is EC2 — or containers on ECS/EKS.

4. Does it need to reach private resources?

By default Lambda runs outside your VPC and talks to AWS services through their APIs. In our ticketing platform, Lambda mainly talks to SQS, DynamoDB and SES — all managed services — so it runs happily outside the VPC.

If it needed to reach the RDS database sitting in a private subnet, we would have to attach it to the VPC, which brings extra networking configuration. Not a blocker, but a real consideration.

The cold start question

Every EC2 vs Lambda discussion eventually reaches cold starts, and it is usually overstated.

When Lambda has no warm execution environment ready, it initialises one before running your code. That adds latency to that particular invocation.

It matters when:

• The function is invoked infrequently, so environments go cold between calls
• The deployment package is large
• You are on a strict latency budget for user-facing requests

It matters much less when:

• Traffic is steady, keeping environments warm
• The work is asynchronous — like our confirmation email, where nobody is watching a spinner

Our email function is triggered off a queue. If one invocation takes an extra fraction of a second to start, no customer notices.

Why real systems use both

Here is the part that separates people who understand AWS from people who memorised it: this is not a competition.

Our ticketing platform runs EC2 and Lambda, because it has two genuinely different kinds of work:

• The application layer runs continuously, serves every browsing customer, and needs a full server environment → EC2 with Auto Scaling behind a load balancer
• The confirmation email fires on an event, takes seconds, and would otherwise pile extra load onto servers already under pressure → Lambda

Choosing Lambda for the email is not just about cost. It is about not burdening machines that are already handling a traffic spike. On launch day, when servers are working hard to keep the site responsive, the last thing you want is those same servers formatting emails.

How this shows up on the exam

SAA-C03 questions rarely ask "what is Lambda?" They give you a scenario and ask which service fits. Watch for these signals:

Points to Lambda:

• "Runs occasionally" / "a few times per day" / "unpredictable, infrequent"
• "Minimise operational overhead" / "no servers to manage"
• "Triggered when a file is uploaded to S3" / "when a message arrives"
• "Pay only for what is used"

Points to EC2:

• "Long-running process"
• "Requires a specific operating system or licensed software"
• "Needs persistent local storage"
• "Steady, predictable, high-volume workload"
• "Full control over the environment"

When a question mentions both a continuous application and a short event-driven task, the answer usually uses both — and the trap option forces everything onto one.

The takeaway

EC2 and Lambda are not competing products. They are answers to different questions.

• Work that runs continuously and needs a full environment → EC2
• Short tasks that fire on an event, do their job and stop → Lambda

Most production systems have both kinds of work, which is why most production systems run both services. Being able to explain why each piece of work went where is the thing that makes you sound like an engineer rather than someone who watched a course.