We’re excited to see Amazon launch Instance Size Flexibility (ISF) for RDS. We’re proud to announce full support within Cloudability including harnessing this feature to manage your risk and admin overhead while opening up savings opportunities.
We have typically seen organization-wide Reserved Instance (RI) coverage on RDS be less than half the level of that attained for EC2. In fact it’s fairly common to see customers who have decent RI coverage for EC2 and not have any RI’s at all for RDS. With the release of RDS RI Size Flexibility, we expect that will no longer be the case.
Historically, there have been two main reasons for the aversion to purchasing RDS RIs. The first is that, unlike EC2 RI’s, there is no facility to modify a reservation to accommodate changes to the underlying instance. The second, is that organizations tend to have fewer RDS instances overall, but their average size is much larger (and more expensive).
Further, RDS instances also tend to be longer lived than EC2 instances and stay on around the clock. One outcome is that they are treated less like a commodity and RI purchasing decisions are made for each instance individually. For example, you might only have one or two r3.8xlarge MySQL Multi-AZ instances running in us-east-1. Committing to the RI is risky since if the instance was to go away you would potentially end up with a net loss.
How Are RDS Reservations Different Than EC2 Reservations?
At a high level, RDS RIs operate in a very similar manner to EC2. You make a commitment to use some instances for one year or three years and can pay all upfront, partial upfront or no upfront. By committing to this usage AWS rewards you with a lower hourly rate. In fact, if you compare the relevant instances sizes you’ll see how similar the savings rates can be:
In terms of strategy of when and when not to buy the RI based on usage patterns and the RI’s savings rate the generic strategy is identical. It’s still all about plotting your usage patterns (even if they are less bumpy) and working out your break even point. What differs (slightly) are the attributes that constitute the reservation itself:
- Both RDS and EC2 have an instance type
- RDS instances have an engine (mysql, postgres), EC2 has an OS (Linux, Windows)
- EC2 you reserve into an AZ or region, RDS single or multiple AZ
So What Was Actually in This ISF Announcement?
This announcement gives RDS RIs similar flexibility characteristics to EC2 ISF with a tad more color.
- Applies to all db engines which have no license fee: MySQL, MariaDB, PostgreSQL, and Amazon Aurora and Oracle for BYOL
- Identical to how EC2 ISF operates in that it lets the savings of an RI apply to any size of instance within a family.
- Specific to RDS reservations is that single-AZ RIs can now apply to multi-AZ Instances, and multi-AZ RIs can now apply to single AZ instances.
As with EC2 there is a normalized point system which allows RI to be shared between a mixture of sized instances. What is especially worth noting here is that there is a simple points weighting between single-AZ and multi-AZ. That is a multi-AZ RI/instance has twice the weighting of a single AZ RI/instance. Let’s look at a couple of examples, presuming a shared DB engine of say MySQL.
You have a r3.4xlarge Multi-AZ Reserved Instance. In a given hour this could cover:
- 2 * r3.4xlarge Single-AZ instances
- 2 * r3.2xlarge Multi-AZ instances
- 4 * r3.2xlarge Single-AZ Instances
This is a fairly limited example but it should convey how a single RI can spread to cover multiple instances under RDS ISF. The opposite is also true that a “smaller” RI can cover partial costs of a larger instance(s).
The Cloudability Point of View
There is no doubt that having this flexibility around applying the benefit of RDS RIs can only be a positive. But the question remains how significant is this change and what can be done strategically to make the most of it. As always Cloudability takes the approach of how can we make this easy for you, with the least amount of admin overhead, to maximize your saving while managing your risk. As it turns out taking full advantage of the normalized point system, modeling peaks and troughs in your overall usage and purchasing to the smallest instance type (like EC2) and single AZ serves this well. This will give you the most flexibility and control in reaching your desired RI coverage. The good news is Cloudability has done the hard work for you and you can start your RDS ISF planning today through our RDS planner:
The Bottom Line: Aggressive RI Planning for RDS
Well for one thing we can start becoming more aggressive in our RI planning. We can begin to think more in that ‘commodity’ mindset: If I purchase that mysql db.r3.xlarge single-AZ RI it can be shared amongst a bunch of actual usage. It isn’t going to matter so much if one team turns off that famous beast database I was planning RIs around – they’ll be used elsewhere. At Cloudability we hope to see RDS reservation coverage rise to reach its brethren at EC2. Regardless we’d love to hear from you and talk about how we can save you money on your public cloud spend today!