When to Use EC2 (vs Lambda & Containers)

AWS gives you several ways to run code, and picking the wrong one wastes money and adds work. Amazon EC2 (Elastic Compute Cloud, AWS’s virtual servers) gives you a full machine you control. AWS Lambda runs your code on demand with no servers to manage. ECS and EKS run your code inside containers. This page helps you choose, and it explains the most common mistake: reaching for EC2 when something simpler would have been cheaper.

The three main ways to run compute on AWS

Before comparing, it helps to define each option in plain terms.

EC2 is a virtual server (a computer you rent by the second). You pick the operating system, install your software, and you are responsible for patching, scaling, and keeping it healthy. It runs until you stop it.
AWS Lambda is “serverless” compute. You upload a function, AWS runs it only when an event happens (an HTTP request, a file upload, a queue message), and you pay only for the milliseconds it runs. There are no servers for you to patch or scale.
Containers package your app with everything it needs to run. AWS runs containers through ECS (Elastic Container Service, AWS’s own container orchestrator) or EKS (Elastic Kubernetes Service, managed Kubernetes). With the Fargate launch type you don’t manage any servers; with the EC2 launch type the containers run on EC2 instances you own.

EC2 vs Lambda vs containers — when to use which

Factor	EC2	Lambda	Containers (ECS/EKS)
Best for	Long-running, stateful, or special-hardware workloads	Short, event-driven, spiky tasks	Microservices and apps you want portable
Who patches the OS	You	AWS	AWS (Fargate) or you (EC2 launch type)
Scales to zero	No (you pay while running)	Yes	Yes (Fargate)
Max run time per task	Unlimited	15 minutes	Unlimited
Startup latency	Minutes (boot time)	Milliseconds to seconds	Seconds
OS-level control	Full (root access)	None	Partial (inside the container)
Typical cost shape	Pay per hour, even when idle	Pay per request and per ms	Pay per running container

A decision rubric by workload shape

Match your workload to the option that fits, instead of defaulting to EC2.

Spiky or unpredictable traffic, stateless code -> Lambda. If a job runs in under 15 minutes, doesn’t keep data in memory between runs, and traffic comes in bursts, Lambda is cheaper and simpler. You pay nothing when nothing is happening.
Microservices you want to run the same way everywhere -> Containers on Fargate. If your team already builds Docker images and wants consistent deployments without managing servers, ECS or EKS on Fargate is the sweet spot.
Always-on services, full OS control, or special hardware -> EC2. If you need a GPU (graphics processing unit, used for machine learning), a persistent database on a disk, custom kernel settings, or legacy software that expects a normal Linux or Windows machine, choose EC2.
High, steady, predictable load -> EC2 with a savings plan, or containers on the EC2 launch type. When a machine runs 24/7 at fairly even load, reserved or committed EC2 pricing usually beats per-request billing.

Gotcha: EC2 is rarely the cheapest or simplest choice for spiky or stateless work. A small EC2 instance left running all month costs you even at 3 a.m. when no one is using it. Lambda and Fargate scale to zero, so an idle workload costs nothing.

When EC2 is genuinely the right call

Choose EC2 when one of these is true:

You need persistent OS-level control. Custom drivers, kernel tuning, specific OS versions, or software that must be installed system-wide.
You need specialized hardware. GPU instances for AI training, instances with very high memory, or local NVMe SSD storage for fast disk access.
You have legacy software that can’t be containerized cheaply. Old monoliths, licensed software tied to a host, or apps that assume a long-lived server.
The workload runs steadily 24/7. A reserved EC2 instance or a Compute Savings Plan can cut the bill by up to ~70% versus on-demand, which often beats serverless for constant load.

How to launch a quick EC2 instance to compare

If you want to try EC2 to benchmark against Lambda, here is the smallest path.

Console steps:

Open the AWS Management Console and go to the EC2 service.
Click Launch instance.
Give it a name, pick an Amazon Machine Image (AMI) such as Amazon Linux 2023, and choose a small instance type like t4g.micro.
Select an existing key pair (for SSH access) or create one.
Click Launch instance.

Equivalent AWS CLI v2 command:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t4g.micro \
  --key-name my-key \
  --security-group-ids sg-0a1b2c3d \
  --subnet-id subnet-0a1b2c3d \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=compute-test}]'

Output:

{
    "Instances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f",
            "InstanceType": "t4g.micro",
            "State": { "Name": "pending" },
            "PrivateIpAddress": "10.0.1.42"
        }
    ]
}

Cost tip: A t4g.micro runs at roughly $0.0084 per hour on-demand, about $6 per month if left on 24/7. The same lightweight task on Lambda might cost cents per month if it only runs occasionally. Always stop or terminate test instances when you’re done.

A quick cost intuition

The deciding number is how busy the workload is. Serverless wins when usage is low or bursty because you pay per use. EC2 wins when usage is high and steady because committed pricing brings the hourly rate down and you’re not paying a premium per request. As a rough rule: if an instance would sit mostly idle, you’re probably overpaying with EC2.

Best practices

Default to the simplest option (Lambda, then Fargate) and only move to EC2 when you hit a concrete limit like run time, hardware, or OS control.
For steady EC2 workloads, buy a Compute Savings Plan instead of paying on-demand to cut costs significantly.
Use Lambda’s 15-minute limit as a hard filter: if a job can exceed it, don’t pick Lambda.
Never leave test or “temporary” EC2 instances running; tag them and set a reminder or auto-stop schedule.
Right-size before you optimize pricing: pick the smallest instance type or memory setting that meets your performance target.
Keep workloads stateless where you can; it makes Lambda and Fargate viable and EC2 easier to scale.