Do Reserved Instances cover RDS Extended Support charges?

No. AWS states that RDS Extended Support charges are independent of instance charges, so Reserved Instance discounts are not applicable to them. A fleet at 100% RI coverage pays the Extended Support surcharge in full.

How do I find Extended Support charges in Cost Explorer?

Extended Support bills under the Amazon RDS service rather than as a separate service, so it does not appear as its own line. Group by Usage Type and filter for usage types containing ExtendedSupport.

What stops an RDS Extended Support charge?

On a running database there are exactly two actions: upgrade to an engine version covered under standard support, or delete the database. The enrolment flag itself can only be set when you create or restore an instance and cannot be changed on an existing one.

Does an EKS cluster enter extended support automatically?

Yes. The default cluster upgrade policy is EXTENDED, so a cluster crosses into extended support pricing with no user action. The control plane rate goes from $0.10 to $0.60 per cluster per hour.

Does upgrading RDS MySQL 8.0 to 8.4 buy more time?

Not much. RDS end of Extended Support for MySQL 8.0 is 31 July 2029, and RDS end of standard support for MySQL 8.4 is also 31 July 2029. Moving from 8.0 to 8.4 lands on the same date.

AWS Extended Support Charges: EKS, RDS and MySQL 8.0

There is a category of AWS charge that starts without anyone approving it, does not change anything you can see, and keeps running until someone does work. It is called Extended Support, and in 2026 three separate services crossed into it.

If you run EKS or RDS MySQL, at least one of these is almost certainly on the bill you are reading right now.

What Extended Support actually is

When an engine version reaches end of standard support, AWS does not switch it off. The database keeps serving traffic. The cluster keeps scheduling pods. What changes is that AWS starts charging you to keep patching software the upstream project has stopped maintaining.

For RDS, that fee buys security updates for critical and high severity CVEs, plus bug fixes and patches for critical issues. It is a real service, and for some teams it is worth paying for. The problem is not the fee. The problem is that it is opt-out, it is invisible in the place most people look, and the meter runs while you decide.

EKS: the control plane goes up 6x

EKS 1.33 reached end of standard support on 29 July 2026, and extended support billing started at the beginning of that day, UTC+0.

The control plane rate:

Standard support: $0.10 per cluster per hour
Extended support: $0.60 per cluster per hour

That is an extra $365 per cluster per month. To be precise about where that number comes from: AWS publishes the hourly rates, not the monthly total. ($0.60 - $0.10) x 730 hours = $365 is my arithmetic, using the standard 730-hour month.

The part that catches teams is the default. The default cluster upgrade policy is EXTENDED, which means a 1.33 cluster enters extended support pricing with no user action at all. Nobody clicked anything. The rate just changed.

Multiply by cluster count. A team running separate clusters for dev, staging and production pays it three times, and the dev cluster costs exactly as much in extended support as the production one.

RDS MySQL 5.7: the meter that doubled

MySQL 5.7 on RDS reached end of standard support on 29 February 2024, and Extended Support billing began on 1 March 2024. It has been running ever since on every 5.7 instance that stayed put.

On 1 March 2026, year 3 pricing kicked in and the rate doubled. Nobody touched the database.

For provisioned instances, Extended Support is priced per vCPU per hour, on top of instance, storage, backup and data transfer charges. It does not vary with database utilisation. The charge follows the CPU count, not the traffic, so an idle instance costs the same as a saturated one.

In US East (N. Virginia):

Years 1 and 2: $0.100 per vCPU-hour
Year 3 onward: $0.200 per vCPU-hour

Worked through on a db.r5.xlarge, which has 4 vCPUs. Again, the multiplication is mine, not AWS's:

Through Feb 2026: 4 x $0.100 x 730 hrs = $292/month
Since Mar 2026: 4 x $0.200 x 730 hrs = $584/month

One caveat on that arithmetic: 730 hours is the usual monthly convention (8760/12), not an AWS-published constant. A 31-day month is 744 hours and runs slightly higher.

There was a reprieve, and it is worth knowing about. AWS extended RDS Extended Support for MySQL 5.7 through 30 June 2029, out from 28 February 2027, with no price increase. Customers continue to pay year 3 pricing through that date. So the $0.200 rate holds until June 2029. That is more runway than most people think they have, at a rate most people have not noticed they are paying.

RDS MySQL 8.0: started 1 August 2026

This is the newest one, and it is the reason to check this month rather than next quarter.

RDS MySQL 8.0 reached end of standard support on 31 July 2026. AWS documents that charges begin the day after the end of standard support date, which makes 1 August 2026 the first billable day. If you are still running an 8.0 instance, that charge is on your current bill.

There is no version of 8.0 you can move to that avoids it. Minor versions 8.0.42 through 8.0.46 all reached end of standard support on the same date, and MySQL Community has retired major version 8.0 entirely and will not release new minor versions.

This is what the fee actually buys: patches now ship as RDS-branded minors. Version 8.0.46-RDS.20260624 was released on 15 July 2026 and fixes CVE-2026-46863. Without Extended Support, that fix does not reach you, because upstream is not producing it.

