What is AWS Lambda & How Does It Work?
The explanation I wish I had a few years ago
okay so every AWS lambda explainer ive ever read does the same thing, it opens with “lambda is a serverless compute service that lets you run code without provisioning servers” and then i close the tab because i still dont actually know what that means. so im not going to do that. im going to explain lambda the way i wish someone had explained it to me when i was new and confused, and by the end of this you will actually get it, not just be able to repeat the AWS website says.
just so you know i have some sort of credentials to speak about this… im a software engineer at AWS and have time and time again worked on lambdas so although i dont know everything here’s what i do know
in simple terms lambda says give me your source code. i’ll allocate a server and run it only when there is a request for it. i’ll take care of hardware, OS, security patches, availability, scaling, maintenance. i won't charge you when your code isn't running.
normally if you wanted to run code on the internet you would go rent a server, install linux, install node or python or whatever, write a little web server that listens on a port, set up a process manager so it restarts when it crashes, get an ssl cert, set up logging, set up monitoring, and then your code finally runs. and that server is on 24/7 whether anyone is using it or not, and youre paying for it 24/7 whether anyone is using it or not. so in my case i’d be paying for an entire server to accommodate my 3 active users :(
lambda just removes all of that. you write a function. one function. it looks like this in python:
`def handler(event, context): return {”hello”: “world”}`
that is genuinely all you have to write. you upload it, you tell aws “hey when something happens, run this code with this information”, and from that moment on aws is responsible for everything else. the server. the runtime. the scaling. the patching. the restart-when-it-crashes. all of it. you just own the function.
so the natural next question is what is the something that causes the function to run, and the answer is basically anything. someone hits an api url, run my function with the form data. a file gets uploaded to s3, run my function with the file. a message lands in a queue, run my function to process the message. its 6am every day, run my function. a database row changes, run my function to send the row to S3 for longterm storage. these are called triggers or event sources and there are like 200 of them and you can pick whichever one matches what youre trying to do.
okay so now that the triggered fired what happens before the code actually starts executing? lets see
an event comes in. the lambda looks around and goes “do i have a warm lambda environment ready for this function?” if yes, great, it shoves the event into that environment and your handler runs basically instantly, well technically in a couple of milliseconds. if no, lambda has to spin up a brand new tiny linux sandbox just for you, download your code into it, start the runtime (the python interpreter or the node process etc.), import all your dependencies, and then run your function. that whole spin-up is called a cold start and depending on your language and how much code you’ve got it can be anywhere from 100ms to a couple of seconds.
after your function finishes lambda keeps it warm for a bit (usually somewhere between a few minutes and an hour) in case another event comes in soon. if another event does come in there is an environment ready to process the request. if not, the environment will eventually disappear.
okay so that covers what it is and how it runs. lets talk about what you actually use it for.
the most common use is sticking a lambda behind something called api gateway and using the two together as a backend api. someone sends a POST request to your-api.com/users, api gateway catches it, invokes your lambda, your lambda does the work, returns a response, api gateway sends it back. pretty easy!
second big use case is file processing. user uploads an image to s3, s3 fires an event, lambda picks up the event which includes the image, resizes it into thumbnails, saves them back to s3. the upload itself is what triggered the work. this is usually configured pretty easily via the aws console or CDK. same with all the other integrations.
third is using lmabdas to connect services together. you have system A and system B and they need to talk to each other but they dont quite speak the same language. solution…write a lambda. it reads from one, transforms the data, writes to the other. from my experience at aws this is probably the most popular use case for lambdas.
fourth is scheduled jobs. cron but in the cloud. some examples off the top of my head are every night at 3am clean up old records, every monday email a report, every 5 minutes check if the api is healthy. eventbridge fires the schedule, lambda runs the function, you go back to sleep. again these sound complex but connecting them is actually really simple.
i dont have a lot of experience with pricing since as a dev at AWS we don’t think a lot about pricing but you pay for two things. number of invocations and how long they run multiplied by how much memory you gave them. there is also a free tier gives you 1 million invocations and 400,000 gb-seconds per month for free. by gb-seconds its the amount of ram allocated to your lambda multiplied by how long the lambda ran.
there are a couple of limits that lambda has though which you honestly dont have to remember but it does help to know when you are discussing trade-offs etc.
it has a hard 15 minute max runtime. it has a stateless model, meaning anything you store in memory or on disk during one invocation is gone the next time, so if you need to remember things between requests you have to put that state somewhere external like dynamodb or s3 or a database. in other words if you create a variable during one invocation the next invocation wont be able to access it. it has cold starts, so if youre building something where every single millisecond of latency matters think about using provisioned concurrency which basically keeps a set amount of lambdas always pre-warmed.
okay so how do you actually try this. honestly the fastest path is just open the aws console, search for lambda, hit “create function”, pick python or node, paste the 3 line handler i wrote earlier, hit test, watch it run, look at the logs in cloudwatch. the whole thing takes maybe 4 minutes and i think doing this once will teach you more than reading 10 more articles like this one. seriously. close this tab after you finish reading and just go click around. its free. use chatgpt if you get stuck.
anyway thats lambda. its just a function that runs when something happens and you pay only for the time it ran. everything else like the runtimes, the triggers, the scaling, the pricing, the cold starts is all just extra details which i honestly learnt a lot of when writing this blog haha. if you remember nothing else from this article remember that one sentence and youll be fine.
i want you to actually go build something with this btw, not just read about it, because lambda is one of those things that goes from “kinda confusing” to “oh thats it?” the second you deploy your first one. so go do it.
if you learnt something subscribe! xD