Serverless Function Pricing: CPU, Memory, Requests, and Egress

Serverless Function Pricing: CPU, Memory, Requests, and Egress

Serverless function pricing should be easy to estimate before a small team deploys code.

The problem is that many serverless bills are not simple. One platform may charge for requests, memory duration, CPU allocation, egress, logs, warm instances, build minutes, gateway traffic, or add-on observability. A workload that looked cheap in development can become harder to forecast when traffic, response size, logging, or runtime duration changes.

Raff Technologies takes a simpler approach with Raff Functions: memory and active CPU are the two metered numbers. Requests and egress are free, a spend cap is on by default, and every account gets a monthly free tier for function usage.

This guide explains how to think about serverless function pricing before deployment: what memory means, what active CPU means, why requests and egress can make other platforms harder to predict, and how small teams should estimate function cost for webhooks, cron jobs, storage events, batch jobs, and small APIs.

If you are still deciding whether the workload belongs on functions or a VM, read Serverless Functions vs VMs: What Small Teams Should Choose first.

Serverless pricing has two different cost shapes

Serverless pricing usually follows the shape of execution.

Instead of choosing a fixed VM size and paying for it while it exists, a function platform bills around how often the function runs and how much resource it uses during execution. That can be excellent for spiky, scheduled, or event-driven work. It can be less ideal when the workload is always busy, requires a heavy runtime, or runs for long periods without interruption.

There are two main cost shapes:

Functions are not automatically cheaper than VMs. VMs are not automatically wasteful.

The right question is:

Does this workload benefit from paying only while it runs?

For example, an image-resize job that runs only when users upload files is a strong function candidate. A queue worker that runs at high utilization all day may be easier to forecast on a VM or Kubernetes worker.

Serverless pricing is strongest when the workload has a clear beginning, clear ending, and idle periods.

The Raff Functions pricing model

Raff Functions uses two metered numbers:

1. Memory
2. Active CPU

Requests and egress are free. Cron scheduling, logs, and metrics are included. A spend cap is on by default. Raff also includes a monthly free tier of:

• 100,000 GB-seconds
• 10,000 vCPU-seconds

The published Raff Functions rates are:

The simple version:

Function cost =
  billable memory GB-seconds
+ billable active CPU seconds

This matters because many teams can reason about two numbers more easily than five or six billing lines.

The important distinction is that memory is based on the provisioned memory over the wall-clock lifetime of the instance, while active CPU is billed only while code is actually on CPU. Waiting on I/O should not behave the same as CPU-heavy work.

That makes the model easier to reason about for common function workloads:

• Webhooks that wait on external APIs
• Storage events that process files
• Cron jobs that call databases
• Small APIs with short execution time
• ETL jobs with mixed CPU and I/O
• AI or batch jobs that need longer execution windows

Memory pricing means duration still matters

Memory pricing is based on GB-seconds.

A GB-second combines two things:

1. How much memory the function is provisioned with
2. How long the function instance runs

A simple way to estimate memory usage is:

memory GB-seconds =
  memory in GB × duration in seconds × invocations

Example:

Invocations: 1,000,000 per month
Memory: 256 MB = 0.25 GB
Average duration: 200 ms = 0.2 seconds

Memory GB-s =
  0.25 × 0.2 × 1,000,000
= 50,000 GB-s

If this is the only memory usage for the month, it fits inside the 100,000 GB-s monthly free tier.

The most important cost levers are:

• Invocation count
• Average duration
• Memory setting
• Whether the function scales into multiple concurrent instances
• Whether optional warm instances are enabled

Do not set memory by guesswork forever. Start with a reasonable value, then review usage. Too little memory may slow the function down. Too much memory may raise memory GB-second usage without improving runtime.

For small teams, the practical goal is not always the lowest memory number. The goal is the best balance between runtime, reliability, and cost.

Active CPU pricing separates compute from waiting

Active CPU pricing is useful because not all function time is equal.

Some functions spend most of their time doing CPU work:

• Image processing
• PDF generation
• Compression
• Data transformation
• Encryption
• CPU-heavy parsing
• AI inference
• Video or audio preprocessing

Other functions spend much of their time waiting:

• Calling an external API
• Waiting for a database response
• Reading or writing object storage
• Waiting on a webhook response
• Performing lightweight request routing

A function that waits on I/O should not necessarily be priced like a function burning CPU the whole time.

That is why Raff separates memory and active CPU. Memory measures the provisioned runtime footprint. Active CPU measures CPU time while the code is actually on CPU.

A rough mental model:

wall-clock duration = how long the function instance exists
active CPU time = how much CPU the code actually consumes

This is especially relevant for webhook handlers and API integrations. A billing webhook may receive an event, validate a signature, write a row, call another API, and return. The wall-clock time may include waiting, but the active CPU time may be lower.

For cost planning, identify whether the workload is CPU-heavy or I/O-heavy.

The more CPU-heavy the function, the more active CPU becomes the key number.

Requests and egress change the predictability of serverless bills

