Lambda vs EC2: Which AWS Compute Service Should You Choose?

Definition

AWS Lambda and Amazon EC2 are the two endpoints of AWS's compute spectrum. AWS Lambda is a serverless, event-driven compute service: you upload code, AWS runs it in response to triggers, and you pay per invocation and per millisecond of execution. There are no servers to patch, no capacity to plan, and no idle cost. Amazon EC2 (Elastic Compute Cloud) is the original AWS compute service: you launch virtual machines (instances), choose the OS and instance type, and pay per second for whatever you provision — running or idle. Lambda gives you zero operational overhead in exchange for strict execution limits; EC2 gives you full control in exchange for capacity management.

Nearly every "should we use Lambda or EC2?" debate is really a question about three trade-offs: execution duration, traffic shape, and operational maturity. This guide breaks each one down with numbers.

How They Work

Lambda runs your code inside a managed, language-specific runtime (Python, Node.js, Java, Go, .NET, Ruby, or a custom runtime via a container image). When an event arrives — an S3 upload, an API Gateway request, an EventBridge rule, a queue message — Lambda allocates an execution environment, loads your code, and runs the handler. If no event arrives for several minutes, the environment is frozen or destroyed; the next event triggers a cold start (typically 100ms–1s for interpreted languages, longer for JVM/.NET unless you use SnapStart). Lambda scales automatically — up to 1,000 concurrent executions per Region by default, raising to tens of thousands on request — and bills only while your code is running.

EC2 provisions virtual machines on AWS's hypervisor (Nitro on current generations). You choose an Amazon Machine Image (AMI), an instance family (t/m/c/r/x/g/p/i/d/z) and size, attach EBS volumes, and place the instance in a VPC subnet. EC2 then runs the instance continuously until you stop or terminate it — and bills per second (Linux/Windows, 60-second minimum) regardless of whether your code is busy. Capacity scaling is your responsibility, typically using an Auto Scaling Group with target-tracking on CPU, request count, or a custom metric.

Mental model: Lambda is rented by the millisecond of work; EC2 is rented by the second of uptime.

Side-by-Side Comparison

| Aspect | AWS Lambda | Amazon EC2 | | --- | --- | --- | | Abstraction | Function (handler) | Virtual machine (OS + disk + network) | | Provisioning | Automatic, on-demand | Manual or via Auto Scaling Group | | Max execution time | 15 minutes per invocation (durable functions: up to 1 year) | Unlimited — runs until you stop it | | Memory range | 128 MB – 10,240 MB | 0.5 GB – 24 TB (x2iezn / u-series) | | vCPUs | Scales with memory (max ~6 vCPUs at 10 GB) | 1 – 448 vCPUs depending on instance type | | Cold start | 100 ms – several seconds (SnapStart reduces this to sub-second) | None — instance is always warm | | Billing granularity | Per 1ms of execution + per request | Per second (60s minimum) | | Idle cost | $0 | Full instance price | | Scaling speed | Sub-second to thousands of concurrent executions | 1–5 minutes to launch a new instance | | OS access | None (managed runtime) | Full root / Administrator | | Persistent disk | /tmp (10 GB ephemeral) + optional EFS mount | EBS volume(s), Instance Store | | Networking | Optional VPC; otherwise AWS-managed network | Always in a VPC | | Runtimes | Managed languages + container images (up to 10 GB) | Anything you can install | | Concurrency limit | 1,000 per Region (raisable) | Limited by instance vCPU count and account quota | | Free Tier | 1M requests + 400,000 GB-seconds / month, always free | 750 hours/month of t3.micro for 12 months |

Pricing Comparison: A Concrete Example

Let's price a workload that handles 2 million HTTP requests per month, each taking 200ms of CPU and 512 MB of memory.

Lambda (us-east-1, x86 Arm Graviton2 pricing is ~20% cheaper):

• Requests: 2,000,000 × $0.20 per million = $0.40
• Compute: 2,000,000 × 0.2s × 0.5 GB = 200,000 GB-seconds × $0.0000166667 = $3.33
• Total: ~$3.73/month

EC2 t3.micro (us-east-1 Linux, $0.0104/hour, ~$7.59/month) running 24/7:

• 730 hours × $0.0104 = $7.59/month (plus ~$0.10 for EBS volume)
• Plus your time configuring auto-scaling, patching the OS, and rotating logs.

For low, intermittent traffic, Lambda wins on raw price and operations. But flip the workload: 200 million requests/month of the same shape costs Lambda about $373/month, while a single c6g.large (2 vCPUs, $0.068/hour, ~$50/month) can handle 200M lightweight requests easily with headroom. At high, steady throughput, EC2 (or Fargate) usually wins.

Rule of thumb: when sustained CPU utilization exceeds ~50% on a right-sized EC2 instance, that instance is cheaper than the equivalent Lambda workload.

When to Choose Lambda

• Spiky or unpredictable traffic — Lambda scales to zero and handles bursts automatically.
• Event-driven workloads — S3 uploads, DynamoDB Streams, SQS, EventBridge, API Gateway, IoT Core.
• Short tasks — webhooks, image thumbnailing, CSV parsing, log enrichment, scheduled jobs.
• You want zero operational burden — no patching, no scaling configuration, no instance failures to handle.
• You're early-stage — Lambda's free tier (1M requests + 400,000 GB-seconds, always free, not 12-month) is generous.
• Multi-language microservices — each function can use a different runtime independently.

When to Choose EC2

