May 17, 2023
There are a few easy options for metering instance hours for compute resources in Amberflo depending on your reporting and latency requirements and your method of integration with Amberflo for event ingestion.
We can use the ‘sum’ meter type and report usage for each instance when that usage concludes. This method is not events-based and instead depends on regularly reporting usage after it has concluded. There are more advanced options such as to automatically report usage every X hours by checking some usage table or database. For example:
06:00am - c5.metal instance activated on us-east-1
08:00am - same c5.metal instance deactivated
Total usage - 2 hours.
Send this 2 hours to Amberflo as a meter event the next time usage is updated in the system.
We can use the ‘duration’ meter type, and report the usage for each instance in real-time. This works by sending a start event to Amberflo when the resource usage commences, and a stop event when the usage concludes. A resource ID dimension is used to associate the start and stop events with each other (ie. sending the instance ID and the customer name with each start and stop event allows the system to associate the two events and automatically calculate the difference between start and stop as the total duration of usage. For example:
06:00am - c5.metal instance activated on us-east-1 (start meter sent to Amberflo containing the customer name, timestamp, and instance identifier)
08:00am - same c5.metal instance deactivated (stop meter sent to Amberflo containing customer name, timestamp, and instance ID)
Amberflo automatically calculates the duration between the start and stop events in milliseconds and stores this value.
In practice, compute resources are typically billed based on several different factors or traits. In Amberflo, these are modeled using dimensions (additional metadata as key-value pairs associated with each meter event), and these dimensions can then be used to filter, analyze, and create multidimensional pricing plans.
The pricing generally depends on the number and type of hardware being accessed (instance type), as well as the region the hardware is hosted, the amount of available memory, the availability zone, and other factors.
In Amberflo, when selecting the rate model you can configure 'Per Unit with Dimensions' or 'Tiered with Dimensions' to create these complex, multidimensional pricing arrays. In the screenshot below you can see a basic example that uses two dimensions, the instance type (type of compute resource being used) and the AWS region that hardware is being accessed from.