There have been some noises about this week’s newsletter issue in which I criticized the release of AWS Compute Optimizer offering RDS recommendations thusly:
Too bad it’s completely useless for most customers, because RDS only has its own bespoke Reserved Instances, which are wildly inflexible. The fact that Savings Plans don’t extend to cover RDS is one of the more customer-hostile things AWS does, and a number of large customers are annoyed by it. So yeah, use this if you want recommendations you can’t take advantage of without leaving bushels of money on the table, I guess.
Let me clarify my position and commentary on this feature announcement.
The feature itself is fine, bordering on great. “You’re running RDS instances of type X, consider type Y instead” is a solid enhancement. For extra style points, it even supports a whole slew of customizations around the recommendations: RI awareness (which we’ll get into in a sec!), idle detection, storage, the lookback period under analysis, and integration with RDS memory metrics for deeper inspection. This is a solid feature enhancement that I’m sure will brighten the days of many customers and represents what I know to be a lot of hard work and internal negotiation to develop and launch.
However!
My concern with the feature is that customers are inherently limited in their ability to migrate between RDS instance types due to the inflexibility of RDS Reserved Instances and the RDS org not deciding not to support Savings Plans, or even a similar structure that’s worse in every way–like SageMaker’s own imagining of Savings Plans versus supporting the existing ones. While this feature announcement is RI-aware and will make recommendations that take those into account, if a customer has existing high RI coverage on RDS, they may not see recommendations to downsize their over-provisioned RDS instances.
That’s my issue: it’s not about this announcement, it’s about the capability being hamstrung by RDS RIs making this less effective than it could be–which is entirely an RDS issue, not an issue with the feature. If there were more flexibility in RDS RIs (Savings Plans!) then this feature might show substantially more optimization opportunities.
What do I mean about RDS RI inflexibility? While the discounts can be high (up to 69% discounting off of on-demand pricing), the RIs are bound to a combination of region, database engine, instance class, and deployment type, roughly equivalent to the inflexibility we had with EC2 Standard RIs–and why Compute Savings Plans were such a massive improvement. One of the best parts about Compute Savings Plans is that it doesn’t matter whether you’re using Lambda, Fargate, EC2, what instance family you’re using, etc–as long as you’re spending at least some committed hourly spend amount, there aren’t artificial economic barriers that constrain your architectural decisions.
This isn’t the first time I’ve made this observation, as have many others, including the vast majority of our clients privately, and I continue to give the RDS organization a remarkably low score for Customer Obsession. (as another example: gp3 is 20% less expensive per gigabyte than gp2 on EBS, but the per GB cost remains the same between gp2 and gp3 on RDS.)
In summary, if you’re running a lot of RDS on-demand (something I strongly advise folks not to do in almost every circumstance) this feature is the cat’s pajamas. If you have high RI coverage on RDS, this feature instead serves as a tantalizing glimpse of a world that the RDS org has firmly shut the door on, at least for the time being.
