Skip to content

Connectivity and security changes in Aurora MySQL 8.4 for DMS users

4 minute read
Content level: Intermediate
0

Aurora MySQL 8.4 is now generally available and introduces security defaults that can silently break existing AWS DMS endpoint connections upon upgrade. This article helps DMS users understand what changes before they upgrade, what actions are required, and how to avoid connectivity failures. Specifically, Aurora MySQL 8.4 enforces TLS by default (require_secure_transport=ON), changes the default authentication plugin to caching_sha2_password, and introduces password policy parameters

If you are creating a new Aurora MySQL instance, follow the official AWS documentation for recommended configuration. The points below are primarily relevant for users upgrading existing Aurora MySQL instances that are already used with AWS DMS tasks.

1. Authentication — No action required, but be aware

Aurora MySQL 8.4 replaces the default_authentication_plugin parameter with authentication_policy, which defaults to *:caching_sha2_password. Existing database users retain their current authentication plugin after the upgrade. This change only affects newly created users and master user password resets. If you create new DMS endpoint users after the upgrade, they will use caching_sha2_password by default unless you set authentication_policy to *:mysql_native_password in your cluster parameter group.

2. Master user password reset — Action may be required if DMS endpoints use the master user

After upgrading to Aurora MySQL 8.4, resetting the master user password — via the AWS Console, CLI (modify-db-cluster --master-user-password), or through AWS Secrets Manager rotation — will change the master user's authentication plugin to match the current authentication_policy parameter value. By default, this means the master user switches from mysql_native_password to caching_sha2_password upon the next password reset.

If your DMS endpoints use the master user account, this can silently break connectivity after a routine password rotation. To prevent this, either:

  • Set authentication_policy to *:mysql_native_password in your cluster parameter group before resetting the password, or
  • Create a dedicated DMS endpoint user with an explicitly specified authentication plugin (recommended):
CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

3. TLS enforcement — Action may be required if your DMS endpoint SSL mode is set to "none"

Aurora MySQL 8.4 sets require_secure_transport to ON by default, meaning all connections must use TLS. Additionally, Aurora MySQL 8.4 enforces stricter cryptographic standards:

  • Only TLS 1.2 is supported (TLS 1.0 and 1.1 are removed). AWS DMS does not support TLS 1.3 for MySQL and MariaDB endpoints.
  • All CBC-mode ciphers have been removed. Only the following GCM ciphers are supported for TLS 1.2:
    • ECDHE-RSA-AES128-GCM-SHA256
    • ECDHE-RSA-AES256-GCM-SHA384
    • ECDHE-ECDSA-AES128-GCM-SHA256
    • ECDHE-ECDSA-AES256-GCM-SHA384

AWS DMS supports TLS 1.2 for MySQL and Aurora MySQL endpoints. However, if your DMS endpoint SSL mode is set to "none", connections will be rejected after the upgrade. Update the endpoint SSL mode to one of the following:

  • verify-ca — encrypts and verifies the server certificate against the CA.
  • verify-full — encrypts and verifies both the server certificate and hostname.

Alternatively, you can set require_secure_transport to OFF in your Aurora cluster parameter group to continue allowing unencrypted connections.

Error you will see: If your DMS endpoint SSL mode is set to "none", connections will fail with:

MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON

4. Password validation and Secrets Manager — No action required, but be aware

Aurora MySQL 8.4 introduces the aurora_enable_validate_password_component cluster parameter to manage the validate_password component without manual INSTALL/UNINSTALL COMPONENT commands. Aurora MySQL 8.4 supports password validation customization parameters (except for dictionary file).

If you enable password validation rules and also use AWS Secrets Manager to manage your master user password, be aware that automatically generated passwords during rotation may not comply with your configured validation requirements, causing rotation to fail. It is not recommended to use the validate_password component together with Secrets Manager managed master user passwords.

5. Password expiration policies — No action required, but be aware

Aurora MySQL 8.4 makes password policy parameters modifiable at the cluster level, including:

  • default_password_lifetime — sets global password expiration in days.
  • password_history — number of previous passwords that cannot be reused.
  • password_reuse_interval — number of days before a password can be reused.
  • password_require_current — requires users to provide current password when changing it.
  • disconnect_on_expired_password — controls whether expired password accounts are disconnected.

If you configure global password expiration after the upgrade, it will apply to all users including DMS endpoint accounts. Ensure DMS endpoint user accounts are accounted for in your password rotation strategy.

For more information