RDS for MySQL 8.0 Extended Support Is Expensive: Upgrade to 8.4 LTS with Blue/Green Before Standard Support Ends

Introduction: RDS Extended Support Is Expensive

One day, an email arrives from AWS to the effect of "Your AWS account has RDS for MySQL 8.0 instances." In short, the announcement says that MySQL 8.0 reached community EOL in April 2026, standard support on RDS ends on July 31, 2026, and after that your instances are automatically enrolled in Extended Support, which incurs additional charges billed per vCPU-hour.

The worst thing you can do with this email is put it off, thinking "I'll get to it eventually." The Extended Support fee is a pure add-on on top of your regular instance and storage charges, and it's not a small amount.

The Extended Support fee is many times the instance cost itself (Tokyo, estimated)This is the part that's easy to miss. For example, a db.t3.micro (2 vCPU) costs about $0.025 per hour, but the Extended Support fee is 2 vCPU × $0.12 = $0.24/hour: nearly 10 times the instance cost on top (per month, that's about ¥28,000 / +$175 in Extended Support versus about ¥3,000 for the instance). It's a pure add-on, separate from your regular instance and storage charges.And it scales with the number of instances. If you run three instances, that's +$526/month in total (about ¥84,000). Leave it for three years and it adds up to about $25,200 (about ¥4 million) in pure extra cost (see the cost section later for the calculation). On top of that, if you run Multi-AZ for redundancy, the standby is billed too, so it's "doubled." The more properly you've built HA in production, the heavier the burden.What's more, billing starts immediately on August 1. There's no grace period where "it'll be fine for a while after support ends." All too often, people only notice when the next month's bill arrives. With an "I'll do it eventually" attitude, you'll forget the deadline and sail past August 1. The right move is to treat EOL work as a task with a hard deadline and get it done early, within the standard support period (by July 31).

At MOOBON, three of the production RDS instances we operate (MySQL 8.0.44) were affected. That's exactly why we decided to upgrade all of them to 8.4 LTS with plenty of time to spare before the deadline.

Upgrade Overview

Here's a summary of what we did in this article up front. The details are covered in the sections that follow.

Target version	MySQL 8.0.44 → 8.4.9. For production, we chose the 8.4 LTS (community support lasts until April 2032; 9.x is an Innovation Release updated on a short cycle, making it unsuitable for production). Of the available upgrade targets from 8.0.44, 8.4.3–8.4.9, we picked the latest minor, 8.4.9.
Upgrade method	Blue/Green Deployments. AWS temporarily sets up managed logical replication, prepares an upgraded copy (Green), and then switches production over to it. This avoids an in-place major upgrade (tens of minutes of downtime).
Downtime	Only a brief interruption during switchover (typically under one minute). The endpoint name is preserved, so no changes to application connection settings are needed. It's not completely zero downtime: existing connections drop at the moment of switchover and reconnect.

What Are Blue/Green Deployments?

If you upgrade RDS the usual way, by changing the DB engine version in the settings, the instance is rewritten in place, which means roughly 10 to 30 minutes of downtime, and once you make the change there's no going back.

Blue/Green is an approach that keeps downtime to a minimum (under one minute). The steps are as follows:

① Copy	Green is created as a read replica of the current environment (Blue). It's first cloned on the same 8.0 version, and Blue → Green replication is set up.
② Upgrade to 8.4	Then only Green is upgraded to 8.4.9. Even after the upgrade, Green keeps replicating from Blue (8.0) (lower-to-higher version replication).
③ Validate	Validate Green without affecting production (version, authentication, replication lag, representative queries).
④ Switch	Once replication has caught up, perform the switchover. Green is promoted to production and the endpoint name is preserved (no need to change application connection settings).

A brief interruption, not zero downtime: switchover isn't completely non-disruptive. It involves confirming zero replication lag → briefly pausing writes → reassigning the endpoint. The benefit is that what used to take more than ten minutes shrinks to an interruption of tens of seconds to under a minute.

Trivia: why Blue = current and Green = new?
Blue/Green originally comes from a software release technique (popularized around 2010 in the context of Continuous Delivery). The colors Blue and Green were chosen as neutral labels that don't imply which one is the "real" environment. And the assignment "Blue = current (production), Green = the newly prepared environment" isn't a technical necessity but a convention; many tools assign them this way, and AWS RDS adopts the same definition.

Preparation: binlog_format, an 8.4 Parameter Group, and Authentication

① Set binlog_format to ROW

Because Blue/Green relies on replication, binlog_format = ROW is required. The RDS engine default is MIXED, so you explicitly set it to ROW in a custom DB parameter group. Rest assured, this is a dynamic parameter, so the RDS instance does not reboot.

aws rds modify-db-parameter-group \
  --db-parameter-group-name <your-pg> \
  --parameters "ParameterName=binlog_format,ParameterValue=ROW,ApplyMethod=immediate"

