What Is AWS Lambda? Serverless in Plain English

AWS Lambda runs your code only when something triggers it — a file upload, a web request, a schedule — and bills you only for the milliseconds it actually runs, with the first million runs every month free, forever. That's the whole idea: renting seconds of a computer instead of renting a computer. And here's the detail that tells you everything about serverless: the most famous Lambda disasters weren't caused by too many visitors. They were functions that accidentally triggered themselves — output feeding back into input, running in a perfect loop, billing by the millisecond around the clock. It happened often enough that AWS built in an automatic circuit breaker: Lambda now detects a function calling itself in a loop and kills the chain after about 16 rounds. The tool is genuinely wonderful. It just rewards understanding what's actually going on — which is what this post is for.

Jake needed eight seconds of computer a day

Jake runs a small phone and laptop repair shop, and by now — if you've been following this series — he has photos of every repair stored in Amazon S3. His new problem was small and annoying: every photo came off his phone at 4 MB, and he wanted a small, fast-loading copy of each one for the customer receipts. Resizing them by hand took a minute per photo. Some days there were thirty photos; some days, none.

His first instinct was the one everyone has: "So I need a server that resizes photos." He priced up an EC2 instance and called Ethan — his friend who works in IT and who, at this point in the series, should probably be on retainer.

"Add it up first," Ethan said. "Resizing one photo takes what, a quarter of a second of actual computing? Thirty photos is eight seconds. You're about to rent a computer for 86,400 seconds a day to use eight of them."

That gap — between the eight seconds of work you need and the always-on computer you were about to rent — is the exact gap Lambda exists to fill. Jake's resizer became a Lambda function: whenever a photo lands in his S3 bucket, the function wakes up, resizes it, saves the small copy, and goes back to not existing. His compute bill for it, most months: $0.00, because the free tier swallows it whole.

What Lambda actually is, in plain English

Lambda is a place to put a function — a small piece of code that does one job — and a menu of triggers that decide when it runs. That's the entire mental model:

The function: code you write, in Python, JavaScript (Node.js), Java, C#, Go, Ruby, or nearly anything else via custom runtimes. It takes an input (the "event" — details of the file that was uploaded, the web request that arrived), does its work, and finishes.

The trigger: the event that wakes it up. A file landing in S3. An HTTP request. A schedule — "every day at 6 pm." A message arriving on a queue. A row changing in a database. If something happens in AWS, there is almost certainly a way to make it run your function.

Everything else — servers, scaling, patching — is AWS's problem. If one photo arrives, your function runs once. If a thousand arrive in the same minute, AWS quietly runs up to a thousand copies of it side by side, then throws them all away when the work is done. You did nothing to make that happen, and you'd have had to do a great deal to make it happen on your own server.

"Serverless" is a lie, but a useful one

"Hang on," Jake said. "If there's no server, what is my code running on? Vibes?"

"There are servers," Ethan said. "Racks of them, same as everything in this series. Serverless means they're not your servers. You'll never see them, name them, patch them, restart them, or pay for them while they're idle. The word describes your job, not the hardware."

That's the honest framing. When we introduced EC2, we said the cloud is renting a computer. Lambda is one step more abstract: renting seconds. And like every abstraction in this series, it trades control for convenience — you can't fine-tune the operating system under a Lambda function, because as far as you're concerned there isn't one. Most of the time, for small jobs, that's a trade you make gladly.

The pricing: milliseconds, GB-seconds, and a free million

Lambda charges you for two things, and both are tiny numbers that only become real money at real scale:

A GB-second sounds like jargon but it's just memory multiplied by time: a function configured with 1 GB of memory that runs for one second used one GB-second. Jake's resizer at 512 MB running a quarter-second per photo uses an eighth of a GB-second per photo — meaning his free 400,000 GB-seconds covers over three million photos a month. His thirty-a-day habit doesn't register as a rounding error.

Two honest footnotes. First, prices vary slightly by region, and Arm-based functions run about 20% cheaper — treat our numbers as the right order of magnitude, not gospel. Second, the free million is an always-free allowance that resets every month, and it's separate from the time-limited credits that new AWS accounts get under the free plan we covered in our AWS billing post. This is the same series rule as always: we tell you the price before you click anything.

The famous failure: the function that hires itself

Now the part most beginner guides skip, which is exactly why we won't. Think about Jake's resizer for a second: it triggers when a photo lands in the bucket, and it finishes by saving a photo into the bucket. Do you see it?

