AWS ALB Attributes: The Land of "Why Is This Even a Setting?"

The Chaos That Is AWS ALB Settings (Decoded for Real People)

AWS ALB (Application Load Balancer) is that one friend who acts all helpful but secretly enjoys messing with you. Out of the box, it works—until it doesn’t. And when it doesn’t, you end up clicking through its settings like a lost tourist, wondering why half of these options exist.

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

---

1. Preserve Host Header: The Setting That Can Make or Break Your App

This decides whether ALB passes the original Host header from the client to your backend.

• Enabled: Your backend sees the exact domain the user requested.

• Disabled (Default, Because AWS Loves Surprises): ALB replaces it with the backend target’s hostname/IP.

Why Should You Care?

Imagine you run coolshop.com, where customers get their own subdomains like shop1.coolshop.com and shop2.coolshop.com.

• Enabled: Your backend knows which shop to serve.

• Disabled: Your backend sees some random ALB hostname and has zero clue which shop the user actually wanted. Enjoy the chaos!

Who Should Enable It?

• SaaS platforms using custom subdomains.

• Apps that route requests based on the domain.

• Anyone who doesn’t like broken apps.

When is AWS’s default actually useful?

• If your backend doesn’t care about the domain.

• If you enjoy debugging mysterious issues at 2 AM.

---

2. TLS Cipher Headers: Because Security Is a Thing

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

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

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

Why Bother?

Security. Some outdated client (probably running Windows XP) tries to connect using TLS 1.0—a security nightmare. These headers help you spot and block weak encryption before it ruins your day.

When should you care?

• If your security team likes to sleep at night.

• If you’re required to enforce strong encryption.

When can you ignore it?

• If you trust the internet (lol).

• If your backend doesn’t even look at these headers.

---

3. Connection Draining: Because Cutting Off Users Mid-Request Is Rude

When you remove an instance from the load balancer, what should happen?

• Enabled: The instance gets time to finish handling requests before being pulled out.

• Disabled (aka Instant Chaos Mode): AWS just yeets it out of rotation immediately, killing active requests.

Why This Matters

Imagine a user is halfway through checking out their shopping cart. Suddenly, AWS decides, "Nope!" and drops the instance handling their request. User is now sad. You lose money. Support tickets flood in.

Best practice?

• Enable it. Always. Unless you love angry customers.

---

4. Idle Timeout: The Silent Killer of Persistent Connections

ALB gets bored quickly. If a connection sits idle too long, it gets dropped. Default? 60 seconds. Max? 4000 seconds.

Why It Matters

You’ve got a fancy real-time dashboard that refreshes every 2 minutes. But ALB’s timeout is 60 seconds. So every time the dashboard tries to pull data, the connection has already been dropped, forcing a reconnect. Super inefficient.

When to increase it?

• If you have long-lived API calls or WebSockets.

• If you don’t want unnecessary reconnections.

When to keep it low?

• If your app serves quick, short-lived requests.

---

5. HTTP Desync Mitigation Mode: Because Some Clients Are Just... Weird

AWS gives you three ways to deal with malformed HTTP requests:

• Defensive (Default, AWS’s "Safe" Mode): Blocks suspicious requests, allows safe ones.

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

• Off (For When You Want Security Nightmares): Accepts all requests, even garbage ones.

Why This Matters

Some hacker (or just a badly coded app) sends a weird HTTP request designed to confuse your backend.

• Defensive mode? Blocks the bad request.

• Off? Congrats, you just let an attacker mess with your system.

Best practice?

• Leave it on Defensive. Unless you like getting hacked.

---

6. Access Logs: Debugging for Grown-Ups

By default, ALB doesn’t log requests. Because why would AWS give you something useful for free?

• Enabled: Every request gets logged in S3.

• Disabled (Default, Because AWS Loves Cost Savings): No logs. Good luck debugging.

Why It’s Useful

User: "Your site is broken!"

You: "What’s the error?"

User: "Idk, it just doesn’t work."

With logging, you can check what’s actually happening. Without it, you’re just guessing.

When to enable it?

• When you want actual visibility into your traffic.

• When debugging blind sounds like a bad idea.

Downside?

• It costs money, so set up a retention policy.

---

Final Words (Wait, We Don’t Do Final Words Here)

AWS ALB settings can be your best friend or your worst enemy. Defaults exist to make life easier—but only if you enjoy unexplained issues that turn into support nightmares.

Tweak wisely, stay paranoid, and may your load balancing actually, you know, balance.

Now go forth and configure like a pro—or at least, like someone who knows better than to trust AWS defaults.