Why can’t cloud providers show the instantaneous consumption / cost?

Because the problem is super, super hard. I did a whole thing about it here: https://www.lastweekinaws.com/blog/the-most-under-appreciate...

I understand why they won't give precise bills in real-time, but I wish they'd do real time bill capping, and eat the cost themselves of any usage before the cap kicks in.

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'.

There are other good answers to the complexity. An additional aspect not mentioned yet is that your bill is not a single thing. Usage, metering, pricing, and billing are all discreet problems. Theyre all interdependent and all of them need to be solved to provide a value thats useful to you, the customer.

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.

They could certainly give 'bill estimates' that are realtime within a few seconds if they wanted to.

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'.

If every action in a cloud service had to be instantly billable, it would just about double the complexity and cost of every operation. For example, fetching a blob from S3 would also need to insert the read activity into some realtime billing database AND check if you've exceeded budget. This ends up coupling everything into your billing system and makes the billing system much more active.

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.

If I should guess, mostly because of the staggering complexity of the pricing and the marginal utility of that information for anybody big enough to matter. Procurement and forecasting is done in quarters in most enterprises.

The factory doesn't necessarily have it easy.

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.

The data pipeline for billing requires aggregation of usage data across multiple regions / availability zones, what have you, and-in some cases-must be locally aggregated due to EU GDPR concerns. It’s a secondary concern relative to actual customer workloads, with finer granularity costing a premium (as it requires a smaller window of billing data consistency and greater control-pkane resources).

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.

money

In the cloud, resources are allocated and deallocated on the fly — servers are constantly being started and stopped or replaced with other instances. The cloud provider does not know in advance when a resource will be requested or released.

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).