TCP #53: AWS Lambda Made Simple

A clear, no-fluff breakdown of how Lambda works and how to use it today.

You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.

---

I offer a ton of free resources. Check out my store at Gumroad if you haven’t already.

---

Let’s get straight to it: AWS Lambda lets you run code without managing servers.

No EC2 instances. No auto-scaling groups. No OS patching.

You write the code. Lambda runs it on demand. It’s fast, cost-effective, and scales automatically, whether you’re handling five requests or five million.

In today’s newsletter issue, I discuss how it works under the hood and how to use it without getting bogged down in the details.

---

What Exactly Is AWS Lambda?

Lambda is a serverless compute service.

You upload your code and configure a trigger, and AWS handles the execution. There is no provisioning, scaling, or worrying about how many CPUs or memory to allocate.

Your code sits idle until an event occurs. That event could be an API request, a new file in S3, a message in an SQS queue, or even a scheduled cron job.

Once triggered, Lambda spins up an isolated container, runs your function, and shuts it down.

Simple in theory. Powerful in practice.

Supported Runtimes

Lambda supports several languages out of the box:

• Python

• Node.js

• Java

• Go

• .NET (C#)

• Ruby

You can use a container image or custom runtime if you need something custom, like Rust or PHP.

For example, you can build a Docker image locally, push it to Amazon ECR, and use it as your Lambda runtime.

That means you're not limited by what AWS supports directly. You can run nearly any code, as long as it starts quickly and fits within Lambda’s resource limits.

---

The Event-Driven Execution Model

Lambda doesn't just run for fun—it reacts to events.

You wire it up to a trigger. That trigger could be:

• An HTTP request via API Gateway

• A file uploaded to S3

• A new record in DynamoDB

• A message in an SQS queue

• A CloudWatch schedule (like a cron job)

Here’s what to do next: define the event source and tell AWS which Lambda function should handle it. Every time the event happens, Lambda gets the event data as a JSON object and runs your code with that input.

You don’t poll. You don’t listen. You just react.

What Happens Behind the Scenes?

Here’s how Lambda actually runs your function:

1. You upload your function code and specify its runtime.

2. An event triggers your function.

3. Lambda allocates a container, runs your function inside it, and sends it the event data.

4. The container might stay warm for a while so that future invocations will be faster.

The first time your function runs, it experiences a cold start. This takes a few hundred milliseconds as AWS provisions the container. After that, AWS tries to reuse the container for future requests (a warm start).

You don’t need to manage any of this. But knowing it exists helps you optimize performance later.

---

Memory and Timeout Settings Matter

When you configure a Lambda function, you pick:

• Memory (128 MB to 10 GB)

• Timeout (up to 15 minutes)

The more memory you assign, the more CPU you get.

So, if your function is CPU-heavy, like resizing images or processing large JSON files, increase the memory for faster execution.

Also, make sure your timeout is long enough to finish the job. But don’t overdo it. You’re billed by the millisecond, so shorter functions save money.

Here’s a rule of thumb:
Start with 512 MB of memory and a 30-second timeout.
Adjust based on real-world performance.

Logging and Monitoring with CloudWatch

Every Lambda function logs to CloudWatch Logs.

When your code prints something to stdout (like console.log in Node.js or print in Python), it goes straight into a CloudWatch log group.

You can also track:

• Number of invocations

• Duration of each execution

• Error rates

• Throttles and cold starts

Here’s what to do next: go to the AWS Console > CloudWatch > Logs. Filter by the log group name, which follows the pattern:

/aws/lambda/<function-name>

From there, set up alarms for high error rates, spikes in duration, or missed invocations.

Versioning and Aliases

Lambda supports versions and aliases, which is handy for production deployments.

A version is an immutable snapshot of your function’s code and configuration. An alias is like a pointer to a version.

Here’s how to use them together:

1. Deploy a new version (v2) of your function.

2. Point the “prod” alias to v2 after testing.

3. If v2 breaks, move the alias back to v1 instantly.

No code redeploys. No rollbacks. Just fast switching.

This lets you do A/B testing or canary deployments by splitting traffic between versions.

---

Limitations to Keep in Mind

Lambda is powerful—but not magic. It has limits:

• Execution timeout: 15 minutes max

• Memory: 10 GB

• Package size: 250 MB (unzipped)

• Request/response size: 6 MB

• Concurrency: Soft limit of 1,000 (can be increased)

If you’re running long batch jobs or need high memory for AI/ML workloads, you may be better off using ECS or Batch.

Use Lambda for short, event-driven tasks, such as API backends, log processors, image resizers, or cron jobs.

Real-World Use Case

Let’s say you have a photo app. You want to create a thumbnail every time a user uploads a photo to S3.

Here’s how to do it:

1. Create an S3 bucket called user-photos.

2. Write a Lambda function in Python to read the image, resize it, and store the result in a thumbnails/ folder.

3. Set up an S3 event trigger on user-photos to invoke the Lambda on every PUT event.

4. Test by uploading an image. The function fires instantly, and you’ll see a thumbnail in seconds.

No servers. No polling. Just clean, reactive code.

---

Getting Started Template

Here’s a basic Node.js Lambda function to help you get started:

exports.handler = async (event) => { console.log('Event received:', JSON.stringify(event)); return { statusCode: 200, body: JSON.stringify({ message: "Hello from Lambda!" }) }; };

Zip this up, upload it in the AWS Console or CLI, and trigger it via the Test button or an actual event.

That’s it. You’re now running code in the cloud—without a server.

---

Final Thoughts

AWS Lambda works because it simplifies the hardest part of running applications—infrastructure.

No patching. No scaling.

You write the function. AWS takes care of the rest.

Start small. Use it for automation, notifications, or file processing. As you get more confident, you’ll find creative ways to offload work into tiny, cheap Lambda functions.

That’s the beauty of being serverless.

---

SPONSOR US

The Cloud Playbook is now offering sponsorship slots in each issue. If you want to feature your product or service in my newsletter, explore my sponsor page

Become a Proud Sponsor!

---

That’s it for today!

Did you enjoy this newsletter issue?

Share with your friends, colleagues, and your favorite social media platform.

Until next week — Amrut

---

Get in touch

You can find me on LinkedIn or X.

If you wish to request a topic you would like to read, you can contact me directly via LinkedIn or X.