• Long-running processes — anything beyond 15 minutes per task. (Durable Lambda functions reach 1 year, but they're stateful workflows, not raw compute.)
• High, steady traffic — sustained CPU/memory utilization makes provisioned EC2 cheaper than per-millisecond Lambda billing.
• GPU / specialized hardware — Lambda doesn't offer GPUs; EC2 has p4/p5 (NVIDIA H100), g5, inf2 (Inferentia), trn1 (Trainium).
• You need OS-level control — kernel modules, sysctl tuning, custom networking, agents that need root.
• Stateful workloads — databases, caches, brokers (RabbitMQ, Kafka), or any process holding in-memory state across requests.
• Legacy lift-and-shift — applications expecting a traditional VM, persistent disk, and a static IP.
• Predictable workloads with Reserved Instances or Savings Plans — 1- or 3-year commitments cut EC2 cost by 40–72%.

The Middle Ground: Fargate, ECS, App Runner

Lambda and EC2 are extremes. Most production AWS workloads land in between:

• AWS Fargate — serverless containers on ECS or EKS. No instances to manage, but tasks can run for hours, use more CPU/memory than Lambda, and run any binary.
• AWS App Runner — managed container service for HTTP applications; scales to zero like Lambda but runs containers like Fargate.
• EC2 Auto Scaling Group — fleet of EC2 instances scaled by target tracking; the traditional choice for predictable, sustained load.
• AWS Batch on Fargate or EC2 — for long-running, parallel job queues.

If Lambda's 15-minute limit, 10 GB memory cap, or cold start latency rule it out — but you still don't want to manage instances — Fargate is usually the answer, not raw EC2.

Cold Starts and How to Manage Them

Lambda cold starts are the most common production concern. Approximate cold start times (2026, x86):

• Python / Node.js: 100–400 ms
• Go (compiled binary): 50–200 ms
• Java (without SnapStart): 1–5 s
• Java with SnapStart: 200–500 ms
• .NET (without SnapStart): 1–3 s
• Container image (10 GB): 1–10 s depending on image size and caching

Mitigations:

1. Provisioned Concurrency — pre-initialized environments held warm; costs extra but eliminates cold starts.
2. SnapStart — snapshot-and-restore for Java, Python, and .NET, included at no extra cost.
3. Reduce package size — smaller deployment packages start faster.
4. Avoid VPC unless needed — VPC cold starts were heavy until 2019; modern Hyperplane ENIs reduced this to ~100 ms additional overhead.
5. Keep the function warm with a scheduled EventBridge ping (older technique, less needed since SnapStart).

EC2 has no cold starts during steady state, but Auto Scaling scale-out still takes 1–5 minutes — slower than Lambda's burst scaling.

Pros and Cons

Lambda Pros — Zero idle cost, automatic scaling, generous always-free tier, deep AWS event integration, sub-second deployment, isolated execution per request.

Lambda Cons — 15-minute hard limit, 10 GB memory cap, cold starts, no GPU, limited concurrent invocations (default 1,000/Region), per-ms billing punishes long sustained workloads, harder local development, opaque infrastructure (you can't SSH in).

EC2 Pros — Full OS control, GPU/specialized hardware, unlimited execution duration, deep cost discounts via Reserved Instances / Savings Plans / Spot, predictable per-second pricing, no cold starts, supports stateful workloads.

EC2 Cons — You're responsible for patching, scaling, monitoring, failure recovery. Pay for idle capacity. Slower scale-out than Lambda. Operational overhead grows with fleet size.

Exam Relevance

• Cloud Practitioner (CLF-C02) — definitions, billing models, the "shared responsibility" difference (Lambda: AWS manages OS; EC2: customer manages OS).
• Solutions Architect Associate (SAA-C03) — given a workload description, choose Lambda, Fargate, or EC2. Strong signals: 15-minute boundary (above → not Lambda alone), spiky/event-driven (→ Lambda), GPU/long-running/stateful (→ EC2), steady high traffic with cost sensitivity (→ EC2 + RI/Savings Plans, or Fargate Spot).
• Developer Associate (DVA-C02) — Lambda runtime details, layers, versions/aliases, concurrency controls, environment variables.
• DevOps Engineer Professional (DOP-C02) — deploying Lambda via CodeDeploy with canary/linear traffic shift, EC2 Auto Scaling lifecycle hooks, blue/green deployments.

Classic exam trap: "a workload runs for 30 minutes per invocation" → not Lambda (over 15-minute limit). Either use Step Functions to orchestrate, durable Lambda functions, Fargate tasks, or EC2.

Frequently Asked Questions

Q: What's the maximum execution time for a Lambda function?

A: A single Lambda invocation has a hard limit of 15 minutes. For longer workflows, you have three options: (1) use Step Functions to orchestrate multiple Lambda invocations, (2) use durable Lambda functions which support stateful workflows up to 1 year, or (3) run the workload on Fargate or EC2 where execution is unlimited.

Q: Is Lambda always cheaper than EC2?

A: No. Lambda is cheaper for low or spiky traffic because you pay nothing when idle. EC2 is cheaper for high, steady traffic because per-second instance billing beats per-millisecond function billing once utilization is high. Break-even is roughly when a right-sized instance sustains over 50% CPU. Add a 1-year Savings Plan and EC2 drops another 30–40%.

Q: Can I avoid Lambda cold starts entirely?

A: Almost. Use SnapStart (free, for Java/Python/.NET) to drop cold starts to sub-second, or Provisioned Concurrency to pre-initialize environments at a fixed cost. For latency-critical APIs where even SnapStart is too slow, run on Fargate or EC2 behind an Application Load Balancer instead.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Lambda and EC2 documentation before making production decisions.