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.
https://aws.amazon.com/blogs/aws/new-aws-global-accelerator-for-availability-and-performance/
Global Accelerator allocates two static IPs from two Network Zones¹, 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, EIP, or EC2 Instance (without EIP) -- with the Global Accelerator instance, and traffic from the edge location where the requests arrive is NAT-ed to your balancer.
When Global Accelerator was initially launched, it relied on Source NAT to tie the global addresses to the VPC devices, so you couldn't use the client source IP or the X-Forwarded-For header from the ALB to determine the client IP address in real-time; however, that has changed -- X-Forwarded-For now correctly identifies the client IP address when an ALB is used with Global Accelerator in most AWS regions.
Client IP address preservation only works when the endpoint is an ALB or an EC2 instance (without EIP). It doesn't work with EIP endpoints or Network Load Balancers; for those cases you can only cross-correlate them later using flow logs, which capture source/destination tuples as well as the intermediate NAT address that your application will see.
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.
¹ network zone is new AWS terminology, introduced with Global Accelerator. It describes the fact that the two IP addresses are, internally, handled by different infrastructure.
