AWS Lambda vs EC2

What is AWS Lambda?

AWS Lambda is a serverless compute service introduced in 2014. You upload a function — a self-contained unit of code — and define what triggers it: an HTTP request via API Gateway, an object uploaded to S3, a message arriving in SQS, a schedule (EventBridge), or dozens of other AWS event sources.

When a trigger fires, AWS spins up an execution environment (or reuses a warm one), runs your function, and tears it down. You are billed for the number of invocations and the duration in 100 ms increments. At zero traffic you pay nothing.

The tradeoff is constraints. Lambda functions are stateless: you cannot rely on data persisting between invocations unless you store it externally in DynamoDB, S3, or RDS. Execution time is capped at 15 minutes. And when no warm environment exists, you suffer a cold start — the latency of initialising a fresh container, downloading your code, and starting the runtime.

Cold start in plain English

Imagine a restaurant kitchen where all the chefs go home when there are no orders. The moment a customer arrives, you must call the chefs back, have them put on their uniforms, and heat the oven — before cooking a single dish. That waiting time is the cold start. A warm instance is a kitchen with a chef already standing by.

What is Amazon EC2?

Amazon Elastic Compute Cloud (EC2), launched in 2006, is AWS's original compute service. You choose an instance type — a combination of vCPUs, RAM, storage, and network throughput — and launch a virtual machine running your choice of operating system. The instance runs continuously until you stop or terminate it.

Common instance families include:

• t3 / t4g — burstable general purpose; cheap, suitable for low-to-moderate workloads
• m6i / m7g — balanced CPU/memory; the default choice for web servers and APIs
• c7g / c6i — compute-optimised; for CPU-intensive workloads
• r6i / r7g — memory-optimised; for in-memory databases or large caches
• p4d / g5 — GPU instances; for machine learning training and inference

Unlike Lambda, EC2 supports persistent processes: a web server, a database, a long-running background worker, or any process that must maintain state in memory or on disk across many requests. You also get full SSH access, which makes debugging significantly easier than in a serverless environment.

EC2 demands maintenance overhead: you are responsible for OS patching, AMI updates, security group rules, monitoring agents, and capacity planning. Auto Scaling Groups help automate horizontal scaling, but the setup is far more involved than Lambda's automatic concurrency.

Lambda function skeleton (Node.js)

A Lambda handler receives an event object and a context object. It must complete within the configured timeout.

// handler.mjs — AWS Lambda (Node.js 20)
export const handler = async (event, context) => {
  // event contains trigger-specific data
  // (API Gateway request, S3 event, SQS message, etc.)
  console.log('Request ID:', context.awsRequestId);

  // Lambda is stateless — don't rely on module-level state
  // across invocations. Use DynamoDB, S3, or RDS for persistence.
  const result = await processEvent(event);

  return {
    statusCode: 200,
    body: JSON.stringify(result),
  };
};

EC2 deployment sketch (systemd service)

On EC2 you manage a persistent process. A typical Node.js API is kept alive by systemd and fronted by nginx.

# /etc/systemd/system/myapp.service
[Unit]
Description=My API Server
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/srv/myapp
ExecStart=/usr/bin/node server.mjs
Restart=on-failure
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Frequently asked questions