Skip to main content
emnode / learn
Compliance High severity

AWS Security Hub · RDS

RDS.51: An Aurora MySQL global cluster runs an unsupported version

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub RDS.51 check?

RDS.51 checks whether an Aurora MySQL global cluster (AWS::RDS::GlobalCluster) runs a supported engine version. It reports FAILED when the version is below the minimum supported release and is not one of the grandfathered LTS versions (3.04.0 through 3.04.3). The rule is change-triggered.

Why does RDS.51 matter?

The consequences compound on two fronts. Security: an unsupported engine no longer receives the CVE patches that keep the data layer defensible. Cost: once a version passes end-of-standard-support, AWS automatically enrolls it in RDS Extended Support, which adds a per-vCPU-hour surcharge that runs continuously and scales with cluster size — a charge most teams discover only when the invoice jumps. An unremediated RDS.51 finding is a standing, avoidable line item that grows with the database.

How do I fix RDS.51?

  1. Identify the global cluster's current engine version and the current minimum supported release.
  2. Test the target version against a clone or staging copy, since a global database upgrade touches the primary and all secondary Regions.
  3. Upgrade the global cluster to a supported version (modify-global-cluster --engine-version) in a maintenance window.
  4. Add monitoring for engine end-of-support dates so the next version transition is planned, not forced.

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 nodejs20.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.29

Full walkthrough (console steps, edge cases and verification) in the lesson Keep software and engines patched.

Is RDS.51 a false positive?

Aurora MySQL's lifecycle is non-contiguous: LTS releases (3.04.x) stay supported longer than some newer non-LTS versions, so a cluster on an LTS version passes RDS.51 even though it looks "older" than a version that fails.

Part of the learning path Build in resilience
  • RDS.1 An RDS snapshot is shared publicly
  • RDS.2 An RDS instance is publicly accessible from the internet
  • RDS.3 RDS DB instances should be encrypted at rest
  • RDS.4 RDS snapshots should be encrypted at rest
  • RDS.5 RDS DB instances should use multiple AZs
  • RDS.6 RDS lacks enhanced monitoring
  • RDS.7 RDS clusters should have deletion protection
  • RDS.8 RDS DB instances should have deletion protection
  • RDS.9 RDS engine logs are not shipped to CloudWatch
  • RDS.10 RDS relies on long-lived database passwords
  • RDS.11 RDS instances should have automatic backups
  • RDS.12 IAM auth should be configured for RDS clusters