Amazon Aurora MySQL 8.4 is now generally available

Today, we are excited to announce the general availability of Amazon Aurora MySQL 8.4, our latest major version, compatible with community MySQL 8.4.7. In this post, we introduce Aurora MySQL 8.4, walk through the new versioning approach and its benefits for customers, cover the key capabilities delivered in Aurora MySQL 8.4, and show you how to get started.

This release marks an important milestone for Aurora MySQL customers, introducing a simplified versioning model aligned directly with community MySQL, along with a streamlined patch version experience, and the full set of community MySQL 8.4 enhancements.

MySQL is one of the most widely deployed open source databases globally, powering applications across every industry and scale. Amazon Aurora MySQL-Compatible Edition combines this broad MySQL compatibility with Aurora’s performance, availability, and managed service benefits. As the MySQL community continues to innovate, Aurora MySQL evolves alongside it, delivering new community capabilities in a way that is easy to adopt while preserving the operational stability that critical workloads rely on.

Introducing Aurora MySQL 8.4

Aurora MySQL 8.4 brings community MySQL 8.4 compatibility to Aurora’s managed infrastructure, with its distributed storage, high availability, Aurora Global Database, RDS Blue/Green Deployments, and Aurora serverless capabilities. You get stronger security defaults, the latest authentication standards, and refreshed InnoDB defaults from community MySQL 8.4, delivered on Aurora.

Beyond the community changes, this release introduces a new versioning model for Aurora MySQL, aligned directly with community MySQL Long Term Support (LTS) releases, and a streamlined patch version experience that aligns Aurora MySQL with Amazon Aurora PostgreSQL-Compatible Edition. The following sections walk through each of these capabilities in detail.

A new versioning model aligned with Community MySQL LTS

Going forward, Amazon Aurora MySQL major versions will align with community MySQL Long Term Support (LTS) major releases. For details on the community MySQL release model, including the distinction between Innovation and LTS tracks, see this Oracle announcement. MySQL 8.4 is the first community MySQL LTS major release, and Aurora MySQL 8.4 is the first Aurora MySQL major version to adopt this alignment. This alignment delivers several benefits for you as a customer.

Simpler version mapping: Starting with this release, Aurora MySQL version numbers align directly with community MySQL. This version is called Aurora MySQL 8.4, not Aurora MySQL 4.x. When you migrate from self-managed MySQL or Amazon RDS for MySQL, or when you evaluate compatibility for your applications, you no longer need to translate between Aurora MySQL major numbers and the community MySQL versions they correspond to. The version you run on Aurora MySQL is the community MySQL version it is compatible with.

Predictable, long stability windows: Because community MySQL LTS major releases receive only bug fixes and security patches after their initial release, your applications running on Aurora MySQL 8.4 can expect consistent behavior across minor version upgrades within the 8.4 major version train. Aurora will continue to release new innovations and additional capabilities for existing features as part of Aurora MySQL 8.4 minor versions. You can plan your application certification and operational runbooks around a stable target.

Simplified version selection and streamlined patch experience

Aurora MySQL 8.4 simplifies customer experience around how you select and manage database versions. Understanding how the version number is structured will help you plan your clusters and upgrades.

How Aurora MySQL 8.4 versions are structured: Your Aurora MySQL version is presented in the form 8.4.7, where 8.4 is the major version, aligned with the community MySQL 8.4 LTS major, and 7 is the Aurora MySQL minor version. The minor version is the unit you select when you provision a new cluster or plan a minor version upgrade. These minor versions are version current with corresponding community MySQL minors and include new Aurora features.

Patches are managed by AWS: Any underlying patch versions within an Aurora MySQL minor are managed by AWS to simplify patch selection and upgrades. You no longer have to select a specific patch when you create a cluster or plan an upgrade. When you choose an Aurora MySQL minor, Aurora automatically launches you on the latest available patch for that minor version. Any new instance added to an existing non-Global Database cluster, or any new secondary Region added to an existing Global Database cluster, will use the same patch version as the existing writer or primary Region to keep behavior consistent across your cluster.

This model aligns with how majority of our customers already operate, relying on Aurora’s automatic minor version upgrade capability and always running the most recent stable patch. You no longer need to manually track which patch your clusters are on, nor re-certify every individual patch. When a new patch is available on a minor version you are running, it is surfaced as an update in the “Recommendations” section of the Amazon RDS console, so you can apply it during your maintenance window.

The result is a simpler day to day experience. You select the major and minor version, Aurora manages the patch, and you retain full visibility when you need it.

Release cycle changes

As highlighted in our latest announcement, Amazon Aurora MySQL aims to launch database releases at a defined cadence. This provides you transparency around frequent operations, such as:

• Plan major version upgrades and estimate when a new Aurora MySQL major version will be available.
• Schedule minor version upgrades during your maintenance windows.
• Select the right Aurora Long-Term Support (LTS) version for workloads that require staying on the same minor version across multiple release cycles.

