How to meter and bill compute instance hours

metering compute resources 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 option 1 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 option 2 we can use the ‘duration’ meter type, and report the usage for each instance in realtime 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 billing compute resources 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 billing for multiple concurrent instances as a cluster in practice, when customers consume compute for a job, they often provision multiple different instances as a cluster consider the example a user may be using 3 server instances (it can be any other number, usually a multiple of 3) of type i3 large in region us east so in this case, the user should be charged $0 123 3 per hour instead of just $0 123 per hour (which is the current per unit price in amberflo) there are two options for handling this use case, depending on whether each instance will be metered individually or if you will be squashing events before ingestion option 1 group the meters by cluster using a 'cluster id' dimension when 3 instances (or some multiple) are activated as a cluster, meter each individual instance (using 'instance id' dimension), and associate them together using the 'cluster id' dimension then when configuring the pricing plan, be sure that the checkbox is selected on 'for invoice group by', and select 'cluster id' as the grouping dimension see an example meter event data structure below \[ { "customerid" "123", "meterapiname" "compute hours", "metervalue" 1 0, "metertimeinmillis" 1678093200000, "dimensions" { "data center id" "1000", "cluster id" "1234", "cloud provider" "aws", "region" "us west (oregon)", "instance type" "i3en xlarge", "uniqueid" "987123zz a2e5 439c a222 a48748361023", "instance id" "instance 1" } } ] on the invoice, the usage will be organized by clusters, with the usage based charge calculated for each based on the number of instances and the amount of time they ran option 2 squash the meters pre ingestion by multiplying the meter value by the number of instances (sending one meter per cluster) in this case, the cluster size would be a known quantity before the meter was ingested to amberflo using this metadata, you can simply multiply the meter value for a single instance by the cluster size to create a cluster level meter that shows all usage for that cluster as a single event consider the following example of a meter event and the pre ingestion multiplication here is the original event notice that the 'metervalue' is 1 0 \[ { "customerid" "123", "meterapiname" "compute hours", "metervalue" 1 0, "metertimeinmillis" 1678093200000, "dimensions" { "data center id" "1000", "cluster id" "1234", "cloud provider" "aws", "region" "us west (oregon)", "instance type" "i3en xlarge", "uniqueid" "987123zz a2e5 439c a222 a48748361023" } } ] using the example above, the cluster size is 3, so the meter value would be multiplied by 3 to give the cluster level meter see below \[ { "customerid" "123", "meterapiname" "compute hours", "metervalue" 3 0 <==== 3 1 0 "metertimeinmillis" 1678093200000, "dimensions" { "data center id" "1000", "cluster id" "1234", "cloud provider" "aws", "region" "us west (oregon)", "instance type" "i3en xlarge", "uniqueid" "987123zz a2e5 439c a222 a48748361023" } } ] this approach involves sending fewer total meter events and may be simpler to orchestrate and maintain, however the trade off is a slight loss of granularity since the instance level events are being squashed pre ingestion to create cluster level events 📘 faqs and how tos docid\ bq14rede1rrwst00mbikx see related from pricing plans and product items how to associate meters with product items for use in multiple pricing plans docid\ pdham68piffum0 frtobu how to enable usage limits with amberflo docid\ jkod5jvrkilcdaw xrmjw how to see a customer's remaining prepaid balance docid\ koqqvxxn26iz5w wtercm how to update existing pricing plans with new product items docid\ r3qthe9dhoczv ekhs g how to delete a product item using the api docid ofduyszmn28qfunzdypv how to enable free trials with amberflo docid 2g657ijel99xgj99pvhyv how to make a support package available as an add on to our standard pricing plans? docid\ ncvayto3gaywyitjrc c how to enable custom or negotiated per unit pricing for customers docid\ vn1c3f wlnegp az3kwe