A webhook handler that runs for a few seconds every hour and a worker that processes jobs continuously might perform the same kind of computation. They should not automatically use the same hosting product. The first can benefit from paying for execution only when work arrives; the second may make better use of a continuously allocated machine.

The usual comparison between serverless, containers and VMs needs one qualification: containers describe packaging and execution, while serverless describes a service model. A managed serverless platform can run containers on infrastructure that the customer never manages directly.

What exactly is being billed?

AWS Lambda pricing includes requests and execution duration for its default compute model, with charges depending on allocated memory. Other modes and features, including provisioned concurrency and managed instances, have their own billing rules.

A VM generally incurs compute charges for the time its allocation runs, regardless of how many application requests arrive. That can be wasteful for a very quiet service but economical when a process uses the allocation consistently.

Containers do not imply one particular meter either. Cloud Run's billing settings distinguish request-based and instance-based billing. With request-based billing, charges relate to request processing and relevant lifecycle activity, with additional conditions for minimum instances. Instance-based billing covers the instance lifecycle and provides CPU allocation outside requests. Sustained workloads can favor that arrangement.

AWS Fargate charges for requested CPU, memory and other applicable resources over the billable task duration, including image download through termination, subject to minimums and granularity. An always-running Fargate task may therefore have a cost profile closer to a VM than an intermittently invoked function.

A break-even example

Assume a VM capable of delivering a particular workload costs $30 per month. Suppose an alternative function-based service would cost $0.00001 per successfully completed request, including its assumed execution charge but excluding shared supporting services.

At one million requests per month, the function cost would be $10. At three million, it would be $30. At six million, it would be $60. Under these deliberately simplified assumptions, the two compute bills cross at three million requests.

This is not a quotation or a universal request threshold. The function cost depends on duration, allocated memory, region, pricing tier and any warm capacity. The VM must also handle the required peak load and response time. If it needs three instances to provide an equivalent service, the comparison changes immediately.

Include storage, network transfer, load balancers, logs and database resources. Those can remain billable regardless of the compute model. See cloud egress costs for why the data path deserves a separate line in the estimate.

Concurrency changes the size of the allocation

A container can process several requests simultaneously. Cloud Run's concurrency documentation describes the configured limit and how it interacts with scaling.

If 100 requests arrive at once and each instance can handle 10 concurrently within the latency requirement, the workload needs roughly 10 active instances for that burst under a simplified model. If each instance can safely handle only two, the corresponding requirement rises to roughly 50. These figures omit startup delay, arrival distribution and ongoing requests, but illustrate the relationship.

An I/O-bound handler may overlap many requests while waiting for a remote service. A CPU-intensive handler may instead compete for processing time when concurrency rises. Measure memory use and tail latency rather than assuming the largest concurrency setting is cheapest.

Warm capacity has a purpose

Cold starts can matter when a request cannot wait for a new instance. Holding a minimum number of instances ready or buying provisioned capacity introduces costs even when traffic is quiet. That is a trade for responsiveness, not automatically wasted capacity.

Short container jobs also need to account for startup and image preparation. If a job takes two seconds to execute but repeatedly spends additional time starting, its billed duration and throughput can differ from a long-lived worker processing the same jobs.

A managed service reduces some host-management work but does not remove responsibility for the application, dependencies, permissions, observability or data recovery. A VM price that ignores the cost of maintaining the system is not directly comparable with a managed service either.

Which workload fits which model?

An intermittent event handler is a good candidate for request-driven execution. A predictable worker with high sustained utilization may suit a VM or an instance-billed container. A service with variable demand and strict latency requirements may use managed containers with warm baseline capacity.

Compare the actual traffic distribution, resource footprint and service objective. The cheapest compute bill is only meaningful when the application continues to serve the same workload at the required performance and reliability.