If he'd configured it carelessly — trigger on the whole bucket, save the resized copy into the same place — the small copy would land, which counts as a photo landing, which triggers the function, which saves a copy, which triggers the function. Forever. Each run costs a fraction of a cent; the loop runs day and night; the "pay only when it runs" model turns into "it always runs." This isn't hypothetical — the S3-to-Lambda loop is the single most storied way people used to wake up to shocking serverless bills, and the internet is full of postmortems written by very embarrassed engineers.

Two things protect you today. The first is design: Jake's function reads from an uploads/ folder and writes to a thumbnails/ folder, and the trigger only watches uploads/ — output can never become input. The second is AWS's circuit breaker: since 2023, Lambda detects common recursive patterns (through queues and notifications, with S3 loops added in late 2024) and drops the event after about 16 loops, then notifies you through the Health Dashboard and email. It's on by default. But note the fine print — it catches the trigger patterns AWS can trace, not every creative way a system can feed itself. The design rule still matters.

What Lambda is brilliant at — and where it's the wrong tool

That last row deserves its own honest section, because it's the first thing you'll notice in practice.

Cold starts: the catch nobody puts in the brochure

When your function hasn't run in a while, AWS has to set up a fresh little environment before it can execute — load the runtime, load your code, then run it. That setup is a cold start, and it adds anywhere from a fraction of a second to a few seconds, depending on the language and how much your function drags in with it. Once warm, repeat runs skip the setup and start almost instantly, until the environment is eventually retired.

Whether this matters depends entirely on who's waiting. Jake's photo resizer runs in the background; nobody notices or cares if it starts half a second late. A checkout button on a store, where a human is watching a spinner? There, cold starts are a real design consideration, and it's a big part of why serious user-facing systems mix serverless with always-on pieces. For your first year of Lambda use — automations, chores, glue — you will mostly not care. We just refuse to be the guide that didn't mention it.

Your first function in five minutes (no code editor required)

You can see all of this yourself, free, inside the console:

1. Sign in to the AWS console and search for Lambda, then click Create function.
2. Choose Author from scratch, name it something like hello-lambda, pick Python as the runtime, and click Create function.
3. AWS drops you into a built-in code editor with a tiny working function already in place — it takes an event in and returns a message.
4. Change the message text to something of yours, then click Deploy.
5. Click Test, give the test event a name, accept the defaults, and run it. The output panel shows your message — plus exactly how many milliseconds it ran and how much memory it used. That readout is the entire billing model, printed after every run.
6. When you're done exploring, delete the function (Actions > Delete). Not because it's costing anything meaningful — an unused function costs nothing to leave around — but because a tidy account is a habit this series keeps recommending.

One thing you'll notice during creation: AWS makes an execution role for the function — its identity and permissions. That's IAM, from earlier in this series, doing exactly what we said it does: your function can only touch what its role allows, which is why a runaway function can't, say, quietly reach into services you never granted it.

Lambda vs. EC2: seconds vs. computers

Since this series covered EC2 first, the natural question is which one you should reach for. The honest answer is a traffic-pattern question, not a technology question. Work that arrives in bursts with silence in between — Jake's photos — is Lambda's home turf, because you pay nothing for the silence. Work that never stops — a busy database, a server that's genuinely computing all day — belongs on a machine you rent flat-out, because at 100% utilization the per-second math favors owning the whole box. In between, teams run both, and that's not indecision; it's using each price model where it wins.

"So the shop analogy," Jake tried: "EC2 is hiring a full-time employee. Lambda is a repair tech I can summon for eight seconds, thirty times a day, who bills me per second and vanishes."

"And the first million summonings each month are free," Ethan said. "Which is a benefits package no employee has ever offered you."

Keeping your Lambda bill at $0 — the checklist

1. Set a Budget alert first — the same free, five-minute setup from the billing post. It's the smoke alarm for everything else on this list.
2. Never let output become input. Separate folders (or separate buckets) for what a function reads and what it writes, and point the trigger only at the input side.
3. Right-size the memory setting. Memory is half the price formula; a function that needs 128 MB configured at 1 GB bills eight times the GB-seconds for the same work. The Test readout tells you what it actually used.
4. Be suspicious of your own schedules. "Every minute" is 43,200 runs a month from one innocent-looking cron trigger. Every five minutes is usually just as good and 5× fewer runs.
5. Glance at the Monitor tab occasionally. The invocation graph makes a misbehaving trigger obvious in one look — a flat line with a daily bump is health; a wall is a problem.

