How to use Elastic Beanstalk with an IP Whitelisted API

I’ve been developing a number of scalable Moodle websites using Amazon Web Services’ Elastic Beanstalk. It’s flexible and allows me to create highly available and scalable Moodle deployments.

One of the challenges I’ve found while implementing cloud based solutions with our enterprise clients has been providing a static IP address which the system uses to contact their internal API servers.

By default, EC2 allocates a dynamic IP to servers which can change during auto-scaling events. Many IT Managers are unwilling to open their servers to the public internet and require all internet based connections be whitelisted in their corporate firewall.

This introduces a need for a consistent static IP address, which conflicts with the dynamic nature of auto-scaling servers.

Amazon already provides very detailed guides for solving this problem with private/public subnets, multiple NAT Gateways and Bastion Hosts to achieve a static IP.

This requires a lot of overhead and configuration to use a static IP address for the single server that needed it.

I needed a solution which I could drop in with minimal change.

The solution is to create a NAT Gateway subnet and configure the Main Route Table to send traffic to the API server through the NAT Gateway, leaving other traffic unaffected.

What it looks like:

How to do it:

• Step 1: Create a new subnet and give it a suitable CIDR block. I used 172.31.128.0/20.

• Step 2: Create a new NAT Gateway in the new subnet. Amazon will create an Elastic IP such as 13.54.86.XX

• Step 3: Create a Route Table for the new NAT Gateway. This should be configured to send internet traffic out via the Internet Gateway.

Note: Your VPC local route may be different from 172.31.0.0/16 depending on your VPC configuration.

• Step 4: Modify the NAT subnet to use your new route table.

• Step 5: Modify the Main Route Table to direct traffic to your target server via the NAT Gateway and direct other internet traffic via the Internet Gateway.

You can add route multiple IP addresses and ranges to the NAT Gateway

This action modifies the Main Route Table for the VPC. All EC2 instances which exist inside this network will now have traffic to the target IP address routed via the NAT Gateway.

Keep in mind a NAT Gateway is created in a single Availability Zone and a failure of an AZ can cause traffic to not reach the target server. While my use case did not require such high levels of availability to the API server it is possible to extend this model to support per-AZ NAT Gateways.

The solution allows any EC2 instances in the VPC to use a static IP Address when contacting specific servers, without losing the benefits of sitting in a public subnet.