# after it takes effect, check the effective value on each instance
#   SHOW VARIABLES LIKE 'binlog_format';  -> ROW

② Prepare a parameter group for the target version (8.4)

Green (the secondary) uses an 8.4-family parameter group, so create a new one and set binlog_format=ROW in it. You specify it with --target-db-parameter-group-name when creating the Blue/Green deployment.

③ Authentication (mysql_native_password) can be left alone

We were wary of reports that "mysql_native_password is disabled in 8.4," but we confirmed in a real environment that in RDS for MySQL 8.4 parameter groups, mysql_native_password is fixed to ON (not modifiable). Vanilla MySQL 8.4 defaults to OFF, but RDS keeps it ON for compatibility.

What we learned in practice: the RDS parameter group had mysql_native_password=ON fixed. As a result, DB users previously created with mysql_native authentication could still connect as is after the upgrade (8.4).

④ Take a protective snapshot

Just in case something goes wrong, take a manual snapshot before the switchover work.

The Main Work: Creating the Blue/Green Deployment and Validating Green

Once preparation is done, create the Blue/Green deployment to build Green (the secondary) and validate it without affecting production.

① Create the Blue/Green deployment

Create it by specifying the source (Blue) ARN, the target engine version (8.4.9), and the 8.4 parameter group.

aws rds create-blue-green-deployment \
  --blue-green-deployment-name <name>-84-bg \
  --source <source-db-arn> \
  --target-engine-version 8.4.9 \
  --target-db-parameter-group-name <8.4-parameter-group>

Database list in the RDS console. Under the Blue/Green deployment, the primary (Blue) DB shows Available and the secondary (Green) DB shows Modifying, indicating that the Green upgrade is in progress — Figure: The RDS console while the Blue/Green deployment is being created. **Blue (primary) stays "Available" and keeps serving production**, while **Green (secondary) is "Modifying"**: the upgrade to 8.4.9 is in progress.

Once you submit the create request, a structure like the one shown above is created:

Container (top row): the name of the Blue/Green deployment you specified
Blue: the existing RDS instance you were already using (production)
Green: a new instance launched as the replication secondary

Wait for Green's replication to complete.
Green's version is upgraded (traffic is still pointed at Blue, so production isn't affected).
Backups are configured for Green, and the overall deployment status becomes "Available (AVAILABLE)."

Because it includes establishing replication and performing the upgrade, this is the most time-consuming step of the entire migration (about 20 to 40 minutes overall). While it's being created, the status shows "Provisioning."

② Validate Green (no impact on production)

Once Green is on 8.4.9 and "Available," connect directly to Green's endpoint and check its contents. Production is still running on Blue, so if you find any issues, you can deal with them calmly. Here's what we checked:

SELECT VERSION(); returns 8.4.9 and binlog_format is ROW
Existing users can connect with native authentication unchanged (RDS keeps it even on 8.4; see Preparation ③)
All tables are InnoDB (no MyISAM left over)
Zero replication lag (Seconds_Behind_Source = 0 in SHOW REPLICA STATUS, with both IO/SQL threads showing Yes)
Row counts for key tables match Blue

Switchover (Promoting the Secondary to Primary)

Once Green is "Available" on 8.4.9 and validation has passed (version, authentication, all tables InnoDB, zero replication lag, matching row counts), run the switchover. It's safer to set a wait time for replication to catch up with --switchover-timeout.

aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier <bgd-id> \
  --switchover-timeout 300
# Status: SWITCHOVER_IN_PROGRESS -> SWITCHOVER_COMPLETED

⚠ Downtime begins the moment you run this command (under one minute)This is the only point in the migration that affects production. AWS confirms zero replication lag → briefly pauses writes → reassigns the endpoint to Green, so at that moment existing connections drop and reconnect (typically under one minute). The endpoint name doesn't change, so there's no need to update application connection settings. It's safest to run it during a low-traffic window.

Measured: "under one minute of downtime" felt like a 13-second wait (added 2026-06-10)In our environment, a page being accessed at the moment of switchover waited about 13 seconds and then rendered normally. No error page appeared, and the login session wasn't lost. "Downtime" conjures up images of error pages, but in reality, our takeaway is that end users may experience it as nothing more than "a moment where things got slow."

Why doesn't it result in errors even though connections are being dropped? This is a useful point for getting things straight in your head, so let's dig in. Two conditions need to hold.

