There are two types of AWS Lambda networking settings: No VPC and VPC-based. The major difference is that VPC-based Lambda allows you to access the resources in your VPC, e.g your EC2 resources sitting in the private subnets. No VPC lambda only can access Internet by default.
Before you choose to use VPC-based lambda, there are a couple of things you need to know first:
- Do you really need VPC-based Lambda? As I have seen many wrong use cases. Users put Lambda functions in the VPC, which actually only require Internet access. The functions still work as long as the VPC subnets have NAT or Proxy. But it will introduce some cons that will be explained below.
- The VPC-based Lambda takes longer time to cold start. The reason is that it will create a ENI which allows the function to access the internal resource through it. Due to the way it works, it brings extra initialisation time.
- Always remember to give the Lambda function the permission to create and delete the ENI, Otherwise you will see lots of invocation errors, it is either caused by it failed to access your internal resources or your account has reached the ENI limit. The best practice is to always have the role ‘AWSLambdaVPCAccessExecutionRole’ included.
- Scaling is one of the benefits of using Lambda, as it is all on demand. But be careful with that if you put Lambda function in your VPC, as you may end up reaching your ENI limit quickly if you have relatively small subnets and high function invocations. The consequence is that other resources in the same subnet won’t be able to scale up either, like ELB or Autoscaling group.
References:
https://docs.aws.amazon.com/lambda/latest/dg/vpc.html
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html#vpc-limitsenis
https://docs.aws.amazon.com/lambda/latest/dg/limits.html
Jackie Chen's IT Workshop 