The following table lists our release objectives for version currency releases on Aurora MySQL. Additional details are available at the Release calendars for Amazon Aurora MySQL.

Enhanced security defaults

Aurora MySQL 8.4 strengthens the default security posture for new clusters, building on the hardening work already delivered in Aurora MySQL version 3 and complementing the recent default encryption at rest change that now applies to all new Aurora clusters. These defaults reduce the configuration surface area you need to manage and align with current cryptographic best practices.

Modernized default authentication plugin: The caching_sha2_password authentication plugin is now the default in Aurora MySQL 8.4, replacing mysql_native_password. While community MySQL 8.4 disables mysql_native_password by default, Aurora MySQL 8.4 keeps the plugin enabled so existing accounts that use it continue to work without interruption. New accounts default to caching_sha2_password. The authentication_policy DB cluster parameter controls which authentication plugin is used by default when creating new accounts. In Aurora MySQL 8.4, this parameter defaults to caching_sha2_password, meaning new accounts use caching_sha2_password unless a different plugin is explicitly specified. For more information on caching_sha2_password compatibility considerations, client and connector requirements, and replication implications, see caching_sha2_password as the Preferred Authentication Plugin in the MySQL documentation. Before upgrading, confirm that your application drivers and connectors support caching_sha2_password. Most modern MySQL drivers already do.

Password validation and policy controls: Aurora MySQL 8.4 includes the community MySQL password validation component, now customizable through Aurora DB cluster parameter groups. You can enforce minimum password length, complexity rules such as uppercase, lowercase, numeric, and special character requirements, and username checking behavior, giving you centralized, declarative control over password policies across your fleet.

TLS enforced by default: The require_secure_transport parameter is now enabled by default in Aurora MySQL 8.4, which means all client connections must use TLS. TLS 1.0 and TLS 1.1 are removed, and only TLS 1.2 and TLS 1.3 are supported. For detailed guidance, see Security with Amazon Aurora MySQL.

Modern cipher suites only: Aurora MySQL version 3 restricted ciphers to those providing forward secrecy. Aurora MySQL 8.4 further tightens this to only ciphers that meet current cryptographic standards. Supported ciphers for TLS 1.2 include ECDHE key exchange with AES-GCM or ChaCha20-Poly1305, providing perfect forward secrecy and AEAD encryption. TLS 1.3 supports TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, and TLS_CHACHA20_POLY1305_SHA256. Before upgrading, confirm that your clients, drivers, and connection configurations are compatible with TLS 1.2 or TLS 1.3 and the updated cipher list. For the full list of supported ciphers by version, see Configuring cipher suites for connections to Aurora MySQL DB clusters.

Community MySQL 8.4 enhancements in Aurora MySQL

In addition to the capabilities described above, Aurora MySQL 8.4 includes the full set of community MySQL 8.4 enhancements. Here are some of the key enhancements to be aware of as you plan your upgrade, along with application or operational adjustments they may involve. For the complete list of additions, deprecations, and removals, see What Is New in MySQL 8.4 since MySQL 8.0 and the Aurora MySQL 8.4 release notes.

Replication terminology changes: Community MySQL 8.4 completes the removal of the legacy MASTER and SLAVE terminology in replication SQL commands and outputs. For example, SHOW MASTER STATUS is now SHOW BINARY LOG STATUS, SHOW SLAVE STATUS is now SHOW REPLICA STATUS, and CHANGE MASTER TO is now CHANGE REPLICATION SOURCE TO. Aurora MySQL began this transition in version 3, where inclusive stored procedure names (such as rds_set_external_source, rds_start_replication) were introduced alongside the legacy names. In Aurora MySQL 8.4, the legacy rds__master* procedure names, which were deprecated in Aurora MySQL version 3, are removed and only the inclusive equivalents remain. Review and update any application code, scripts, runbooks, or monitoring tools that use the legacy SQL syntax or legacy Aurora stored procedure names before upgrading. For more information on the RDS specific inclusive terminology changes introduced in Aurora MySQL version 3, see Inclusive language changes for Aurora MySQL version 3.

AUTO_INCREMENT with FLOAT and DOUBLE removed: The use of the AUTO_INCREMENT modifier on FLOAT and DOUBLE columns was deprecated in MySQL 8.0 and is removed in MySQL 8.4. Before upgrading to Aurora MySQL 8.4, identify and remediate any tables using this pattern. The upgrade prechecks will flag this incompatibility (see the columnDefinition precheck), and the upgrade cannot proceed until it is resolved.

Upgrade prechecks for Aurora MySQL 8.4

To help you prepare for the upgrade, Aurora MySQL 8.4 introduces a new set of automated upgrade prechecks that run before your cluster is taken offline for a major version upgrade. Customers trying to validate the upgrade readiness only can take a snapshot of their production database and run a test of major version upgrade to initiate the prechecks. These prechecks attempt to identify compatibility issues on the database level early, so you can resolve them before attempting the upgrade rather than encountering failures mid-process.

