Extend billing API to consider fair use of reservations
My company uses a mix of reserved instances and pay-as-you go instances. I want a convenient way to evaluate how much it cost in a given month to operate a virtual machine. This convenient way should fairly distribute reserved instance usage among eligible machines.
With pay-as-you-go instances, you can pull monthly data that shows how much an instance cost to operate this month. The costs are a direct function of the delivered value. With reserved instances, you pay in advance and you may (or may not) use the reservation over the course of the years. Value stream (usage) and money stream (pre-payment) are decoupled from each other.
To evaluate how much it really costs to operate a given machine, I am interested in the value stream. This should be the sum of pay-as-you-go costs plus pro-rated reservation costs for a given machine.
The current APIs offer this functionality easy enough. However, there are a few issues:
* You have to use multiple data sources (usage details or reservation details for usage hours, reservation charges for initial charges) to derive the reservation value stream
* Reservation APIs hide data of expired reservations - no cost control in the past - very annoying
* The APIs have no concept of fair share.
To illustrate the last point, consider the situations where you have 1 reservation for an E16v3 machine, but you use 2 E16v3 machines. The pro-rated reservation cost is 350$ per month, while the pay-as-you-go cost is 650$ per month. Depending on the constellation of planets, the reservation will be consumed by both E16_v3 machines in undefined fractions. One machine could cost 350$ and the other 650$, or one could cost 575$ and the other 425$. Fair costs would be a stable 500$ for each machine month after month.
I want an API that gives me the fair share costs for each individual instance in a given month. These costs should be a mix of pay-as-you-go and pro-rated reservation charges. All machines that are eligible for a given reservation (i.e., matching region, virtual machine family, optionally subscription and specific virtual machine size) should benefit from the existing reservations in the same way. This also includes flexible instance sizing.
Currently, I do this by hand, and it is very painful to reimplement Azure's reservation usage rules.
Valid feedback. Open for customer upvotes