A workload runs continuously at moderate load. Finance asks why the serverless bill is four times the previous instance cost. Explain the crossover and how you would calculate it.

What is being tested

Whether you can price elasticity rather than assume it is free, and whether you can do a back-of-envelope calculation rather than argue from preference.

The mechanism

Serverless pricing charges for elasticity you are not using. Per-invocation and per-GB-second rates carry a premium over raw compute, and that premium is worth paying when capacity would otherwise sit idle. A workload at continuous moderate utilisation has no idle capacity to eliminate, so it pays the premium for nothing.

The calculation

Work out the effective duty cycle: total execution time divided by wall-clock time, multiplied by average concurrency.

• Serverless cost is roughly invocations × duration × memory × rate.
• Instance cost is roughly instance-hours × rate, regardless of utilisation.

Where they cross depends on the provider and the memory allocation, but the rule of thumb is consistent: above roughly 30–50% sustained utilisation of an equivalent instance, the instance wins, and the gap widens fast. Below about 10%, serverless usually wins decisively.

There is a second term people omit: with serverless you pay per unit of allocated memory for the whole duration, so a function allocated 2 GB because it briefly needs it is charged 2 GB for its entire runtime. Profiling and reducing the allocation is often the largest single saving available without changing anything architecturally.

Before migrating away

Check whether the workload is actually continuous or merely appears so. A workload invoked steadily at low concurrency may still be well suited to functions if concurrency is low and duration is short. The pathological case is the opposite: high concurrency, long durations, sustained — which is a service, and should be one.

Also check the hidden costs on the other side: an always-on instance needs patching, monitoring, scaling configuration and on-call attention. If the team is small, several thousand pounds a year of premium may still be cheaper than the engineering time. Say so explicitly rather than letting finance optimise a number that omits it.

The architectural answer

Most systems should be mixed, and that is not a compromise. Functions at the edges — event handling, webhooks, irregular jobs, glue — where duty cycle is genuinely low and operational relief is the point. Containers or instances for sustained services. Dedicated capacity for the one path with a hard latency floor.

Real-time media is the clearest example of that last case: sustained throughput, predictable low latency, direct networking control and no tolerance for cold starts point at dedicated capacity for the media path — while the signalling, scheduling and billing surfaces around it have completely different profiles and can live anywhere.

What a strong answer adds

Naming the migration cost. Moving a working serverless workload to instances has a real engineering cost, and if the annual saving is smaller than the migration, the correct answer is to reduce the memory allocation, leave it alone, and revisit at higher volume.