① The switchover is shorter than every timeout along the request path. Requests made during the switchover "hang" while waiting for a DB response, but as long as they don't hit the load balancer's idle timeout (60 seconds by default on ALB), the web server's proxy timeout (60 seconds by default on nginx), or the application's execution time limit, they complete after the wait. The 13 seconds we saw was well below every one of these timeouts, so the result was "slow but successful." Conversely, if the switchover had taken more than 60 seconds, some layer would have returned a 504 or similar.
② Dropped connections can be recovered by reconnecting. During switchover, RDS forcibly closes existing connections. Requests that hit the switchover while acquiring a connection get connected after it completes, thanks to the pool reconnecting (which is what happened in our case). On the other hand, requests that are cut off mid-query can fail with a connection error; this is the case the FAQ refers to as "about one request's worth failing." If your driver or connection pool supports retries, this can be absorbed as well.

Whether login sessions are lost depends on where sessions are stored. If they live in cookies or Redis, they have nothing to do with the RDS switchover, and even if they're stored in a sessions table in the DB, the records have already been replicated to Green, so the switchover doesn't wipe them. When a session "appears to have been lost," it's because the session-loading query failed during the switchover window and the application treated the user as logged out; the DB upgrade itself doesn't invalidate sessions.

After the switchover, the endpoint points to the new production instance (8.4.9). Here's what we checked:

SELECT VERSION(); returns 8.4.9, and the endpoint name is preserved
Each application connects to the new DB and responds (login, key screens, representative writes)
No new anomalies in the slow query log or error log. 8.4 changes some optimizer behavior, so watch for worse plans on heavy listing and search queries

Three Easy-to-Miss Pitfalls

That covers the migration flow. Finally, here are three pitfalls that are easy to overlook when upgrading with Blue/Green. None of them are a problem if you catch and address them in advance.

① Leftover MyISAM tables (e.g., from WordPress) break Blue/Green

Blue/Green relies on binlog replication, and consistency isn't guaranteed for non-transactional MyISAM tables. Check the engine of every schema in advance, and if you find any MyISAM tables, convert them with ALTER TABLE ... ENGINE=InnoDB (WordPress officially recommends InnoDB too).

② With a custom option group, Blue/Green for a major upgrade is rejected

