Blog
Cloud Optimizationbluebill.io — bluebill.io - Kevin Meyer

Serverless cost control: pay for what you use, not what you fear

Serverless bills scale with invocations, duration and memory settings — small configuration choices compound fast. Here is how to keep Lambda and friends cheap without slowing anything down.

Serverless cost control: pay for what you use, not what you fear

Serverless promises that you only pay for what you use. That is true — but what you use is shaped by configuration choices most teams set once and never revisit.

Where serverless bills actually grow

Three levers dominate serverless cost. Memory allocation is also CPU allocation: doubling memory doubles the price per millisecond, but often more than halves duration, so the cheapest setting is rarely the smallest. Invocation patterns matter more than code: a chatty frontend polling an endpoint every second costs 60 times more than one polling every minute. And log retention quietly becomes the largest line item — CloudWatch or equivalent logging at debug level in production adds up fast.

Right-size memory with data, not guesses

Run a memory-tuning pass on your ten most-invoked functions. Measure billed duration at 256MB, 512MB, 1GB and 2GB under realistic load. Most teams find one of two surprises: functions over-provisioned by habit, or CPU-bound functions that get cheaper when given more memory because they finish sooner.

Tame invocations at the edge

Cache aggressively at the CDN layer. Use event-driven triggers instead of polling. Batch queue messages so one invocation processes fifty records instead of fifty invocations processing one. Each of these cuts invocation count, which is the metric the bill actually follows.

Set log policies like budgets

Decide per function: what log level ships to production, and how long logs are retained. Seven to thirty days is enough for most workloads. Anything longer should be a deliberate decision with a cost estimate attached.

The takeaway

Serverless cost control is not about writing less code — it is about measuring the three levers (memory, invocations, logs) on the functions that matter and reviewing them quarterly. Twenty minutes of tuning usually pays for itself within the first billing cycle.