Amazon Aurora MySQL 8.4 Is Now GA, So I Checked the Changes Related to 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 (GA).
Aurora MySQL 8.4 is a major version compatible with community MySQL 8.4 LTS. The versioning model has also changed, moving from the previous 8.0.mysql_aurora.3.x.y format to the 8.4.mysql_aurora.8.4.7 format.
The security-related default values 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 parameters) | OFF (optional) | ON (require_secure_transport=ON) |
| TLS versions | TLS 1.0–1.3 | TLS 1.2/1.3 only (*) |
| Password validation | Manually enabled | Enabled by default (MEDIUM) |
| SHOW MASTER STATUS | Available | Syntax error |
- The TLS version restriction is based on the official documentation. In this verification, I confirmed a connection over TLSv1.3, but I did not run tests explicitly confirming that TLS 1.0/1.1 are rejected.
This article checks the default behavior of a newly created cluster in the Tokyo region. How existing parameter groups and existing users are handled when upgrading from an existing cluster is out of scope.
Test 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) |
Results
| Item checked | Result | Impact |
|---|---|---|
| Version string | Both VERSION() and AURORA_VERSION() return 8.4.7 |
No impact on normal connections. Version-detection scripts need to be checked |
| Default authentication plugin | New users get caching_sha2_password (* mysql_native_password can also be used when explicitly specified) |
Connections may be affected with older drivers |
| TLS enforcement | require_secure_transport=ON |
Non-TLS connections are rejected with ERROR 3159 |
| Password validation | Enabled by default, MEDIUM | Users cannot be created with weak passwords |
SHOW MASTER STATUS |
Syntax error | Affects monitoring and operations scripts |
Checking the Version
In the 8.4.mysql_aurora.8.4.7 I tested, both VERSION() and AURORA_VERSION() returned 8.4.7. In Aurora MySQL 3, the two returned different values, so 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 I tested, *:caching_sha2_password was displayed. At the very least, this value confirms that the default authentication plugin for new users is caching_sha2_password.
I created a new user and checked the authentication plugin.
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 administrator user and the new user were set to caching_sha2_password.
On the other hand, I also checked explicitly specifying mysql_native_password.
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 enabled. In the newly created cluster used here, mysql_native_password could be used when creating new users as long as it was explicitly specified. 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 to watch out for is that the default when creating new users has changed, and that the application-side driver must 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 the default. The actual connection was made over TLSv1.3. When I tried 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 done on the server side, not a difference due to client implementation. You need to check whether any connection settings disable TLS.
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. Under the MEDIUM policy, a password must be at least 8 characters long and contain at least one uppercase letter, one lowercase letter, one digit, and one special character. The settings can be adjusted in the parameter group.
This restriction applies when creating new users or changing passwords. At the very least, 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 | (値省略) | | | |
+----------------------------+----------+--------------+------------------+-------------------+
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 resulted in a syntax error because it is syntax removed in MySQL 8.4. If monitoring scripts or management tools call the old syntax internally, errors may occur after migrating to Aurora MySQL 8.4.
Notes
The engine version to specify when creating a cluster is 8.4.mysql_aurora.8.4.7. If you specify just 8.4.7, you get the error InvalidParameterCombination: Cannot find version 8.4.7 for aurora-mysql.
The mariadb 10.5.29 client in AL2023 standard does not have the --ssl-mode option. Use --ssl (enabled by default) for TLS connections and --skip-ssl to disable it. With the official MySQL 8.0-series client, it is --ssl-mode=REQUIRED / --ssl-mode=DISABLED.
When using master user password management via Secrets Manager (--manage-master-user-password) as in this case, the generated password may contain characters that are interpreted by the shell. Be careful with quoting when connecting manually from the CLI.
Summary
In Aurora MySQL 8.4, the security-related defaults have been significantly strengthened, and TLS enforcement, the authentication plugin change, and the password policy have moved in a direction that is "secure even without configuration." On the other hand, with the defaults for a newly created cluster, non-TLS connections are rejected, and the old replication syntax cannot be used. Behavior during upgrades depends on existing settings, so advance verification is necessary. Standard support for Aurora MySQL 3 lasts until April 30, 2028, so it would be wise to proceed with planned upgrade preparations.
Here are the minimum points I would want to check before upgrading.
- Whether the application's MySQL drivers and connectors support
caching_sha2_password - Whether TLS is disabled in connection settings (
ssl-mode=DISABLED,useSSL=false,--skip-ssl, etc.) - Whether user creation and password change processes satisfy the password policy
- Whether monitoring scripts and operations tools use old syntax such as
SHOW MASTER STATUS
The basic approach is to first deal with these by fixing applications and connection settings. Depending on requirements, things like TLS enforcement and the password policy may be adjustable through parameter groups. However, the replication syntax cannot be handled via parameter groups, so scripts need to be fixed.
References
