Cheaply Whitelist Your AWS Server

Let’s say “Barney’s Book Price Lookup Tool”, a third party service, has asked you for your IP address so that they can whitelist you on their firewall.  They don’t care or even understand that your infrastructure is elastic or that your IP list can grow or shrink or change several times a day from a huge and unknown pool rationed by your cloud provider.  What’s a body to do? Route requests to the service through a NAT gateway!

To be clear, this guide treats the case where you want to make requests to another service from a static IP.  It does not cover the case of trying to set up a general static IP for inbound access to your servers.

Of course, setting up a special route to the SaaS service means that the service you’re connecting to will also need a predictable IP or range.  If they can’t show you theirs, ask them why they expect you to show yours. You might deduce their static IP with a DNS lookup of the service hostname; but asking the provider whether the IP is static is wise.  For example:


Assuming you have obtained a static IP or range for the service, you can use this guide to set up an AWS NAT gatewayNetwork address translation (NAT) and a static route will allow you to specify a special path for requests to the SaaS service.  Other requests will go out the normal, cheaper, non-deterministic set of IPs that you will have on your AWS Internet gateway. I prefer not to use the NAT gateway for all outbound traffic, mainly because there is an additional cost for data processed by the gateway ($0.045/GB at the time of this writing).  By the way, as of the time of this writing, just turning on at NAT Gateway will cost you about $32/mo ($0.045/hr) if no data is passed through it.

Now, if this sounds like it ‘s for you, let’s get to it.  The principles in this article apply to server networking in general.  But, I only cover an AWS implementation here. Note that you must be using a VPC, not classic AWS networking.  All of this AWS configuration can be done from the VPC section of the AWS console. I will refer to your servers that will be accessing the SaaS service as the clients.

1. Create a subnet for the NAT gateway in the region and VPC wherein your clients reside. The VPC and subnet can be found by looking a the details of one of your clients. Its route table can be determined by looking at the details of its subnet.

2. Create a route table.

3. In the new route table, add a route for all traffic ( to route to the internet gateway (igw-xxxxx).

4. In the new route table, associate the new subnet with this new route table.

5. Create a NAT gateway in this new subnet. Note the Elastic IP created for your gateway.

6. Modify the route table used by your clients to include a route to the SaaS provider IP/CIDR through the NAT gateway. Of course, the CIDR notation of a single IP is /32.

7. From one of your clients, test connectivity to the SaaS service hostname and port using traceroute/tracepath and look for the NAT gateway IP in the list of servers along the route. If you don’t see it; review all previous steps. For example:

traceroute -n 443
traceroute to (, 64 hops max, 443 byte packets
1 1.718 ms 1.813 ms 1.011 ms
2 5.711 ms 5.855 ms 6.570 ms
3 8.229 ms 6.647 ms 9.437 ms
4 5.981 ms 6.638 ms 6.727 ms
5 8.981 ms 8.885 ms 8.872 ms

Let’s say is my NAT gateway IP.

8. Give the IP of the NAT gateway to your SaaS Provider for whitelisting

In sum, a NAT gateway with a static route to a NAT gateway subnet should allow you to send certain traffic out from a static IP.  I’d argue that IP whitelisting is a tired and cumbersome approach to security. It seems like we should be moving towards trusting authenticated requests and WAFs.  I could be convinced that this arrangement or site-to-site VPNs would be more efficient for long-term service integrations. But, they seem a little too onerous and involves systems work, where an ideal solution would only require developer work on the client side.  Why can’t it be simple?