They would be willing to do this probably if you let them evict your entire workload from memory during the period you were not paying for it, and then were able to charge you for CPU time and some additional charge to reload workload into memory from hibernation.

Most workloads ALSO hold memory (which is a key constraint) over the entire wall clock time, and the delays and impacts/costs of hibernating out the memory and then bringing it back so you can just be charged for CPU time may not make sense.

They could also charge you some rate for CPU seconds + Gb-seconds of memory used? Sort of the ultimately flexible cloud platform. You could apply the same sort of thinking to other resources, but it works best for CPU/memory I think.

That would be ideal, as it more closely fits consumption to billing. But potentially harder for end users to reason about. AWS's bills are already notorious.

I'd bet a significant portion of their margins come from this, given Lambda's focus on I/O-bound workloads.

If the profits exist there, then others might eventually find it advantageous to have this metric in the future.

Maybe even accounting for strong and weak nuclear forces (not sarcasm...we are engineering at the quantum level now, soon it will be apart of a business metric. Instead of 'equipment' being servers, it might be the domain-space-time used).

You pay for more than cpu cycles. Yu are paying for those cycles to occur at a particular wall time and for some segment of memory to be reserved during that time as well.