AWS-style Pay-as-you-Go (PayG)

aws pioneered the model of usage based pricing combined with a product led go to market strategy , where customers select the tools and hardware needed and pay only for what they use this model lowers barriers to entry and enables customers to scale spending as their needs grow overview follow this template to implement an aws style pay as you go billing model using amberflo this guide outlines how to define usage metrics track and meter usage build flexible usage based pricing models using product dimensions (e g region, instance type, availability zone) how it works aws provides hardware as a service, charging by the hour based on usage customers choose instance type (performance specifications) region (where resources are accessed) operating system (os) each of these factors contributes to the final hourly rate this model can be recreated in amberflo using similar logic to keep things simpler for this example, we chose 2 instance types, c5 high cpu extra large, and c5 high cpu metal and show the hourly rates across different aws regions in the table below instructions we will walk through how to re create this pricing model in amberflo the first step is to create an amberflo account if you haven’t already (use this link https //ui amberflo io/signup ) see our documentation for help getting your account set up and inviting team members to join step 1 create a meter to track compute consumption amberflo uses its metering cloud to track usage and billing cloud to generate accurate, usage based invoices aws ec2 pricing is centered on tracking compute hours per instance you can replicate this with one of two meter types in amberflo option 1 use a sum meter type (usage reported after it concludes) in this approach, you do not send individual start and stop events instead, you track usage in your internal systems and report the total usage after the session concludes this is not event based and is often implemented via scheduled reporting (e g , hourly or daily jobs that calculate and report usage) example at 06 00 am , a c5 metal instance is activated in the us east 1 region at 08 00 am , the same instance is deactivated you calculate a total of 2 hours of usage for that instance and then send this value as a single meter event to amberflo more advanced implementations might involve reading from a usage database and reporting deltas on a fixed schedule (e g , every x hours) option 2 use a duration meter type (real time tracking via start/stop events) this approach is event based and captures usage in real time by sending both a start and stop event when the resource usage begins, a start meter event is sent to amberflo when usage ends, a stop event is sent these events are connected by a shared identifier — typically a resourceid or instance id — which amberflo uses to automatically calculate the duration between them example at 06 00 am , a c5 metal instance is activated in us east 1 → you send a start meter event that includes customer id timestamp instance id (used as the resource identifier) at 08 00 am , the same instance is deactivated → you send a stop meter event with the same identifying info amberflo calculates the duration of the session in milliseconds based on the timestamps and stores it for billing and reporting purposes using dimensions dimensions are key value metadata fields that are sent along with each meter event they allow you to filter , analyze , and define billing logic based on specific attributes of the usage in this aws style pay as you go billing model, we’ll use dimensions to reflect the real world variability in compute pricing these dimensions capture the contextual information needed for both analytics and multidimensional pricing the aws region indicates the region where the compute instance is running pricing can vary by region due to infrastructure and operational cost differences the instance type describes the compute resource type, such as t2 micro, m5 large, or c5 metal each type has different memory, cpu, and performance specs that affect the billing rate we’ve also added a third dimension, instance id , which is a unique code or tag given to each instance, allowing it to be identified for the duration meter, this is the dimension used to associate the start and stop events including these dimensions with each meter event will allow us to filter and analyze usage by aws region and instance type these dimensions are also the foundation for the billing logic we’ll build in later steps example meter data structure step 2 deploy meters to track usage as users consume compute resources, aws records the usage period in amberflo, this usage would be sent as meter events below is an example of what the meter event payload would look like (using a sum meter from option 1 above) you have several options for integrating your solution with amberflo to ingest usage to the metering system we provide sdks in several common languages; an ingestion api; and we enable meter ingestion from files, databases, and other common tools including aws cloudwatch aws s3 aws sqs elastic logstash mongodb databases and jdbc files postman collections kong api gateway for step by step walkthroughs on how to use each ingestion method, please refer to our documentation here is the sdk information curl metering example here is the api reference https //docs amberflo io/reference/ingest meter records https //docs amberflo io/reference/ingest meter records here are the docs on other ingestion options aws cloudwatch once the meter ingestion pipeline is configured, usage will be tracked and aggregated (by customer and by all custom dimensions you included) in real time you can visualize and query the usage data from the moment it is ingested step 3 create the pay as you go pricing plan when setting up a new pricing plan in amberflo, start by assigning a name to the plan and selecting the appropriate billing period (e g , monthly, quarterly) the core of your pricing plan is made up of product items —these represent the services or resources you are charging your customers for each product item must be linked to a meter , which captures the usage for that specific item in the case of aws style pay as you go pricing for ec2, there are no subscription fees no startup fees no recurring fixed charges the entire invoice is based solely on the usage recorded by the compute meter—customers are charged only for what they consume this flexible model allows businesses to scale without upfront commitments, aligning costs directly with resource usage in this example for ec2, compute is the only charge vector, so there will only be a single product item we will select the ‘by unit with dimensions’ pricing model, and then set the rates according to the region and instance type (see the table in step 1 above) step 4 activate the plan and assign customers to begin generating invoices once your pricing plan is fully configured, the next step is to activate the plan and assign it to the appropriate customers from the moment a plan is assigned, amberflo will begin tracking usage and applying the product item rates to calculate billing amounts in real time you can monitor usage and billing at any time during the billing cycle by going to the customer view and selecting the active invoice for that customer this gives you full visibility into the metered usage and accumulated charges throughout the billing period pulling it together usage based pricing with a pay as you go model—like the one aws uses—offers flexibility, transparency, and control for customers over their spend it removes friction from the adoption process and aligns well with a product led growth (plg) strategy with amberflo , you can implement any custom variation of an aws style pay as you go pricing model in just minutes, enabling you to scale your billing infrastructure with your business get started today, click here https //ui amberflo io/signup to create your account and start building