Amazon Aurora MySQL 8.4 has become GA, so I tried checking the changes around connection and authentication
This page has been translated by machine translation. View original
Introduction
On May 21, 2026, Amazon Aurora MySQL 8.4 became generally available.
Aurora MySQL 8.4 is a major version compatible with community MySQL 8.4 LTS. The versioning model has also changed, moving from the conventional 8.0.mysql_aurora.3.x.y format to the 8.4.mysql_aurora.8.4.7 format.
The default values for security-related settings have changed as follows.
| Item | Aurora MySQL 3 (MySQL 8.0 compatible) | Aurora MySQL 8.4 (MySQL 8.4 compatible) |
|---|---|---|
| Default authentication (new users) | mysql_native_password | caching_sha2_password |
| TLS enforcement (default parameter) | OFF (optional) | ON (require_secure_transport=ON) |
| TLS version | TLS 1.0–1.3 | TLS 1.2/1.3 only (※) |
| Password validation | Manual activation | Enabled by default (MEDIUM) |
| SHOW MASTER STATUS | Available | Syntax error |
※ The TLS version restriction is based on the official documentation. In this verification, a connection via TLSv1.3 was confirmed, but explicit rejection testing of TLS 1.0/1.1 was not performed.
This article confirms the default behavior of a newly created cluster in the Tokyo region. How existing parameter groups and existing users are handled during an upgrade from an existing cluster is out of scope.
Verification Environment
| Item | Value |
|---|---|
| Region | ap-northeast-1 |
| Engine version | 8.4.mysql_aurora.8.4.7 |
| Instance class | db.r8g.large |
| Connection method | Bastion EC2 (t4g.micro, AL2023) → via SSM |
| Client | mariadb 10.5.29 (AL2023 standard package) |
Verification Results
| Verification item | Result | Impact |
|---|---|---|
| Version notation | Both VERSION() / AURORA_VERSION() return 8.4.7 |
No impact on normal connections. Version-checking scripts should be reviewed |
| Default authentication plugin | New users use caching_sha2_password (※ mysql_native_password is also available with explicit specification) |
Potential connection impact with older drivers |
| TLS enforcement | require_secure_transport=ON |
Non-TLS connections are rejected with ERROR 3159 |
| Password validation | Enabled by default, MEDIUM | Cannot create users with weak passwords |
SHOW MASTER STATUS |
Syntax error | Impacts monitoring and operational scripts |
Version Check
In the 8.4.mysql_aurora.8.4.7 version verified this time, both VERSION() and AURORA_VERSION() returned 8.4.7. Since the two values differed in Aurora MySQL 3.x, it would be a good idea to check any scripts that perform version detection.
SELECT VERSION(); -- 8.4.7
SELECT AURORA_VERSION(); -- 8.4.7
Default Authentication Plugin
SHOW VARIABLES LIKE 'authentication_policy';
-- *:caching_sha2_password
In the Aurora MySQL 8.4 verified this time, *:caching_sha2_password was displayed. At a minimum, this value confirms that the default authentication plugin for new users is caching_sha2_password.
A new user was created and the authentication plugin was checked.
CREATE USER 'testuser'@'%' IDENTIFIED BY 'TestPass123!';
SELECT user, plugin FROM mysql.user WHERE user IN ('admin','testuser');
+----------+-----------------------+
| user | plugin |
+----------+-----------------------+
| admin | caching_sha2_password |
| testuser | caching_sha2_password |
+----------+-----------------------+
Both the admin user and the new user had caching_sha2_password set.
On the other hand, explicit specification of mysql_native_password was also confirmed.
CREATE USER 'nativeuser'@'%' IDENTIFIED WITH mysql_native_password BY 'NativePass123!';
SELECT user, plugin FROM mysql.user WHERE user = 'nativeuser';
+------------+-----------------------+
| user | plugin |
+------------+-----------------------+
| nativeuser | mysql_native_password |
+------------+-----------------------+
In community MySQL 8.4, mysql_native_password is disabled by default, but in Aurora MySQL 8.4 the plugin was in an enabled state. In the newly created cluster verified this time, mysql_native_password could be used by explicitly specifying it when creating a new user. The official blog also states, from the perspective of continued use of existing accounts, "Aurora MySQL 8.4 keeps the plugin enabled so existing accounts that use it continue to work without interruption."
What should be noted is that the default changes when creating new users, and that the application-side driver needs to support caching_sha2_password.
TLS Enforcement
SHOW VARIABLES LIKE 'require_secure_transport'; -- ON
SHOW STATUS LIKE 'Ssl_version'; -- TLSv1.3
SHOW STATUS LIKE 'Ssl_cipher'; -- TLS_AES_256_GCM_SHA384
require_secure_transport=ON was set by default. The actual connection was made via TLSv1.3. When attempting a non-TLS connection by specifying --skip-ssl with the MariaDB client, it was rejected with ERROR 3159.
$ mysql -h <endpoint> -u admin -p --skip-ssl
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.
This confirms that the rejection is clearly happening on the server side, not due to differences in client implementation. It is necessary to check whether any connection settings have TLS disabled.
Password Validation
SHOW VARIABLES LIKE 'validate_password%';
+--------------------------------------+--------+
| Variable_name | Value |
+--------------------------------------+--------+
| validate_password.policy | MEDIUM |
| validate_password.length | 8 |
| validate_password.mixed_case_count | 1 |
| validate_password.number_count | 1 |
| validate_password.special_char_count | 1 |
+--------------------------------------+--------+
Password validation was enabled by default. The MEDIUM policy requires a minimum of 8 characters, including at least one uppercase letter, one lowercase letter, one number, and one special character. The configured values can be adjusted in the parameter group.
This restriction applies when creating new users or changing passwords. At a minimum, password validation itself does not immediately make existing accounts unable to log in.
Changes to Replication-Related Syntax
SHOW BINARY LOG STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000002 | (value omitted) | | | |
+----------------------------+----------+--------------+------------------+-------------------+
SHOW MASTER STATUS; -- ERROR 1064 (42000): You have an error in your SQL syntax
The new syntax SHOW BINARY LOG STATUS was accepted normally. On the other hand, the old syntax SHOW MASTER STATUS is a syntax removed in MySQL 8.4, so it results in a syntax error. If monitoring scripts or management tools internally call the old syntax, errors may occur after migrating to Aurora MySQL 8.4.
Notes
When specifying the engine version at cluster creation, use 8.4.mysql_aurora.8.4.7. Specifying 8.4.7 alone results in an InvalidParameterCombination: Cannot find version 8.4.7 for aurora-mysql error.
The mariadb 10.5.29 client that is standard in AL2023 does not have the --ssl-mode option. Use --ssl (enabled by default) for TLS connections, and --skip-ssl to disable it. For the official MySQL 8.0.x client, use --ssl-mode=REQUIRED / --ssl-mode=DISABLED.
When managing the master user password via Secrets Manager (--manage-master-user-password) as in this case, the generated password may contain symbols that are interpreted by the shell. Care should be taken with quoting when connecting manually from the CLI.
Summary
In Aurora MySQL 8.4, security-related defaults have been significantly strengthened, with TLS enforcement, authentication plugin changes, and password policy all moving in a "secure by default" direction. On the other hand, with the defaults at new cluster creation, non-TLS connections are rejected, and old replication syntax cannot be used. Since the behavior during upgrades depends on existing settings, prior verification is necessary. Since standard support for Aurora MySQL 3 ends on April 30, 2028, it would be a good idea to proceed with planned upgrade preparations.
Here are the minimum items to check before upgrading.
- Whether the application's MySQL driver or connector supports
caching_sha2_password - Whether TLS is disabled in any connection settings (
ssl-mode=DISABLED,useSSL=false,--skip-ssl, etc.) - Whether user creation and password change processes satisfy the password policy
- Whether monitoring scripts or operational tools use old syntax such as
SHOW MASTER STATUS
The basic approach is to first address issues by modifying the application or connection settings. TLS enforcement, password policy, and similar settings can in some cases be adjusted via parameter groups, depending on requirements. However, replication syntax cannot be addressed via parameter groups, so script modifications are required.
Reference Links
