AWS Security Hub · EKS
EKS.2: An EKS cluster runs an unsupported Kubernetes version
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub EKS.2 check?
EKS.2 fails when a cluster's control plane runs a Kubernetes version that is no longer in standard support. It is scored separately from EKS.9, which covers the node groups.
Why does EKS.2 matter?
An out-of-support control plane misses the latest security patches and slips onto the extended-support tier, which carries a steep per-cluster-hour surcharge, roughly six times the base rate. A few clusters quietly on extended-support versions can burn over a thousand dollars a month in surcharge alone, all for running an older, less-patched Kubernetes.
How do I fix EKS.2?
- Inventory cluster versions and their support status with the CLI.
- Run the in-place control-plane upgrade one minor version at a time, checking for removed/deprecated APIs before each step.
- Upgrade node groups (EKS.9) to keep them within the supported skew of the new control plane.
- Set an upgrade cadence so clusters never drift onto the extended-support tier again.
Remediation script · bash
# Enable auto minor version upgrade on every RDS instance that has it disabled.
for id in $(aws rds describe-db-instances \
--query 'DBInstances[?AutoMinorVersionUpgrade==`false`].DBInstanceIdentifier' --output text); do
aws rds modify-db-instance --db-instance-identifier "$id" \
--auto-minor-version-upgrade --no-apply-immediately
done
# Move a deprecated Lambda function to a supported runtime.
aws lambda update-function-configuration --function-name auth-token-issuer \
--runtime nodejs22.x
# Upgrade an out-of-support EKS control plane one minor version at a time (then catch up node groups).
aws eks update-cluster-version --name prod-payments --kubernetes-version 1.29Full walkthrough (console steps, edge cases and verification) in the lesson Keep software and engines patched.
Is EKS.2 a false positive?
EKS.2 fails on both unsupported and extended-support versions, and the `oldestVersionSupported` parameter is fixed at the current floor and not customisable, so a cluster pinned to an older minor version for a genuine compatibility reason (a workload that has not yet certified against the newer Kubernetes API, or a vendor appliance that lags the release calendar) will fail even when staying back is the deliberate, budgeted choice. Paying the extended-support surcharge to hold a version is a legitimate strategy while you finish the upgrade work. Where that is the case, suppress the finding with a documented exception that names the blocking dependency and the target date to exit extended support, rather than forcing a premature control-plane upgrade that could break the very workload you are protecting.