[admiun]

They do, yes. Rounded up to the nearest 100ms, scaled for chosen RAM capacity: https://aws.amazon.com/lambda/pricing/ Note that this doesn't measure actual RAM use, although they do display it after lambda runs.

Data traffic is already measured and priced accordingly in AWS so that's not something new for Lambda.

[sokoloff]

That's not exactly what marktt was asking. For example, calling sleep (explicitly or implicitly while waiting on network input) would not incur much CPU cost under marktt's accounting method but does incur wall clock charge under Lambda.

(It's totally understandable and fair that it does; it's just different than what he asked.)

[michaelt]

One could think of Lambda as charging for (A * network bandwidth + B * RAM usage * wall clock time + C * CPU time + D * Disk IO) where C and D are both zero.

[marktangotango]

From a capacity planning perspective, your goal should be 100% cpu utilization per box. Allocating excessive, unutilized wall clock time is wasted capacity. Same applies for ram/heap per call. These are the same considerations that played out in client/server vs mainframes for so many years.

Mainframe budgeting of cycles, memory, an IO was highly effective and efficiently utilizing resources. It's a model of computation that has disappeared, but is still relevant. When google app engine first came I had hoped it would utilize this model, but instead went the containerization route.