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

aws pioneered combining usage based pricing with a product led go to market motion, where customers select the hardware and tools required for their project and then are only billed for the resources consumed this minimizes barriers to entry and allows each company or independent user to enter at a price point they are comfortable with, with a predictable pathway to increasing scale and spend follow this template for a step by step guide to get started implementing an aws style pay as you go billing model for your business this guide will detail how to define metrics, track usage, and build flexible usage based pricing models from your product catalog based on dimensions such as region, instance type, and availability zone how it works aws offers hardware that customers can use as a service and then pay only for what is used rather than the purchase and upkeep of proprietary infrastructure customers can select the instance type with the specifications and performance capabilities that are best suited for the intended use case then for each instance type, aws sets the hourly rate based on a number of dimensions such as the aws region the service is accessed from and the operating system (os) in use here is a section of pricing data for aws ec2 for aws region us east 1 to illustrate the concepts of instance types, the specifications, and the different hourly rates by os 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 is a platform solution, with the metering service (amberflo metering cloud) as the foundation and the billing service (amberflo billing cloud) built as an integrated application sitting on top amberflo tracks and aggregates usage in realtime and applies your billing logic to that usage to generate the usage based bill aws’ ec2 pricing is built around a single meter the number of compute hours of use for each instance there are two easy options for creating this corresponding meter 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 resourceid 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) using dimensions dimensions are additional metadata that is sent with each meter event that can be used to filter, analyze, or even create billing rules in our example, there are two dimensions that are being used to create the pricing plan (in real world aws pricing, there are additional other dimensions used as shown in the pricing example above) the aws region that the customer is accessing the service from the instance type for the compute resource being accessed different instance types have different capabilities and memory specifications, so customers can select the instance that is optimized for their job 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 creating a new pricing plan, the first step is to name the plan and set the billing period next, you create product items that will make up your plan these are the items in your catalog that you will charge customers for using; each product item should be associated with a meter which tracks usage for that resource aws offers a pay as you go pricing model for its services including ec2, so there is no subscription fee, startup fee, or other recurring charges the bill is entirely based on the compute consumed 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 to begin generating invoices for usage, you must activate the pricing plan and assign the plan to customers from the moment the plan is assigned, the billed amount will be calculated in realtime as usage occurs by applying the product item rates you can view the on demand invoice at any point during the billing cycle by navigating to the customer view and selecting the invoice you’d like to view pulling it together usage based pricing with a pay as you go model like aws employs offers flexibility, transparency, and control for customers over their spend it removes friction to increasing product adoption and synergizes perfectly with the plg motion with amberflo you can implement any custom variation of aws style pay as you go pricing in minutes get started today, click here https //ui amberflo io/signup to create your account and start building