Dedicated Host Cost Details

Products

• CloudHealth

Issue/Introduction

Dedicated Hosts are now reported as a direct cost. More specifically, Dedicated Hosts are two direct costs, EC2 - Dedicated Hosts Unused Cost and EC2 - Dedicated Host Instances. 

Line items in the bill attribute cost to the dedicated host, but attribute no cost to instances running on the dedicated host. 

CloudHealth’s goal is to distribute the cost of the dedicated host across its instances and to attribute an “unused” cost back to the dedicated host itself.

The DH (Dedicated Host) unused cost will be the aggregated cost of unused slots on the DH throughout the time period. The DHI (Dedicated Host Instance) cost will be the aggregated cost of the total DH cost divided by the DH’s total capacity. 

Resolution

For example, for daily granularity, let’s say DH1 is a DH with the capacity to run 8 instances and has the cost of $8/hour.  DH1 has instances I1, I2, and I3, running from 00:00-07:00 and then I3 is shutdown but the others continue to run till 11:00 at which point I4 gets started and continues with I1 and I2 till 14:00.  At 14:00 I1 and I2 are shutdown and I3 is started again.  I3 and I4 continue until 21:00, when all the instances get shutdown for the day.

Note, when reading the bill, there could be more instances associated with the DH than its total capacity.  If, for example, the capacity of the DH is 4, it could have spun up four instances, shut two down and spun up another two which would result in six line items for instances running on that DH.  So the DHI cost will be the aggregated cost of the total DH cost divided by max(DH total capacity, n_instances) where n_instances is the total number of instances associated with the DH for the given time period.  Ideally, in this example, knowing that certain instances run for the entire time period we can always attribute DH-total-cost/DH-total-capacity for their cost.  Then consider the instances that don’t run for the entire time period as partial DHIs, the platform would attribute them with the cost DH-total-cost/(DH-total-capacity*n_remaining_slots) where n_remaining_slots are the number of slots left on the DH where a DHI did not run for the entire time period.

Note if n_instances >= the DH total capacity, then the reported unused cost for the DH will be 0 even though it may be the case that there were times during the time period where less than the total capacity of the DH was running.

The correctness of the aggregated cost attributed to the DH versus the DHI will improve with increased granularity.  For monthly granularity, as stated above, the cost associated with each DHI will be the cost of the DH divided by max(DH total capacity, n_instances) where n_instances is the total number of instances associated with the DH for the month.  Given 30 days in a month, the number of instances could be far more than the total capacity of the DH.  However for hourly granularity, again the cost associated with each DHI will be the cost of the DH divided by max(DH total capacity, n_instances) where n_instances is the total number of instances associated with the DH this time for each hour.  This data will more accurately reflect the distribution of cost for the DH across all instances running on the DH.  Although, even here, if total capacity instances or more are spun up during the hour, the unused DH cost will not correctly reflect unused downtime for the DH.