Fixer
When Software Grows Old... Minimizing Spend on AWS Extended Support
Minimize AWS Extended Support costs for EKS Kubernetes and RDS engines. Upgrade from end-of-life versions to avoid paying up to 50% more in support fees.
Updated 25 Aug 2024
Introduction
Amazon Elastic Kubernetes Service (EKS) and Relational Database Service (RDS) both lean on open source projects at the core of their offering. For EKS, the core open source dependencies are Kubernetes, etcd, CoreDNS, CNI Core binaries, CSI Sidecar Containers, and various other components and security updates (see EKS Distro Introductory Blog Post). For RDS, the major open source dependencies are the core database engines, namely PostgreSQL and MySQL. These core open source projects are not controlled by Amazon. In fairness, AWS does contribute to Kubernetes, Postgres, MySQL, and many other open source projects. For a great blog post on AWS’ contributions to these and other projects, see this AWS blog post as well as the entire AWS Open Source Blog.
In the rest of this blog post, I’m going to discuss the challenges of maintaining old software, the End Of Life (EOL) policies for Kubernetes, MySQL, and Postgres, discuss Amazon’s Extended Support plans and pricing, which RDS and EKS usage will incur Extended Support Charges, and how CloudFix can automatically find such software for you.
Maintaining Old Software
Maintaining old versions of software is difficult. You need to make sure that the software does not fail catastrophically, but without changing any behavior of the function. This is especially true for foundational pieces of software such as databases and container orchestration engines, where there are many downstream software projects. It has become a known fact that much of the financial system runs on COBOL, and programmers who are proficient in COBOL can command high salaries. This speaks to the difficulty of maintaining older software systems. For programs which can communicate with the public internet, keeping old programs secure is complicated. This is because flaws are often discovered in the latest running versions of the code, and the patches to fix these flaws must be then “backported.” This can be difficult and even introduce new bugs, and the code changes over time. In fact, just last year a bug was introduced to the Linux kernel due to a failed attempt to backport a patch. Quoting Chris Siebenmann’s blog:
the more old versions you ask people to support (and the more support you want for those old versions), the more backports you’re asking them to do and the more bugs you’re going to get.
With all of these downsides to using (and therefore, maintaining) old versions of software, why do some people choose to do so? There are many possible reasons, from a simple lack of engineering resources, a general aversion to change, or, most likely, external dependencies. There may be third party software that has not been certified to work with newer versions. For whatever reason, we can see that, like most decisions, there is a tradeoff of costs and benefits.
AWS EOL for EKS and RDS
Amazon considers software at End Of Life (EOL) once it is past the standard support date.
RDS mySQL
For AWS RDS, the standard support dates are announced for each major version. MySQL is versioned X.Y.Z, and the “major version” component of this is 8.0. The MySQL major version support dates are listed in the MySQL on Amazon RDS versions page, and in this table:
MySQL major version | Community release date | RDS release date | Community end of life date | RDS end of standard support date | RDS start of Extended Support year 1 pricing date | RDS start of Extended Support year 3 pricing date | RDS end of Extended Support date |
MySQL 8.0 | 19 April 2018 | 23 October 2018 | April 2026 | 31 July 2026 | 1 August 2026 | 1 August 2028 | 31 July 2029 |
MySQL 5.7* | 21 October 2015 | 22 February 2016 | October 2023 | 29 Feb 2024 | 1 March 2024 | 1 March 2026 | 28 Feb 2027 |
|
|
|
|
RDS PostgreSQL
In PostgreSQL land, to quote the official versioning policy:
Starting with PostgreSQL 10, a major version is indicated by increasing the first part of the version, e.g. 10 to 11. Before PostgreSQL 10, a major version was indicated by increasing either the first or second part of the version number, e.g. 9.5 to 9.6.
Amazon RDS support for PostgreSQL is given in this page. The RDS API can also list the engine versions available to you.
By “support”, Amazon is committing to provide patches for “Amazon RDS will supply patches for Critical and High CVEs as defined by the National Vulnerability Database (NVD) CVSS severity ratings.” This support is baked into the RDS pricing during the period defined as the Standard Support Date. Outside of this period, Amazon offers Extended Support.
Kubernetes
As described in the AWS EKS Kubernetes versions page, standard support applies to versions 1.29, 1.28, 1.27, 1.26, and 1.25. Extended support applies to 1.24 and 1.23. EKS standard support typically lasts for 26 months after the release of the major version.
Extended Support, and Pricing
Extended support for RDS MySQL and PostgreSQL
Extended Support is Amazon’s way of providing High and Critical CVEs and bug fixes to older versions of software, which are outside of the standard support window. For both RDS and PostgreSQL, the pricing is between $0.10 – $0.12 per vCPU-hour in years 1 and 2, and up to $0.419 per hour in year 3. See the Amazon RDS Extended Support costs section of the MySQL and PostgreSQL for the full pricing tables. Note that the pricing for extended support can very substantially by region. Note that this pricing is in addition to the standard instance price. A db.trg.2xlarge running RDS MySQL in Sao Paulo would cost $1.12 per hour during the Standard Support phase, and has 8 vCPUs. During Years 1 and 2 of the extended support window, there is an additional charge of $0.210 per vCPU, or $1.12 + 8 * $0.210 = $2.80 per hour. During Year 3 of the extended support window, the surcharge jumps to $0.419 per vCPU, or $1.12 + 8 * $0.49 = $5.04 per hour.
Standard Support | Extended Support | Extended Support |
$1.12 / hour | $2.80 / hour | $5.04 / hour |
Of particular note is that you are automatically enrolled in Extended Support if your RDS instances are running a version which is no longer in the Standard Support window. This was announced in an AWS News Blog in late 2023. Due to this automatic enrolment, it is crucial that you are aware of any RDS clusters which are nearing the end of a support window, as the pricing will change drastically. Depending on the constraints of the environment, it may or may not be worth the effort to upgrade to a version in Standard Support, but this decision should be made well in advance and with full information.
Extended Support for EKS
Amazon EKS extended support for Kubernetes versions was announced early January of 2024. According to the blog post, the pricing for EKS Extended Support is $0.60 per cluster per hour. This is in contrast to standard EKS pricing, which is $0.10 per cluster per hour (in addition to the instances and other costs).
Finding RDS and EKS Clusters
Which of your databases and clusters are affected? You can check each RDS instance’s engine version and each EKS cluster’s Kubernetes version against AWS’s published support calendars, but across many accounts and regions that gets tedious fast, and the calendars keep moving.
CloudFix does the finding for you. The finders work read-only: CloudFix uses your cost and usage data and your resources’ configuration to flag RDS databases and EKS clusters that are in, or heading into, Extended Support, along with what that is costing you. The upgrade itself is a guided change: you decide which ones are worth upgrading and make the version change on your own schedule.
Using CloudFix
The Finder/Fixers associated with this article are “RDS Optimize EOL Version” and “EKS Optimize EOL Version”, both of which are found in the Advanced panel of the CloudFix dashboard.
Clicking on either Finder/Fixer will present the familiar interface.
We see all of the identified EKS or RDS clusters, along with their associated account, organizational unit, cost, and potential savings. With this information in hand, it makes prioritizing which databases to migrate straightforward. Clicking on Options will give you more details:
In the above panel, we see that this cluster is running Kubernetes 1.23, and that standard support ended in 11 Oct 2023, and extended support ends 11 Oct 2024. The potential savings on the previous screen is showing us how much can be saved by migrating the EKS cluster to a Kubernetes version on standard support. With this information, you can decide if the savings are worth the effort. As they say, knowledge is power – in this case the power to save!
Try CloudFix
Whether you decide to upgrade versions or pay the extended support costs is up to you. With CloudFix, you can see all extended support costs associated with EKS and RDS in one place, and from there decide which upgrades are worth pursuing. Give CloudFix a try today. Get started with a savings assessment, and find out how much you can save with our automated Finder/Fixers.
