What changed, and when
Amazon publishes a release calendar for every RDS engine, and the MySQL one has a column most people never read until it applies to them. For MySQL 8.0 it reads:
- Community end of life: 30 April 2026
- RDS end of standard support: 31 July 2026
- Start of Extended Support year 1 pricing: 1 August 2026
- Start of Extended Support year 3 pricing: 1 August 2028
- End of Extended Support: 31 July 2029
One day separates the end of standard support from the start of billing. That is not a grace period that ran out; there was never a gap.
MySQL 8.0 is finished upstream too
This is not AWS deciding to retire something the world still maintains. Oracle ended community support for MySQL 8.0 on 30 April 2026, and the AWS documentation notes plainly that "MySQL Community retired major version 8.0 and won't be releasing new minor versions."
What AWS ships instead is its own patched build. The Extended Support table lists 8.0.46-RDS.20260624, released on 15 July 2026, described as "a minor version that Amazon RDS released with critical security patches and bug fixes for MySQL 8.0 databases that are covered under RDS Extended Support". That is the substance of the charge: somebody is backporting security fixes to a version its own maintainer has stopped touching, and that work is not free.
Nobody has to agree to it
The mechanism is what makes this worth writing about rather than filing under routine deprecation. AWS is explicit:
If you enabled RDS Extended Support during the creation or restoration of a DB instance, then after the RDS end of standard support date, Amazon RDS will automatically enroll the DB instance in RDS Extended Support.
And, from the worked example in the same document, describing the 5.7 cutover:
Amazon RDS automatically enrolls your databases in RDS Extended Support on February 29, 2024, and you can continue to run RDS for MySQL version 5.7. Starting March 1, 2024, Amazon RDS automatically charges you for RDS Extended Support.
Why it is easy to miss
The sentence that explains the whole problem is this one:
Automatic enrolment into RDS Extended Support doesn't change the database engine and doesn't impact the uptime or performance of your DB instance.
Read as reassurance, it is reassuring, and it is also the reason the change is invisible. Nothing degrades. No connection drops. No query slows. No dashboard turns amber. An engineer looking at the database sees a database working exactly as it did on 31 July.
The change is real and it appears in one place only, which is the bill, and specifically in a line item nobody was watching because it did not exist the previous month. The people who monitor the database and the people who read the invoice are usually not the same people, and this change is visible only to the second group.
It is not a trap, and it is not an accident either
Worth being fair about this: continuing to run an unsupported database with security patches is a service, and it is a service AWS chose to offer rather than simply cutting people off. The alternative to Extended Support is not free support, it is a forced upgrade on AWS's schedule instead of yours.
But the default matters. Opt-out billing on a thing that shows no symptom is a design that reliably collects money from organisations that would have upgraded if anyone had noticed, and that is a different proposition from the same charge behind an opt-in.
The price goes up again in 2028
The calendar carries two pricing dates, not one, and the second is the one worth putting in a calendar of your own.
For MySQL 8.0, year 1 pricing started on 1 August 2026 and year 3 pricing starts on 1 August 2028. An instance nobody touches therefore gets more expensive twice: once this month, and again in two years, with no separate announcement because the date was published in advance.
MySQL 5.7 is the worked example, and it already happened
Anyone wanting to know what the second step feels like can look at 5.7, which is two years ahead on the same path. Its end of standard support was 29 February 2024, and its year 3 pricing date was 1 March 2026. That step change landed earlier this year.
It is also a useful reality check on how long these versions persist. MySQL 5.7 reached community end of life in October 2023, has been out of standard support on RDS since February 2024, and AWS is still shipping patched builds for it: 5.7.44-RDS.20260624 was released on 15 July 2026 with a CVE fix. Instances are still out there, still running, still being billed, more than two years after the deadline.
What the escalation is for
The rising price is doing a job. Backporting security fixes to an abandoned version gets harder and less justifiable the further it drifts from upstream, and a flat fee would let organisations sit on 5.7 indefinitely because inertia is cheaper than a migration. A staircase makes the arithmetic tip over eventually.
That is legitimate. It is also worth understanding, because the cost of doing nothing is not fixed, and a budget built on this year's Extended Support charge will be wrong in 2028.
The exit, and what it costs you
Unusually for this class of change, the escape is a parameter rather than a project. AWS documents it directly:
You can also change the enrollment status of an existing DB instance or DB cluster at any time by modifying the EngineLifecycleSupport parameter using the AWS CLI or RDS API. This change takes effect immediately with no downtime.
The consequence is the part to read twice:
If you disable the enrollment status of a DB instance or DB cluster that is already past its standard support end date, the instance or cluster automatically upgrades to the next supported major version.
So turning off the charge is the same action as upgrading
For a MySQL 8.0 instance the next supported major version is 8.4, and AWS supports 8.0 to 8.4 as a major version upgrade path. Flipping the parameter is not a way to keep 8.0 for free. It is a way to say "upgrade me now", and the upgrade happens.
That makes the decision cleaner than most, and more consequential. There is no third option where the database stays on 8.0 and stops costing extra.
Why 8.4 rather than a holding pattern
MySQL 8.4 is the current LTS on RDS and its runway is long: community end of life 30 April 2029, RDS end of standard support 31 July 2029. Moving there buys roughly three years before this conversation happens again, which is the point of moving to an LTS rather than to whatever is newest.
AWS also states plainly that major version upgrades "involve some compatibility risk" and "do not occur automatically; you must make a request to modify the DB instance". Its own recommended rehearsal is worth repeating because it costs almost nothing: take a snapshot, restore it to a new instance, upgrade the clone, and test against that before touching production.
The deadline behind the deadline
Extended Support is not indefinite. It runs for up to three years past the end of standard support, and after that:
if you haven't upgraded your major engine version to a supported version, then Amazon RDS will automatically upgrade your major engine version.
For MySQL 8.0 that outer limit is 31 July 2029. The choice is which of the three years you spend paying for, and whether the upgrade happens on a date you picked.
What to check this week
Four steps, in the order that resolves the most for the least effort.
1. Find out whether you are affected at all
List your RDS instances and their engine versions. Anything on MySQL 8.0 or 5.7 is being billed for Extended Support right now. AWS notes you can read the support dates programmatically as well as from the console, so this does not need to be a manual audit.
The instances most likely to be missed are the ones nobody thinks about: a reporting replica, a staging database that mirrors production, an instance behind a service whose original team has moved on. Those are exactly the workloads where an upgrade is low risk and the charge runs longest.
2. Look at the bill rather than the console
Extended Support appears as its own line. If you want to know what this is actually costing, that is where it is, and it is worth getting the number before deciding whether to act, because for a small instance the charge may be genuinely less than the engineering time to move.
That is a real answer, not a cop out. What makes it a bad answer is arriving at it by accident rather than by choosing it.
3. Decide per instance, not per fleet
A staging database can be upgraded on a Tuesday afternoon. A production database behind an application with MySQL-specific queries deserves the snapshot-and-clone rehearsal. Treating both the same is how a fleet ends up either upgraded recklessly or not at all.
4. Put 1 August 2028 in the calendar now
If the decision is to stay on Extended Support for a while, that is defensible, and the date the price steps up should be written down at the same time as the decision. The single most avoidable version of this story is an organisation that consciously accepted year 1 pricing and then met year 3 pricing by surprise.
The same shape as everything else this year
This is the third variation on one theme we have covered in a month, and the repetition is the story.
Microsoft is adding 5% to annual-term CSP software billed monthly from 1 October, applied at renewal, so the announced date is not the customer's date. Vendors across the market are retiring the plans people are actually on, with the migration triggered by a renewal or by a change the customer makes. And now a version deadline turns into a line item by automatic enrolment.
None of them is a price increase in the form organisations have a process for. Nobody sends a notice saying the product costs more. What changes is a term: a billing uplift for paying monthly, a plan that stops being sold, a support tier you are enrolled in because a date passed. Each is individually defensible and none of them shows up in a year-on-year comparison of what the product costs.
The defence is the same every time, and it is unglamorous. Know which of your own dates matter rather than the vendor's announcement dates. Know what unit you are billed in and whether that unit is still the one being sold. And check the invoice, not the dashboard, because the dashboard is where these changes are specifically designed not to appear.
Questions people ask
- Is my RDS MySQL 8.0 database being charged for Extended Support right now?
- If it is still on MySQL 8.0 and enrolment has not been disabled, yes. AWS lists 31 July 2026 as the RDS end of standard support date for MySQL 8.0 and 1 August 2026 as the start of Extended Support year 1 pricing, and enrolment after the end of standard support date is automatic. The database itself gives no sign: AWS states that automatic enrolment does not change the engine and does not affect uptime or performance.
- How do I stop paying for it?
- By modifying the EngineLifecycleSupport parameter through the AWS CLI or RDS API, which AWS says takes effect immediately with no downtime. Be clear about what that does though: on an instance already past its standard support date, disabling enrolment means the instance automatically upgrades to the next supported major version. There is no option where the database stays on 8.0 and stops costing extra.
- What version would my database be upgraded to?
- MySQL 8.4, which is the next supported major version and a documented upgrade path from 8.0 on RDS. It is the current LTS and its runway is long: community end of life 30 April 2029 and RDS end of standard support 31 July 2029, so moving there buys roughly three years.
- Does the price stay the same if I do nothing?
- No. The pricing is staged and the calendar carries two dates. For MySQL 8.0, year 1 pricing started on 1 August 2026 and year 3 pricing starts on 1 August 2028. MySQL 5.7 is the worked example of that second step, having reached its year 3 pricing date on 1 March 2026.
- Can I stay on Extended Support indefinitely?
- No. It runs for up to three years past the end of standard support, which for MySQL 8.0 means it ends on 31 July 2029, and AWS states that after that it will automatically upgrade your major engine version if you have not. The choice is which of those years you pay for and whether the upgrade happens on a date you chose.
- Is MySQL 5.7 still running anywhere?
- Evidently yes, and that is the useful signal. AWS released a patched 5.7 build, 5.7.44-RDS.20260624, on 15 July 2026 with a CVE fix, more than two years after 5.7 left standard support in February 2024. Vendors do not keep backporting security fixes to versions nobody is running.
Sources
Every price, limit and date above was checked against these pages on the day shown. Where a figure has since moved, the vendor’s own page is the authority and this one is a snapshot.
- 1Amazon RDS Extended Support · Amazon Web ServicesStates that RDS automatically enrols instances after the end of standard support date, that enrolment does not change the engine or affect uptime, that EngineLifecycleSupport can be modified at any time with no downtime, that disabling it past the standard support date triggers an automatic major version upgrade, and that Extended Support runs for up to three years before RDS upgrades the version itself.Checked
- 2MySQL on Amazon RDS versions, release calendar · Amazon Web ServicesCarries the dated release calendar: MySQL 8.0 end of standard support 31 July 2026, year 1 pricing 1 August 2026, year 3 pricing 1 August 2028, end of Extended Support 31 July 2029; MySQL 5.7 year 3 pricing 1 March 2026; MySQL 8.4 end of standard support 31 July 2029. Also records that MySQL Community retired 8.0 and lists the RDS-patched builds 8.0.46-RDS.20260624 and 5.7.44-RDS.20260624, both released 15 July 2026.Checked