Amazon Aurora MySQL 3.13 became GA, so I tried checking the version with the Data API
This page has been translated by machine translation. View original
Introduction
Amazon Aurora MySQL 3.13.0 was released on 2026-08-27 and became generally available. The compatible MySQL version is 8.0.45.
The differences from 3.12.0, the previous minor version, are as follows.
| Item | 3.12.0 | 3.13.0 |
|---|---|---|
| Compatible MySQL version | 8.0.44 | 8.0.45 |
| Release date | 2026-02-17 | 2026-08-27 |
Looking at the 3.13.0 release notes, there is no New features section. The overall content consists of Improvements and the incorporation of community edition bug fixes. The Improvements are broken down into four categories: security fixes, availability improvements, general improvements, and upgrades and migration.
The security fixes include one high-severity CVE-2026-46863 and five medium-severity issues. The availability improvements address restarts that occurred during partition operations, global database switchovers, and when Enhanced Binlog was enabled. In terms of performance, Aurora's physical replication now allows the reader side to apply writer changes using multiple threads.
This article launches a minimal cluster in ap-northeast-1 to verify the version, and organizes the support end dates based on the release calendar.
Verification
The following shows the results of running in ap-northeast-1 in order.
Checking Available Versions
First, I listed the Aurora MySQL engine versions available for selection in ap-northeast-1.
aws rds describe-db-engine-versions \
--region ap-northeast-1 \
--engine aurora-mysql \
--query 'DBEngineVersions[].{EngineVersion:EngineVersion,Status:Status,Major:MajorEngineVersion}'
An excerpt from the end of the output.
{
"EngineVersion": "8.0.mysql_aurora.3.12.0",
"Status": "available",
"Major": "8.0"
},
{
"EngineVersion": "8.0.mysql_aurora.3.13.0",
"Status": "available",
"Major": "8.0"
},
{
"EngineVersion": "8.4.mysql_aurora.8.4.7",
"Status": "available",
"Major": "8.4"
}
3.13.0 was returned as available. I then checked the default value when creating without specifying a version.
aws rds describe-db-engine-versions \
--region ap-northeast-1 \
--engine aurora-mysql \
--default-only \
--query 'DBEngineVersions[].{EngineVersion:EngineVersion,MajorEngineVersion:MajorEngineVersion}'
[
{
"EngineVersion": "8.0.mysql_aurora.3.10.3",
"MajorEngineVersion": "8.0"
}
]
3.10.3 was returned. According to the documentation, describe-db-engine-versions is a command that returns supported versions and the default version when creating a new instance. To use 3.13.0, you need to explicitly specify --engine-version at creation time.
Checking the Version with Data API
The RDS Data API limitations state "Data API isn't supported on T DB instance classes," so I chose db.serverless this time. In the Data API compatibility table, Aurora MySQL version 3 in Asia Pacific (Tokyo) is listed as "Version 3.07 and higher," which includes 3.13.0.
I created a DB subnet group, cluster, and DB instance in order with the following commands.
aws rds create-db-subnet-group --region ap-northeast-1 \
--db-subnet-group-name aurora313-verify-subnet-group \
--db-subnet-group-description "temporary subnet group for Aurora MySQL 3.13.0 verification" \
--subnet-ids subnet-xxxxxxxxxxxxxxxxx1 subnet-xxxxxxxxxxxxxxxxx2 subnet-xxxxxxxxxxxxxxxxx3
aws rds create-db-cluster --region ap-northeast-1 \
--db-cluster-identifier aurora313-verify \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.13.0 \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=8 \
--master-username admin \
--manage-master-user-password \
--db-subnet-group-name aurora313-verify-subnet-group \
--enable-http-endpoint \
--backup-retention-period 1 \
--no-deletion-protection
aws rds create-db-instance --region ap-northeast-1 \
--db-instance-identifier aurora313-verify-instance-1 \
--db-cluster-identifier aurora313-verify \
--db-instance-class db.serverless \
--engine aurora-mysql \
--no-publicly-accessible
The DB subnet group was created by specifying subnets in three availability zones within the same VPC. No security group was specified and the default was used, with public access disabled. Since the Data API is called via an HTTPS endpoint, no route connecting to the DB port was prepared.
From the time create-db-instance was executed until the status became available took approximately 8 minutes (15:27:10 → 15:35:19 JST) this time. The status transitioned in the order of creating, configuring-enhanced-monitoring, and available.
An excerpt of the cluster state after creation.
EngineVersion = 8.0.mysql_aurora.3.13.0
Status = available
HttpEndpointEnabled = True
ServerlessV2ScalingConfiguration = {'MinCapacity': 0.5, 'MaxCapacity': 8.0}
I retrieved the version information returned by the engine using the Data API. The secret ARN specifies the Secrets Manager secret created with --manage-master-user-password.
aws rds-data execute-statement --region ap-northeast-1 \
--resource-arn "arn:aws:rds:ap-northeast-1:123456789012:cluster:aurora313-verify" \
--secret-arn "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds!cluster-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-xxxxxx" \
--sql "SELECT @@version AS mysql_version, @@version_comment AS version_comment, aurora_version() AS aurora_version" \
--format-records-as JSON
{
"numberOfRecordsUpdated": 0,
"formattedRecords": "[{\"mysql_version\":\"8.0.45\",\"version_comment\":\"2410d24e\",\"aurora_version\":\"3.13.0\"}]"
}
Without using a MySQL client or a bastion host inside the VPC, I was able to retrieve the compatible MySQL version and Aurora version using only HTTPS API calls.
Checking Support End Dates
I checked the lifecycle by major version. According to the current information, standard support for Aurora MySQL 8.0 (version 3) ends on 2028-04-30.
Output of describe-db-major-engine-versions (8.0 section)
aws rds describe-db-major-engine-versions --region ap-northeast-1 --engine aurora-mysql
{
"Engine": "aurora-mysql",
"MajorEngineVersion": "8.0",
"SupportedEngineLifecycles": [
{
"LifecycleSupportName": "open-source-rds-standard-support",
"LifecycleSupportStartDate": "2021-11-18T00:00:00+00:00",
"LifecycleSupportEndDate": "2028-04-30T23:59:59.999000+00:00"
},
{
"LifecycleSupportName": "open-source-rds-extended-support",
"LifecycleSupportStartDate": "2028-05-01T00:00:00+00:00",
"LifecycleSupportEndDate": "2029-07-31T23:59:59.999000+00:00"
}
]
}
The end dates by minor version are published in the release calendar.
| Aurora MySQL Version | Compatible MySQL | Release Date | Standard Support End Date |
|---|---|---|---|
| 3.13 | 8.0.45 | 2026-08-27 | 2027-08-27 |
| 3.12 | 8.0.44 | 2026-02-17 | 2027-02-17 |
| 3.11 | 8.0.43 | 2025-11-13 | 2026-11-13 |
| 3.10 (LTS) | 8.0.42 | 2025-07-31 | 2028-04-30 |
| 3.09 | 8.0.40 | 2025-05-14 | 2026-08-31 |
| 3.08 | 8.0.39 | 2024-11-18 | 2026-08-31 |
| 3.04 (LTS) | 8.0.28 | 2023-07-31 | 2026-10-31 |
Details on LTS are summarized in the following documentation.
Summary
In Aurora MySQL version 3, version 3.13 has been released incorporating a new compatible MySQL version and fixes. If prioritizing total support period, LTS 3.10 is the candidate; if prioritizing the fixes introduced in 3.11 and later, 3.13 is the current candidate.
Standard support for RDS for MySQL 8.0 ended on 2026-07-31, and it is currently in the extended support period, which incurs additional costs.
If the cost of extended support is a concern and migration to 8.4 is also difficult, Aurora MySQL version 3 is worth considering. Since standard support continues until 2028-04-30, you can extend the period while remaining compatible with 8.0.
For compatibility between RDS for MySQL and Aurora MySQL, please refer to the official documentation.



