Runtimes

Alright, let’s talk money. Or, more accurately, let’s talk about how AWS decides to bill you for the privilege of running your brilliant little snippets of code. It’s a surprisingly elegant model, but if you don’t understand its moving parts, you can get a nasty surprise on your monthly bill. It’s not magic; it’s just math. Let’s break it down so you’re the one in control. AWS charges you for two things, and two things only: the number of times your function is invoked, and the total compute time it consumes. That’s it. No hourly fees for idle time, no complex licensing. You pay for the electrons as they spin.

Right, let’s talk about logging. Because when your function vanishes into the ether milliseconds after running, a print("here") statement isn’t going to cut it. You need to know what happened, and for that, we’re stuck with CloudWatch Logs. It’s not a perfect relationship, but we can make it work. The absolute first thing you need to get through your skull is that every print() or console.log() statement is a log event. Lambda automatically captures anything written to stdout or stderr and shoves it into a CloudWatch Logs stream. This is both a blessing and a curse. It’s dead simple, but it also means that if you log a big JSON object as a string, you’re going to have a truly miserable time trying to query it later. Which brings me to my first major point.

Right, so you’ve written a function. It’s beautiful. It’s perfect. It’s going to take a string, reverse it, and save it to an S3 bucket. You deploy it, you test it, and… AccessDenied. It blew up the moment it tried to even look at S3. Why? Because your Lambda function is a digital amnesiac. It has no idea who it is or what it’s allowed to do. It’s running in a vacuum, utterly powerless.

Right, let’s talk about the two strange little packages that get delivered to your Lambda function’s door every time it’s invoked: the event and context objects. These are your inputs, your parameters, your window into what’s happening. Understanding them is the difference between a function that works and one that you actually understand why it works. Think of the event object as the “what.” It’s the payload, the reason your function was called in the first place. Did an image get uploaded to S3? The event will be a JSON object detailing the bucket name, the file key, and a bunch of other metadata. Did an API Gateway request come in? The event will contain the HTTP method, headers, path, and—if you’re lucky—the body of the request. The structure of this object is entirely dependent on what triggered the function. AWS services shove their relevant data into this bag and hand it to you. It’s your job to know how to unpack it.

Alright, let’s talk about the knobs and dials you get to play with on your Lambda function. This isn’t just a boring configuration page; this is where you turn a generic piece of code into a tailored, efficient, and cost-effective component of your system. Get these wrong, and you’ll either be overpaying, underperforming, or waking up at 3 AM. No pressure. Memory: The CPU Piggy Bank Here’s the first thing AWS doesn’t scream from the rooftops: when you configure memory, you’re also configuring CPU. It’s a two-for-one deal, but they only advertise the memory part. AWS allocates CPU power linearly in proportion to the amount of memory you choose. Choose 128 MB? You get a sliver of a vCPU. Choose 1792 MB? You’re almost at a full vCPU (which is actually 1 vCPU at 1769 MB, but who’s counting).

Right, let’s talk runtimes. This is where the rubber meets the road, or more accurately, where your code meets Lambda’s execution environment. Think of a runtime as a pre-packaged, ready-to-go operating system for your function. It’s the layer of software that knows how to talk to the Lambda service, bootstrap your code, and crucially, how to execute it. AWS, in its infinite wisdom (and desire to get you locked in), provides a curated list of these for popular languages. We’ve got the usual suspects: Python, Node.js, Java, Go, .NET, Ruby. And then, for when you’re feeling particularly adventurous or masochistic, the “Custom Runtime” option. Let’s break them down.

Right, let’s get into the engine room. You’ve got your function code, but how does AWS actually run it? The Lambda execution model is the secret sauce that makes this whole serverless thing work, and misunderstanding it is the number one cause of “but it works on my machine!” headaches. It’s not magic; it’s just a very clever, very disciplined system of recycling. Think of it like a restaurant kitchen. AWS has a huge pool of chefs (execution environments). When an order comes in (an invocation), the head chef (the Lambda service) needs to find a chef for it. If a chef is already prepped and waiting, they just hand them the order. If not, they have to go hire a new chef, set up their station, and then hand them the order. That setup time? That’s your cold start.