AWS Lambda functions is one of the popular Compute service for Serverless which provides powerful executions for your business logic. Lambda functions have seamless integration to every other AWS Service, but some of the services cannot be available over public network to resolve this Lambda functions can also be configured with a Virtual Private Cloud (VPC).
Why in VPC?
Whenever your Lambda function is invoking or communicating with services such as -
- Amazon RDS
- Aurora
- Elasticache
- Internal APIs with containers/EC2
- Elastic File System
With this you can not only get a network separation but also you will be able to securely connect to the dedicated services for all read or write as all the services in a VPC can communicate effectively.
Additionally, if the use-case involves external systems whitelisting your IP Address for invocation of external systems then you can add an Elastic IP and add the Lambda function to that VPC.
If your Lambda function is not in the VPC and if you are trying to invoke RDS or Aurora, the query results in a timed-out request.
Down-side to having Lambda in VPC
When your Lambda function is in a VPC, there are some down-side also which can affect the execution/computation for your application.
- Lambda fn will not have access to DynamoDB
- Lambda fn will not have access to SNS, SQS, EventBridge.
- Restricted access to only the services which are there in VPC.
- Lambda fn will not have access to external internet.
- Elongated cold starts with Lambda fns in VPC.
- Exhausting ENI Limits for the IP address which are associated to a subnet.
When to add VPC to your Lambda and when not to?
AWS Serverless Application Lens gives a perfect overview of how to choose and decide if you want the Lambda function in a VPC or not.
This makes it clear that unless, the Lambda function is using only AWS Services which are in VPC and works only in VPC such as RDS or Elasticache, don't go with VPC and if at all a VPC is setup and your Lambda function needs internet access, setup a NAT Gateway.
Conclusion
Lambda functions in VPC can affect connection to other AWS Services in a good and bad way, to help us decide better AWS Serverless Application Lens whitepaper provides a decision tree where it makes it clear that unless needed, not to setup Lambda function in VPC.
Top comments (4)
Nice post.
A couple of points. You mentioned:
Lambda fn will not have access to DynamoDB
Lambda fn will not have access to SNS, SQS, EventBridge.
I assume you mean Lambda will not have access to these services DIRECTLY.
There are 2 ways to achieve this though. You can have NAT Gateway with EIP in Public Subnet and appropriate Route table change for the private subnet and Lambda can access these services. This applies to whitelisting EIP case as well that you mentioned. It's done at NAT Gateway level, not directly at Lambda.
Second way, if you only need to access other AWS services, better option is to create VPC End point for those services and your Lambda in VPC can reach them without the traffic leaving the AWS network. In this case no NAT Gateway (which is quite expensive comparatively) is required.
Thanks
@girishjaju yes I did mean direct access but like you mentioned, alternatively you can have a NAT gateway which is allowing internet access.
AWS introduced Hyperplane Networking for Lambda in 2019, which invalidates some of the claims in this article, like :
Creation of ENIs and concurrency is managed much better by AWS. Hyperplane now creates a shared network interface when your Lambda function is first created or when its VPC settings are updated, improving function setup performance and scalability. This reduces the Cold Start time considerably. In many cases, the cold start time has gone down one or two orders of magnitude in milliseconds.
Should there be any security concerns on not running inside a VPC?
I understand that as you are not in a "closed network", theoretically, your lambda function and every metadata it produces is "in the open", more vulnerable for attacks.