Use ACM certificates on Classic Load Balancers

A load balancer is the front door that accepts encrypted (HTTPS) traffic for a service. To do that it has to hold a security certificate, and that certificate has an expiry date — usually a little over a year out. AWS offers a managed service, AWS Certificate Manager (ACM), that renews these certificates automatically and for free. The alternative is a certificate someone uploaded and manages by hand, which has to be manually replaced before it expires or the entire service goes dark.

This finding flags load balancers that are still relying on the manual path. There is no direct dollar amount on the invoice — ACM-issued certificates are free, and the manual ones may be free too — so this is not a cost-saving item in the usual sense. The cost it controls is the cost of an outage: a public-facing service that stops responding because a certificate quietly lapsed, with all the revenue loss, SLA penalties, and reputational damage that follows.

From a finance and risk standpoint, the right way to read ELB.2 is as a cheap insurance policy that hasn't been bought yet. Moving a certificate to ACM is a one-time, no-cost engineering task that removes a recurring operational risk permanently. The framing for the business is not "how much will this save" but "how much does an unplanned outage of this service cost, and are we one forgotten calendar reminder away from it."

Priya is the finance partner embedded with the platform team. ELB.2 shows up on the monthly risk-and-cost review with no dollar figure attached, which is exactly why it tends to get skipped. She asks the one question that makes it real: "If the certificate on this service expired tomorrow, what breaks, and what does an hour of that being down cost us?" The answer — the billing API, and "a lot" — is enough to reprioritise it.

She doesn't need to understand ACM versus IAM certificates. What she establishes is that the fix is free, takes one engineer under an hour, and permanently removes a manual deadline that currently lives in nobody's job description. That turns ELB.2 from an ignorable line on a compliance report into an obvious yes: zero cost, removes outage risk, done once.

At the following review the finding is closed. Priya adds a single standing item to the risk pack — "any HTTPS load balancer not on automatic certificate renewal" — so that the next time someone stands up a service the manual way, it surfaces immediately instead of becoming a latent outage waiting twelve months to fire.

There is no cost saving in this finding, and it's important to be clear about that up front so it isn't mis-sold. ACM certificates are free; the legacy certificates this finding flags are typically free too. The dollar figure attached to ELB.2 on a cost dashboard is zero, which is exactly why it tends to get deprioritised against findings with a visible number next to them.

The financial exposure is on the risk side of the ledger, not the spend side. The relevant number is the cost of an outage of whatever the load balancer fronts — lost transactions per hour, SLA credits owed to customers, the support and incident-response cost, and the reputational tail. For a revenue-generating service those numbers dwarf any line item this lesson could save. The fix is a free, one-time engineering task, so the return-on-effort is effectively infinite: spend an hour, remove a guaranteed-eventually outage.

The right way to carry this on a finance pack is as a risk item with a notional outage-cost attached, not as a cost-optimisation opportunity. "This service does X dollars of revenue per hour and is one missed renewal away from being down" is the framing that gets it prioritised. Once fixed, it's closed permanently — it doesn't recur month to month the way usage-based waste does.

Finally, treat a non-zero ELB.2 count as a leading indicator of process gaps. If services are still being stood up with manually managed certificates, the same teams are likely missing other automation defaults too. The dollar value of fixing this one finding is small; the value of the operating discipline it points at is not.

Public-facing services hold a security certificate that expires roughly once a year. AWS can renew these automatically and for free through its Certificate Manager service. This finding flags services that instead rely on someone manually replacing the certificate before it lapses — and if that's missed, the service goes completely offline.

This is a resilience and operational-discipline issue, not a spend issue. Fixing it costs nothing on the bill and removes a class of self-inflicted outage entirely. The leadership question is simply whether the org is running its critical front doors on automatic renewal or on someone's memory.

At one company the CTO kept seeing certificate-related items drift on the compliance summary quarter after quarter — low individual urgency, never quite prioritised. After a peer organisation made the news for an expired-certificate outage, she stopped asking about the specific findings and asked one structural question instead: "Are all of our public-facing services on automatic certificate renewal, yes or no?"

That reframed it. The answer was "mostly," and "mostly" was the problem — every exception was a service running on a manual deadline that someone would eventually miss. The team made automatic renewal the default and closed the exceptions within a sprint. The cost was an engineer's afternoon; the outcome was an entire failure class removed.

The right end state isn't "ELB.2 is green this month." It's "we don't run critical front doors on human memory." Once that's an operating norm, the finding stops recurring and the question drops off the leadership agenda entirely.

This finding carries no cost number, which is precisely why it's worth a moment of leadership attention rather than none. It represents a guaranteed-eventually outage of a public-facing service, controlled by a manual task that depends on a person remembering a date that's over a year away. That's the kind of risk organisations discover the hard way — at the moment of failure, not before.

The fix is free and one-time, so there's no cost-benefit trade-off to agonise over; it's simply a question of whether the org has made automatic certificate renewal a default. A persistent or growing ELB.2 count says new services are still being built the fragile way, which usually means the same teams are skipping other resilience defaults. The single useful question at the leadership level is whether all critical front doors are on automatic renewal — and the right answer is an unqualified yes.