Question

How ALB Preserves Host Header for Accurate Routing

Posted on by William Zheng

Ever found yourself wondering how your website traffic keeps landing on the right domain, even behind an Application Load Balancer (ALB)? Understanding how ALB preserves the Host header is crucial for seamless routing, SSL security, and multi-site management.

This article unpacks how ALB handles the Host header, why it matters for your applications, and what you should do to ensure it works smoothly. We’ll walk you through the essentials, helpful tips, and practical steps to maintain reliable, predictable user experiences.

Related Video

How Does an Application Load Balancer (ALB) Preserve the Host Header?

When working with AWS Application Load Balancers (ALB), one of the most common concerns is how the ALB handles and preserves the HTTP Host header as requests pass through. This is especially important if your application relies on the host information for routing, security, or operational purposes.

In this article, you’ll discover exactly how the ALB manages the Host header, along with strategies, best practices, and common pitfalls associated with this crucial piece of data.

Understanding the Host Header

Every HTTP request includes a Host header, which specifies the domain name (such as www.example.com) of the server being requested. This header is essential for:


Aws - ALB Attribute - Learning-Ocean - alb preserve host header

  • Routing requests to the correct virtual host or service
  • Handling host-based routing rules at the load balancer or backend application
  • Implementing security defenses (like preventing Host header attacks)

Maintaining the integrity of this header is important for the functionality and security of modern web applications.

Does the ALB Preserve the Host Header?

The Short Answer

Yes – AWS Application Load Balancer (ALB) by default preserves the Host header from client requests and forwards it to your target groups (such as Amazon EC2 instances or containers) without modification.

This means:

  • If a client accesses your site using https://mydomain.com, the Host header seen by your back-end server will still be mydomain.com.
  • Custom or non-standard Host headers sent by the client are not rewritten by the ALB.

Key Behaviors:

  • The ALB is protocol-aware (works at HTTP/HTTPS level).
  • It uses the Host header itself for host-based routing but passes it through unchanged.
  • Backend servers see the same Host header the client sent.

How Host Headers Work with ALB in Practice

