As you continue your journey in and to the cloud, you may find yourself using Lambda functions to send data to remote/3rd party API servers. Not only that, you may find that these 3rd party API providers only accept requests from whitelisted IP addresses. This may shock you, but Lambda functions are not the same as EC2 instances in that we cannot explicitly assign them elastic IPs which could then be whitelisted. Is there a workaround? Is there a way to allow Lambda functions to use 3rd party API services if that vendor only accepts requests from whitelisted IPs?
Fortunately for all of us, there is a fairly easy solution. In a blog post entitled ‘AWS Lambda functions with a static IP‘, Matthew Leak details the solution:
“AWS Lambda supports executing your code from inside a VPC. With this ability we’re able to create a NAT (Network Address Translator) Gateway so that all out-bound connections from our lambda functions will exit from the NAT which is assigned to a fixed IP address. This fixed IP address can then be whitelisted by our third-parties.
- Create a new VPC to run your code in (or use an existing VPC)
- Create a new Internet Gateway to communicate with the Internet from inside your VPC
- Create a Public Subnet and add a new route to the route table which routes to your Internet Gateway from 0.0.0.0/0
- Create a new Elastic IP address.
- Create a new NAT Gateway and assign it to the Public Subnet and Elastic IP address that you just created.
- Create a Private Subnet and add a new route to the route table which routes to your NAT Gateway from 0.0.0.0/0
A lambda function can then be created inside your VPC to make a request to the Internet. The Elastic IP address that we created earlier can then be added to any external organisations’ IP whitelist.“
Close but not quite….
I recently worked with a customer who found themselves in this exact situation, they implemented this solution, yet their Lambda function was still unable to access the 3rd party API server. So let me expand on the solution just a little bit and share with you how their Lambda issue was solved.
- When executing a Lambda function within a VPC, setup the Lambda function to run in the private subnet(s) of the VPC so that all requests to the Internet will be through the static Elastic IP of the NAT.
- If you look the properties of a Lambda function, you’ll see a “Network” heading. Within the Network properties, you can specify a VPC, Subnets, and Security groups. To ensure a Lambda function uses the elastic IP assigned to a NAT Gateway, ensure that only private subnet(s) are selected.
- The client I worked with recently had both public and private subnets available to their Lambda function, thus it could use either the NAT Gateway (the function would work) or the Internet Gateway (the function wouldn’t work)
- The Lambda function must have permissions to execute inside a VPC, thus assign an execution role to Lambda with the “AWSLambdaVPCAccessExecutionRole” policy attached to it.
- Create a Private Subnet and add a new route to the route table which routes to your NAT Gateway from 0.0.0.0/0
- Yes, this is a repeat of step #6. In this case, a new route table was created for and associated it with the public subnet but for the private subnet, the client edited the main route table to use the NAT Gateway as the default route.
- We created a new route table for and associated it with the private subnet.
Once these changes were made, the Lambda function was able to use the remote API server.
Additional Resources
Below are a few additional resources you may find helpful:
Blog Post: AWS Lambda functions with a static IP – Matthew Leak
Blog Post: AWS Lambdas with a static outgoing IP – Ivonne Roberts
AWS Docs: Configuring a Lambda Function to Access Resources in an Amazon VPC
