Harden load balancers (ALB/NLB/CLB)

Load balancers sit in front of every internet-facing application and decide how traffic is parsed, handed off and spread. Nearly every control in this group is a configuration change with no AWS spend: rejecting malformed headers, tightening the HTTP parsing mode, draining connections and acting on the load balancer's health signal are all zero-cost attribute flips. Two of them, cross-zone balancing (ELB.9) and ELB health checks on Auto Scaling groups (AutoScaling.1), actually point in the same direction as cost optimisation, because they stop teams over-provisioning to work around uneven or zombie capacity.

Frame each failing control by the downside it removes, not by its severity label. ELB.4 and ELB.12/ELB.14 close HTTP request smuggling, a breach-class attack with documented six-figure bounty payouts and real authentication-bypass incidents; ELB.7 stops routine deploys dropping live customer requests; ELB.9 and AutoScaling.1 are availability-and-waste items where the real exposure shows up during a traffic peak. Several map to PCI DSS and NIST controls, so an open finding is also an audit item.

Because the fixes are free, the metric that matters is how fast they close, not their dollar cost. A zero-cost, audit-mapped, breach-class fix aging in a backlog is a process signal: the same backlog discipline that lets a free fix linger is what lets the expensive risks linger. The finance role is to make sure these are closed promptly across the whole estate and prevented from recurring with an IaC default.

Priya is the finance partner reviewing the perimeter findings ahead of the SOC 2 renewal. Security Hub has flagged several ALBs and CLBs (ELB.4, ELB.12, ELB.7, ELB.9) plus an AutoScaling.1 finding. Her instinct is not to weigh these against budget, because nearly every one is a zero-cost attribute flip with no new resources and no usage charge. Her question is which of these removes a balance-sheet downside, and which two might actually reduce the bill.

She sorts the cohort by downside rather than by severity label. ELB.4 and ELB.12 close HTTP request smuggling, a breach-class attack with documented six-figure bounty payouts and real authentication-bypass incidents, so they go on the risk register at full weight even though one is labelled Medium. ELB.9 and AutoScaling.1 she tags as availability-and-waste items that point the same way as cost optimisation, because both stop teams over-provisioning to paper over uneven load or zombie instances. Her output is one line for the finance pack: the fixes are free, two of them save compute, and the only metric that matters is how fast a zero-cost breach-class fix closes, because a free fix aging in a backlog is a process signal.

The cost model here is unusually one-sided. Remediation is near-zero, no new AWS resources, no usage charge, no downtime, just a sliver of engineering time, and two of the controls (cross-zone balancing and ELB health checks) actually reduce compute spend by removing the reason teams over-provision. So this category rarely competes for budget; it competes only for attention.

The risk side is concrete. Request smuggling has been used to bypass authentication and hijack sessions at scale, with documented bounty payouts in the tens of thousands and real breaches behind them; for a payments or healthcare application that triggers regulatory notification, forensics and customer remediation costs orders of magnitude larger than the free fix. The reliability controls turn into incident cost during a traffic peak, when the gap between provisioned and serving capacity becomes customer-facing. The finance contribution is to ensure these appear on the risk register at the right size, so a free fix is not deprioritised just because it is labelled Medium or Low.

Because the fixes are free, the metric to watch is aging, not dollars. A zero-cost, audit-mapped fix sitting open for weeks is a process signal worth raising. Pair the cleanup with an IaC default and a Config rule so the finding never returns, which is cheaper than re-remediating it every audit cycle.

Every internet-facing application sits behind a load balancer that acts as the first filter for inbound traffic. Some of ours are configured permissively: forwarding malformed requests that enable a recognised attack class (request smuggling), cutting live customer connections during routine deploys, spreading load unevenly so we over-provision to compensate, or failing to replace servers that have actually broken. The report shows these as separate findings across our load balancers and the auto-scaling groups behind them.

Almost all of these are free configuration changes with no downtime. A few of them save money as a side effect by letting the same workload run on fewer instances. The reason they are worth leadership awareness is the asymmetry: a one-line change versus a breach, dropped revenue, or an availability incident at the worst moment.

The defensible end state is that every load balancer rejects ambiguous traffic, hands off and balances cleanly, and acts on real application health, with new ones born that way through our infrastructure templates. The leadership question is whether we have a process that closes free, important fixes promptly and prevents them from recurring.

After a vendor in the sector disclosed an authentication bypass traced to an HTTP request-smuggling chain, the CTO asked a blunt question: could a single malformed header get past our front door? The honest answer was maybe, because some public ALBs were still in monitor mode and forwarding invalid headers, configurations that predated AWS tightening the defaults and had never been revisited.

The leadership response was to treat the perimeter as a default rather than a per-load-balancer task. The HTTP-hardening attributes were flipped to defensive across the public, authenticated services first, the two changes with caveats (the desync mode and ELB health checks) were checked against access logs and probe health before being applied, and the safe values were baked into the Terraform load-balancer module so new load balancers are born compliant. Two months on, the same question had a clear answer backed by an enforced SLA on free-and-important security fixes and a Config rule that catches any drift, which is the confidence signal that belongs on an operational review.

The dollar cost of fixing these is effectively zero, which is exactly why they deserve a moment of attention. When a recognised attack class, or a recurring drop in customer requests, can be closed by a single configuration change at no cost, the only reason it stays open is organisational, it got lost in a backlog or no one owns it. That, not the load-balancer setting itself, is the real signal.

There is a compliance and reputational dimension too. The HTTP-hardening controls map to PCI DSS and NIST, so leaving them open creates an audit finding on infrastructure that handles your customers' traffic, and the downside scenario, request smuggling leading to session hijacking or mass cache poisoning, is the kind of incident that makes headlines and breaks trust. The leadership move is to ensure free-and-important security fixes have a fast, enforced SLA, and that new load balancers are born compliant.