If you're here for the certification

Lambda shows up on nearly every AWS exam, but it's the beating heart of the AWS Certified Developer – Associate, and the Solutions Architect – Associate loves scenario questions shaped exactly like this post: "traffic arrives in unpredictable bursts; minimize cost" (that's Lambda) versus "steady 24/7 processing; minimize cost" (that's not). If you can explain the GB-second, the 15-minute cap, cold starts, and why the S3 loop happens, you can already answer a surprising share of the serverless questions on either exam. Our AWS series is deliberately built in the order those exams think: storage, compute, permissions, billing, and now event-driven glue.

Frequently asked questions

What is AWS Lambda in simple terms?

A service that runs your code only when something triggers it and bills only for the milliseconds it ran. You upload a function, connect a trigger, and AWS handles servers, scaling, and patching invisibly.

Does serverless mean there are no servers?

No — your code runs on AWS servers. Serverless means they're not your problem: you never choose, patch, restart, or pay for an idle machine. You rent seconds of computing instead of a computer.

How much does AWS Lambda cost?

Roughly $0.20 per million requests plus about $0.0000166667 per GB-second on x86, billed in 1-millisecond slices — after a monthly free allowance of 1 million requests and 400,000 GB-seconds.

Is the Lambda free tier really free forever?

Yes — it's an always-free allowance that resets monthly, separate from the time-limited credits new accounts get. Many small automations genuinely run for $0.00 indefinitely.

What is a Lambda infinite loop, and can it still bankrupt me?

It's a function whose output re-triggers its own input, classically through S3. Since 2023 Lambda detects the common patterns and drops the event after about 16 loops (S3 coverage arrived late 2024) — so the storied disaster bills are largely fenced off, but only for patterns AWS can trace. Good input/output separation is still on you.

What is a GB-second?

Memory times time: 1 GB of configured memory running for one second. A 512 MB function running two seconds is also one GB-second. It's the unit Lambda uses to charge for compute.

What programming languages does Lambda support?

Python, JavaScript (Node.js), Java, C#/.NET, Go, and Ruby officially, plus almost anything else through custom runtimes or container images.

What is a cold start?

The setup delay when a function that hasn't run recently needs a fresh environment — a fraction of a second to a few seconds. Warm functions skip it. It matters for user-facing requests, barely at all for background jobs.

How long can a Lambda function run?

Up to 15 minutes per invocation. Longer work belongs on EC2, containers, or a queue that splits the job into smaller pieces.

When is Lambda the wrong choice?

Long-running processes, apps needing persistent connections or in-memory state, latency-critical paths that can't tolerate cold starts, and steady heavy workloads where an always-on server is cheaper. Serverless is a tool, not a religion.

Is Lambda cheaper than EC2?

For spiky or occasional work, dramatically — you pay nothing between runs. For steady always-busy workloads the math flips and a reserved instance usually wins. The crossover is about your traffic pattern.

Do I need to know Linux or servers to use Lambda?

No — that's most of the appeal. Console editor, Deploy, Test, done. You'll eventually want to understand triggers and IAM permissions, but there's no server administration.

What triggers can start a Lambda function?

A file landing in S3, an HTTP request via API Gateway or a function URL, a schedule, a queue message (SQS), a notification (SNS), database and stream events — if something happens in AWS, it can usually run a function.

Can a Lambda function talk to S3, EC2, or a database?

Yes — that's the normal pattern. Lambda is the glue of AWS. What a function may touch is controlled by its IAM execution role.

How do I make sure Lambda never surprises me on a bill?

Budget alert on day one, deliberate triggers (output never feeds input, schedules no more frequent than needed), and an occasional glance at the invocation graph in the Monitor tab. Most surprises are a trigger firing more than expected, not the per-run price.

Which AWS certification covers Lambda?

It appears across most of them, but it's central to Developer – Associate and features heavily in Solutions Architect – Associate scenario questions about serverless versus servers.

Next stop in the series: your function resized the photo — but where do you keep the record of it? Order numbers, customer names, repair status — that's a database question, and AWS's answer for the serverless world is DynamoDB. That's the next post. Jake's shop, as ever, will be our test lab — over chai, per tradition.