Requests and egress can make serverless bills harder to forecast.

A request fee charges based on how many times the function is invoked. That may seem small per request, but it becomes another moving part. Egress charges based on outbound data transfer. That can be especially hard to forecast when response sizes, downloads, media files, or API payloads grow.

Raff Functions keeps requests and egress free for the functions product.

That means teams do not need to model these function-specific cost lines:

• Request count fees
• Outbound egress from function responses
• Cron trigger fees
• Basic logs and metrics as a separate product bill

This is useful for workloads like:

• Webhooks with unpredictable retry behavior
• Public API endpoints with many small requests
• Object-storage event handlers
• Report download preparation
• Image transformation endpoints
• Automation callbacks
• Scheduled API syncs
• Developer tools and internal APIs

Free requests do not mean cost does not change. Memory and active CPU can still increase with usage. But removing request and egress fees makes the bill easier to reason about.

For a small team, fewer billing dimensions are often more valuable than a tiny discount on one meter.

Estimate cost before deployment

Before deploying a function, estimate the workload with five inputs:

1. Monthly invocations
2. Average duration
3. Memory setting
4. Active CPU behavior
5. Response size or egress pattern

On Raff, response size does not add function egress charges, but it still helps the team understand workload shape. A function returning tiny webhook responses is different from a function returning large generated files. Large files should often be stored in Raff Object Storage and returned through object storage patterns instead of direct function responses.

A simple estimate table:

With the monthly free tier applied:

Memory:
67,500 GB-s - 100,000 free GB-s = $0.00

Active CPU:
33,750 vCPU-s - 10,000 free vCPU-s = 23,750 billable vCPU-s
23,750 × $0.000020 = $0.475

This is a simplified planning example. Real usage depends on actual runtime, memory setting, CPU behavior, concurrency, and workload mix. The important point is that a small team can estimate the main cost drivers before deployment.

Common workload examples

Different function workloads behave differently.

Webhook receiver

A webhook receiver is usually a strong serverless fit.

External service → Function → Database or queue → Quick response

Cost drivers:

• Invocation count
• Signature validation time
• Database write time
• Retry volume
• Logging volume

Optimization:

• Return quickly
• Store event ID
• Avoid heavy work inside the request
• Send longer work to a queue, function, or worker
• Keep response payload small

Image resize after upload

Image resizing is often CPU-heavy.

Object Storage upload → Function → Resize → Object Storage output

Cost drivers:

• Number of uploads
• Image size
• Processing time
• Memory requirement
• CPU time

Optimization:

• Resize only required sizes
• Store outputs in object storage
• Avoid reprocessing existing images
• Use metadata to track completed variants

Scheduled cleanup job

Cron jobs are usually easy to estimate.

Cron schedule → Function → Database cleanup or API sync

Cost drivers:

• Schedule frequency
• Average duration
• Database/API response time
• Memory setting

Optimization:

• Reduce unnecessary frequency
• Batch safely
• Use indexes
• Avoid scanning full tables
• Log summaries, not every row

Long-running ETL or batch task

Batch functions need careful planning.

Trigger → Function → Transform data → Database/Object Storage

Cost drivers:

• Duration
• Memory
• Active CPU
• Retry behavior
• Output size
• Failure recovery

Optimization:

• Make tasks idempotent
• Split very large jobs into chunks
• Store intermediate results safely
• Track progress in a database
• Use object storage for files and artifacts

Lightweight API endpoint

Small APIs can be a strong fit when traffic is spiky.

HTTP request → Function → API response

Cost drivers:

• Invocation count
• Average duration
• Memory
• Cold start sensitivity
• External API waiting time

Optimization:

• Keep handler small
• Avoid unnecessary dependencies
• Use standard handlers
• Keep secrets and bindings clean
• Consider warm instances only for latency-critical paths

When a VM may cost less

A VM may be cheaper or cleaner when the workload is always running.

For example, if a worker processes jobs all day with steady CPU usage, a VM can be easier to forecast. The team pays for capacity and keeps using it. A function can still work, but the usage-based model may not provide the same benefit when there is little idle time.

Use Raff VM when:

• The workload runs constantly
• The app needs a full Linux environment
• Docker Compose is the deployment model
• SSH debugging matters
• Custom packages are required
• Several services must run together
• The workload needs persistent local processes
• Capacity-based monthly pricing is easier to plan
• The team wants server-level control

A pricing decision should include operations.

A VM may require more patching, process management, and scaling decisions. A function may require more attention to triggers, stateless design, runtime limits, retries, and event behavior. The cheaper bill is not always the cheaper operating model.

For the architecture decision, read Cloud VM vs App Platform for Startups and Production VPS Checklist Before Launching a SaaS App.

Spend caps matter for small teams

A spend cap is not a small feature. It is a financial safety guard.

Serverless workloads can grow quickly because functions are easy to trigger. A webhook retry storm, bad cron loop, public API spike, broken client, or repeated object-storage event can create more execution than expected.

Raff Functions has a spend cap on by default. When the cap is reached, functions pause instead of creating a runaway bill.

