TL;DR on the AWS Lambda Security Overview

By Abhay Bhargav

Image for post
Image for post
Abhay Bhargav

AWS recently released a whitepaper on the Security Overview of Lambda. This document is meant to be an in-depth look at Lambda Security. Its definitely a worthwhile read. However, I have tried to simplify and distill some of the most important security points for general consumption

A little bit of background on my work in Lambda. I work with AWS Lambda every day. I continue to build and release production-grade applications on Lambda and have deployed complex stacks in EdTech, Security Automation and Payment Processing, built entirely as an event-driven system on AWS Lambda. I really love AWS Lambda and the general “serverless” paradigm. It has been a game-changer for the way we build applications within we45. We’ve been able to be much more productive and faster to market because we’ve built our stack on AWS Lambda. Some of the obvious benefits of Lambda include:

  • No managing servers

I will divide this blogpost into specific segments based on topics related to AWS Lambda security. Let’s dive in!

Shared Responsibility and Lambda Layers

  • Unlike IaaS services (EC2) and PaaS Services (Elastic Beanstalk) on AWS, the Shared Responsibility Model (your problem) for Lambda largely extends to your Code, third party libraries, configurations and IAM configs applied on Lambda. You don’t need to manage the servers, consequently, the hardening, the hypervisor, the Runtime, the Sandbox, the hardware, etc.
  • Two types of Invoke Modes: Event and Request-Response Invoke Modes
Request => API Gateway => Invoke Service => Worker (VM) => MicroVM (for exec)
  • Event Invoke Modes are queued with SQS. Retrieved in batches by poller fleet. Passes to the invoke service
  • Customers cannot directly communicate with execution environment
  • Exec Role is assumed to perform Control-Plane Ops like configuring ENIs, Logs for Cloudwatch, AWS X-Ray
  • Fleet of EC2 Servers == Lambda Workers
  • Cloudwatch ⇒ Logs