I'm overseeing an integration for a customer and their vendor needs a number of IP Addresses to whitelist. The originating server(s) is an Elastic Beanstalk Instance fronted by an Application Load Balancer with all the trimmings via Route53.

That's not going to work, since you can't assign a static IP to Application Load Balancers by definition (and I do need the Layer 7 features).

I can't just proxy the specific requests to the vendor via code and an additional EC2 instance because it's a two-way integration.

I've read through this article, but that frankly seems like a hack and not something I'd do in a production environment.

It certainly seems like I need some combination of an NLB with an ALB, but again, the references article introduces a ton of moving parts.


  • I am using a VPC
  • The instance itself lives in a private subnet
  • The ALB lives in a public subnet and both have the necessary routing to communicate
  • I'm almost certain I'm talking in circles trying to convince myself Static IP !== Single Point of Failure
  • Or try and convince them IP Whitelist != Security. Propose a VPN instead. – Jacob Evans Jan 4 at 18:13
  • @JacobEvans Yes, it would be nice if I didn't have to solve this problem. Unfortunately, it doesn't always work out that way. – sean Jan 4 at 18:37

There is currently only one way to associate static IP addresses with Application Load Balancer (ALB) -- AWS Global Accelerator.

Static Anycast IPs – Global Accelerator uses Static IP addresses that serve as a fixed entry point to your applications hosted in any number of AWS Regions. These IP addresses are Anycast from AWS edge locations, meaning that these IP addresses are announced from multiple AWS edge locations, enabling traffic to ingress onto the AWS global network as close to your users as possible. You can associate these addresses to regional AWS resources or endpoints, such as Network Load Balancers, Application Load Balancers, and Elastic IP addresses. You don’t need to make any client-facing changes or update DNS records as you modify or replace endpoints.


Global Accelerator allocates two static IPs from two redundant internal AWS systems, and these are unique to your deployment -- not shared. These are advertised out to the Internet via peering connections at multiple locations on the AWS Edge Network (the same network where CloudFront, Route 53, and S3 Transfer Acceleration all operate -- it has more points of presence than just the AWS regions, and AWS-managed fiber connections to the regions). Then you associate the endpoints (ALB, NLB, and/or EIP) with the Global Accelerator instance, and traffic from the edge location where the requests arrive is NAT-ed to your balancer.

Because the arrangement uses source NAT, you aren't able to use things like the client source IP or X-Forwarded-For to determine the client IP address in real-time, but you can cross-correlate them later using flow logs, which capture source/destination tuples as well as the intermediate NAT address that your application will see. That's a notable limitation, but may be worthwhile if you really, really need static IP addresses for your endpoint -- as indeed, is inevitable in some corporate environments.

Importantly, ALB is inbound only (connections are only ever established from outside to inside, regardless of the ultimate direction of data transfer), so if your servers are also initiating connections, you need a separate solution for a static source address -- a NAT Gateway.

One NAT Gateway per availability zone, placed on a public subnet, can serve as the default gateway for one or more private subnets within the availability zone, so that all instances on those subnets use the same source IP when contacting the Internet. NAT Gateway is not a black box in a physical place -- it's a feature of the network infrastructure, so it's intrinsically fail-safe and not considered a single point of failure within a single AZ. You can share a single NAT Gateway across availability zones, but then you do have a single point of failure if something catastrophic occurs in that one availability zone (and you'll pay slightly more to transport Internet traffic across AZ boundaries, compared to placing one NAT Gateway in each AZ). The NAT Gateway requires no application changes, because it isn't a proxy -- it's a network address translator that's transparent to the instances that are located on the subnets that are configured to use it. Each NAT Gateway has a static EIP.


This is frustrating because there is no good way to do this especially if you are serving a website and want to know who is coming to your site,

Option 1: AWS Global Accelerator - which works but strips the client IP so you have no accounting of where people are coming from.

Option 2: This really obscure method : https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/ which in short requires an ELB and an ALB and so forth which breaks some functionality in the process and requires a heavy handed approach.

As of 5/2019 these are the main ways to do it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.