DevOps Engineer
Jatin is an AWS-certified SysOps Administrator Associate with extensive expertise in AWS cloud services and a broad spectrum of DevOps tools.
5
5Being 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?
| Service | Is Original Client IP Preserved? | How the Backend Gets the Client IP | Configuration | Key Considerations |
| Application Load Balancer (ALB) | Not as the backend connection's source IP | Through the X-Forwarded-For HTTP header | routing.http.xff_header_processing.mode controls whether ALB appends, preserves, or removes XFF | Layer 7 only. The backend TCP connection originates from the ALB, so applications must read XFF to identify the client |
| Network Load Balancer (NLB) | Yes, when client IP preservation is enabled or required by the protocol | Directly as the source IP in the IP packet | Controlled by the preserve_client_ip.enabled target group attribute for TCP/TLS | Behavior depends on target type and protocol. For some configurations, client IP preservation is enabled by default, while TCP/TLS IP target groups have it disabled by default |
| NLB with Proxy Protocol v2 | Client information is carried separately rather than relying only on the packet source IP | Through the Proxy Protocol v2 header | Enable proxy_protocol_v2.enabled on the target group | Useful when native source-IP preservation isn't available. The backend must understand Proxy Protocol v2 |
| AWS Global Accelerator + NLB | Yes, for supported NLB endpoints when client IP preservation is enabled | Original client IP reaches the NLB in the packet header and can continue to the backend | Enable client IP preservation on the supported Global Accelerator endpoint and configure the NLB appropriately | Requires an NLB with security groups. Client IP preservation isn't supported for NLB endpoints with TLS listeners |
AWS Global Accelerator + ALB
| Preserved to the ALB, then exposed to the backend through XFF | X-Forwarded-For at the application target | Global Accelerator client IP preservation plus ALB XFF processing | Global Accelerator can preserve the client source IP up to the ALB, but the ALB still terminates the connection and passes the IP to its targets through XFF |
The key difference is where the original client IP survives. With an NLB, supported configurations can preserve it at the network layer so the backend sees the client as the connection source. With an ALB, the backend sees a connection from the load balancer and retrieves the client's IP from X-Forwarded-For. Global Accelerator can preserve the original source IP as traffic enters AWS, but the endpoint behind it still determines the final behavior.
Considerations
- Security First
Never trust client-supplied headers unless they are from secured AWS load balancers in your own VPC. - Ensure Backend Compatibility
If proxy protocol is being used, ensure that your backend application supports and anticipates it (e.g., NGINX, HAProxy, Envoy). - CloudFormation Automates Setup
For instance, AWS offers templates for Proxy Protocol configurations with NLB + NGINX or HAProxy—for testing by hand. - IP + Port Preservation
ALB can also retain the client port if it is set right through the xff_client_port configurations. - 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.
