Compute: Amazon EC2 and AWS Lambda

Lantern’s old server did everything: served pages, handled RSVPs, resized posters, ran a nightly export. On AWS each of those jobs can run on the compute model that fits its shape. The two you will use most are Amazon EC2, virtual servers you rent by the second, and AWS Lambda, functions that run only when something calls them.

Amazon EC2: a server, rented

An EC2 instance is a virtual machine. You choose an operating system image (an AMI, such as Amazon Linux 2023), an instance type, a network and storage, and AWS starts it in the Availability Zone you pick. Everything above the hypervisor is yours: OS patches, the runtime, the app, and scaling.

Reading an instance type

Instance type names are dense but regular. Take m7g.large:

Common families: t (burstable, cheap for spiky low use), m (balanced), c (compute-heavy), r (memory-heavy). Other suffixes include i (Intel), a (AMD) and d (local NVMe disk). Each size step, from large to xlarge to 2xlarge, roughly doubles vCPUs, memory and price. Graviton instances usually give better price-performance if your software runs on Arm, which Node.js and Python do without changes.

How you pay

The instance is the same; the commitment changes the price.

• On-Demand: pay per second (Linux, with a 60-second minimum), no commitment. Right for anything short-lived, new or unpredictable.
• Savings Plans: commit to a fixed amount of compute spend per hour for one or three years, for a significant discount. Right for the baseline you know will run all year. (The older Reserved Instances model still exists and works similarly.)
• Spot Instances: spare AWS capacity at a deep discount, but AWS can reclaim it with a two-minute warning. Right for batch work that can restart.
• Dedicated Hosts and Capacity Reservations cover licensing and guaranteed-capacity needs you are unlikely to have yet.

Commitments are not available on the Free account plan; another reason Lantern’s production account is on the Paid plan.

AWS Lambda: code that runs on events

With Lambda you upload a function and say what triggers it: an HTTP request through API Gateway, a file landing in S3, a schedule, a message on a queue. Lambda runs as many copies as there are concurrent events, and none when there are none.

Here is Lantern’s thumbnail function. S3 calls it with an event describing the uploaded poster:

export const handler = async (event) => {
  const { bucket, object } = event.Records[0].s3;
  console.log(`New poster: s3://${bucket.name}/${object.key}`);
  // …download, resize, upload to thumbnails/
  return { resized: object.key };
};

And you create it with the CLI, choosing the runtime, Arm architecture, memory and timeout:

aws lambda create-function --function-name lantern-thumbnail \
  --runtime nodejs24.x --architectures arm64 \
  --handler index.handler --zip-file fileb://thumbnail.zip \
  --role arn:aws:iam::111122223333:role/lantern-thumbnail-role \
  --memory-size 512 --timeout 30

The role is the execution role from last section: it can read uploads/ and write thumbnails/, nothing else.

The Lambda cost model

You pay per request and per GB-second: memory size in GB multiplied by run time in seconds, measured to the millisecond. CPU power scales with the memory you allocate (128 MB to 10,240 MB), and one invocation can run for at most 15 minutes. Work out Lantern’s thumbnail usage:

const postersPerMonth = 3000;
const avgSeconds = 0.8;    // measured from CloudWatch logs
const memoryGb = 512 / 1024;

const gbSeconds = postersPerMonth * avgSeconds * memoryGb;
console.log(`Requests: ${postersPerMonth}`);
console.log(`GB-seconds: ${gbSeconds}`);

1,200 GB-seconds and 3,000 requests a month sit far inside Lambda’s always-free monthly allowance, which at the time of writing is 1 million requests and 400,000 GB-seconds. An EC2 instance doing the same job would bill every second of the month, busy or idle.

Choosing between them

A good default for a team of Lantern’s size: Lambda for event-driven pieces, EC2 only when something needs a long-running process, OS-level control or steady heavy load. Containers on Amazon ECS with AWS Fargate sit between the two, and are worth a look once you package apps as images.

Compute needs somewhere to keep files. Next: Amazon S3 for objects, and EBS and EFS for disks.