If you are using MySQL v5.7.x still for a software project, you likely know that you’re already skating on thin ice. MySQL v5.7 was released in 2015, and Oracle has just moved the product into its ‘Sustaining Support’ category. However, if you’re using MySQL in AWS RDS, there are some additional factors to consider.
Starting 2024-Feb-29, AWS will automatically enroll any MySQL v5.7 databases (RDS or Aurora) into an Extended Support plan, which comes at an additional cost per vCPU-hour.
Automatic Enrolment
The original announcement for extended support positioned it as an opt-in support feature. Amazon says that they changed their mind due to customer feedback:
However, we heard lots of feedback from customers that these automatic upgrades may cause their applications to experience breaking changes and other unpredictable behavior between major versions of community DB engines. For example, an unplanned major version upgrade could introduce compatibility issues or downtime if applications are not ready for MySQL 8.0 or PostgreSQL 15.
Anyone who is aware of this impending change would be reasonably likely to understand that if they cannot upgrade, they ought to enrol into Extended Support, so my guess is that the customers who provided feedback weren’t the ones who were most likely to suffer. But there’s definitely a tradeoff to be made here. Assuming some percentage of customers are not going to get the message no matter how many emails and announcements you publish, do you want those customers to:
- Have a new unexpected cost added to the bill?
- Possibly have application downtime after their database gets an upgrade and their software can no longer connect?
Neither experience is great, but I suspect AWS did the math and decided that option #2 is possibly better for customers and potentially better for revenue as well. Some customers will disagree of course.
Avoiding Extended Support
There’s a way to avoid extended support. Upgrade. Move your existing v5.7.x MySQL Databases to MySQL v8.x. It sounds simple, and for some of you it might be fairly simple. Anyone currently running MySQL v5.7 on AWS RDS or Aurora ought to at least evaluate that option, and see if that’s feasible. You will, however, need to do a proof-of-concept and some testing to make sure that your application doesn’t have any side-effects of a major version upgrade.
If you’ve set up your RDS instances manually, this might be something you can test by doing an upgrade in the console. I wouldn’t recommend testing this in production, but I hope most of you have at least one development AWS environment you can use to test this, and if you don’t, this is a good time to consider setting that up.
If you’re using automation (e.g. GitHub Actions, Terraform, etc), you might need a little bit more time to implement and test the change, but fundamentally it’s the same sort of thing.
Why use Extended Support
The main reasons I can see for continuing on MySQL v5.7 past the end of February are these:
- Upgrade Failed
- You’ve tried to upgrade to MySQL v8 and you’ve encountered a problem.
- You may be able to fix that before the end of February or you may not.
- If you haven’t resolved all your problems with the upgrade by the end of February you’ll probably know whether or not those problems are worse than paying for extended support.
- Opportunity Cost
- Upgrading MySQL will take some time. Depending on your organization it might take time from:
- your AWS or DevOps people (doing the upgrade, adjusting automation, etc)
- testers (QA, business users)
- production staff (during deployment, support)
- Those people might already be working on business-critical tasks that you don’t want to take them off. That time comes from somewhere, and you might put a higher value on that than on the Extended Support cost.
- Upgrading MySQL will take some time. Depending on your organization it might take time from:
- Risk
- This might be organization-specific; the work involved and the perceived risk of doing this before the end of February can vary a lot.
- If you’re a small team, with a small project and you aren’t currently under the gun, two months might seem like way more time than anyone needs to implement and test this change.
- On the other hand, in larger companies with more complexity and that move a little more slowly it might take most of those two months to come up with a good plan for what systems need to be upgraded, which teams will do the work to upgrade, test and roll it all out.
Cost
The cost varies by region, by the number of vCPUs (instances * vCPUs/instance) but the current costs are $0.10 - $0.21 per vCPU-hour for the first two years, and roughly double that for the third year. It will depend a lot on how many MySQL instances you’re already using, which instance types, and what region you’re running them in.
I’m working in Canada, so in ca-central-1, your additional cost for a given instance type would be $0.108/vCPU-hour. That would work out to $72.58 - $80.35 in additional monthly costs per vCPU. If you were running an admittedly massive db.m6i.32xlarge, that would be upward of $10k for a single instance in extended support costs for a 31-day month.
Even a tiny instance is non-trivial — a single db.t4g.micro might cost $0.018 per instance-hour in Canada, but it has two vCPUs, so would cost $0.216 per instance-hour for the extended support. Extended support in this case costs more than 10x the instance cost. About 7.5% of the cost of that instance after March 1st would be for the instance and the remaining 92.5% would be support costs. On larger instances, typically this ratio isn't quite so skewed. Looking at a few more examples, again using Canadian pricing:
| Instance Class | Instance Cost (HA) | Extended Support (/hr) | % of Total Cost for Support |
|---|---|---|---|
| db.t4g.micro | $0.018 | $0.216 | 92% |
| db.t4g.small | $0.035 | $0.216 | 86% |
| db.t4g.large | $0.007 | $0.216 | 97% |
| db.t4g.xlarge | $0.141 | $0.432 | 75% |
| db.t4g.2xlarge | $0.563 | $0.864 | 61% |
| db.m6g.large | $0.168 | $0.216 | 56% |
| db.m6g.xlarge | $0.336 | $0.432 | 56% |
| db.m6g.2xlarge | $0.672 | $0.864 | 56% |
| db.m6g.4xlarge | $1.344 | $1.728 | 56% |
| db.m6g.8xlarge | $2.688 | $3.456 | 56% |
| db.m6g.12xlarge | $4.032 | $5.184 | 56% |
| db.m6g.16xlarge | $5.376 | $6.912 | 56% |
| db.r6g.large | $0.278 | $0.216 | 44% |
| db.r6g.xlarge | $0.556 | $0.432 | 44% |
| db.r6g.2xlarge | $1.113 | $0.864 | 44% |
| db.r6g.4xlarge | $2.226 | $1.728 | 44% |
| db.r6g.8xlarge | $4.451 | $3.456 | 44% |
| db.r6g.12xlarge | $6.677 | $5.184 | 44% |
| db.r6g.16xlarge | $8.903 | $6.912 | 44% |
It's worth noting that this isn't considering the cost of storage, backups, snapshots, and also isn't factoring in reserved instances or savings plans. I've also left out the high-availability options for now. There are so many variables in AWS cost projections that it's very difficult to be comprehensive.
I’ll do a case study below with specific costs for a particular scenario, to get a sense of what it might look like with multiple database instances of different classes.
It’s going to add up, so if you can upgrade, you probably need to start looking at your options to do that.
End of Extended Support
Extended Support doesn’t last forever. It will help bridge the gap if moving off of MySQL v5.7 is hard for you, but at the moment RDS Extended Support for MySQL v5.7 is expected to be available until 2027-Feb-28. If upgrading from (or switching away from) MySQL v5.7 is a challenge, you’re still going to want to put it in your roadmap for sometime in the next few years, otherwise you’ll be facing an even harder challenge in 2027.
What should I do?
First, do the math. How many MySQL v5.7 instances do you have? How many vCPUs do those have? What’s the additional cost per month that you’ll have to pay under Extended Support?
Next, set some time aside. Attempt an upgrade in a local environment or in a development environment. Is it easy? Does it seem to work? A quick proof-of-concept isn’t necessarily enough to move forward, but it should give you some sense of how much work you have ahead.
Then evaluate the tradeoff. Can you afford the time required to make the changes, test them and deploy them? How much time will that take in your organization? What else is your team working on and can you afford that time? What’s the opportunity cost of doing the upgrade when compared to the support cost of not doing the upgrade?
And if you can’t do the upgrade by the end of February, when can you do it? How much will that support cost add up to in three months, or six months?
Case Study
I have a client in this situation. They had planned to move off MySQL v5.7 in October, but those plans were derailed, and further testing on a proof-of-concept has revealed problems that don’t have an identified fix — it’s a weird problem, and it only seems to be exposed in the cloud environments, but it’s going to take some work to diagnose and fix.
In addition, this client has a lot of work already in flight on the project, and the opportunity cost of delaying that work may be larger than the cost per month they’ll currently have to pay in extended support.
So if they were running:
- 5
t3.microinstances- $0.037 per hour each
- 2 vCPUs, so $0.216 per hour each
- 8
t2.microinstances- $0.037 per hour each
- 1 vCPU, so $0.108 per hour each
- 1
m5.2xlargeinstance- $1.512 per hour
- 8 vCPU, so $0.864 per hour
If I’m doing the math correctly, I could project their bill for the next six months as:
| Month | Cost |
|---|---|
| Jan | $1,483.79 |
| Feb | $1,406.69 |
| Mar | $2,366.66 |
| Apr | $2,290.32 |
| May | $2,366.66 |
| Jun | $2,290.32 |
Effectively, starting March, the database cost will go up roughly 65% until they can find the time to resolve the issues and upgrade.
What about you?
Were you able to migrate in time? Are you already working towards it? Or have you decided that you're going to be using Extended Support already?
Top comments (0)