Is RI ruining teams accountability?

10 out of 10 successful FinOps strategies have a special VIP section reserved for Reserved Instances. It’s like getting a golden ticket to the cloud party! These bad boys are your best pals for slashing those big cloud bills, especially when it comes to Virtual Machines. But arent’t we before a hidden villain?

I won’t bore you with the nitty-gritty. You know that RIs can “magically” make 50% to 70% of your Virtual Machine costs disappear in exchange for a 1 year or 3 year commitment. Although one of the most popular challenge RI brings is the fear of RI overallocation, that will generate unused reservation (this is not necessarily a bad thing in essence. But this is something for another article), there is a more subtle, hidden and still harmful effect that can jeopardize one of the pillars of any winning FinOps implementation. And it is Team Accountability.

On the winding road of FinOps history, convincing Engineers to act has been a major challenge for FinOps practitioners. Bombarded with requests from all sides, engineering teams have to perform a juggling act of epic proportions. They’ve got Security, Support, Managers, Directors, and every other stakeholder clamoring for their attention, not to mention the never-ending meetings. And now, on top of it all, the FinOps team is asking them to work on cost optimization. How in the world can we grab the attention of these Engineering Teams amidst this chaotic circus of competing priorities?

Ok, this thing of getting Engineering attention is another history( you might find some clues there). But for this article’s sake, imagine this: the Engineering Teams are all in about taking action. The FinOps Team has managed to convince them that cost optimization should be part of their everyday routine. So, the next thing on their agenda is to ask: “How do I know how much my services cost?” This is our moment to shine and whip out our dazzling Cloud Cost Report. They leave feeling ecstatic, seeing their costs from every angle. Fast forward to the next month, they’re baffled to see a dramatic change in their costs, even though nothing really changed. What could it be? After realizing that everything is interconnected and there are no leaks, they go back to the billing data. And the verdict is in: the Reserved Instance effect.

how on earth am I supposed to keep a lid on my costs when they’re changing based on God knows what?

Engeneering team

The thing is, imagine RI getting all dolled up and purchased at the top-tier account level. Then the Cloud Service Provider (CSP) applies the discounts related to RI purchased price using a random rule. So, one VM might strike it lucky and get the RI price today, but there’s no guarantee it’ll hit the jackpot again tomorrow. By the end of the month, assuming everything’s chugging along smoothly, the same gang of VMs could end up with different costs. And that’s when the FinOps team finds themselves in a pickle. Our response to Engineering would have to be that it’s all down to the wacky RI effect. They might counter with, “Sure, I get it, but how on earth am I supposed to keep a lid on my costs when they’re changing based on God knows what?” Fair point, don’t you think?

So, in summary

• Reserved Instance normally can be classified as a “low hanging fruit”.
• Once harvested, organizations need to continue the FinOps journey.
• This journey is as successful as Engineering Teams take ownership of their cloud costs.
• Ownership is only possible with cost reports that is the reflection of their usage.
• Reserved instances impact price, outside Engineering line of action.
• The organization can´t afford leaving RI discounts over the table.  

All things considered, the question is: how do we, FinOps team, get out of this dilemma?

Stable Price

We must devise a method to attain a consistent pricing structure. The cost is determined by the quantity used multiplied by the price. While the engineering teams significantly influence resource usage, they have minimal impact on resource pricing. Why doesn’t the Engineering team solely evaluate optimizations based on the quantity used? This is because different units of measurement cannot be directly compared. By standardizing everything in terms of cost (dollars, euros, etc.), we establish a common metric for easier comparisons. If the price remains stable, fluctuations in cost can be attributed to variations in usage, providing the Engineering teams with an actionable area of influence.

There are two methods for achieving a stable price. It is crucial to comprehend each approach in order to implement the necessary adjustments and ensure uniform communication among all FinOps personnel.

Blended price

This represents an average price. The blended price for each model or SKU is determined by dividing the total cost by the total quantity. This resulting price is generally stable as it factors in the RI price applied to the specific SKU and the potential pay-as-you-go price, thereby mitigating the impact of resources that may have received larger discounts. Further insight into the various cost types can be found in this article .

Things to take into consideration:

• Price may vary as you purchase/exchange RI.
• Total sum of cost resulting from quantity times blended price should match with billed cost.
• Other commercial or contractual discounts should be excluded from the blended price calculation.
• It will be required to display somewhere the blended price used, for the sake of transparency.

Full Price

UPDATE: On FOCUS, this is the same as Contracted Unit Price.

This represents the pre-Reserved Instance price and is derived by multiplying the quantity by the list price, or in some cases, the negotiated price with the CSP. I have written about Full Price on the same article mentioned above. An advantage of this method is that Engineering teams can directly verify the resource price on the CSP website. For instance, Microsoft offers the Azure Pricing Calculator, where users logged in with their corporate accounts can view the negotiated price. This capability is valuable for validating costs or estimating future workloads.

Things to take into consideration:

• Communicate broadly if any change to negotiated price and expected impact.
• Educate all personas that Full Cost will NOT match billed price.
• Educate all personas that savings in Full Cost will not result the same impact on final billed cost.
• On budgeting exercise, FinOps team should deduct the cost reduction of RI on top of Full cost so the result will be equivalent to expected billed cost.

All the points mentioned above are not just limited to Reserved Instances, but also extend to Saving Plans or any other current or future type of discounts applied across the board or on a larger scale. What’s crucial here is that any cost savings or optimizations that directly impact prices must be approached from an Engineering standpoint. For engineers, the cost report should vividly reflect the impact of their actions. The ability to track their costs independently of external factors marks the beginning of Engineering accountability in the short term and lays the foundation for a successful FinOps strategy in the long run.