The key idea here is how cloud VM usage is billed. When you run a virtual machine on Google Cloud, you pay for the time the instance is running. Compute Engine bills by the second (with a minimum charge per instance in many cases), based on the machine type, the region, and any attached resources like disks and network egress. So the statement that Google Cloud doesn’t charge for VM instance hours isn’t true. There are ways to lower costs, such as the Always Free tier for small instances in selected regions, trial credits, sustained use discounts that kick in the more you run, preemptible instances for short-lived workloads, and committed-use contracts for predictable workloads. But in general, VM hours are billable.

Pricing in serverless computing is driven by usage. You aren’t charged a fixed monthly fee or for reserved capacity; you pay for what actually happens when your code runs. That typically means paying per function invocation and for the time the function executes (often tied to the memory it uses), with any additional data transfer charged separately in some setups. This pay-per-use model is why the best description is that pricing is based on actual functions performed—the amount of work your code does determines the cost. The other ideas don’t fit the serverless model. A fixed monthly fee implies paying regardless of usage, which erodes the elasticity serverless aims to provide. Data transfer charges can occur, but they’re not the primary basis for serverless pricing. Provisioned capacity charges you for reserved resources whether you use them or not, which contrasts with the on-demand nature of serverless where resources scale with demand and you’re billed for actual execution.

Rightsizing means adjusting cloud resources to fit actual demand, so you’re not paying for capacity you don’t use or risking performance shortfalls. It involves analyzing workload patterns, performance metrics, and cost, then resizing instances, storage, or databases, or enabling autoscaling to align capacity with need. For example, moving from a large VM to a medium VM if utilization is consistently low, or enabling auto-scaling to handle spikes. This is different from deleting all unused resources, negotiating prices, or tagging for cost allocation. In short, rightsizing is about matching resource size to workload requirements to optimize value.

Blended rates describe distributing charges evenly across the resource fleet, yielding a single standardized hourly rate. This approach averages the costs of different resources or services so you see one predictable price per hour, which simplifies budgeting, forecasting, and chargeback across teams. It helps avoid cost volatility from individual resource price swings because the total cost is spread out evenly, making financial planning more straightforward. The trade-off is less precision: resources that are more expensive or less or more utilized aren’t separately visible in the rate, so you might be paying a bit more or less per hour than the exact usage would imply. Unblended rates, by contrast, keep separate rates for each resource, which provides precise cost visibility per item but makes budgeting more complex. The terms coverable usage or covered usage don’t describe this standardized, fleet-wide averaging concept, so they don’t capture the idea of a single shared hourly rate.