AWS ALB Attributes: Because Defaults Are for the Weak

AWS Application Load Balancer (ALB) settings—because life wasn't complicated enough. If you've ever got lost and accidentally clicked on "Edit attributes" in your ALB and been greeted with a list of toggles, congratulations, you're about to enter a world where defaults are fine—until they're not.

So yeah, let’s break this down in a way that actually makes sense.

---

1. Preserve Host Header: AWS’s Favorite Gaslighting Tool

This little gem controls whether ALB forwards the original Host header from the client to your backend. Sounds harmless, right? Let’s see what happens when you play with it:

• Enabled: The backend sees the exact domain that the client requested. Great for multi-tenant apps and services that rely on domain-based logic.

• Disabled (Default, Because Chaos Reigns): ALB replaces it with the backend target’s hostname/IP. If your app depends on the original domain, well, tough luck.

Example of AWS-Induced Headaches

Let’s say you run example-store.com, where users get custom subdomains like shop1.example-store.com and shop2.example-store.com.

• With Preserve Host Header enabled: The backend gets the actual domain (shop1.example-store.com), so everything works.

• Disabled (aka "Default for No Good Reason"): Your backend gets a generic hostname, breaking subdomain-based routing. Users are now screaming.

When should you enable this?

• Multi-Tenant Apps (Shopify-style platforms, SaaS products, or anything that needs per-user domains).

• API Gateways that route requests based on domains.

• Backend SSL/TLS validation based on domain.

When is the default (disabled) actually useful?

• You run a single-domain app and don’t care.

• You enjoy watching your app fail in mysterious ways.

• You work for AWS support and want job security.

---

2. TLS Cipher Headers: Cuz Security Is Optional (Kidding, It’s Not)

By default, AWS adds two headers to every request sent to your backend:

• x-amzn-tls-version: The TLS version negotiated with the client.

• x-amzn-tls-cipher-suite: The cipher suite used.

Why Should You Care?

Picture this: You’re running an ultra-secure banking app, and some dinosaur of a client is trying to connect with TLS 1.0. (Why? Because corporate IT never updates anything.) With these headers, your backend can detect weak security and take action—like blocking outdated clients or sending them a very condescending error message.

When should you use it?

• If you have security policies that enforce strong encryption.

• If you need to audit which TLS versions are in use.

When can you ignore it?

• If you don’t care about security (enjoy your data breaches!).

• If your backend isn’t even looking at these headers.

---

3. Connection Draining: The Difference Between a Smooth Transition and a Dumpster Fire

Imagine you’re removing an instance from your load balancer. What should happen?

• Enabled (Smart People Mode): The instance is given time to finish handling requests before being taken out of service.

• Disabled (Chaos Mode): AWS yeets the instance out of rotation immediately, killing any in-progress requests.

Example: A Tale of Two Developers

Dev A: Uses connection draining, so users never experience dropped connections. Smooth sailing.

Dev B: Disables connection draining because “it’s fine.” Users start getting random errors mid-request. The support team quits. The site is on fire. Dev B is now Dev Unemployed.

Best practice?

• Always enable it unless you love angry customers.

---

4. Idle Timeout: The Silent Killer of Persistent Connections

Your ALB is impatient. If a connection sits idle for too long, it’s gone. The default timeout? 60 seconds.

• You can extend it up to 4000 seconds (because why not?).

Example: Why This Matters

Your fancy real-time dashboard fetches data every two minutes. If the idle timeout is 60 seconds, AWS will gleefully drop connections before the next request, forcing a reconnect each time. Increasing the timeout solves this.

When to increase it?

• Long-lived API calls (e.g., large database queries).

• WebSockets or real-time connections.

When to keep it low?

• If your app serves quick requests and you don’t want idle connections clogging up resources.

---

5. HTTP Desync Mitigation Mode: Because Not All Clients Are Well-Behaved

AWS gives you three ways to handle malformed or desynchronized HTTP requests:

• Defensive (Default, AWS’s Version of "Let’s Not Get Sued"): Blocks dangerous requests, allows safe ones.

• Strictest (For the Ultra-Paranoid): Blocks anything remotely suspicious.

• Off (For When You Want To Be In a Cybersecurity Breach Report): Accepts all requests, even the sketchy ones.

Example: An Attacker Walks Into a Load Balancer...

A hacker sends a malformed HTTP request designed to confuse your backend. If Defensive mode is on, AWS blocks it. If it’s off, congratulations! You’ve just introduced a security vulnerability.

Best practice?

• Leave it on Defensive. If you turn it off, may the AWS gods have mercy on your soul.

---

6. Access Logs: Do You Even Debug, Bro?

By default, AWS doesn’t log anything for you. Because why would they? If you want to troubleshoot issues, enable ALB Access Logs.

• Enabled: Logs every request, stored in S3.

• Disabled (Default, Because Storage Costs Money): No logs. Debugging is now a guessing game.

Example: A Client Complains, And You Have No Idea Why

User: "Your site is broken!"

You: "What’s the error?"

User: "I dunno, just fix it."

If you enabled logging, you’d have a trail of requests to investigate. If not, good luck explaining to your boss why you have no clue what’s happening.

When to enable it?

• When you need to monitor security or troubleshoot requests.

• When you don’t like blind troubleshooting.

Downside?

• Costs money, so set up lifecycle policies to delete old logs.

---