Creation fails with an error saying only default option groups are supported. If the option group is empty, switching to the default OG before creating the deployment solves it (if it contains options, you'll need to separately figure out how to cover them on the target).

③ Deleting an old Blue with deletion protection ON takes an extra step

When you delete the old Blue left behind after switchover (<original-name>-old1), you can't delete it directly if deletion protection is ON. Disable it with --no-deletion-protection first, then delete it.

Revisiting RDS Extended Support Pricing

If you leave the instance un-upgraded, Extended Support charges are added per vCPU-hour. In Asia Pacific (Tokyo), it's $0.12 per vCPU-hour in Years 1 and 2, and $0.24 per vCPU-hour from Year 3 (doubling in the third year). Instance types from micro to large all have 2 vCPUs, so even a single micro instance adds ¥28,000 per month in Extended Support charges. Multi-AZ standbys and read replicas are also billed, so it can keep doubling from there.

Below are the instance costs and Extended Support charges for each instance type.

Instance class	vCPU	Instance (hour / month)	Extended Support (hour / month)	Ratio
db.t3.micro	2	$0.025 /hr ≈ ¥2,900 /mo	$0.12 x 2vCPU/hr ≈ ¥28,000 /mo	~9.6x
db.t3.small	2	$0.05 /hr ≈ ¥5,800 /mo	$0.12 x 2vCPU/hr ≈ ¥28,000 /mo	~4.8x
db.t3.medium	2	$0.10 /hr ≈ ¥11,700 /mo	$0.12 x 2vCPU/hr ≈ ¥28,000 /mo	~2.4x
db.t3.large	2	$0.20 /hr ≈ ¥23,400 /mo	$0.12 x 2vCPU/hr ≈ ¥28,000 /mo	~1.2x

* Calculated at ¥160 per USD.

In our case: +¥84,000 a month "for doing nothing"

The instances we upgraded to 8.4 this time were three RDS instances we operate. They weren't even running in a redundant (Multi-AZ) configuration, yet the Extended Support charges for those three instances alone would have added ¥84,000 a month (about ¥4 million if left for three years).

"For doing nothing." Actually, no: it's a charge you incur precisely because you did nothing.

Honestly, the thought of wasting ¥84,000 a month on something like this is enough to keep me up at night.

Finish upgrading to 8.4 LTS within the standard support period and these extra charges drop to zero. The Blue/Green migration itself only costs you the temporary extra Green instance (for the tens of minutes to few hours the migration takes). Compared with the Extended Support fee, it's an investment that's orders of magnitude smaller.

* Unit prices vary by region and are subject to revision (the table above is based on provisioned instance pricing in Asia Pacific (Tokyo)). For the latest figures, see the RDS for MySQL pricing page (Extended Support).

Afterword

Blue/Green Deployments is a well-designed mechanism that lets you push a major upgrade through with minimal production downtime, even on a simple setup. But the main thing we want to get across in this article isn't the migration procedure; it's that RDS Extended Support charges are steep and easy to overlook. If you finish upgrading to 8.4 before standard support ends (July 31), you can bring these extra charges down to zero. We recommend getting it done early instead of putting it off as "something to do someday."

Incidentally, RDS for MySQL 8.4 became available on November 21, 2024. Services built before then are likely still running on 8.0 and are prime candidates for this end of standard support, so keep an eye out.

In particular, cases involving small instances like micro, where the AWS bill is only around ¥10,000–20,000 a month, are exactly where people let their guard down and overlook maintenance. Because Extended Support costs several times the instance price, it's entirely possible that your bill quietly more than doubles and you only notice months later.

There's no reason to pay charges you don't have to. If this sounds familiar, check sooner rather than later, and please give a heads-up to anyone around you who uses RDS. Let's keep a firm handle on costs like these, if only to help shrink Japan's digital trade deficit a little.

At MOOBON, we take on this kind of AWS maintenance, migration, and cost optimization as part of our operations services. Whether it's "We got an EOL notice but don't know what to watch out for in our setup" or "We want to upgrade with minimal downtime," we'll work alongside you from the upfront inventory described in this article through the switchover and verification. Feel free to get in touch.

References (official AWS)

FAQ

Frequently Asked Questions

QCan Blue/Green Deployments really deliver a major version upgrade with zero downtime?

Strictly speaking, it isn't zero downtime. Existing connections are dropped at the moment of switchover, so there is a few seconds to a dozen or so seconds of "disconnect and reconnect." AWS documentation says it typically takes under a minute. In our environment, a page being accessed during the switchover waited about 13 seconds and then rendered normally, with no error page and no lost session. Because the switchover was well within the load balancer and web server timeouts (usually around 60 seconds), it was absorbed as "waiting time" rather than an error. That said, a request whose connection is cut mid-query can still fail, so it's worth checking whether your application's connection pool supports retries. Since the duration varies with load and state, we recommend measuring it in an environment close to production.

QShould I upgrade to MySQL 8.4 or 9.x?

For production, we recommend 8.4 LTS (Long Term Support). 8.4 is MySQL's first LTS series, with community support running until April 2032, and the RDS for MySQL lifecycle is expected to follow suit and be similarly long. 9.x, on the other hand, is an Innovation Release designed to ship new major versions on a short cycle, which makes it a poor fit if you don't want to increase maintenance frequency in production. A practical split is to use 9.x in development environments where you want to try new features, and standardize on 8.4 LTS for production.

QWhat are the requirements for enabling Blue/Green Deployments?

For RDS for MySQL, the minimum requirements are: (1) backup_retention_period of at least 1 day (automated backups enabled), (2) binlog_format = ROW, and (3) a supported engine version. binlog_format must be explicitly set to ROW in a custom DB parameter group; if it's left at the engine default of MIXED, the request to create the Blue/Green deployment is rejected. In addition, for a major version upgrade via Blue/Green, the source instance must use a default option group (see pitfall ② in the article).

QI heard mysql_native_password is disabled in MySQL 8.4. Do I need to change my application?

In vanilla MySQL 8.4, mysql_native_password is disabled by default, but we confirmed in a real environment that in RDS for MySQL 8.4 parameter groups, mysql_native_password is fixed to ON (not modifiable). As a result, DB users created with native authentication could still connect after the upgrade to 8.4, and no application changes were needed. The "mysql_native_password is deprecated" warning from AWS's pre-upgrade compatibility check (PrePatchCompatibility) is general guidance aimed at upstream MySQL; on RDS there is neither the need nor a way to set loose_mysql_native_password=ON separately. Our position is that migrating to caching_sha2_password can wait until we upgrade to a future major version that actually removes the native plugin.

QEven if the database side has no downtime, can the application still throw errors?

It can. Blue/Green is a feature for switching the DB engine version with near-zero downtime; it doesn't take care of compatibility for your application's client libraries, queries, or schema. Before switching over, we recommend identifying every path that connects to the target DB and checking the version of each application's MySQL client library. In particular, 8.4 changes some optimizer behavior, so it's reassuring to check the slow query log after the switchover to make sure heavy listing, search, and reporting queries haven't gotten worse plans.

QIf I find a problem after switchover, can I roll back?

Right after switchover, the old Blue environment remains as <original-name>-old1, so keeping it around for a while serves as insurance. However, writes made on the new Blue (formerly Green) after the switchover aren't reflected in the old Blue, so the longer you wait, the less realistic a rollback becomes. Our process is to delete the old Blue and the Blue/Green deployment once everything checks out, to stop paying twice. The protective snapshot taken just before the switchover is kept as a deeper restore point.

RDS for MySQL 8.0 Extended Support Is ExpensiveUpgrade to 8.4 LTS with Blue/Green before standard support ends

Contents