RDS has been charging extra for MySQL 8.0 since August

CODELEVEL - Jacob Binczyk — Thu, 08 Oct 2026 13:27:27 +0000

Standard support for MySQL 8.0 on RDS ended on 31 July 2026. Since 1 August AWS has been adding an Extended Support charge to every such database that has it enabled. The API, the CLI and Terraform enable it by default; in the console you have to tick it. The charge is already on your August and September bills.

If you run MySQL 8.0, move it to 8.4, which has standard support until 31 July 2029. Aurora MySQL 3, the 8.0-compatible line, has standard support until 30 April 2028, so there is no surcharge there yet.

What Extended Support costs

In Frankfurt, the AWS price list on 6 October 2026 gives $0.122 per vCPU-hour for the first two years, which is about $89 a month for each vCPU. From 1 August 2028 the rate doubles to $0.244. A Multi-AZ database keeps a standby copy in a second zone, and AWS charges for that standby too, so you pay twice as much.

Take a db.m6g.large in Multi-AZ, with 2 vCPUs. The instance alone costs about $264 a month in Frankfurt, and Extended Support adds $356 on top. For August and September AWS has already added about $714 to that database.

The chart for this part is in the original post.
Reserved Instances won't reduce the surcharge, because RI discounts don't apply to Extended Support.

Where it shows on the bill

Extended Support is a separate line item on the bill, next to instance hours and storage. In Cost Explorer, type ExtendedSupport into the Usage Type filter and select every result. The Frankfurt usage type for MySQL 8.0 is EUC1-ExtendedSupport:Yr1-Yr2:MySQL8.0.

The same filter catches databases on older versions too. MySQL 5.7 has been billed at the year-three rate since 1 March 2026. You can also load a Cost Explorer export grouped by usage type into the CSV analysis, which lists the largest items on the bill.

To see which databases you are paying for, run this command in each region:

aws rds describe-db-instances --region eu-central-1 \
  --query "DBInstances[?Engine=='mysql'].[
    DBInstanceIdentifier,
    EngineVersion, MultiAZ,
    EngineLifecycleSupport]" \
  --output table

Any 8.0.x row with open-source-rds-extended-support in the last column is a database you are paying the surcharge on.

Switching it off means an upgrade

You can change EngineLifecycleSupport at any time. But if you disable Extended Support on an 8.0 database, RDS upgrades it automatically to the next supported version, 8.4, whether or not you have tested the application on it. The charge stops once the database reaches a supported version. I described the same mechanism for PostgreSQL 14, where the deadline is still ahead.

How to move to 8.4

The target is 8.4, because newer MySQL versions are only available on RDS in the Database Preview environment, which AWS does not allow for production.

AWS recommends a blue/green deployment. RDS builds a copy of the database and replicates production changes into it, and you upgrade the copy to 8.4 and test the application against it. The copy is read-only and should stay that way, because writes to it break replication and can end up in production after the switch-over. Run tests that write against a database restored from a snapshot.

The switch-over itself usually takes under a minute. Afterwards the old database stays as …-old1, still on 8.0, and AWS keeps charging for the instance and for Extended Support. Delete it once you no longer need a way back.

An in-place upgrade takes about 10 minutes, and the database is down for that time. The documentation describes no way back to 8.0 after a successful upgrade.

On the copy, read PrePatchCompatibility.log: RDS runs prechecks before it stops the database and cancels the upgrade if any of them fail. Then check the changes listed in AWS's announcement of MySQL 8.4 on RDS:

New users in 8.4 get the caching_sha2_password plugin by default, while existing ones keep mysql_native_password. Make sure the application can connect with an account created after the upgrade.
restrict_fk_on_non_standard_key is on by default and stops you creating foreign keys built on non-unique or partial keys. Check that your schema migrations don't create any.
The old replication statements are syntax errors in 8.4, so in scripts and monitoring replace SHOW MASTER STATUS with SHOW BINARY LOG STATUS.
Compare the timing of your heaviest queries, because 8.4 changes InnoDB defaults.

When to do it

Ideally in October 2026. On the example db.m6g.large, every month of delay costs about $356. If the account has several 8.0 databases, start with the largest by vCPU count, standby included, since the charge scales with it.

Move anything on Aurora MySQL 3 to Aurora MySQL 8.4 during 2027, ahead of the 30 April 2028 deadline.