Skip to main content
emnode
Compliance Medium severity

AWS Security Hub · DMS

DMS.6: DMS instances auto minor version upgrade

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub DMS.6 check?

DMS.6 fails when a replication instance has AutoMinorVersionUpgrade turned off. The control reads that flag, which controls whether DMS applies minor engine patches automatically during the instance's maintenance window.

Why does DMS.6 matter?

Replication instances are easy to forget: many run continuous change data capture for years on the version they were launched with. With auto minor upgrades off, those instances quietly drift behind on security and stability patches, sometimes several versions, until someone notices during a security sweep. Letting AWS apply minor patches keeps long-lived infrastructure current with no babysitting.

How do I fix DMS.6?

  1. Inventory replication instances and find those with AutoMinorVersionUpgrade disabled.
  2. Enable the flag with a single modify-replication-instance call.
  3. Confirm the maintenance window is set to a low-traffic period, since the upgrade applies there and can briefly interrupt running tasks.
  4. Set the flag on by default in your provisioning template.

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

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

Is DMS.6 a false positive?

A pinned engine version under strict change control is the legitimate fail here. If a regulated or tightly validated migration requires the replication engine to stay on an exact, qualified version (so that patches land only inside an approved maintenance change rather than automatically) then disabling AutoMinorVersionUpgrade is the deliberate, correct state, and the control's FAILED is expected. The check has no parameters and only reads the flag, so it can't tell a controlled pin apart from neglect. Don't flip the flag just to pass; suppress the finding with the workflow status set to SUPPRESSED (via BatchUpdateFindings or an automation rule) and a note pointing at the change-control process, so the exception is documented and auditable rather than silently re-enabled.

Part of the learning path Build in resilience
  • DMS.1 A DMS replication instance is publicly accessible
  • DMS.7 DMS target DB tasks should have logging
  • DMS.8 DMS source DB tasks should have logging
  • DMS.9 DMS endpoints should use SSL
  • DMS.10 DMS Neptune endpoints should have IAM auth
  • DMS.11 DMS MongoDB endpoints should have auth
  • DMS.12 DMS Redis endpoints should have TLS
  • DMS.13 DMS replication instances should be Multi-AZ