Amazon Aurora MySQL 8.4.8 Is Now GA, So I Checked the Changes from 8.4.7

Introduction

On September 3, 2026, the GA of Amazon Aurora MySQL 8.4.8 was announced in What's New.

https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-aurora-mysql-848-available/

For version 8.4.7, the initial release of Aurora MySQL 8.4 that reached GA in May 2026, I covered the changes to connection and authentication from Aurora MySQL 8.0, centered on mandatory TLS connections, in the following article.

https://dev.classmethod.jp/articles/aurora-mysql-84-ga-connection-auth-changes/

This time, I launched an Aurora MySQL 8.4.8 cluster in the Tokyo Region and checked the main changes from 8.4.7.

Verification Details

The checks were performed with the AWS CLI and the RDS Data API.

Verification Environment

Available Versions and Cluster Creation

I checked 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

Here is an excerpt of the upgrade target portion from the 8.4.7 entry.

        "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 for 8.4.7 is 8.4.8, and it is offered as a minor version upgrade. The 8.4.8 entry has no upgrade targets, so 8.4.8 was the latest version at this point.

Comparing the 8.4.7 and 8.4.8 entries, 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, features added in 8.4.8 do not appear in this metadata, so I verified them on the server side from here on.

The version string to specify when creating a cluster is 8.4.mysql_aurora.8.4.8. You cannot specify just 8.4.8. I confirmed the same restriction with 8.4.7.

In preparation for the replication checks covered in a separate article, I prepared a custom cluster parameter group with binlog_format set to ROW. Since binlog_format is a static parameter, it needs to be set in the parameter group before creating the cluster.

[
  {"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

I created the cluster and writer instance with this parameter group specified. Because the RDS Data API is used to run SQL, I specified --enable-http-endpoint on the cluster.

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.

HttpEndpointEnabled was true, so the RDS Data API could be enabled on an 8.4.8 provisioned cluster. All subsequent SQL was run via the Data API.

I checked 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 Procedures

It has been announced that multi-source replication and delayed replication are available in 8.4.8 and later.

https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-aurora-mysql-multisourcerep-delayedrep/

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.

I checked whether administrative procedures for operating these features are provided.

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 four procedures for specifying the 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

Multi-source replication uses a separate channel for each source, so _for_channel versions that take a channel name as an argument are required. The _for_channel versions were available for the main operations, such as starting and stopping replication and specifying the source.

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

Default Values for Connection, Authentication, and TLS

To check whether a minor upgrade requires any reconfiguration related to connections, I compared the default values in 8.4.8 against the values for 8.4.7 measured in the existing article.

The defaults for the 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 numbers of uppercase letters, lowercase letters, digits, and symbols are 1 in both versions. I found no changes that would require reviewing connection settings.

In the Data API session, Ssl_version was TLSv1.3 and Ssl_cipher was TLS_AES_256_GCM_SHA384. Both are per-session values and vary depending on the client implementation and the negotiation result.

I also checked the TLS-related server variables 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

As a countermeasure against the problem of long-running transactions blocking InnoDB purge, a transaction timeout became available in 8.4.8. I checked the corresponding server variable.

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, and its value was 0. I also ran SHOW VARIABLES LIKE '%timeout%', but this was the only variable corresponding to the transaction timeout. It is disabled by default, and you need to set a value to use it.

Support Deadlines and Version Selection

For minor versions of the 8.4 series, the release calendar lists two: 8.4.7 and 8.4.8.

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.release-calendars.html

Standard support for both ends within 2027. The 8.4 series has no versions designated as LTS, and the only LTS versions are 3.10 and 3.04.

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Update.SpecialVersions.html

By major version, the end of standard support is as follows.

The 8.4 series is the one you can use for a long time as a major version, but its minor versions are replaced roughly every year. If you can plan on about one minor upgrade per year, the 8.4 series is the choice; if you prioritize staying on the same minor version for a long time, the choice is 3.10, the LTS 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 in the Tokyo Region you can upgrade to it from 8.4.7. The default values related to connections are the same as in 8.4.7, so if you operate with the defaults, there is no need to change your connection settings.

In 8.4.8, in addition to multi-source replication and delayed replication, PQ-TLS key exchange is also available. If you need these features, or if you are in an environment where guidelines or the like require support for post-quantum cryptography, that is a reason to choose 8.4.8. Choosing 8.4.8 early is also an option if you want to avoid the risk of postponing updates and having to deal with them all at once later.

Details of the new features in Aurora MySQL 8.4.8, such as the replication features and post-quantum cryptography support, will be introduced in separate articles later.