Expose AWS Lambda Function Behind Static IP When a DNS Cannot be Managed

Up until recently, the best practice to expose an AWS Lambda function has been to use Amazon API Gateway. This solution protects your functions from direct client traffic. This is explained in the API Gateway tutorial, where Amazon API Gateway acts as a proxy in front of the Lambda function. This practice is useful when the clients call the Amazon API Gateway DNS endpoints.

Considerations

Some clients have strict requirements when they must call an internet service. For security purposes, they use a permission list mechanism. This mechanism specifies the entire list of IPs used for outbound calls, and requires that no other IP can be used for this purpose. Most of the time this list is difficult to update due to internal procedures and approval processes, so changes could take days. A change of the internet service IP could have an enormous impact on the business.

In this case, clients could be limited to using Lambda functions as a backend serverless solution. At the moment, Lambda functions can be exposed to the internet using Amazon API Gateway or Application Load Balancer. Both must go through a DNS endpoint. This operation hides the IP address range used by these two services from the clients.

Although this is subject to change, you can still get the IP address range used by Amazon API Gateway, by downloading this JSON file. It is possible to subscribe and receive a notification for the IP address range change. But if the client doesn’t have a smart procedure to update its own permission list, this isn’t a viable solution.

As you can see, there was a missing mechanism to call a Lambda function using a specific IP address range.

Solution

To provide the same fixed IPs to clients while using a serverless backend, the solution is to use a combination of AWS Global Accelerator, Application Load Balancer, and Lambda functions. AWS Global Accelerator is a networking service that sends your clients’ traffic through the global network infrastructure of Amazon Web Services (AWS). It provides two global static customer-facing IPs to simplify traffic management. With AWS Global Accelerator, you can take advantage of the AWS global network to direct end client traffic to a healthy application endpoint. As well, this endpoint can be in the closest AWS Region to the client. This improves latency and throughput of your application traffic.

Lambda behind static IP diagram

The Lambda function in Figure 1 isn’t a target of the AWS Global Accelerator, so an extra hop is necessary to archive the communication. However, Application Load Balancer can be used as a target of AWS Global Accelerator, shown in this blog on one-click integration. In this blog, Application Load Balancer can act as a proxy for Lambda functions.

Conclusion

Before AWS Global Accelerator was launched, exposing Lambda functions though Amazon API Gateway would be the most common way to manage the change of IP address ranges. Now it is possible to manage this same scenario, using static IPs with no change requirement.

In this blog, Amazon API Gateway was used as a simple pass-through. But API Gateway has more functionalities like AuthN/Z, request validation, rate limiting, direct AWS service integration, and more. These functionalities are not part of Application Load Balancer, and should be implemented using other services or customization. So, keep in mind this when you evaluate your use case.

When static IPs are not required from clients, and you need API Gateways other features, it is still recommended to continue to use Amazon API Gateway. But in the use case outlined in this blog, AWS Global Accelerator makes a great architectural alternative.