Title: How to Configure a Static IP For Your Serverless App
Publication: Ready, Set, Cloud!
Author: Allen Helton
Published: March 02, 2021
URL: https://www.readysetcloud.io/blog/allen.helton/how-to-configure-a-static-ip-for-your-serverless-app/

It might sound like a difficult task to send your outbound Lambda traffic through a static IP address. But don't worry, it's easier than you think.


Serverless is great. There, I said it.

At this point I'm not sure many people would argue with me on that, but to each their own.

Serverless provides us with the luxury of fast compute in the cloud without having to worry about machines or state. Pretty awesome.

But since we don't have to worry about machines or state, a handful of problems present themselves that we didn't have before.

Things like [monitoring your app](/blog/allen.helton/how-to-monitor-your-serverless-application) become more difficult. You also have all the difficulties of distributed computing thrown into the mix.



But what about a static IP? There are a multitude of reasons you would need a static IP address, like integrating with a 3rd party or connecting to an internal network. These tasks typically need to whitelist IP address for security measures.

It's hard to argue against security, so we must come up with a way to get Lambda functions to send external traffic from a known IP address.

## Setup
Full disclosure - this has been a solved problem for a while. When I was doing my initial research on how to get Lambda to use a static IP, I used [this tutorial](https://medium.com/cloud-prodigy/aws-lambda-with-static-ip-address-c82e3043c2ed) and [this one](https://matthewleak.medium.com/aws-lambda-functions-with-a-static-ip-89a3ada0b471) to work my way through the console and set it up.

But I am a boy scout. I like to leave things better than how I found them.

I've taken the tutorials, comments, and trial and error, and [created a SAM template](https://github.com/allenheltondev/aws-lambda-static-ip) that will automatically deploy everything you need into the cloud with minimal setup.

All you need are:
* [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html) configured on your machine
* [SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)
* An [S3 Bucket](https://s3.console.aws.amazon.com/s3/home) in your account to deploy resources into
* A [CIDR block](https://www.digitalocean.com/community/tutorials/understanding-ip-addresses-subnets-and-cidr-notation-for-networking) for the network you're about to create

If you're unfamiliar with CIDR, networking, subnets, and IP configuration like I am, don't worry. These are the values I used in test.

```
Parameters:
  VpcCidrBlock:
    Type: String
    Default: "12.0.0.0/16"
  PublicSubnetCidrBlock:
    Type: String
    Default: "12.0.0.0/24"
  PrivateSubnetCidrBlock:
    Type: String
    Default: "12.0.1.0/24"
```

You will probably want to change these for production usage, but these values should get you by for a POC.

## Architecture
Networking is hard. I often say *don't confuse complexity with unfamiliarity*. But my college degree is "Bachelor of Science in Software Engineering with Focus in Networking" and I still think it's hard. I'm familiar with it, yet it remains complex.

That's why we chose serverless, right? Because we want to focus on solving business problems instead of dealing with networking.



For those curious (which I expect everyone reading this is, that's just the nature of engineers), here is the architecture we're setting up with this SAM template.

![Architecture diagram of the AWS setup in the SAM Template](https://readysetcloud.s3.amazonaws.com/Static+IP.png)

At a high level, we've configured a few moving parts that communicate with each other to route traffic through a static IP:
* API Gateway to accept incoming requests
* VPC containing a private subnet and a public subnet
* Lambda function in the **private subnet**
* Internet gateway giving internet access to the **public subnet**
* NAT Gateway with a configured static IP to route external traffic
* Route tables to send traffic through the gateways

## Outputs
When you deploy the stack in your AWS account, CloudFormation will provide you with two outputs: an **IP address** and a **url**.

The **IP address** is your assigned elastic IP. This is the address you can give to your integrators to whitelist. It is not going to change. All outbound web traffic from your lambda functions in the private subnet will be coming from that IP.

The **url** is a test endpoint. It is an API that hits [ipify](https://www.ipify.org/) to get the IP address of the Lambda and compares that address to your static IP. The response will give you the expected IP, actual IP, and tell you if they match.

That's it! Configure a couple of minor parameters, deploy, and enjoy!

From here you can either modify the test endpoint or create a new one to satisfy your needs.

I hope this gets you past your problem as fast as possible and opens the door to solving business problems. Again, that's why we chose serverless: to spend as much time as we can on helping our customers, not configuring and maintaining infrastructure.

Cheers!