Amazon Aurora MySQL 8.4.8 has been released as GA, so I checked the changes from 8.4.7
This page has been translated by machine translation. View original
Introduction
On September 3, 2026, the GA of Amazon Aurora MySQL 8.4.8 was announced in What's New.
Regarding the initial release of Aurora MySQL 8.4, which became GA in May 2026, version 8.4.7, the following article introduced changes to connection and authentication around Aurora MySQL 8.0, focusing on the mandatory TLS connection requirement.
This time, we will actually launch an Aurora MySQL 8.4.8 cluster in the Tokyo region and verify the main changes from 8.4.7.
Verification Contents
Verification was performed using the AWS CLI and RDS Data API.
Verification Environment
| Item | Value |
|---|---|
| Region | ap-northeast-1 |
| Engine Version | 8.4.mysql_aurora.8.4.8 |
| Instance Class | db.r8g.large |
| SQL Execution Path | RDS Data API |
| Cluster Parameter Group | aurora848-verify-binlog-row (binlog_format=ROW) |
Available Versions and Cluster Creation
We confirmed the availability in the Tokyo region and the upgrade path from 8.4.7.
aws rds describe-db-engine-versions \
--engine aurora-mysql \
--engine-version 8.4 \
--region ap-northeast-1
From the 8.4.7 entry, here is an excerpt of the upgrade target section.
"EngineVersion": "8.4.mysql_aurora.8.4.7",
"ValidUpgradeTarget": [
{
"Engine": "aurora-mysql",
"EngineVersion": "8.4.mysql_aurora.8.4.8",
"Description": "Aurora MySQL 8.4.8 (compatible with MySQL 8.4.8)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": false,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsLocalWriteForwarding": true,
"SupportsIntegrations": true
}
],
In the Tokyo region, the status of 8.4.8 was available. The only upgrade target from 8.4.7 is 8.4.8, provided as a minor version upgrade. The 8.4.8 entry has no upgrade targets, confirming that 8.4.8 is the latest version at this time.
Comparing the entries for 8.4.7 and 8.4.8, there were no differences other than the list of upgrade targets. The supported engine features, exportable log types, and selectable CA certificates are the same. However, since features added in 8.4.8 do not appear in this metadata, subsequent verification was performed on the server side.
The version string to specify when creating a cluster is 8.4.mysql_aurora.8.4.8. Specifying just 8.4.8 is not possible. The same constraint was confirmed with 8.4.7 as well.
In preparation for replication verification to be covered in a separate article, we prepared a custom cluster parameter group with binlog_format set to ROW. Since binlog_format is a static parameter, it needs to be set on the parameter group side before creating the cluster.
Applied parameter file (cluster-parameters.json)
[
{"ParameterName":"binlog_format","ParameterValue":"ROW","ApplyMethod":"pending-reboot"}
]
aws rds create-db-cluster-parameter-group \
--db-cluster-parameter-group-name aurora848-verify-binlog-row \
--db-parameter-group-family aurora-mysql8.4 \
--description "binlog row for replication verification"
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name aurora848-verify-binlog-row \
--parameters file://cluster-parameters.json
Using this parameter group, we created a cluster and writer instance. To use the RDS Data API for SQL execution, --enable-http-endpoint was specified on the cluster side.
aws rds create-db-cluster \
--db-cluster-identifier aurora848-verify-source \
--engine aurora-mysql \
--engine-version 8.4.mysql_aurora.8.4.8 \
--master-username admin \
--manage-master-user-password \
--db-subnet-group-name aurora848-verify-subnet-group \
--vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \
--db-cluster-parameter-group-name aurora848-verify-binlog-row \
--database-insights-mode standard \
--backup-retention-period 1 \
--no-deletion-protection \
--enable-http-endpoint
aws rds create-db-instance \
--db-instance-identifier aurora848-verify-source-1 \
--db-cluster-identifier aurora848-verify-source \
--db-instance-class db.r8g.large \
--engine aurora-mysql \
--enable-performance-insights \
--performance-insights-retention-period 7 \
--no-publicly-accessible
The cluster was created with the specified version and configuration. The main items in the creation response are as follows.
| Response Item | Value |
|---|---|
| EngineVersion | 8.4.mysql_aurora.8.4.8 |
| HttpEndpointEnabled | true |
| DatabaseInsightsMode | standard |
With HttpEndpointEnabled set to true, the RDS Data API was successfully enabled on an 8.4.8 provisioned cluster. All subsequent SQL statements are executed via the Data API.
We confirmed the version on the cluster.
aws rds-data execute-statement \
--resource-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:aurora848-verify-source \
--secret-arn arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds!cluster-xxxxxxxx \
--database mysql \
--format-records-as JSON \
--sql "SELECT VERSION() AS mysql_version, AURORA_VERSION() AS aurora_version;"
Both VERSION() and AURORA_VERSION() returned 8.4.8.
Replication-Related Procedures
Multi-source replication and delayed replication are announced as available from 8.4.8 onward.
Multi-source replication and Delayed replication are supported on Aurora MySQL version 8.4.8 and higher, in all AWS Regions where Aurora MySQL is available.
We confirmed whether administrative procedures for operating these features are available.
aws rds-data execute-statement \
--resource-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:aurora848-verify-source \
--secret-arn arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds!cluster-xxxxxxxx \
--database mysql \
--format-records-as JSON \
--sql "SHOW PROCEDURE STATUS WHERE Db='mysql';"
The following 4 procedures for specifying delay time in delayed replication were available.
rds_set_source_delay
rds_set_source_delay_for_channel
rds_set_external_source_with_delay
rds_set_external_source_with_delay_for_channel
Since multi-source replication uses separate channels per source, the _for_channel variants that take a channel name as an argument are necessary. The _for_channel variants were available for major operations such as starting/stopping replication and specifying sources.
List of replication-related procedures
rds_clean_replication_status_for_channel
rds_external_source
rds_import_binlog_ssl_material
rds_next_source_log
rds_next_source_log_for_channel
rds_remove_binlog_ssl_material
rds_reset_external_source
rds_reset_external_source_for_channel
rds_set_binlog_source_ssl
rds_set_binlog_source_ssl_for_channel
rds_set_external_source
rds_set_external_source_for_channel
rds_set_external_source_with_auto_position
rds_set_external_source_with_auto_position_for_channel
rds_set_external_source_with_delay
rds_set_external_source_with_delay_for_channel
rds_set_source_auto_position
rds_set_source_auto_position_for_channel
rds_set_source_delay
rds_set_source_delay_for_channel
rds_skip_repl_error
rds_skip_repl_error_for_channel
rds_start_replication
rds_start_replication_for_channel
rds_start_replication_until
rds_start_replication_until_for_channel
rds_start_replication_until_gtid
rds_start_replication_until_gtid_for_channel
rds_stop_replication
rds_stop_replication_for_channel
Connection, Authentication, and TLS Defaults
To confirm whether any reconnection-related changes are required after a minor upgrade, we compared the default values of 8.4.8 against the measured values of 8.4.7 from the existing article.
| Item | 8.4.7 | 8.4.8 |
|---|---|---|
| authentication_policy | *:caching_sha2_password | *:caching_sha2_password |
| require_secure_transport | ON | ON |
| validate_password.policy | MEDIUM | MEDIUM |
| validate_password.length | 8 | 8 |
The default values for authentication method, mandatory communication encryption, and password policy were the same as in 8.4.7. For items not listed in the table, the required number of uppercase letters, lowercase letters, digits, and special characters is 1 in both versions. No changes were found that would require revisiting connection settings.
In the Data API session, Ssl_version was TLSv1.3 and Ssl_cipher was TLS_AES_256_GCM_SHA384. These are per-session values that vary depending on the client implementation and negotiation result.
TLS-related server variables were also confirmed by running SHOW VARIABLES LIKE 'tls%' and LIKE 'ssl%' via the Data API. tls_version was TLSv1.2 and TLSv1.3, tls_ciphersuites was TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384, tls_certificates_enforced_validation was OFF, and ssl_fips_mode was ON.
Transaction Timeout
Transaction timeout became available in 8.4.8 as a measure against the problem of long-running transactions hindering InnoDB purge. We confirmed the corresponding server variables.
aws rds-data execute-statement \
--resource-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:aurora848-verify-source \
--secret-arn arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds!cluster-xxxxxxxx \
--database mysql \
--format-records-as JSON \
--sql "SHOW VARIABLES LIKE '%transaction%';"
aurora_transaction_timeout exists with a value of 0. Running SHOW VARIABLES LIKE '%timeout%' as well, this was the only variable corresponding to transaction timeout. It is disabled by default and requires a value to be set in order to use it.
Support End Dates and Version Selection
The minor versions in the 8.4 series have 8.4.7 and 8.4.8 listed in the release calendar.
| Aurora MySQL Version | Compatible MySQL | Release Date | Standard Support End Date |
|---|---|---|---|
| 8.4.8 | 8.4.8 | 2026-09-03 | 2027-09-03 |
| 8.4.7 | 8.4.7 | 2026-05-21 | 2027-11-30 |
Standard support for both ends within 2027. The 8.4 series has no LTS-designated versions; LTS applies only to 3.10 and 3.04.
Looking at major versions, the standard support end dates are as follows.
| Aurora Major Version | Compatible MySQL | Standard Support End |
|---|---|---|
| 8.4 | MySQL 8.4 | April 2032 |
| 3 | MySQL 8.0 | 2028-04-30 |
The 8.4 series can be used longer as a major version, but the minor versions within it are replaced approximately every year. If you can accommodate minor upgrades roughly once a year, the 8.4 series is appropriate; if you prioritize staying on the same minor version for a longer period, the choice would be 3.10, the LTS version of the 3 series (standard support until 2028-04-30).
Summary
Aurora MySQL 8.4.8 is a minor update in the 8.4 series and can be upgraded from 8.4.7 in the Tokyo region. The default values for connections are the same as in 8.4.7, so if you are operating with the defaults, no changes to connection settings are required.
In 8.4.8, multi-source replication, delayed replication, and PQ-TLS key exchange are available. If these features are needed, or in environments where post-quantum cryptography compliance is required by guidelines or other policies, these are reasons to choose 8.4.8. If you want to avoid the risk of deferring updates and dealing with them all at once later, choosing 8.4.8 early is also an option.
Details on the new features of Aurora MySQL 8.4.8, including replication functionality and post-quantum cryptography support, are planned to be introduced in a separate article at a later date.
