Maintaining Client IP Addresses Using AWS Load Balancers: A Practical Guide

Being aware of the client’s actual IP address is important in cloud-native architectures today—logging, geolocation, security, personalization, compliance, and rate limiting. Yet,  when you add AWS load balancers to the equation, proxying can hide the original client IP. But don’t worry: AWS provides solid mechanisms throughout its Load Balancer services to allow you to maintain or capture client IP information efficiently. 

1. Application Load Balancer (ALB) & X-Forwarded Headers 

• How it works 
  ALBs run at Layer 7 (HTTP/HTTPS). They transparently maintain client IP addresses by injecting regular HTTP headers—primarily the X-Forwarded-For header—so your backend can easily get the real IP of the client. 
• Header modes 
  ALBs have three modes: 
  a) append (default): Appends the client IP to the X-Forwarded-For header—maintaining existing values. 
  b) preserve: Does not modify the header. 
  c) remove: Removes the header. You can set this field through the AWS Console or CLI. 
  
• Usage tips 
  Be careful with X-Forwarded-For—only trust values added within your secure AWS  environment. Don’t use or expose this header to untrusted clients. 

2. ALB + AWS Lambda: Capturing Client IP in Functions 

If your ALB forwards to AWS Lambda functions, the header still works. A typical Python excerpt:

This pulls out the client’s original IP (the first one in the list) and nicely falls through to the AWS Lambda’s own sourceIp if the header is not present. 

3. Classic AWS Load Balancer (CLB) & Instance-Level Choices 

CLBs (Layer 4/7 hybrid) can support Proxy Protocol as an option: 

• CLBs forward traffic normally without the proxy protocol—logging will show the AWS load balancer’s IP address. 
• When Proxy Protocol is enabled, the connection context (such as source IP and port) is appended in front of every request. Your backend has to parse that header accordingly. 

4. Network Load Balancer (NLB): Layer 4 and Raw Client IP 

• Default behavior 
  NLBs (Layer 4) maintain the source IP by default—backend instances receive the client’s IP as the connection origin. 
• When Proxy Protocol Is Needed 
  Scenarios such as remote, cross-VPC targets, PrivateLink, or hairpinning may obscure the source IPs. Proxy Protocol v2 can be enabled on NLBs to explicitly pass client data (including IP, port, protocol, checksum, and more) in the TCP  header.

• Important: Your backend must support parsing Proxy Protocol v2—or it will break connections. 

5. NLB Behind AWS Global Accelerator: Preserving IP Across the Edge

AWS Global Accelerator in front of an NLB makes client IP retention even more critical: 

• Feature:  
  Global Accelerator can now retain the original client IP via NLB endpoints,  enabling backend destinations to receive the actual source IP—even through anycast edge routing. 
• Why it matters:  
  Supports geo-based routing logic, IP-based auditing, compliance checks, and user-specific personalization. 
• Requirements: 
  The NLB should be in a VPC with a security group that permits client IP addresses and health checks. ◦ If the NLB is internal, the VPC should have an Internet Gateway. 

Both Accelerator and NLB should be set to keep the client IP.

Quick Comparison: Which Tool for Which Use Case? 

Considerations 

1. Security First 
   Never trust client-supplied headers unless they are from secured AWS load balancers in your own VPC. 
2. Ensure Backend Compatibility 
   If proxy protocol is being used, ensure that your backend application supports and anticipates it (e.g., NGINX, HAProxy, Envoy). 
3. CloudFormation Automates Setup 
   For instance, AWS offers templates for Proxy Protocol configurations with NLB +  NGINX or HAProxy—for testing by hand. 
4. IP + Port Preservation 
   ALB can also retain the client port if it is set right through the xff_client_port  configurations. 
5. Global Accelerator Use Cases 
   Maintaining IP with Global Accelerator is best suited for geo-targeted functionality, data residency compliance, and analytics.

Summary 

Capturing an actual client IP in AWS is load-balancer and architecture dependent: 

• ALB—use X-Forwarded-For 
• Lambda behind ALB—parse header in code 
• CLB—use Proxy Protocol if necessary 
• NLB—native IP or Proxy Protocol for edge or cross-network 
• Global Accelerator—allow IP preservation on the accelerator and NLB 

Selecting the proper method provides greater logging, enhanced personalization, greater security, and regulatory compliance—all part of cloud computing applications today.