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.
\nAn 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.
\nInstance type names are dense but regular. Take m7g.large:
| Part | \nMeaning | \n
|---|---|
m | \nfamily: general purpose | \n
7 | \ngeneration: newer is usually better value | \n
g | \nextra capability: AWS Graviton (Arm) processor | \n
large | \nsize | \n
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.
The instance is the same; the commitment changes the price.
\nCommitments are not available on the Free account plan; another reason Lantern’s production account is on the Paid plan.
\n\nWith 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.
\nHere is Lantern’s thumbnail function. S3 calls it with an event describing the uploaded poster:
\nexport const handler = async (event) => {\n const { bucket, object } = event.Records[0].s3;\n console.log(`New poster: s3://${bucket.name}/${object.key}`);\n // …download, resize, upload to thumbnails/\n return { resized: object.key };\n};And you create it with the CLI, choosing the runtime, Arm architecture, memory and timeout:
\naws lambda create-function --function-name lantern-thumbnail \\\n --runtime nodejs24.x --architectures arm64 \\\n --handler index.handler --zip-file fileb://thumbnail.zip \\\n --role arn:aws:iam::111122223333:role/lantern-thumbnail-role \\\n --memory-size 512 --timeout 30The role is the execution role from last section: it can read uploads/ and write thumbnails/, nothing else.
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:
\nconst postersPerMonth = 3000;\nconst avgSeconds = 0.8; // measured from CloudWatch logs\nconst memoryGb = 512 / 1024;\n\nconst gbSeconds = postersPerMonth * avgSeconds * memoryGb;\nconsole.log(`Requests: ${postersPerMonth}`);\nconsole.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.
\n| Lantern job | \nPick | \nWhy | \n
|---|---|---|
| RSVP API | \nLambda | \nSpiky traffic, short requests, idle most of the night | \n
| Poster thumbnails | \nLambda | \nTriggered by S3 uploads, seconds of work | \n
| Nightly 40-minute archive | \nEC2 On-Demand or Spot | \nToo long for one invocation; runs briefly each day | \n
| Old Node.js app during migration | \nEC2 | \nNeeds to run unchanged until it is retired | \n
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.
\n\nCompute needs somewhere to keep files. Next: Amazon S3 for objects, and EBS and EFS for disks.
\n","toc":[{"id":"sec-1","text":"Amazon EC2: a server, rented","level":2},{"id":"sec-2","text":"Reading an instance type","level":3},{"id":"sec-3","text":"How you pay","level":3},{"id":"sec-4","text":"AWS Lambda: code that runs on events","level":2},{"id":"sec-5","text":"The Lambda cost model","level":3},{"id":"sec-6","text":"Choosing between them","level":2}],"takeaways":["An instance type such as m7g.large encodes family, generation, extra capabilities and size, and each size step roughly doubles vCPUs and memory.","On-Demand suits short or unpredictable use, Savings Plans suit steady use you can commit to, and Spot suits interruptible work at a deep discount.","A stopped EC2 instance stops compute charges, but its EBS volumes and any Elastic IP address kept on it keep billing.","Lambda charges per request and per GB-second of run time, scales to zero, and suits event-driven work that finishes within 15 minutes.","Choose Lambda by default for small event-driven jobs, and EC2 when you need long-running processes, full OS control or steady heavy load."],"further":[{"title":"Amazon EC2 instance types","url":"https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-types.html"},{"title":"Amazon EC2 billing and purchasing options","url":"https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html"},{"title":"How Lambda works","url":"https://docs.aws.amazon.com/lambda/latest/dg/concepts-basics.html"},{"title":"AWS Lambda pricing","url":"https://aws.amazon.com/lambda/pricing/"}],"quiz":[{"q":"What does c7g.xlarge tell you compared with c7g.large?
g in c7g means Graviton (Arm) in both names. An x86 equivalent would drop the g, for example c7i."}],"answer":0},{"q":"Lantern runs a nightly poster-archive job that takes 40 minutes and can safely restart if interrupted. Which option fits best?
","options":[{"text":"AWS Lambda, because it is always the cheapest compute.","why":"A single Lambda invocation can run for at most 15 minutes, so a 40-minute job does not fit without splitting it up."},{"text":"A 3-year Savings Plan on a large instance that runs all day.","why":"A commitment for 24 hours a day to cover 40 minutes of work pays for 23 idle hours."},{"text":"An On-Demand instance that runs only for the job, or a Spot Instance since interruptions are acceptable.","why":"Correct. Paying only while the job runs fits a short daily task, and Spot’s discount suits work that can restart."}],"answer":2},{"q":"You stop Lantern’s old migration server for the weekend. Which charges continue?
","options":[{"text":"None; a stopped instance is free.","why":"Only the compute charge stops. Attached storage and Elastic IP addresses are separate resources with their own billing."},{"text":"The instance’s hourly compute rate, at a reduced weekend price.","why":"AWS has no weekend pricing, and a stopped instance does not accrue compute charges."},{"text":"Data transfer for the traffic the server would have received.","why":"A stopped server receives no traffic, so there is no data transfer to bill."},{"text":"Its EBS volumes and any public IPv4 address that stays allocated to it.","why":"Correct. Storage persists while stopped, and AWS charges for public IPv4 addresses by the hour whether or not they are in use."}],"answer":3}],"exercise":{"kind":"choice","multiple":true,"options":["spot-batch","sp-steady","lambda-long","ondemand-trial","spot-db","ec2-idle-api"],"correct":["spot-batch","sp-steady","ondemand-trial"],"title":"Match workloads to compute and pricing","prompt":"A cost review of Lantern lists six proposals. Select every proposal that is a sensible match between the workload’s shape and the compute or purchasing option.
\n","hints":["Ask three questions per proposal: how long does it run, how steady is it, and what happens if it is interrupted?","Spot is cheap because it can disappear with two minutes’ notice. Which workloads tolerate that?","A Lambda invocation has a hard 15-minute limit."],"explanation":"Spot suits the archive job because it restarts safely, and the discount is large. A Savings Plan suits the baseline that runs every hour of the year, because a commitment is only good value when it is fully used. On-Demand is right for a three-week trial: no commitment for something that may not last. A 40-minute job cannot run in one Lambda invocation. A primary database on Spot would go down whenever AWS reclaims the capacity. And an always-on instance for an API that is idle most of the time pays for idle hours that Lambda would not charge for.
\n","checkLabels":{},"optionText":{"spot-batch":{"text":"Run the nightly 40-minute poster archive, which can restart from a checkpoint, on Spot Instances.","why":"Sensible. Interruptible batch work is exactly what Spot is for, and a restart costs only a few minutes."},"sp-steady":{"text":"Cover the always-on migration server, which will run all year at steady load, with a one-year Compute Savings Plan.","why":"Sensible. Steady, predictable use is where a commitment pays off, because every committed hour is used."},"lambda-long":{"text":"Move the 40-minute archive job into a single Lambda invocation to stop paying for a server.","why":"Not sensible. One Lambda invocation can run for at most 15 minutes, so the job would time out every night."},"ondemand-trial":{"text":"Run a three-week trial of a new search feature on On-Demand instances.","why":"Sensible. Short and uncertain usage should not carry a one- or three-year commitment."},"spot-db":{"text":"Host the primary PostgreSQL database on a Spot Instance to save money.","why":"Not sensible. A database must not disappear on two minutes’ notice; reclaimed capacity means an outage and possibly lost writes."},"ec2-idle-api":{"text":"Run the RSVP API, idle most nights and busy during big events, on a large always-on instance.","why":"Not sensible. You pay for idle hours and still risk running out of capacity in a spike. Lambda scales with requests and charges nothing when idle."}}},"words":781,"readMinutes":4}