Summer 2023 AWS accounced they will start charging for every public IPv4 address you deploy, starting February 1st 2024. This charge applies to all addresses wheather attached to a service/server or not. Since the announcement, potential ways to avoid paying extra for public IPv4 addresses have got a lot of attention in engineering and FinOps communities.
Shortly after there were also 2 other announcements that would deserve a bit more attention than they have got1. These are EKS extented support for Kubernetes and RDS extented support for MySQL and PostgreSQL, ie. ability to continue getting support for versions that were dropped off from official support, in exchange for extra charges. These charges will be in effect from March 1st (RDS) and April 1st (EKS).
1Google Trend lines for ipv4 (blue) and extented support (flat red)
Business model of providing extented support beyond normal product lifecycle is nothing new. It is like taking high interest rate loan for technical debt you haven’t been able to pay back in time. Kubernetes, and EKS, has a very frequent release cycle of 3-4 versions / year, and only 12 months of patch support after the release date. This means you must have a continuous process updating your clusters to stay on supported version.
EKS extented support gives you now automatically extra 12 months to catch up if you haven’t been able to keep with pace. However that comes with a price of $0.50 / hour / cluster. So after 12 months have past, you are 12 more months behind the release schedule and $4380 poorer :-(
Nice thing about EKS extented support is that it puts a clear monetary value on keeping up with Kubernetes releases. Benefits of having up-to-date patches and features are obvious but not easy to convert to $’s. With extented support cost, it is trivial to show how investing into things like having a proper test environment, continuous update process or buying cluster maintenance from your favorite managed service provider, can be a very good investment. Just multiply number of EKS cluster with $4380 and see if this yearly budget would get you the improvements required to stay up-to-date. For an enterprice with modest number of 20 EKS clusters you would have almost $90.000 budget with very decent 1 year payback period. And when the option is to pay the same amount, and get nothing, it should be an easy decision.
Where to start from?
Another nice thing about extented support is, that it is very FinOps -friendly topic. You don’t need to have comprehensive and up-to-date inventory over all AWS accounts and resources your company has. All you need CUR -records. And everyone has those. It is not clear yet if extented support will be reported as separate line item, or price increase for EKS cluster. This is to be found out April 1st when first billing records have been delivered. But to find it wouldn’t be much different from simple Athena query that finds your EKS clusters.
product['product_name'] as product_name,
where product['product_name'] LIKE '%Kubernetes%'
AND line_item_resource_id != ''
As usual you should start updates from test environments to verify nothing getis broken in the process. This is especially important for Kubenetes because minor versions are not 100% backwards compatible. Some old APIs might have been removed and replaced with new ones.
It is good to remember extented support costs the same regardless of cluster size or complexity, and as soon as you get to supported version, the meter stops running. This means it makes sense to start from simple and work towards more complex clusters. Simple in this context being a cluster that is close to supported version, has small number of nodes and upgrade insights report is short.
What about RDS?
RDS extented support for MySQL and Postgres is very similar opportunity as EKS. However there are some differences in RDS pricing model that can make it bit more complex.
- RDS extented support is offered up to 3 year, but year 3 is twice as expensive.
- Pricing is based on vCPUs, ie. there is no simple formula to calculate savings potential beforehand, but you can see the price you pay from CURs (assuming this will be reported as separate line item). Price also varies between regions.
- vCPU based pricing means some instance types have much bigger % uplift than others. As a rule of thumb, more memory db instance has, smaller % uplift is. Also storage and I/O have (major) effect on RDS pricing, but have no effect for extented support.
Be ready and start preparing today. You can create a good estimate for business case to build missing capabilities required to stay up-to-date. Databases have slower release cycle so you could do with less than 100% automated process, but EKS you need continuous update capability in your organisation. If that feels more than what you are capable right now, good options could be swiching to simpler container platform like ECS or fully managed Kubernetes platform such as Red Hat OpenShift Service for AWS.