One planning problem: as of 6 August 2026, AWS publishes no per-vCPU-hour Extended Support rate for MySQL 8.0. The MySQL pricing page carries only the 5.7 worked example. You can see the charge on your bill, but there is no published rate to forecast from before it lands.

The four things all of these share

Different services, same shape. This is the pattern worth internalising:

It defaults to on. EKS clusters default to the EXTENDED upgrade policy. RDS instances enrol unless you set the flag at create time. Inaction is the expensive path.
Commitments do not cover it. AWS is explicit: RDS Extended Support charges are independent of instance charges, therefore Reserved Instance discounts are not applicable. You can have an instance price locked for three years and this surcharge still lands in full, outside the reservation.
It multiplies across replicas. Extended Support charges apply to primary instances, read replicas, and all standbys in Multi-AZ deployments, each at its own full vCPU count. That db.r5.xlarge in Multi-AZ is billed for 8 vCPUs, not 4. Primary has 4, standby has 4, and the standby serves no traffic.
Nothing about the resource changed. Same instance size, same storage, same traffic, same everything. That is precisely why it survives a glance at the bill.

How to actually find it

Extended Support does not bill as a separate service. It bills under Amazon RDS, as its own usage type. In Cost Explorer the RDS row simply goes up by the full amount, which is why a month-over-month service-level review misses it.

Group by Usage Type and filter for anything containing ExtendedSupport. Rows there mean you are paying it. If you have never looked, look before you finish reading.

The two exits, and the flag that does not work how you would expect

On a running database there are exactly two actions that stop the charge: upgrade to an engine version covered under standard support, or delete the database. There is no third option and no support ticket that turns it off.

The enrolment setting is not a toggle. Extended Support enrolment can only be set when you first create or restore a DB instance, and cannot be updated on an existing instance.

The console and your IaC default opposite ways

This is the detail that decides whether you are paying, and it is the one I see missed most often.

In the console, the Enable RDS Extended Support setting is not selected by default. You tick a box to enrol.

In the AWS CLI, the RDS API and CloudFormation, the same setting defaults to enabled when left unspecified. Terraform's aws_db_instance defaults engine_lifecycle_support to open-source-rds-extended-support, and CDK synthesises to CloudFormation, so both inherit the enabled-by-default behaviour.

So if you clicked through the console, you are probably not enrolled. If Terraform or CDK created the instance, you probably are. Same engine version, opposite billing outcome, decided by which tool provisioned it, often years ago, by someone who never saw the setting.

And since enrolment cannot be changed on a running instance, that decision is already locked for every database you currently operate. The only thing left to do is find out which branch you are on.

What the disabled branch actually costs

Not being enrolled is not free of consequences. With Extended Support disabled, Amazon RDS upgrades the DB instance to a supported engine version on or shortly after the RDS end of standard support date.

So the two branches are: pay the per-vCPU meter, or take an unscheduled engine upgrade on a production database on a date AWS chooses. After 31 July 2026 no 8.0 minor version remains under standard support, so in practice that is a major version upgrade. That last step is my inference rather than an AWS quote: the AWS table says only "a supported engine version", and 8.0 to 8.4 is the documented major upgrade path.

Neither branch is a good surprise. Knowing which one you are on is what lets you schedule the upgrade rather than receive it.

And restoring with it disabled does not do what the name suggests. Restoring with open-source-rds-extended-support-disabled makes RDS attempt to automatically upgrade the restored database to a newer supported major version, rolling back to the Extended Support version if pre-upgrade checks fail. It dodges the fee by doing the upgrade, not by skipping it. If you were not ready for a major version upgrade, you are not ready for this either.

The 8.4 trap

If you are planning the escape from 8.0, check the dates before you pick a target.

RDS end of Extended Support for MySQL 8.0 is 31 July 2029. RDS end of standard support for MySQL 8.4 is also 31 July 2029. Moving from 8.0 to 8.4 buys you a supported engine today, but it lands you on exactly the same cliff.

And if you have not upgraded by the end of the Extended Support window, AWS documents that RDS will automatically upgrade your major engine version for you. An unattended major version upgrade on a production database, on a date chosen by your provider, is a worse outcome than a planned one.

What I would actually do

I have put off a version upgrade too, on systems that were working fine. That is a defensible call right up until you notice it has been running a meter the whole time.

The order I would work in:

Open Cost Explorer, group by usage type, filter for ExtendedSupport. Find out whether this is hypothetical or already costing you.
List EKS clusters by version. Non-production clusters on old versions are pure waste at $0.60 per hour, and they are usually the easiest thing in the estate to upgrade.
Count vCPUs, not instances, and remember to count standbys and read replicas. The Multi-AZ doubling is where the forecast usually goes wrong.
Pick upgrade targets by end-of-support date, not by version number. 8.4 is the obvious next step and it expires the same day 8.0 does.

None of this is a trick or a billing error. AWS documents all of it. It just sits in the gap between the team that picked the engine version and the person who reads the invoice, and that gap is where most cloud spend goes to die.

Sources

Every figure above comes from AWS documentation, checked on the dates noted. Monthly totals are my arithmetic on AWS's published hourly rates and are marked as such in the text.

AWS Extended Support: The Charge Nobody Approved