AWS Lambda: Under the Hood — How Lambda Works

In my previous article, I gave an introduction to the serverless ecosystem on AWS and with slight weight to AWS Lambda. Continuing on from that post, it felt fitting to write an article that gave an introduction to how Lambda works. Many organisations and business are adopting Lambda as part of their technology stacks but have no idea on what exactly is under-the-hood.

The Lambda service is divided into two planes: The control plane and the data plane. The former being responsible for the function management API (UpdateFunctionCode, CreateFunction, DeleteFunction, etc) and the latter being responsible for the invocation API that invokes Lambda functions.

The Lambda invocation flow is a whole set of services working together to provide the complete range of functionality that Lambda provides. These services are:

• Worker — A secure environment for customers to execute their code in. This is the service responsible for downloading your code package and executing it in an environment.
• Worker Manager — As you might have guessed, this manages workers. It tracks the usage of resources and execution environments and handles the assignments of requests.
• Frontend Worker — This receives function invocation requests, validates them and dispatches the requests to the Worker Manager.
• Load Balancer — Distributes invocation requests to multiple frontend invokers in different availability zones. When AZ failures are detected, requests are routed to alternate AZ’s automatically.

There is also a Placement Service to manage the packing density of sandboxes on Workers and a Counter Service that’s responsible for tracking usage as well as concurrency limits.

To put the above services into some sort of flow to understand how they’d interact with one another, it would look a bit like this:

1. Incoming invocation requests are passed by a Load Balancer to a selected Frontend Worker
2. The Frontend Worker validates the quests and asks the Worker Manager for a sandboxed function that will handle the function invocation
3. The Worker Manager either finds a pre-existing Worker or it creates one
4. Function code is executed by a Worker

Firecracker

Workers are typically EC2 instances that have multiple functions being executed on them and these functions are owned by multiple users, not just a single user. To keep this method of execution secure, each function runs in its own secure Sandbox and is totally isolated from other sandboxes using things such as cgroups, namespaces, iptables, etc.

Sandboxes can be re-used for another invocation of the same function (what we’d call “warm”) but a sandbox will never be shared between different Lambda functions. These sandboxes have a lifespan of the function execution and are then destroyed.

The powerful technology that provides this functionality is Firecracker, an open-source project developed by Amazon and it allows for thousands of lightweight sandboxes to be executed in a single Worker environment.

Wrapping up

I hope this has been useful and you’re now a little more aware to just exactly how is able to provide us with this incredibly powerful technology. I’ve aimed to keep the article condense so it’s easily digestible.

Feel free to drop a question in the comments and as always, if you’ve enjoyed the article then please give it a clap, you can give up to 50!