There are so many corporate usecases that I want to be able to hand an AWS account to someone and say 'have this was account. Do all your experiments over here. It is capped at your project budget'.
You could have 'soft cap and hard cap'. You could have everything deleted except persistent data. You could have everything gets rate limited to near zero to keep the rate of spend per hour below some threshold.
If my business runs of AWS, then rate limit or even reclaim some servers if storage is in S3.
The nightmare scenarios that keep showing up in news are the reason that I stopped playing around in AWS/Cloud.
A resource is used, when is the usage metered? If your instance is priced by run time when is that metering durably recorded? End of a time period, a billing period (oops! Havent got to billing periods yet!), on resource state change?
Assume you have a bunch of metering records. What price do you apply? There are LOTS of prices, even for the same thing. So now we need to know per account/service/region/contract/whatever the price to apply to the metering data. Oh no! The final price depends on aggregate usage! We cant determine the “price” for any single metering record without knowing cumulative usage. So now we have to aggregate total usage and apply the different marginal prices before we can determine any single price :(
Now we have lots of metering data + pricing data, lets make a bill. Who is the bill for? An account, a group of accounts, an organization? I hope you dont support credits, discounts, or similar that cross accounts. In practice the answer is probably “yes” and you e run in to another round of aggregation.
This isnt specific to SaaS, but describes billing in general. Its not A hard problem, its Many hard problems. And that general pattern of business problems is why you see most (all?) providers end up at a process that looks like recurrent batch computations.
Disclaimer: principal at AWS, but do not work in the metering/billing space directly. None of the above is specific to my employer and solely my personal observations/opinions.
But other teams seem to replicate AWS pricing models, I assume to stay competitive with it.
The other bane is value based pricing that business units and MBAs love. Trying to extract the maximum downstream (economic) value from the customer who’s using the service.
I do reckon you’re right though. Providing more timely estimated usage, and maybe even an approximate or base rate, would answer a LOT of these questions.
But for precise billing they need to handle a bunch of corner cases - things like 'you did this expensive thing while there was a network outage for 36 hours'.
Instead what cloud providers do is cheaply write an activity log to some async queue system. Eventually (hours later) those logs get aggregated into a central location and a bulk usage levels get updated onto your account. This is much cheaper to do and keeps everything decoupled.
Downstream impact in a JIT environment. Shipping cost, logistics, what can and cannot be swallowed or negotiated up and down. Worker or plant availability, cost, to make up. Tax, tax rebates, pollution offsets, constant or marginal utility pricing, fees for non consumption, incentive pricing.
A whole bunch more. Corrective action in a factory may take quite a lot of off the back of a napkin calculations.
If you built out an accurate data model for cloud service billing, this would become quite obvious: it’s not as simple as accumulating the consumption of a single resource from an upstream source.
Frankly-this would make a great FAANG interview question, though the implications should be obvious to anyone who’s ever worked in a public-facing cloud service: operations are themselves a billable client whose resource spend must ALSO be managed carefully.
This introduces a delay between the moment a cost is incurred and the moment it is billed. This delay can be of several hours or even days, depending on the billing frequency (hourly, daily, monthly).
For example:
- You start an instance at 10am. You are billed for it from 10am to 11am. You stop the instance at 11:05am. The charge should be removed from the bill at 12pm (because bills are generated hourly). If you look at your bill at 11:05am though, you will still see a charge for an hour of usage, since your bill has not been updated yet. If you want to check if your charges were correctly applied to your bill, you will have to wait until 12pm to look at your bill again.
Because of this delay, cloud providers cannot show your consumption / cost in real time: they would either show incorrect information (if they use billing data) or make you wait until they have updated their bills (if they use raw usage data).