Network Configuration - Serverless Architectures with AWS Lambda

Network Configuration

Executing your Lambda function occurs through the use of the Invoke API that is part of the AWS Lambda service APIs; so, there is no direct inbound network access to your function to manage. However, your function code might need to integrate with external dependencies (internal or publically hosted web services, AWS services, databases, etc.). A Lambda function has two broad options for outbound network connectivity:

  • Default – Your Lambda function communicates from inside a virtual private cloud (VPC) that is managed by Lambda. It can connect to the internet, but not to any privately deployed resources running within your own VPCs.

  • VPC – Your Lambda function communicates through an Elastic Network Interface (ENI) that is provisioned within the VPC and subnets you choose within your own account. These ENIs can be assigned security groups, and traffic will route based on the route tables of the subnets those ENIs are placed within—just the same as if an EC2 instance were placed in the same subnet.

If your Lambda function doesn’t require connectivity to any privately deployed resources, we recommend you select the default networking option. Choosing the VPC option will require you to manage:

  • Selecting appropriate subnets to ensure multiple Availability Zones are being used for the purposes of high availability.

  • Allocating the appropriate number of IP addresses to each subnet to manage capacity.

  • Implementing a VPC network design that will permit your Lambda functions to have the connectivity and security required.

  • An increase in Lambda cold start times if your Lambda function invocation patterns require a new ENI to be created just in time. (ENI creation can take many seconds today.)

However, if your use case requires private connectivity, use the VPC option with Lambda. For deeper guidance if you plan to deploy your Lambda functions within your own VPC, see this documentation.