Since 1 August 2026, Amazon RDS for MySQL 8.0 instances have been billed for RDS Extended Support, and enrollment is the default for instances created through the AWS CLI, the RDS API, or CloudFormation. RDS standard support for MySQL 8.0 ended on 31 July 2026, three months after the community end of life on 30 April 2026. AWS did not stop or upgrade those instances. It enrolled them automatically, and a new line item appeared on the bill: a charge per vCPU per hour, on top of the instance price, that doubles on 1 August 2028. Multi-AZ standbys count too. This post shows how the charge is calculated, which instances pay it, what turning enrollment off does today, where Aurora MySQL version 3 stands, and how to reach MySQL 8.4 with a blue/green deployment.
- RDS for MySQL 8.0 left standard support on 31 July 2026. Extended Support year 1 pricing started on 1 August 2026, year 3 pricing starts on 1 August 2028, and Extended Support ends on 31 July 2029.
- The charge is vCPUs x hours x rate, for every 8.0 DB instance, including Multi-AZ standbys. For US East (N. Virginia), AWS lists USD 0.10 per vCPU-hour in years 1 and 2 and USD 0.20 in year 3 (read 9 November 2026; recheck before you budget).
- Turning enrollment off on an 8.0 instance today does not just stop the bill. AWS says the instance is then upgraded automatically to the next supported major version.
- Aurora MySQL version 3 (8.0-compatible) stays in Aurora standard support until 30 April 2028, so it carries no Extended Support charge yet.
- The charge stops when the instance runs 8.4 or is deleted. A blue/green deployment gets you there with a write pause limited to the switchover.
Scope and review date: November 2026. This post covers Amazon RDS for MySQL 8.0 DB instances (Single-AZ and Multi-AZ DB instance deployments) moving to RDS for MySQL 8.4, with a section on Aurora MySQL version 3. Dates, prices, and commands were checked against the Amazon RDS documentation, the Amazon RDS for MySQL pricing page, and the AWS Price List on 9 November 2026. The commands were not run in a lab, so rehearse them on a non-production instance first.
When did RDS for MySQL 8.0 Extended Support charges start?
On 1 August 2026. The RDS for MySQL version page publishes one row per major version, and the Extended Support charges page says billing begins the day after the RDS end of standard support date.
| Milestone | RDS for MySQL 8.0 | RDS for MySQL 8.4 |
|---|---|---|
| Community end of life | 30 April 2026 | 30 April 2029 |
| RDS end of standard support | 31 July 2026 | 31 July 2029 |
| Extended Support year 1 pricing starts | 1 August 2026 | 1 August 2029 |
| Extended Support year 3 pricing starts | 1 August 2028 | 1 August 2031 |
| RDS end of Extended Support | 31 July 2029 | 31 July 2032 |
The same page marks MySQL 8.0 as available only under RDS Extended Support. The last community 8.0 minor on RDS is 8.0.46. Since then, AWS builds its own: 8.0.46-RDS.20260624 (released 15 July 2026) and 8.0.46-RDS.20260908 (released 23 September 2026).
Support dates for the MySQL 8.0 major version
Illustrative output: the shape follows the AWS CLI reference, the dates follow the RDS release calendar
Missing date: this API returns the start and end of each support phase, but not the year 3 price step on 1 August 2028. That date is only in the release calendar.
How is RDS Extended Support for MySQL 8.0 priced?
Per vCPU per hour. The RDS for MySQL pricing page says: "For provisioned instances on RDS for MySQL, RDS Extended Support is priced per vCPU per hour." The rate depends on the MySQL version, the AWS Region, and the number of calendar years since standard support ended. The charge is added to the normal instance, storage, and I/O charges. It does not replace them.
- Standbys pay. AWS states that the charges "apply to standby instances in Multi-AZ deployments", so a Multi-AZ DB instance pays for twice its vCPUs.
- Read replicas are DB instances on 8.0 too. The docs do not name them separately, so confirm one replica's line item on your bill.
- Billing is per second, with a 10-minute minimum after a status change such as creating, starting, or modifying.
- Two things stop it: upgrading to a version in standard support, or deleting the database.
The rates for MySQL 8.0 in US East (N. Virginia), as published in the AWS Price List offer file for Amazon RDS (publication date 29 October 2026, effective date 1 October 2026):
# AWS Price List, AmazonRDS, us-east-1 (read 9 November 2026)
"USD 0.10 per hour per vCPU running RDS Extended Support for MySQL 8 in Year 1, Year 2"
"USD 0.20 per hour per vCPU running RDS Extended Support for MySQL 8 in Year 3"Interpretation: these are the AWS descriptions of the two price lines, quoted as published. On the same date, the pricing page's Extended Support table showed USD 0.100 and USD 0.200 per vCPU-hour for US East (N. Virginia). Its worked example is still written for MySQL 5.7. Rates differ by Region, so read yours from the page's Region selector.
Every USD figure in this post was copied from the AWS Price List and the RDS for MySQL pricing page for US East (N. Virginia) on 9 November 2026. AWS can change prices, and rates differ by Region. Confirm the current rate for your Region on the pricing page before you put a number in a budget or a business case.
RDS for MySQL 8.0: standard support and the two Extended Support price periods
Switch periods to see the date range, the US East (N. Virginia) rate, and what you get
Standard support
| Item | Standard support |
|---|---|
| Period | 23 October 2018 to 31 July 2026 |
| Extended Support charge | None |
| Fixes | Everything in each community minor release |
| At the end of the period | Enrolled instances move into Extended Support; instances with enrollment off are upgraded |
Extended Support, years 1 and 2
| Item | Extended Support, years 1 and 2 |
|---|---|
| Period | 1 August 2026 to 31 July 2028 |
| Extended Support charge | USD 0.10 per vCPU-hour (US East, N. Virginia, read 9 November 2026) |
| Fixes | Critical and high CVEs, and fixes for critical bugs |
| At the end of the period | The rate moves to year 3 pricing |
Extended Support, year 3
| Item | Extended Support, year 3 |
|---|---|
| Period | 1 August 2028 to 31 July 2029 |
| Extended Support charge | USD 0.20 per vCPU-hour (US East, N. Virginia, read 9 November 2026) |
| Fixes | Critical and high CVEs, and fixes for critical bugs |
| At the end of the period | RDS upgrades the major version automatically |
The fixes are narrower: the Extended Support overview lists critical and high CVEs and critical bug fixes. You pay more per hour for less change than a community minor release used to bring.
How do you estimate what your MySQL 8.0 fleet costs per month?
The monthly charge is the sum of vCPUs on every 8.0 DB instance (counting each Multi-AZ standby), times the hours in the month, times the rate for your Region and price year. This post uses 730 hours as an average month. Start with the inventory, one Region at a time:
aws rds describe-db-instances --region us-east-1 --output table \
--query "DBInstances[?Engine=='mysql' && starts_with(EngineVersion, '8.0')].[DBInstanceIdentifier, DBInstanceClass, EngineVersion, MultiAZ, ReadReplicaSourceDBInstanceIdentifier, EngineLifecycleSupport]"Interpretation: each row is one billed instance; rows with MultiAZ set to True count twice. open-source-rds-extended-support in the last column means the instance is enrolled. Take vCPU counts from the DB instance class hardware table.
A labelled example, not a quote
A db.r6g.xlarge (4 vCPUs in the AWS Price List) in US East (N. Virginia), at the rates above and 730 hours a month. These totals are arithmetic on published rates, not an AWS quote and not anyone's bill.
| Deployment (example) | vCPUs billed | Years 1 and 2, per month | Year 3, per month |
|---|---|---|---|
| Single-AZ | 4 | 4 x 730 x 0.10 = USD 292 | USD 584 |
| Multi-AZ DB instance (primary and standby) | 8 | USD 584 | USD 1,168 |
| Multi-AZ primary plus one Single-AZ read replica | 12 | USD 876 | USD 1,752 |
# vCPUs x hours x rate, for the third row in years 1 and 2
echo "12 * 730 * 0.10" | bcInterpretation: this prints 876.00. For scale, the same Price List shows the on-demand Single-AZ db.r6g.xlarge MySQL instance at USD 0.43 per hour, so USD 0.40 per hour of Extended Support almost doubles that instance's compute line.
Which instances are enrolled, and can you opt out now?
Expect most 8.0 instances to be enrolled, because enrollment is the default everywhere except the console. The create page for Extended Support says that in the console, "Enable RDS Extended Support" is not selected by default. With the AWS CLI or the RDS API, a create call that does not set it defaults to open-source-rds-extended-support. AWS says this default also applies to CloudFormation and other automation.
Opting out is no longer a free way to keep 8.0. With Extended Support disabled, "Amazon RDS upgrades your DB instance or Multi-AZ DB cluster to a supported engine version." The Extended Support overview adds that disabling enrollment on an instance already past its end of standard support date upgrades it automatically to the next supported major version.
# Do NOT run this on a production 8.0 instance as a cost fix.
# On 8.0 today it triggers an automatic major version upgrade.
aws rds modify-db-instance \
--db-instance-identifier mydb \
--engine-lifecycle-support open-source-rds-extended-support-disabledInterpretation: EngineLifecycleSupport is a valid ModifyDBInstance parameter for RDS for MySQL and PostgreSQL. On 8.0, the result is an upgrade you did not schedule, without the green environment, testing, or switchover control described below.
The disabled setting is still useful as a guardrail. AWS says that once the end of standard support date has passed, creating an instance with --engine-lifecycle-support open-source-rds-extended-support-disabled "will always fail". Set it in your infrastructure code, and nobody starts a new billed 8.0 instance by accident. On an 8.4 instance, the same flag means it is upgraded, not billed, when 8.4 leaves standard support in 2029.
The create page still says an enrolled instance is "permanently enrolled in RDS Extended Support for the life of the DB instance". The Extended Support overview and the ModifyDBInstance reference say you can change enrollment at any time. Either way, a change to disabled on 8.0 is a major version upgrade. Plan it as one.
Is Aurora MySQL version 3 paying Extended Support yet?
No. Aurora has its own calendar. The Aurora MySQL release calendar lists Aurora MySQL version 3, compatible with MySQL 8.0, with an Aurora end of standard support date of 30 April 2028. Extended Support year 1 pricing starts on 1 May 2028, there is no year 3 price step ("Not applicable"), and Extended Support ends on 31 July 2029.
- Minor versions end earlier. Aurora MySQL 3.04 (LTS) reached end of standard support on 31 October 2026, and 3.08 and 3.09 reached it on 31 August 2026. Version 3.10 (LTS) and 3.14 run to 30 April 2028.
- Aurora MySQL 8.4 is available. The calendar lists 8.4.7 (released 21 May 2026), 8.4.8, and 8.4.10 (released 26 October 2026).
aws rds describe-db-clusters --region us-east-1 --output table \
--query "DBClusters[?Engine=='aurora-mysql'].[DBClusterIdentifier, EngineVersion, EngineLifecycleSupport]"Interpretation: an engine version such as 8.0.mysql_aurora.3.04.x is on a minor version whose standard support ended on 31 October 2026. Plan a minor upgrade now, and the 8.4 move before May 2028.
For Aurora Serverless v2, the AWS Price List already carries an Extended Support line billed per ACU-hour instead of per vCPU-hour: "USD 0.085 per ACU-hour running Extended Support on Aurora Serverless v2 with MySQL 3 in Year 1, Year 2" (us-east-1, read 9 November 2026). It does not apply before 1 May 2028.
What blocks an RDS upgrade from MySQL 8.0 to 8.4?
RDS runs mandatory prechecks before it stops the instance. If one fails, RDS cancels the upgrade and writes the details to PrePatchCompatibility.log. The RDS major version upgrade page lists what they look for: obsolete data types or functions, triggers with a missing or invalid definer, names that collide with new reserved words, obsolete SQL modes, oversized ENUM or SET elements, foreign key names over 64 characters, and features removed in 8.4. Run the MySQL Shell upgrade checker yourself weeks earlier, so the findings land in a sprint and not in the maintenance window.
# From a host that can reach the instance. Use a MySQL Shell release
# at least as new as the target version.
mysqlsh -- util checkForServerUpgrade \
admin@mydb.abcdefghijkl.us-east-1.rds.amazonaws.com:3306 \
--target-version=8.4.11
# After a failed upgrade attempt, read the RDS precheck log
aws rds download-db-log-file-portion --db-instance-identifier mydb \
--log-file-name PrePatchCompatibility.log --output textInterpretation: fix every error the checker reports and review its warnings. RDS also empties the slow_log and general_log tables during a major version upgrade, so export them first if you need them.
Build a mysql8.4 parameter group on purpose
A custom 8.0 parameter group cannot be attached to 8.4. For a major upgrade with a non-default group, ModifyDBInstance requires a group from the new family. Create one in the mysql8.4 family and copy only the overrides you still mean, including your max_connections setting. Several InnoDB defaults changed: the AWS launch post for RDS for MySQL 8.4 lists innodb_adaptive_hash_index going from ON to OFF, innodb_change_buffering from ALL to NONE, innodb_io_capacity from 200 to 10000, and innodb_log_buffer_size from 16 MB to 64 MB.
aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.4 \
--output table \
--query "EngineDefaults.Parameters[?contains(['innodb_adaptive_hash_index','innodb_io_capacity','mysql_native_password','authentication_policy','max_connections'], ParameterName)].[ParameterName, ParameterValue, IsModifiable]"Interpretation: compare each default with the value in your 8.0 group. Where you carried an 8.0 override forward, decide again whether 8.4 still needs it.
Authentication, in one paragraph
RDS for MySQL 8.4 creates new users with caching_sha2_password, and the AWS launch post says existing users, including the primary user, keep mysql_native_password after an upgrade. Whether those accounts can still log in on 8.4 depends on the mysql_native_password parameter, and public reports disagree on its RDS default. Check it and authentication_policy with the query above, and test logins on green; error strings and the account migration are in MySQL 8.4 authentication errors and fixes.
-- On the 8.0 instance: accounts still on the old plugin
SELECT user, host FROM mysql.user
WHERE plugin = 'mysql_native_password'
ORDER BY user;Interpretation: every row is an account whose clients you should test against 8.4 on the green instance before switchover.
How does a blue/green upgrade from 8.0 to 8.4 work on RDS?
RDS copies your production instance (blue) into a staging copy (green), upgrades green to 8.4, and keeps it in sync with binary log replication. At switchover, RDS renames the green instance and its endpoints to the production names, so the application keeps its connection string. The blue/green create page lists one prerequisite for RDS for MySQL: automated backups must be on.
Blue/green upgrade from RDS for MySQL 8.0 to 8.4
Writes stay on 8.0 until step 3; the only write pause is the switchover
Billing during the overlap: green is a normal 8.4 instance billed at standard rates, and blue keeps paying Extended Support until you delete it. Keep the overlap short, but not shorter than your recovery window (see the runbook).
Check the blue/green limitations before you pick a date. Blue/green does not support a master password managed in AWS Secrets Manager, cascading or cross-Region read replicas, Multi-AZ DB cluster deployments, CloudFormation, or the AWS JDBC Driver for MySQL. event_scheduler must be off on green, and the blue instance cannot be an external binlog replica. With a custom option group, create the deployment first and upgrade green afterwards. With RDS Proxy, register blue with the proxy before you create the deployment.
What is the runbook from blue/green creation to deleting 8.0?
The switchover page describes what RDS does in step 6. It runs guardrail checks, stops new writes on both primaries, drops connections, waits for green to catch up, renames instances and endpoints, then allows writes on the new primary. The timeout is 30 to 3,600 seconds, with a default of 300. If it runs over, RDS rolls the switchover back and changes neither environment.
RDS for MySQL 8.0 to 8.4 with blue/green deployments
Eight steps; step 6 is the write pause
-
List valid 8.4 targets for your minor
Read the
ValidUpgradeTargetlist for the exact 8.0 version you run, and pick an 8.4 entry from it.aws rds describe-db-engine-versions \ --engine mysql \ --engine-version 8.0.46-RDS.20260908 \ --output json -
Clear the upgrade checker findings
Fix reserved word, definer, and removed feature errors on 8.0 while it serves traffic.
-
Create the mysql8.4 parameter group
Add back only the overrides you still need, then set
event_schedulerto OFF for green if you use it.aws rds create-db-parameter-group \ --db-parameter-group-name mydb-mysql84 \ --db-parameter-group-family mysql8.4 \ --description "mydb on MySQL 8.4" -
Create the blue/green deployment
Green is restored from a snapshot, upgraded, and replicates from blue. Blue keeps serving.
aws rds create-blue-green-deployment \ --blue-green-deployment-name mydb-to-84 \ --source arn:aws:rds:us-east-1:111122223333:db:mydb \ --target-engine-version 8.4.11 \ --target-db-parameter-group-name mydb-mysql84 -
Test green and wait for it to settle
Run read tests and client logins against the green endpoint. Wait for storage initialization to finish and
ReplicaLagto sit near zero. -
Switch over at low traffic
Writes pausedWrites stop and connections drop on both sides until green takes the production name. Keep client DNS TTL at 5 seconds or less.
aws rds switchover-blue-green-deployment \ --blue-green-deployment-identifier bgd-EXAMPLE \ --switchover-timeout 300 -
Verify production on 8.4
Confirm the engine version, the parameter group, application error rates, and replication to any external consumers.
aws rds describe-db-instances \ --db-instance-identifier mydb \ --query 'DBInstances[0].EngineVersion' -
Delete the old 8.0 instance
The renamed
mydb-old1keeps paying Extended Support while it exists. Delete it once your recovery window has passed.aws rds delete-db-instance \ --db-instance-identifier mydb-old1 \ --final-db-snapshot-identifier mydb-80-final
Rollback point: before step 6, delete the blue/green deployment and nothing changes. After step 6, replication stops and blue is read-only, so going back means setting read_only to 0 on mydb-old1, rebooting it, repointing clients, and losing writes made on 8.4.
AWS documents that PITR history does not carry over to the new production instance: its earliest restorable time is when green was created. Earlier recovery points need the old blue instance, restored by its DbiResourceId. That is why step 8 waits for your recovery window.
After switchover, repoint external binlog consumers using the coordinates RDS publishes in an event, recreate AWS DMS tasks, reattach IAM roles, and update anything that filters by resource ID, such as AWS Backup.
If blue/green does not fit, the in-place path is one command. AWS says major upgrades typically take about 10 minutes, with the instance unavailable. If the upgrade fails after the prechecks, RDS rolls back to 8.0 and logs the reason in upgradeFailure.log.
aws rds modify-db-instance --db-instance-identifier mydb \
--engine-version 8.4.11 --allow-major-version-upgrade \
--db-parameter-group-name mydb-mysql84 --apply-immediatelyInterpretation: without --apply-immediately, the change waits for the next maintenance window. Once 8.4 is running, the next hop is described in upgrading MySQL 8.4 LTS to 9.7 LTS, for when RDS offers 9.7 outside the Database Preview environment.
Frequently asked questions
Is RDS Extended Support for MySQL 8.0 charged automatically?
Yes, for enrolled instances. RDS standard support for MySQL 8.0 ended on 31 July 2026, and charges started on 1 August 2026. Instances created with the AWS CLI, the RDS API, or CloudFormation are enrolled by default. Instances created in the console are enrolled only if someone selected the Extended Support option. Check the EngineLifecycleSupport field in describe-db-instances.
How much does RDS Extended Support cost for MySQL 8.0?
It is billed per vCPU per hour on top of the instance price. On 9 November 2026, AWS listed USD 0.10 per vCPU-hour for years 1 and 2 and USD 0.20 for year 3 in US East (N. Virginia). A 4-vCPU Single-AZ instance at USD 0.10 comes to about USD 292 for a 730-hour month. Recheck your Region's rate on the AWS pricing page.
Can I turn off RDS Extended Support on a MySQL 8.0 instance?
You can set EngineLifecycleSupport to open-source-rds-extended-support-disabled. But AWS documents that disabling enrollment on an instance already past its end of standard support date upgrades it automatically to the next supported major version. For MySQL 8.0 that means an unplanned move to 8.4. Upgrade on your own schedule with a blue/green deployment instead.
Does Aurora MySQL version 3 have Extended Support charges in 2026?
No. Aurora MySQL version 3, which is compatible with MySQL 8.0, stays in Aurora standard support until 30 April 2028. Extended Support pricing for it starts on 1 May 2028 and ends on 31 July 2029. Individual minor versions end sooner. Aurora MySQL 3.04 LTS reached end of standard support on 31 October 2026.
Key takeaways
- RDS for MySQL 8.0 has been in paid Extended Support since 1 August 2026; the rate doubles on 1 August 2028, and support ends on 31 July 2029.
- Estimate the bill as vCPUs x hours x rate, counting Multi-AZ standbys and replicas, and recheck the rate for your Region on the AWS pricing page.
- Do not disable enrollment on a running 8.0 instance to save money: AWS then upgrades it to the next major version automatically.
- Aurora MySQL version 3 is not charged until 1 May 2028, but its 3.04, 3.08, and 3.09 minors are at or past end of standard support.
- Clear the 8.4 prechecks, build a mysql8.4 parameter group, upgrade with a blue/green deployment, and delete the old 8.0 instance after your recovery window.
Plan your RDS for MySQL 8.4 upgrade with JusDB
JusDB's Amazon RDS for MySQL team can review your 8.0 fleet, estimate the Extended Support charge from your instance list, and plan a blue/green upgrade to 8.4 with a rehearsed switchover and rollback.
Bring your instance inventory, parameter group overrides, client and driver versions, and your maintenance windows. Your team approves every production change.