In my honest (and truly humble) opinion, VPCs don’t make much sense in a serverless architecture — it’s not that they don’t add value, it’s that the value the add isn’t worth the complexity you incur.
After all, you can’t log into a lambda function, there are no inward connections allowed. And it isn’t a persistent environment, some functions may timeout after just 2-3 seconds. Sure, network level security is still worthy pursuit, but for serverless, tightly managing IAM roles and looking after your software supply chain for vulnerabilities would be better value for your money.
But if you’ve got a fleet of EC2s already deployed in a VPC, and your Lambda function needs access them. Then you have no choice but to deploy that function in a VPC as well. Or, if your org requires full network logging of all your workloads, then you’ll also need VPC (and their flow logs) to comply with such requests.
Don’t get me wrong, there is value in having your functions in a VPC, just probably not as much as you think.
Put that aside though, let’s dive into the wonderful world of Lambda functions and VPCs
First, imagine we deploy a simple VPC with 4 subnets.
- A Public Subnet with a Nat Gateway inside it.
- A Private Subnet which routes all traffic through that NAT Gateway
- A Private Subnet without internet (only local routing)
- A Private Subnet without internet but with a SSM VPCe inside it
Let’s label these subnets (1), (2) ,(3) and (4) for simplicity.
Now we write some Lambda functions, and deploy each of them to each subnet. The functions have an attached security group that allows all outgoing connections, and similarly each subnet has very liberal NACLs that allow incoming and outgoing connections.
Then we create a gateway S3 VPC-endpoint (VPCe), and route subnet (4) to it.
Finally, we enable private DNS on the entire VPC. And then outside the subnet we create a bucket and an System Manager Parameter Store Parameter (AWS really need better terms for these things).
The final network looks like this: