Setting Up a VPC for Your App Using AWS Management Console

In this blog, I will demonstrate how to set up a Virtual Private Cloud (VPC) using the AWS Management Console for your application. I have a Lambda function that is behind a custom domain API Gateway. This Lambda function interacts with DynamoDB (without going through the internet) and some third-party APIs. The Lambda function is behind a custom domain API Gateway.

Things to Keep in Mind

1. Resources inside a VPC must use security groups (SG) which act as firewalls, defining inbound and outbound rules for each resource.
2. Once inside the VPC, the Lambda function cannot talk with DynamoDB or any other third-party API due to the security group.
3. To allow the Lambda function to talk with DynamoDB while keeping the connection within AWS VPC, we use a VPC Endpoint of type Gateway (which is cost-effective compared to Interface type).
4. Currently, Gateway type VPC Endpoints are only supported by S3 and DynamoDB. To communicate with other services, Interface type VPC Endpoints are required.
5. Gateway type VPC Endpoints require a record in the route table and do not depend on security group outbound rules, whereas Interface type VPC Endpoints require security group inbound and outbound rules.
6. To allow our Lambda function to talk to public APIs over the internet, we need to create a NAT Gateway in a public subnet and associate that NAT Gateway with the private subnet's route table. Public subnets are those with a route table linked to an Internet Gateway.
7. Although resources inside a private subnet should not talk to the public internet, for convenience, we will set this up.

Creating a VPC

In your AWS account, there is always a default VPC. You have the option to create only a VPC or a VPC with additional resources (subnets, NAT Gateway, VPC Endpoint). In this guide, we will create everything one by one.

Integrating VPC with Your Lambda Function

1. Create VPC
   
   This will result in your VPC entry:
   
   

2. Create a Public Subnet
   Note: Ideally, create multiple subnets in multiple availability
   zones, but for this demonstration, I will create only one per subnet.
   
   

3. Create a Private Subnet
   
   Now you can see your entries:
   

4. Create Route Tables for Each Subnet Type (Public and Private)
   Although there is a default route created at the time of VPC creation, we will create separate routes for better management.
   
   

5. Associate the Subnets with the Created Routes
   
   
   Your route configuration for private and public subnets should look something like this:
   
   
   Make sure to associate the intended subnets.

6. Provide Internet Access to Lambda Function Inside VPC

   • Create Internet Gateway and Attach it to VPC
   • Associate Internet Gateway with Public Subnet Route
   • Create NAT Gateway on a Public Subnet and Associate it with Private Subnet Route

7. Create VPC Endpoint for DynamoDB to Avoid Internet Connections
   
   
   
   As we have selected the private route table for the above VPCE, a new entry will be created inside the private route table of type prefix list as shown below:
   

8. Create Security Group for More Granular Restrictions
   
   
   
   Generally, it is a bad practice for a security group linked to a private subnet resource to have a default outbound rule allowing outgoing internet connections for every protocol, port, and IP.

9. Link the VPC to Lambda Function
   Linking the VPC to a Lambda function is straightforward:
   
   
   

Conclusion

By following these steps, you can set up a secure and efficient environment for your application on AWS, ensuring that your Lambda function can interact with DynamoDB without going through the public internet. This setup involves creating and configuring a VPC, subnets, route tables, internet gateway, NAT gateway, and VPC endpoints, along with associating them appropriately. Following these steps will help you establish a secure and efficient environment for your application on AWS.