That matters for small teams because the team may not have a dedicated infrastructure finance process. A default cap helps prevent cost surprises while the product is still learning traffic patterns.

A good operating rule:

• Set a cap before production traffic.
• Monitor usage during the first week.
• Review 5-minute usage windows after launch.
• Raise the cap only after expected traffic is understood.
• Treat sudden usage increases as product and security signals.

Spend caps do not replace monitoring, but they create a safer default.

Logs and metrics should not become a second bill

Observability is part of function operations.

A team needs to know:

• How many times the function ran
• How long it took
• Whether it failed
• Which trigger caused it
• Which request produced which logs
• Whether p95 latency changed
• Whether errors increased
• Whether cold starts matter
• Whether retries are happening

Raff Functions includes logs and metrics for every invocation, with live log tail, search, level filters, 14-day retention, count, p50, p95, and error rate per function.

This matters because some serverless systems become hard to forecast when the function bill is only one part of the real operating cost. If logs, metrics, tracing, and alerting require a separate paid setup, the total bill can feel different from the compute estimate.

For small teams, included observability reduces the number of add-ons needed to operate the function safely.

Warm instances should be used intentionally

Scale-to-zero is one of the strongest serverless cost advantages.

When a function is idle, it does not need to keep a full server running. Raff Functions scales to zero, and optional warm instances are available at 30% of the memory rate for latency-critical paths.

That creates a decision:

Do not keep every function warm by default.

Warm instances can improve latency, but they also change the cost shape because some capacity stays ready. Use them only when latency matters enough to justify the always-ready baseline.

A good pattern:

• Keep webhooks scale-to-zero unless latency is customer-critical.
• Keep cron jobs scale-to-zero.
• Keep file event processors scale-to-zero.
• Consider warm instances for user-facing APIs with strict latency needs.
• Revisit warm settings after measuring p50 and p95 latency.

Pricing should influence architecture, not distort it

Pricing should guide architecture, not force unnatural design.

Do not split a simple application into ten functions only because the first estimate looks cheap. Each function adds deployment, ownership, logs, environment variables, secrets, testing, and failure modes.

Also do not keep every background task on one VM just because the VM already exists. If scheduled jobs and webhooks are slowing the main app, the "free" capacity may be costing user experience and developer time.

A good Raff architecture often looks mixed:

Raff VM = main app
Raff Managed Database = durable records
Raff Object Storage = uploads and files
Raff Functions = event-driven tasks

This keeps each workload in the right cost model.

Use functions for work that starts and ends cleanly. Use VMs for full environments and persistent services. Use managed databases for durable records. Use object storage for files and artifacts.

Serverless pricing checklist

Before deploying a production function, answer these questions:

• What triggers the function?
• How many invocations per month are expected?
• What is the average duration?
• What is the p95 duration?
• How much memory does the function need?
• Is the workload CPU-heavy or I/O-heavy?
• Does it need warm instances?
• Does it write durable records to a database?
• Does it store files in object storage?
• Is retry behavior controlled?
• Is the function idempotent?
• What happens if the trigger fires repeatedly?
• What spend cap should be set?
• Who owns the function?
• What logs and metrics should be reviewed?
• Should this run as a VM worker instead?

The last question is important. A function is not the right answer just because the platform supports it.

Common pricing mistakes to avoid

Comparing only compute price

Compute is only one part of the operating model.

Requests, egress, logs, metrics, warm instances, retries, and development workflow can change the real cost.

Ignoring duration

A function that runs twice as long may cost roughly twice as much on duration-based meters.

Optimize slow database calls, external API waits, and unnecessary dependency loading.

Overprovisioning memory

More memory can improve performance for some workloads, but it should be measured.

Do not keep oversized memory settings if runtime does not improve.

Treating every endpoint as a function

Some apps are easier on a VM.

Use functions for clear event-driven units of work, not as a default replacement for all application structure.

Forgetting retry storms

Webhook retries, failed jobs, or repeated storage events can create unexpected invocation volume.

Design idempotency and set spend caps.

Returning large files directly from functions

Large files should often live in object storage.

Use functions to authorize, transform, or generate metadata, then store artifacts in object storage when appropriate.

Keeping warm instances everywhere

Warm instances are useful for latency-sensitive functions, but they add baseline cost.

Use them selectively.

Serverless function pricing should be predictable before launch

Small teams should not discover their function bill after production traffic arrives.

Estimate invocation volume, duration, memory, active CPU behavior, and whether the workload truly benefits from usage-based execution. On Raff Functions, the model is intentionally narrow: memory and active CPU are metered, while requests and egress are free. The monthly free tier, included logs and metrics, and default spend cap make it easier to start safely.

Use Raff Functions for event-driven tasks, webhooks, cron jobs, object-storage events, and one-off work. Use Raff VM when the workload needs a full Linux environment, persistent services, Docker Compose, SSH access, or capacity-based cost planning.

Then check Raff pricing and compare the workload shape before choosing the deployment model.