Serverless computing is often touted as being an architecture that scales automatically, is less expensive to run, and offers developers a nice abstraction from the underlying infrastructure. AWS Lambda is an example of a serverless service that provides developers a mechanism to execute code without worrying about servers — or does it?
Let’s assume we wish to create a Lambda function that will access an AWS database and consume an external web API. In order to do this, the Lambda function must be configured to run in a Virtual Private Cloud (VPC). Understanding how to properly build a VPC to run a Lambda function that scales with high availability requires knowledge in a few areas.
It’s important to understand CIDR notation and how it relates to Availability Zones (AZs) and subnets. If your application has the potential to scale to many users, it’s critical to create subnets that are sized appropriately. Since our Lambda function needs to access the Internet, a NAT gateway is required in our VPC. Adding a NAT gateway to the VPC requires an understanding of network routing tables, private & public subnets and their subnet associations.
AWS Lambda functions run under an execution role. Creating an executing role requires understanding the AWS security model which includes things like policy documents, roles, trust relationships, and optionally permissions boundaries. Once our VPC is properly configured and our execution role is properly defined, we can start to create the code for our Lambda function.
In order to get our serverless AWS Lambda function to run and connect to the desired resources, we have to configure a lot of things that are typically associated with servers! We also need to be familiar with the AWS security model. This is a lot of stuff to understand and this can be confusing for developers that are looking for a simple serverless solution.