RDS MySQL 8.0 Leaves Standard Support in July and AWS Auto-Enrolls You Into a Paid Bill

The change and the date

Amazon RDS for MySQL 8.0 reaches its RDS end of standard support date on July 31, 2026. Starting the next day, August 1, 2026, AWS automatically enrolls any RDS instance still running the 8.0 major version into paid RDS Extended Support, billed as a per vCPU-hour surcharge on top of your normal instance cost. This is not an outage and not a forced engine change: your database keeps running on 8.0. What changes is the bill, quietly, on the first invoice after the cutover. The supported in-place upgrade path off 8.0 is to MySQL 8.4, and the window to do it without paying the surcharge closes on July 31.

The mechanism here mirrors what happened with RDS for MySQL 5.7, whose RDS end of standard support date was February 29, 2024 with Extended Support charges starting March 1, 2024. It is the same paid-runway model AWS now applies across its open-source engines. If that pattern feels familiar from the Kubernetes world, it is the same playbook we covered in the EKS 1.33 extended support cost jump: keep running the old version, but pay a premium for the privilege.

Who is hit hardest

The teams most exposed are the ones who never disabled the option. Per the AWS documentation, after the RDS end of standard support date, if you did not disable RDS Extended Support during creation or restoration of the instance, Amazon RDS automatically enrolls it. The opt-out is a create-time or restore-time choice: you set open-source-rds-extended-support-disabled on the --engine-lifecycle-support option (or the LifeCycleSupport API parameter). Most fleets created over the past several years did not set that flag, because it was not the kind of thing anyone thought about. So the realistic exposure is broad: any RDS for MySQL instance still pinned to an 8.0 minor version on August 1.

The cost stings more than a single instance suggests, for two reasons. First, the surcharge is billed per vCPU-hour, so it scales with vCPU count and instance size, not with a flat per-database fee. A fleet of large multi-vCPU instances accrues the charge fast. Second, AWS states that Extended Support charges apply to the standby in a Multi-AZ deployment, so a Multi-AZ instance is charged on both nodes. Any other instances still on 8.0, including read replicas, are separately billable in the same way. A modest-looking per-hour number multiplies across vCPUs, standbys, and the full set of databases in an account.

The failure mode in plain terms

There is no error, no alarm, and no downtime. That is exactly what makes this a trap. On July 31 everything works; on August 1 everything still works, and a new line item starts accruing per vCPU-hour against every 8.0 instance you did not upgrade or opt out of. The first time most teams notice is the Cost Explorer anomaly or the monthly invoice, by which point the surcharge has already been running for days or weeks.

There is a second, slower failure mode worth naming. AWS documents that Extended Support is bounded: it runs for up to three years past end of standard support, with RDS for MySQL 8.0 Extended Support ending July 31, 2029. The pricing is also tiered: AWS lists a year-1 price starting August 1, 2026 and a higher year-3 price starting August 1, 2028. So the cost is not flat, it steps up the longer you defer. And at the end of the Extended Support window, AWS will automatically upgrade an instance still on the old major version, on its schedule rather than yours, which is the one upgrade timing a production team never wants to cede.

What to do before July 31

The clean fix is to get off 8.0 before the date. The supported in-place path is an upgrade from MySQL 8.0 to MySQL 8.4 (AWS labels the target simply MySQL 8.4). A pragmatic readiness sequence:

• Inventory every RDS for MySQL instance, replica, and Multi-AZ standby still on an 8.0 minor version, across all accounts and regions. Do not trust memory; query it with the RDS API or CLI.
• Confirm the engine lifecycle support setting on each instance so you know which ones would auto-enroll versus which were created with the disabled flag.
• Test the 8.0 to 8.4 upgrade on a snapshot-restored clone first. MySQL 8.4 changes some defaults and removes deprecated configuration, so validate application compatibility, parameter groups, and any deprecated variables before touching production.
• Check replication topology and any external replicas, since a major version upgrade affects binlog and replica compatibility.
• Schedule the production upgrade inside a maintenance window with a tested rollback (a pre-upgrade snapshot), well ahead of July 31 rather than on the deadline.
• If you genuinely need to stay on 8.0 past the date, make that a deliberate decision: budget the per vCPU-hour surcharge and the year-3 step-up explicitly, rather than discovering it on an invoice.

One honest caveat

Two clarifications so we do not overstate this. First, scope: this applies to Amazon RDS for MySQL only. Aurora MySQL has its own version lifecycle and its own end-of-standard-support timeline, so an Aurora MySQL fleet is not governed by the July 31, 2026 RDS date and should be checked separately against Aurora's calendar. Second, this is a cost and governance event, not a reliability cliff. Your database does not stop working on August 1, and Extended Support continues to deliver security updates for critical and high CVEs plus bug fixes and patches for critical issues on the old version. If a small instance must stay on 8.0 for a few weeks while you finish testing, the surcharge is a manageable, bounded cost, not an emergency. The point is to make that a choice, not a surprise.

How a senior team de-risks this

The senior move is to treat engine end-of-life as a scheduled, owned event rather than a billing ambush. That means a tracked inventory of every managed-database version with its end-of-standard-support date, a tested upgrade runbook validated on a clone before production, and a cost guardrail (a budget alert or anomaly detector) that catches an Extended Support line item the moment it appears. Done well, the upgrade lands in a planned window weeks before the deadline and the surcharge never accrues at all. That lifecycle discipline, applied consistently across RDS, Aurora, EKS, and the rest of the managed-service estate, is exactly the ongoing work of AWS cloud management: knowing what is aging out, when, and what it costs to do nothing.

Sources

• Amazon RDS for MySQL version management and major-version support calendar
• Amazon RDS Extended Support (User Guide)
• Overview of Amazon RDS Extended Support (automatic enrollment behavior)
• Amazon RDS Extended Support charges
• Amazon RDS for MySQL pricing