Keep software and engines patched

Most of this capability costs nothing on the invoice to fix. A minor version upgrade is free, enabling an auto-upgrade flag is free, and moving a Lambda function to a current runtime is free. So this is rarely a budget decision. The cost is contingent: it is the expected value of a breach on an unpatched data store, a failed audit, or an emergency upgrade when a version reaches end-of-support and AWS forces the change with little notice.

There are two places where staying behind has a direct dollar consequence, and both run in your favour when you fix them. EKS extended support adds a per-cluster-hour surcharge, several times the base rate, for every hour a cluster runs on an out-of-support version, so the finding is also a recurring penalty with no offsetting value. And newer Lambda runtimes routinely run 15 to 30 percent faster than deprecated ones with no code change, cutting GB-second billing, so a runtime migration often pays for itself. Frame remediation as removing avoidable spend and contingent risk at once.

Auditors under PCI DSS and frameworks built on NIST 800-53 treat unpatched databases and runtimes as a direct finding, not a soft recommendation, so this is the line item that can fail a compliance review and stall a customer deal. The right framing is that enabling supported-version defaults converts an unpredictable, lumpy, high-stress cost (emergency upgrades, breach response, audit remediation) into a predictable, near-zero one.

Lena is the finance partner for a mid-sized SaaS company mid-way through a SOC 2 and PCI renewal. Security Hub has thrown patching failures across RDS, Lambda and EKS in three accounts, and the auditor's pre-read has flagged unpatched systems as an area of focus. Her first instinct is not to ask for a budget, because she already knows most of these fixes carry no invoice line. It is to ask which workloads are in audit scope and which sit near a published deprecation deadline, so the work is ordered by the risk it removes rather than by the order the report lists it.

The team pulls the inventory. Two production databases (prod-orders and prod-billing) have auto minor version upgrade off and are sitting on old engines accumulating CVEs, a couple of Lambda functions are on deprecated runtimes, and one EKS cluster has slipped into extended support. Lena's framing for the finance pack has two halves. First, the contingent risk: an unpatched data store in PCI scope is a direct audit finding that can stall the certification and the revenue gated behind it, with the breach tail (forensics, notification, churn) landing in a different part of the P&L entirely. Second, the savings: the EKS extended-support surcharge is a pure, fully-avoidable penalty several times the base rate per cluster-hour that no Reserved Instance covers, and migrating the Lambda functions to current runtimes cuts GB-second billing by 15 to 30 percent. She frames remediation as removing avoidable spend and contingent risk at the same time, which moves the tickets up the backlog faster than a security finding alone.

Most of this capability carries no invoice line: a minor version upgrade and an auto-upgrade flag are free, and the brief maintenance-window downtime has no incremental charge. That is exactly why it is easy to under-prioritise next to categories that do show up on the bill. The cost is contingent and asymmetric: small and predictable if you stay current, large and lumpy if you do not (breach response, emergency upgrades, audit remediation). The most direct financial impact is on audit and sales, because an unpatched fleet is a finding auditors write up and a question on enterprise security questionnaires, and an open finding can delay a certification and the revenue gated behind it.

Two parts of the capability run the other way and make remediation a savings item. The EKS extended-support surcharge is a pure, fully-avoidable penalty, several times the base control-plane rate per cluster-hour, that no Reserved Instance or Savings Plan covers, so the only lever is upgrading on time; you can put an exact monthly figure on a slipped upgrade, which moves a maintenance ticket up the backlog faster than a security finding alone. And migrating Lambda functions to current runtimes cuts GB-second billing by 15 to 30 percent on real workloads, often paying for the migration sprint in the first billing cycle. The finance role is to track the count of unpatched workloads (and in-scope ones) as a risk indicator, quantify the EKS slip cost and the Lambda savings to fund the work, and require a recorded, dated exception for any deliberate version pin.

"Managed" does not mean "automatically kept secure." AWS applies routine security patches to an engine or runtime only if the workload is configured to follow the supported track. When a workload falls behind, it stops receiving security fixes and carries any published vulnerabilities until someone intervenes, which routinely does not happen on time. The report shows this as a scatter of findings across databases, runtimes, clusters and instances, but the underlying question is one: is anything running on a version nobody is patching?

What makes this a leadership item is that several of these findings have a hard expiry. AWS publishes deprecation dates 12 or more months in advance and will eventually force the change (blocking Lambda invocations, auto-upgrading an EKS cluster) on its own schedule. Missing a deadline means the team knew about a published, often High-severity obligation and did not act, which reads in an audit as a process-maturity gap rather than a one-off misconfiguration.

The defensible end state is that staying current is the default, with manual control reserved for a short, named list of documented exceptions, and deprecation dates on a shared calendar so upgrades are planned events rather than fire drills. For the EKS surcharge and the slower-runtime billing, the fix even removes cost while removing risk.

After a production PostgreSQL instance, whose auto-minor-version-upgrade flag had been switched off years earlier to avoid surprises, got force-upgraded by AWS in a maintenance window anyway because the engine had drifted toward end-of-support, the CTO asked a pointed question at the review: are we managing version lifecycle, or are we just hoping AWS does not call the deadline on us first? The honest answer was the latter. Falling behind had not avoided the upgrade, it had simply handed AWS the timing, on its schedule rather than the team's.

The response was to stop treating patching as a per-workload choice and make staying current the default. Auto-upgrade flags and supported-version pins went into the CloudFormation and Terraform modules so new workloads arrive current, AWS Config rules catch drift, and every published deprecation date now sits on the team calendar with 90 days of lead time, so upgrades are planned change windows rather than fire drills. The handful of workloads that legitimately pin a version (a vendor certification, a known regression) are tracked exceptions with an owner and a re-review date, not silent skips. A quarter on, the same CTO asked the simpler question, is anything running on a version nobody is patching, and the answer was a short, flat, documented list instead of a scramble. That shift, from reactive emergency upgrades to a calendar-driven process, is the whole point, and for the EKS surcharge and the slower-runtime billing it removed cost while it removed risk.

These findings mostly carry no dollar cost, which is the whole reason they need a leadership frame: there is no invoice pressure to fix them, so they only get done if the org treats staying patched as a default rather than a per-workload decision. They sit squarely in the security and compliance lane, unpatched workloads are a top breach vector and a direct finding under the frameworks customers audit against, and several have a published deadline that turns deferral into a guaranteed incident.

The second-order point is what the number says about discipline. A small, flat count with documented exceptions means the org has a working patching policy applied to new systems automatically. A growing count means workloads are launching without the policy and quietly accumulating risk that surfaces only at an audit or an incident. Both the CISO and the CFO have a stake: one in the breach risk, the other in the audit and deal exposure, plus the avoidable EKS surcharge and slower-runtime billing that staying behind quietly racks up.