Compute: capacity-time, not work

Why does a cheaper-per-hour engine often cost more per useful hour?

Compute: you are billed for capacity-time, not for work

Compute meters occupancy. The billed quantity is capacity × time. The useful quantity is work done. The ratio between them is utilization, and it is entirely your problem. So

Minimum billing increments are fixed cost in dollars

A minimum increment is the fixed cost per operation of the vendor, shown on your bill. A 60-second minimum against 5-second jobs means you pay 12× for the work. The natural batch size is exactly that ratio: consolidate small jobs until the job duration is larger than the billing increment. Run twelve 5-second jobs inside one 60-second billed slot, and the waste disappears.

Parallelism is not free

Under occupancy pricing, parallelism looks free: ten machines for one hour cost the same as one machine for ten hours. That is true only while efficiency stays constant. But more machines also mean more coordination. Scalability models (the Universal Scalability Law) show that past a certain number of workers, throughput goes down. Beyond that peak you pay strictly more money for a strictly slower answer. This is the cost of coordination, now with a price tag.

Burstable, credit-based machines hide one more term: they earn credits when idle and are throttled when the credits run out. The meter hides the throttling, and it contaminates any measurement taken on such machines: a benchmark run with full credits does not represent steady state.