How to meter and bill compute instance hours

amberflo provides multiple options for metering and billing compute instance hours depending on your integration method and latency requirements metering compute resources option 1 using the sum meter type report total usage after it has concluded useful for scheduled or batch reporting example 06 00 am — c5 metal instance activated in us east 1 08 00 am — same instance deactivated you would send a meter event to amberflo with a value of 2 hours can be automated by periodically checking a usage database and submitting totals option 2 using the duration meter type report usage in real time with start and stop events useful when you want accurate, granular tracking of compute time each event should include a unique instance id and customer identifier example 06 00 am — start event for c5 metal , includes timestamp, customer id, and instance id 08 00 am — stop event for same instance amberflo calculates the time difference automatically in milliseconds and stores the duration billing compute resources compute usage is typically billed based on multiple dimensions, such as instance type (e g c5 large , t2 micro ) region (e g us east 1 ) availability zone memory/cpu size custom traits these characteristics are sent as dimensions with each meter event (key value pairs like r egion=us east 1 , instance type=c5 metal ) pricing setup in amberflo use "per unit with dimensions" or "tiered with dimensions" in your pricing plan define rates based on one or more dimensions (e g per hour rate by instance type and region) this setup enables accurate and flexible pricing across many combinations of usage types 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 an existing pricing plan 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