If you run Amazon RDS for MySQL 8.0, AWS moved you onto Extended Support on 1 August 2026 and started charging by the vCPU hour, on every instance, including staging, dev and the replicas nobody remembers. It is not a penalty and nothing is broken: AWS is charging to keep patching an engine version that left standard support. Upgrading is what makes it stop. Start with a free read-only check of your fleet.
Billed per instance.
RDS Extended Support is what AWS charges to keep shipping security patches for a major engine version after it leaves standard support. Enrolment is automatic, so there is no email you missed and no setting you forgot. The first most teams hear of it is the invoice.
AWS lists 31 July 2026 as the end of standard support for RDS for MySQL 8.0, with Extended Support year one pricing starting 1 August 2026. So the first affected invoice is the August bill, which most teams read in early September. MySQL 5.7 has been in Extended Support since March 2024 and moved to the higher year three rate on 1 March 2026.
Open Cost Explorer, set the range to this month, group by Usage Type, and filter for usage types containing ExtendedSupport. Whatever appears is what you are paying. It is worth doing before anything else, because the number is usually larger than the mental estimate and it is spread across more instances than expected.
The charge is per vCPU per hour on every enrolled instance, not once per account. Production is the one people think of. Staging, dev, the analytics replica and the read replica behind a reporting tool all bill at the same rate, and those are usually the instances nobody has looked at in a year. Fleets pay several times what the production instance alone would suggest.
PostgreSQL runs the same calendar. Versions 11, 12 and 13 are all in Extended Support today, with PostgreSQL 11 on the higher year three rate since 1 April 2026 and 13 billing since 1 March 2026. PostgreSQL 14 leaves standard support on 28 February 2027, so if you are on 14 this is a planning problem rather than a billing one, for now.
AWS publishes 0.100 dollars per vCPU-hour for years one and two, rising to 0.200 dollars from year three, using US East Ohio as the worked example. Rates depend on the engine version, the Region and how long the version has been out of standard support, so check the RDS pricing page for your own region.
| Instance | vCPUs | Year 1 to 2, per month | Year 3 onward, per month |
|---|---|---|---|
| db.r6g.large | 2 | About 146 dollars | About 292 dollars |
| db.r6g.xlarge | 4 | About 292 dollars | About 584 dollars |
| db.r6g.2xlarge | 8 | About 584 dollars | About 1,168 dollars |
| db.r6g.4xlarge | 16 | About 1,168 dollars | About 2,336 dollars |
This is the whole check. If it comes back clean, you are not affected and there is nothing to buy.
Open the RDS console and go to Databases. Add the Engine version column if it is not shown, and do this in every region and every account, not just the one you work in daily. Forgotten instances in a second region are common and they bill exactly the same.
Flag anything on MySQL 8.0 or 5.7, or PostgreSQL 11, 12 or 13. Those are in Extended Support now. Note anything on PostgreSQL 14 as a plan-ahead item, since its standard support ends 28 February 2027. Include replicas: they show as separate instances and bill separately.
Group by Usage Type and filter for usage types containing ExtendedSupport, over the current month. That gives you the real number rather than an estimate, broken down by instance so you can see which environments are contributing.
If the total is small and an upgrade is already scheduled, paying for a couple of months is a sensible trade. If it is significant, or you have no upgrade date in the calendar, that is when it is worth talking. If nothing appeared at either step, you are current and you can stop reading.
Nobody postponed a major version upgrade out of laziness. They postponed it because it can break things, and because the person who would test it is busy. That is the actual work, and it is what we take off your plate.
We check for deprecated syntax and removed features, compare parameter groups against the new version defaults, and review driver and ORM compatibility for your application. This is where surprises are supposed to surface, on a clone, not in production.
We restore a snapshot into a temporary instance, upgrade that, and exercise your application against it. It costs a little compute for a few days and it is the cheapest possible place to discover a broken query.
Staging goes first and stays on the new version long enough to be believed. Production follows in an agreed window, once staging has been quiet. No environment is upgraded on the same day it is tested.
We use RDS blue/green deployments where the engine supports it: a synchronised copy runs on the new version, and the switch happens in a short controlled window with the old environment still standing behind you if something looks wrong.
Read-only access, every RDS instance across your accounts and regions, engine versions listed, what Extended Support is costing you today, what it becomes at the year three rate, and a recommended upgrade order. No charge and no obligation. If you are already current, we say so and that is the end of it.
If you want the upgrades done, we scope them from the check and quote a fixed price with a written timeline. We share full pricing before any commitment. You can also take the report and do the work yourself, which is a completely reasonable outcome.
Extended Support fees on aging engines are one of the findings a broader AWS cost audit surfaces. If the RDS line is the symptom rather than the whole story, the audit is the better starting point and this check is one section of it.
Dates and rates here follow the AWS version calendars and the RDS pricing page. Check your own region, since rates vary.
A read-only look at every RDS instance you run, what Extended Support is costing you now, what it doubles to, and the order we would upgrade them in. Free, and genuinely useful even if you never hire us. If the check comes back clean, we will tell you that.
