Amazon Virtual Private Cloud (VPC) is a service that allows cloud engineering teams to create a private network within the Amazon Web Services (AWS) cloud. It enables them to define a virtual network environment, including IP address ranges, subnets, and route tables while providing control over network configuration and security. AWS Lambda is a serverless computing service that allows cloud engineers to run code in response to events without provisioning or managing servers. AWS Lambda functions run in a managed, serverless environment provided by AWS, which is not tied to a specific VPC unless configured that way. By default, the Lambda functions can access the Internet and AWS services without being constrained to a VPC. This capability allows them to operate seamlessly without needing user-defined infrastructure management. However, AWS Lambda can be connected to a custom Amazon Virtual Private Cloud (VPC). Connecting AWS Lambda to an Amazon VPC provides enhanced security by allowing cloud engineering teams to control access to resources through VPC security groups and network access control lists (ACLs). It also enables the Lambda functions to connect to private resources, such as databases and internal services, without exposing them to the public Internet. Additionally, deploying Lambda within a VPC can improve compliance with regulatory requirements by keeping data within a defined network boundary.

There are a few factors to consider when connecting an AWS Lambda to an Amazon VPC. I will discuss them in this note and review the Terraform code for this use case. If you are interested and want to follow along, here is the link to my GitHub repository: kunduso/add-aws-lambda-terraform. Please note that the branch name = add-vpc.

I will be deriving heavily from the Terraform AWS Provider documentation for Lambda. Also, please check  -automating-aws-lambda-deployment-harnessing-terraform-github-actions-and-python-for-cloudwatch-logging, where I discussed how to provision a Lambda function using Terraform.

1. Subnet and Security Groups Configuration These two properties are defined in the vpc_config property of the aws_lambda_function Terraform resource definition. The subnet_ids stores a list of subnets where several instances of a Lambda function can be hosted. Ideally, it is preferred to assign private subnets if the Lambda functions do not need public internet access. A private subnet does not have a route to the Internet (0.0.0.0/0) via an Internet Gateway. Similarly, the security_group_ids are a list of security groups that are applied to manage communication with the Lambda function to control inbound and outbound traffic, allowing the Lambda function to communicate with other resources in the VPC. The security group ingress and egress rules determine which protocol, port, and addresses the Lambda can communicate with.

2. VPC Endpoint Configuration A VPC endpoint is a network component that allows private connections between the Virtual Private Cloud (VPC) and supported AWS services without using public IPs or traversing the Internet. It improves security and performance by enabling direct, secure access to services like S3, DynamoDB, or private service links within the AWS network. So, if the Lambda function requires access to AWS services like S3 or DynamoDB, VPC endpoints can be used to avoid public internet traffic. Below is an example of a VPC endpoint configuration. As you can examine, an aws_vpc_endpoint resource requires the vpc_id, the AWS service_name (which is CloudWatch Logs in this case), the endpoint_type (Gateway or Interface), the subnet_ids to associate with the endpoint and the security_group_ids to manage secure communication with the endpoint. The snippet below also contains the aws_security_group and aws_security_group_rule to manage communication with the endpoint. In this case, the VPC endpoint and the Lambda function are hosted in the same subnets. You can read more about that at -configuration-vpc-endpoints.

3. IAM Role Configuration An AWS Lambda function requires an IAM role to access resources within a VPC. The IAM role needs the AWSLambdaVPCAccessExecutionRole policy, which grants the necessary permissions to create and manage network interfaces in the VPC. This role ensures that the Lambda function can securely communicate with resources like RDS, EC2, and other services inside the VPC. The code snippet below shows how to attach the managed policy with the role. And, under the aws_lambda_function resource, the role property determines the ARN of the IAM role with the attached managed policy discussed above. You can read more about that at  -AWSLambdaVPCAccessExecutionRole. With these three configuration changes, the cloud engineering team can smoothly and securely host the AWS Lambda function inside a VPC. After implementing these changes, I navigated to AWS Console and searched for Lambda -> selected the Lambda function  -> Configurations  -> VPC to view the network configurations along with the security group ingress and egress rules applied to the Lambda function. If you are interested in learning more, please check -giving Lambda functions access to resources in an Amazon VPC. If you have any questions or suggestions, please do not hesitate to contact me via the comments below.