[Deep Dive] AWS Lambda — Understand the Internals

[Deep Dive] AWS Lambda — Understand the Internals

I hope you know about AWS Lambda, its AWS’s one of the most powerful serverless service , here we are not discussing about lambda features and capabilities — here we are doing a Laparoscopy of a lambda instance —Let’s see what technologies stand as the backbone of AWS Lambda services.

All this blog post idea has started from a reinvent session which I’ve seen its — AWS re:Invent 2019: Firecracker open-source innovation (OPN402) (Old but trust me its Nice)

Let’s break down Lambda and take a look inside***!!!***

First, let’s read some snippets from AWS articles, and at the end, we can try to decode it and grab info from it.

“Lambda made up of mulitple layers , These layers start with Bare metal instances, the same ones that any customer can provision, using the same underlying Nitro architecture with its security benefits Then, at a subsequent layer, there is the purpose-built lightweight virtual machine monitor called Firecracker which was created by AWS to securely manage containers and serverless functions.

Firecracker functions as an isolated environment that provides secure runtime execution for serverless functions and containers. Lambda operates in EC2 as Micro virtual machines (micro-VMs) and offers similar protections for logical isolation as other EC2 instances. Each function executes in a sandbox that is contained in the micro-VM. The sandbox offers secure Linux kernel isolation using cgroups, namespaces, seccomp, and other features. Additionally, techniques such as process jailing and static linking are used to securely isolate runtime. “

When I first heard about this ‘micro VM,’ the first two things that came to my sysad mind were:

Q1. Why they choose VM, why not using small containers?
Q2. Our traditional VM itself is a “mico” or smallest unit to run a function then what is this new term “micro vm”

After some thoughts & research I got the answer for my both questions:
To understand it better , Lets see some more snippet from the history of AWS Lambda.

Phase-1
When AWS first built Lambda, They had to choose between two security approaches. One, containerization, is fast and resource efficient but doesn’t provide strong isolation between customers; the other, running code inside a virtual machine, offers greater security at the cost of computational overhead. Security is always our top priority at AWS, so AWS built Lambda using traditional VMs.

Phase-2
AWS customers challenged to offer faster scaling, lower latency, and advanced features like provisioned concurrency. AWS knew they couldn’t build those features on traditional VMs, so they built Firecracker, which AWS released in November 2018 as an open-sourcevirtualization platform under apache 2.0 licentig.

https://aws.amazon.com/about-aws/whats-new/2018/11/firecracker-lightweight-virtualization-for-serverless-computing/

Do you get all your answers from our above snippet?

Yes — also No — It's actually create more questions to me !LoL

Q1. In Phase-1 They had choose VM over containers due to security feature — let's understand the security part little bit in-depth

Q2. In Phase-2 they created “firecracker” for microvm — lets try to understand more information about that, I’ve worked lots on VM instances for privisioning so it make sense to understand more about that.

Finally, let’s see what’s inside a Micro VM and try to understand AWS thought process in choosing it instead of containers.”

Interesting Facts:
During initial time i.e 2014 — AWS running each Lambda in separated EC2 instances :-)

Firecracker, built on top of the Kernel-based Virtual Machine (KVM) technology, brings several additional benefits compared to traditional KVM-based virtualization. Here are some advantages that Firecracker derives from KVM:

  1. Lightweight Footprint: Firecracker leverages KVM’s lightweight virtualization capabilities to create microVMs with minimal resource requirements. Each Firecracker microVM can start with as little as 5MB of memory, making it highly efficient in terms of memory utilization. This lightweight footprint allows for high-density packing of microVMs on the host infrastructure, optimising resource utilisation and enabling rapid scaling.

  2. Fast Startup Times: One of the standout advantages of Firecracker is its ability to start microVMs within milliseconds. This near-instantaneous startup time is critical for serverless workloads, where quick response times and dynamic scaling are essential. By leveraging KVM’s efficient virtualisation technology, Firecracker enables rapid provisioning of microVMs, ensuring that workloads can scale up and down seamlessly based on demand.

  3. Enhanced Security: KVM provides hardware-enforced isolation between different virtual machines, ensuring strong security boundaries. Firecracker builds upon this foundation by further reducing the attack surface. Firecracker employs a minimalistic design approach, focusing only on the essential components required for running workloads securely. This design principle enhances the overall security of Firecracker-based deployments, including those used by AWS Lambda, by reducing the potential entry points for malicious activities.

  4. Efficient Resource Utilization: Firecracker’s integration with KVM enables efficient utilization of compute resources. KVM allows Firecracker to leverage hardware-assisted virtualization, which improves the overall performance of virtualized workloads. By utilizing the capabilities of KVM, Firecracker can achieve near-native performance for workloads running inside microVMs. This efficient resource utilization translates to cost savings and optimized performance for AWS Lambda and other serverless applications.

  5. Compatibility and Ecosystem: Being built on KVM, Firecracker benefits from the broad ecosystem and compatibility that KVM offers. KVM is a widely adopted and mature virtualization technology, supported by various operating systems and hypervisor management tools. This compatibility allows Firecracker to integrate seamlessly into existing infrastructure and tooling ecosystems, making it easier to adopt and leverage for serverless workloads.

  6. Strong Isolation: Each Lambda function is executed within its own Firecracker microVM, providing strong isolation from other functions. This isolation prevents any malicious or misbehaving function from impacting the stability or security of other functions running on the same infrastructure.

“I believe now we all understand that, why Firecracker is chosen by AWS over containers. I like the security aspect and am interested in doing a deep dive to understand it more. Lazy for this post, will spend another time and come up with a security deep dive post on VM vs. containers.”

Thanks:
Diagrams | Images | Gif's are not created by me - All credit for that goes to the creators.

📚 "Stay in the know! Subscribe to the blog for the latest insights on tech trends, DevOps and Cloud strategies, and more. 📚#StayTuned
- Site Reliability.in

References:
https://www.amazon.science/publications/firecracker-lightweight-virtualization-for-serverless-applications
amazon.science/blog/how-awss-firecracker-vi...

https://www.bschaatsbergen.com/behind-the-scenes-lambda/

Did you find this article valuable?

Support Midhun K by becoming a sponsor. Any amount is appreciated!