Use static ips for AWS Application Load Balancers

Question

Our requirement is to

1. Assign static IPs to an ALB, because many of our customers have whitelisted it in their firewalls.
2. The X-Forwarded-For HTTP header should contain the clients IP address, because we have a https://www.whatismyip.com/ like service running which thousands of our IOT devices already use.

Tried following solution but it does not do #2, we see the internal NLB ip instead of the client IP in the X-FF https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/

Is there any load balancer out there that can do #1 and #2 or can AWS make this happen on request? Any help/pointers appreciated, thanks!

Answer 1

AWS Global Accelerator lets you associate regional resources, such as load balancers and EC2 instances, to two static IP addresses.

https://aws.amazon.com/global-accelerator/

Originally, Global Accelerator did not preserve the IP address of the client, but a subsequent enhancement made that possible.

Client IP Address Preservation

Today we are announcing an important new feature for AWS Global Accelerator. If you are routing traffic to an Application Load Balancer, the IP address of the user's client is now available to code running on the endpoint.

https://aws.amazon.com/blogs/aws/new-client-ip-address-preservation-for-aws-global-accelerator/

With this feature, the behavior of X-Forwarded-For is correct because the ALB sees the client IP.

This also has the potential to improve end-to-end performance, because the static addresses assigned to you from Global Accelerator are anycast routed from the Internet to a number of edge locations on the AWS Edge Network (where global services CloudFront and Route 53 live, though Global Accelerator does not directly use either of those services; by contrast, some other edge services like S3 Transfer Acceleration and "Edge Optimized" API Gateway actually use CloudFront under the hood). From ingress at the edge, the traffic rides AWS fiber to the region of your ALB, and responses ride back to the edge and out to the viewer, eliminating some of the variability and vagaries of the public Internet.

This description seems like an impossibility and/or magic to those familiar with how networking and NAT typically work (and are constrained) but the secret sauce is an interconnection with the VPC network through an internal AWS service called Hyperplane, which also allows Network Load Balancers and NAT Gateways to work their magic with address translation and stateful flows.

This is the only official way to have static IPv4 addresses on the outside of an ALB with correct X-Forwarded-For handling and is well-suited to environments where there is an inflexible requirement for static addresses, due to factors outside your control.

The "two" static addresses mentioned above are for redundancy. Two will be assigned. You don't strictly need to use both of them, but it's best if you do.