Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how to capture the true client IP address when traffic is routed through an ALB. In production, this is about knowing exactly how the X-Forwarded-For header works, and ensuring your app correctly parses it to retain accurate client IPs while maintaining scalability and cost control. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
BlueOcean Analytics, a SaaS startup, has migrated their web application to AWS to leverage scalability and reliability. Their app runs behind an Application Load Balancer (ALB) to efficiently distribute incoming HTTP requests across multiple targets. The application needs to process users’ original IP addresses for analytics and fraud detection purposes. However, since the app is behind the ALB, all client IP addresses appear to be the same — the ALB’s IP. The development team wants a solution that preserves client IP address visibility in a way that allows the app to continue scaling horizontally without introducing significant cost increases or architectural complexity.
The Requirement: #
What is the MOST cost-effective and scalable way for BlueOcean Analytics to correctly obtain client IP addresses in this ALB-backed architecture?
The Options #
- A) Remove the application from behind the ALB. Delete the ALB. Use Route 53 to direct all traffic directly to the application instances.
- B) Replace the ALB with a Classic Load Balancer. Configure the Classic Load Balancer to use the HTTP protocol and forward client IPs directly.
- C) Modify the application code to inspect the X-Forwarded-For HTTP header added by the ALB. Ensure the code correctly handles multiple IP addresses in the header.
- D) Modify the application code to inspect a custom HTTP header. Change client-side code to send the client IP in this custom header.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Developer Imperative #
The ALB injects client IPs in the X-Forwarded-For header. Reading this header correctly from the application code is the industry standard solution. This approach maintains horizontal scalability, does not require client changes, and avoids costly architecture rewrites.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option C
The Winning Logic #
AWS Application Load Balancers add the originating client IP address in the X-Forwarded-For HTTP header for every request they proxy. The header contains a comma-separated list of IPs; the first IP is usually the client’s real IP, followed by chain of proxies/load balancers. Modifying application code to parse this header is the recommended method for preserving client IP data behind an ALB.
- This approach requires no architectural changes or additional AWS resources.
- It allows horizontal scaling behind the ALB without loss of client IP fidelity.
- It is cost-effective—no need for Classic Load Balancers (which would add operational complexity and possibly cost) or custom client modifications.
- It leverages the standard industry pattern for proxy/load balancer environments.
The Trap (Distractor Analysis) #
-
Why not A?
Removing the ALB eliminates key benefits: no centralized routing, no built-in health checks, and no elastic scalability. Directing traffic via Route 53 to EC2 instances is brittle, less scalable, and usually more expensive in maintenance overhead. -
Why not B?
Classic Load Balancer (CLB) is older generation, lacks many ALB features, and is being phased out for most use cases. While CLB can preserve IPs differently, replacing ALB with CLB sacrifices modern features and often leads to higher complexity and cost. -
Why not D?
Requiring clients to inject a custom header with their IP address breaks standardization, exposes potential security risks (clients can spoof IPs), complicates client deployment, and is impractical at scale.
The Technical Blueprint #
# Example snippet to extract client IP from X-Forwarded-For in a Node.js Express app:
app.use((req, res, next) => {
const xForwardedFor = req.header('X-Forwarded-For');
const clientIp = xForwardedFor ? xForwardedFor.split(',')[0].trim() : req.connection.remoteAddress;
req.clientIp = clientIp;
next();
});
The Comparative Analysis #
| Option | API/Code Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low | Poor | Bypasses ALB, reduces scalability |
| B | Moderate | Moderate | Legacy solution, less feature-rich than ALB |
| C | Low | High | Standard method, scales, cost-effective |
| D | High | Poor | Requires client changes, security risks |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick modifying the app to read X-Forwarded-For when you see ALB + client IP.
Real World #
In reality, some advanced architectures augment this with AWS WAF or CloudFront for additional IP security or geolocation filtering, but reading X-Forwarded-For remains the core pattern.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.