The prechecks cover both community MySQL 8.4 incompatibilities and Aurora-specific requirements, including:

• columnDefinition – Identifies FLOAT or DOUBLE columns with AUTO_INCREMENT, which are no longer supported.
• partitionsWithPrefixKeys – Flags partitioned tables using columns with prefix key indexes in their partitioning key.
• authMethodUsage – Reports user accounts still using deprecated authentication methods such as mysql_native_password.
• auroraUnsupportedPluginsCheck – Identifies plugins not supported in Aurora MySQL 8.4.
• foreignKeyReferences – Warns about foreign keys referencing non-unique or partial parent indexes.

If any precheck returns an error, the upgrade is automatically canceled and a detailed `upgrade-prechecks.log` file is generated with the specific objects and remediation steps. Warnings and notices allow the upgrade to proceed but should be reviewed and addressed. For the full list of prechecks and resolution guidance, see Precheck descriptions for upgrading Aurora MySQL version 3 to version 8.4 and Major version upgrade prechecks for Aurora MySQL.

Flexible upgrade and migration paths

Aurora MySQL 8.4 supports the full set of Aurora upgrade and migration paths, so you can adopt it in the way that best fits your workload, your downtime tolerance, and your existing topology. We aim to provide customers with a variety of upgrade mechanisms and a longer upgrade planning and implementation runway based on their business and technical objectives. Aurora MySQL 3 is supported under 30 April 2028 under standard support before RDS Extended Support coverage begins.

• Amazon RDS Blue/Green Deployments let you create a synchronized staging environment on Aurora MySQL 8.4 alongside your existing production cluster, validate the target, and switch over with minimal downtime. This is our recommended path for production workloads that require tight downtime windows.
• In-place major version upgrade lets you upgrade an existing Aurora MySQL 3.x cluster directly to Aurora MySQL 8.4 through the AWS Management Console, AWS Command Line Interface (AWS CLI), or Amazon RDS API.
• Snapshot restore allows you to restore a snapshot of an Aurora MySQL 3 cluster directly into Aurora MySQL 8.4, which is useful for creating isolated test environments or for migrating with a controlled cutover.
• AWS Database Migration Service (AWS DMS) is certified for Aurora MySQL 8.4 at general availability, supporting both full load and change data capture migrations from a wide range of sources.
• Physical migration with Percona XtraBackup is supported starting at general availability. If you run self managed MySQL or Percona Server for MySQL and need a faster, storage level non-blocking migration path for large workloads, you can use Percona XtraBackup to migrate directly onto Aurora MySQL 8.4, avoiding the performance overhead of logical migration.

Before upgrading, we recommend to reviewing application and operational changes called out in the previous section, validating the target in a non-production environment, and planning the upgrade during a maintenance window. For detailed guidance, see Upgrading Amazon Aurora MySQL DB clusters in the Amazon RDS User Guide.

How to get started

Aurora MySQL 8.4 is available in all AWS Regions where Amazon Aurora MySQL-Compatible Edition is supported. You can create and manage Aurora MySQL 8.4 clusters using the AWS Management Console, the AWS CLI, or the Amazon RDS API.

When you create a new Aurora MySQL cluster, select engine version 8.4.7 or higher. Aurora automatically launches you on the latest available patch for that minor. For step by step guidance, see Creating an Amazon Aurora DB cluster. For guidance on upgrading existing clusters, see Upgrading the major version of an Aurora MySQL DB cluster. For details on release timelines and availability for current and upcoming Aurora MySQL minors, see the Amazon Aurora MySQL release calendar.

To learn more about Amazon Aurora MySQL-Compatible Edition, visit the Aurora MySQL product page. For pricing, see Amazon Aurora pricing.

Conclusion

In this post, we discussed the general availability of Amazon Aurora MySQL 8.4 , our latest major version, compatible with community MySQL 8.4.7. This release aligns Aurora MySQL major versions with community MySQL Long Term Support releases going forward, bringing a simpler version mapping, predictable stability windows, a long support runway anchored to Oracle’s Lifetime Support Policy, and a clear cadence for future Aurora MySQL major versions. Aurora MySQL 8.4 also introduces a streamlined patch version experience aligned with Aurora PostgreSQL, strengthens default security with modern authentication, password policy controls, and TLS enforcement, and delivers the full community MySQL 8.4 payload on Aurora. You can adopt Aurora MySQL 8.4 using the migration and upgrade paths that best fit your workload, including Amazon RDS Blue/Green Deployments, in place major version upgrade, snapshot restore, AWS DMS, and Percona XtraBackup.

Get started with Aurora MySQL 8.4 today by creating a new cluster or planning an upgrade from your existing Aurora MySQL environment. For more information, see Working with Amazon Aurora MySQL.

About the authors