Let’s break down how the Host header is managed at each stage of the request:

  1. Client Sends Request:
    A user’s browser or an API client sends an HTTP/S request (e.g., to https://myapp.example.com). The HTTP header includes:
    Host: myapp.example.com

  2. ALB Receives the Request:
    The ALB inspects the Host header for routing decisions (if you’ve set up host-based listener rules), then passes the request on to the appropriate target group.

  3. Request Forwarded to Backend:
    The original Host header value (myapp.example.com) is sent along with the rest of the headers to your backend server—unless you’ve specifically configured header rewrites, which are available only in ALB advanced rules.

  4. Backend Receives Host Header:
    Your application can access the Host header and use it for its own routing, domain validation, logging, or security checks.

Bottom line: The default behavior of ALB is to transparently forward the Host header.

Detailed Points to Consider

1. Host-Based Routing

The ALB uses the Host header to implement host-based routing. For example, you can configure the ALB to send traffic for:

  • api.example.com to a different target group than
  • www.example.com

This is done by creating listener rules that watch for specific Host header values.

2. Supporting Multiple Domains or Subdomains

ALBs make it simple to host multiple websites or services behind the same endpoint, using host-based routing. Since the Host header is used both for routing at the ALB and by your backend, this approach keeps configuration simple and robust.

3. Use of X-Forwarded-Host and X-Forwarded-For

ALB adds certain headers such as:

  • X-Forwarded-For: Shows the originating IP address of the client.
  • X-Forwarded-Host: Only added if you configure custom rules for header insertion. By default, the original Host header is used, so checking for this header may not be necessary unless you have specific routing requirements.

4. HTTPS and Host Headers

When using HTTPS/TLS, the SNI (Server Name Indication) from the SSL handshake is matched with the Host header. However, the Host header inside the HTTP request is what is actually used for routing at the ALB and by your back-end. The ALB preserves it even when decrypting and re-encrypting traffic.

Benefits of ALB Host Header Preservation

  • Consistency: Backends get the original domain that clients requested.
  • Flexibility: Enables host-based routing and multi-tenant architectures.
  • Security: Your application can validate the Host header, mitigating certain attack classes.
  • Transparency: No surprises—your backend always knows which host or domain the client intended.

Common Challenges and Issues

Despite the ALB’s transparent approach, there are scenarios where Host header handling becomes challenging:

1. Requests with IP Address Instead of Domain

Sometimes, your backend may see the Host header as the public IP address of the ALB rather than the expected domain. This happens if:

  • The client requested the ALB endpoint with the IP address (not the domain name).
  • The ALB simply passes through whatever Host header the client sent.

Solution: Encourage clients to use the correct domain name rather than the ALB’s IP.

2. Custom Host Headers or Manipulated Headers

If a client deliberately sends a fake or unexpected Host header, the ALB does not automatically overwrite or sanitize it before sending it to the backend.

Solution: Implement validation logic on your backend to check that the Host header matches expected values.

3. Backends Listening on Specific Host Values

If your backend only responds to requests with a specific Host header, any incorrect or missing Host headers from the client will result in failures—since ALB won’t rewrite it for you.

Solution: Either configure your backend to handle multiple Host values or ensure your clients use the proper domain.

4. Internal vs. External ALB

  • Internal ALB: Host header preservation works the same, but ensure your internal clients use DNS names and not IPs.
  • External ALB: The Host header seen by your backend is exactly as provided by public clients.

Practical Tips and Best Practices

Here are some recommendations to ensure smooth operation when working with ALB Host header preservation:

1. Enforce Use of Domains

  • Configure DNS and share domain names, not IPs, with clients.
  • Reject requests with Host headers that are IP addresses at the backend.

2. Implement Host Header Validation

Validate the Host header in your backend code. For example:

  • Only process requests with trusted domains (e.g., example.com, api.example.com).
  • Return HTTP 400 Bad Request for unknown or malicious Host headers.

3. Utilize ALB Listener Rules

Leverage host-based and path-based routing in your listener rules to offload logic from your backend and route traffic efficiently.

4. Monitor and Log Host Headers

Keep logs of incoming Host headers at both the ALB and application level. This can:

  • Help diagnose misconfigured clients
  • Detect attacks or unusual patterns

5. Tighten Security Posture

  • Consider using Web Application Firewalls (WAF) in front of your ALB to block common Host header attacks.
  • Use HTTPS and enforce SNI in combination with correct Host headers for added assurance.

6. Know When to Use Advanced ALB Features

If you need to add, remove, or overwrite headers (including Host) as traffic passes through ALB, look into advanced listener rule actions. However, most typical architectures do not require custom Host header rewrites.

Cost Considerations

While Host header preservation itself doesn’t incur specific costs, hosting your application behind an ALB does come with standard ALB pricing, which includes:

  • Per hour or per provisioned ALB
  • Per processed request (LCU pricing)

There is no additional fee for host-based routing or forwarding Host headers. To optimize costs:

  • Route only necessary traffic through the ALB
  • Use a single ALB with host-based rules instead of multiple load balancers, where possible

Conclusion

To sum up, AWS Application Load Balancers are designed to forward the HTTP Host header from the client to your target groups without modification. This default behavior allows you to build flexible, multi-domain, and secure web architectures. Understanding and leveraging the Host header gives you fine-grained control over routing, security, and user experience.

If your application relies heavily on host information, always validate the header and encourage proper client usage to avoid potential security issues or configuration headaches.

Frequently Asked Questions (FAQs)

Does the AWS Application Load Balancer (ALB) change the Host header of client requests?

No, by default the ALB forwards the exact Host header sent by the client to your backend servers without modification.

How can I use host-based routing with ALB?

You can configure listener rules in your ALB to route traffic based on the Host header value. For example, you might send traffic for api.yourdomain.com to one service and www.yourdomain.com to another.

Why does my backend see the Host header as an IP address?

If your backend is seeing the Host header as an IP address, it’s likely because the client made a request to the ALB using its IP address instead of the domain name. The ALB passes this header as-is to your backend.

Can I rewrite or override the Host header in ALB?

As of now, ALB does not natively support rewriting the Host header via basic configuration. Advanced header manipulation may be possible using ALB listener rule actions, but the default and recommended behavior is to forward the Host header unchanged.

Are there any security concerns with Host headers at ALB?

Yes. Because the ALB forwards the Host header as sent by the client, malicious users could try sending unexpected or fake headers to exploit your backend application. Always validate the Host header in your application and consider using additional protections like AWS WAF.

By understanding how AWS ALB preserves and handles the Host header, you can build web services that are robust, scalable, and secure, with full control over how client requests are handled end to end.

Post Views: 4