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!

--

--

--

UK-based Technology Consultant working in London and Manchester.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Running multiple versions of Pop!_OS

GOOGLE Drive 相互複製 對拷

Implementing a WSO2 Identity Server Extension Using a gRPC Service

CAP Theorem

Software Delivery Process Assessment

GWC Club May 11 2022

The Most Important Person for You to Listen to

Case Studies for Software Development Outsourcing — Blog

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Matthew Leak

Matthew Leak

UK-based Technology Consultant working in London and Manchester.

More from Medium

How we handle repeated tasks using Amazon EventBridge and AWS Lambda

Laptop on desk with code

AWS Lambda: A Serverless Framework

Run a Serverless “Hello World” with AWS Lambda

AWS Lambda based on Container Image