2 Real-Life Stories about Cloud Cost Allocation

November 16 2014 | by Zev Schonberg Cloud Cost Management

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- Filament.io 0 Flares ×

Consolidated billing and reserved instances are two commonly known AWS features that are often times misused in terms of optimal cost allocation. As a quick refresher, consolidated billing allows you to concentrate all of your separate AWS accounts into one comprehensive bill. At Cloudyn, we use this feature to aid in optimizing resource consumption and pricing, however, this approach is not always widely accepted. Similarly, reserved instances, could save customers significant amounts of money, though the up-front fee and fear of being locked into a plan for a certain amount of time tends to be a disincentive. Below, I will tell you two different stories about real life cases that demonstrate just how each of these features aids in cost allocation. As I head up customer success at Cloudyn, I bump into a new and interesting cloud stories nearly every day, especially when it comes to enterprise adoption.

An Enterprise Affair

The first story is about a large enterprise that spends millions of dollars per year on Amazon Web Services. From discussions with them, I’ve learned that their reserved instances were bought in linked accounts which were organized nicely into separate business units. As a means of organization, Amazon floats all reservations up to users’ consolidated master accounts. The method behind the madness is that the savings that can be generated from those floating reservations (the unused reservations) can be applied to any matching instance, regardless of its corresponding business unit or linked account. The question is, what happens to the unused reservations if a match is not found? it was lost.

At Cloudyn, we have a tool called the Unused Reservation Detector, which highlights purchased reservations that are not in use. What’s more, the detector makes recommendations about how reservations can be recycled by either modifying them or relocating them to a different availability zone. Due to the fact that there is very little liquidity in the Amazon marketplace, you are much better off relocating a reservation from one availability zone to another or modifying it by breaking it down (i.e. from an m1.large into two m1mediums)

After a bit of searching for ways to cut cloud costs, we realized that there was an unused m3.large instance that was located in Availability Zone 1 in the Asia Pacific North East region. Using our handy dandy Unused Reservation Detector, we were able to identify a number of opportunities for this specific situation. First, we discovered an additional on-demand m3.large instance running in Availability Zone 2. Therefore, we recommended relocating the unused reservation to Availability Zone 2 to match the instance that was running on-demand. A second option was to recycle the instance, breaking it down into two smaller on-demand instances.

This is a common scenario that we encounter with a number of customers who have unused reservations. Despite the hefty overall cost benefits, many companies decide against relocating their cloud reservations. Reservations are purchased for specific business units, and it is up to each unit to budget the appropriate amount of reservations it would utilize. Unfortunately, this approach will only lead to the company, as a whole, losing money. The mere 5 minutes needed to invest in relocating unused reservations between availability zones could result in massive discounts in the realm of as much as 6 figures per year for a company of this size. At the end of the day, these reservations translate into money that could be brought to the table by simply implementing policies that make the most sense for optimal cost allocation.

The MSP Economies of Scale Story

On the other end of the spectrum, an MSP customer of ours offered a completely different scenario for cost allocation. Similar to the enterprise use case above, this MSP is working with a consolidated environment with all of their customers in linked accounts.

Though reservations are not yet used, they are a top priority due to the fact that they provide a sure fire way to make a profit. For example, if the MSP has 10 customers that are all using the m3.large instance, there is enough usage to justify and buy a reservation. If the reservation rates are $0.20/hour, the MSP can still charge customers $0.30/hour, providing them happy a discounted rate from the on-demand rate of $0.40/hour, and making a profit all the while.

Ideally, this particular MSP would have clear monthly cost information for each customer that is provided separately from the consolidated level. Unfortunately, trying to explain the bigger picture of leveraging reservations to increase profits to non-technical departments does not always work out. As a result, this particular sales department did not see the technical aspect of how consolidated billing works, where buying one reservation could translate into cost benefits spread out across multiple customers. Reservations were seen as tangible objects that could only be allocated to their designated customers for face value.

Final note

So, as we have demonstrated above, these two use cases still “suffer” from the traditional state of mind that servers need to be physical entities that are owned by each business unit. This is definitely not the case when it comes to reserved compute capacity. If done correctly, leveraging consolidated billing and reserved instances can lead to significant savings and even increased profits.

Experience Cost Allocation

Cloudyn’s Cost Allocation 360° enables you to Optimize, manage and maintain your cloud costs from an enterprise-wide perspective for ongoing clarity, accountability, and control.
start free trial

Connect with us
Sign up for our newsletter
  • альтернативный текст
  • альтернативный текст
  • альтернативный текст
  • альтернативный текст


SSO Login

Forgot Password?

No account yet? Register.

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- Filament.io 0 Flares ×