Serverless functions cost compared: Lambda vs Azure Functions vs Cloud Functions
AWS Lambda, Azure Functions, and Google Cloud Functions all bill invocations plus compute (memory times duration), with a free tier. The models are close; the real cost differences come from configuration and the surrounding services. Here is the comparison.
Quick answer
AWS Lambda, Azure Functions, and Google Cloud Functions price serverless the same way: a charge per invocation plus compute (memory times duration, in GB-seconds), each with a monthly free tier. The rates are close, so the real cost differences come from configuration (memory sizing, idle warm capacity) and the surrounding services the functions call, not the per-invocation price.
The three major clouds offer function-as-a-service with strikingly similar pricing: pay per invocation and per unit of compute consumed. The headline rates differ only modestly, so choosing a provider on function price alone rarely moves the needle. What matters is how efficiently you configure functions and what they cost you downstream.
The shared model
| Provider | Bills for | Free tier |
|---|---|---|
| AWS Lambda | Invocations + GB-seconds | Monthly requests + GB-seconds |
| Azure Functions | Executions + GB-seconds (Consumption) | Monthly executions + GB-seconds |
| Google Cloud Functions | Invocations + GB-seconds + GHz-seconds | Monthly invocations + compute |
All three charge per invocation and per GB-second of memory-time, with a free tier that covers low-volume workloads. Google separates CPU (GHz-seconds) from memory in its model, and each provider has premium or provisioned tiers for consistent performance, but the core consumption pricing is close across the three.
Where real cost differences come from
Because the rates are close, the differences that matter are configuration and context. Memory sizing (which sets both cost and, on Lambda and others, CPU) determines cost per invocation. Idle warm capacity, provisioned concurrency on Lambda, premium plans on Azure, minimum instances on Google, adds always-on cost if misused. And the surrounding services, the database, queue, or API the function calls, often cost more than the function itself, as covered in serverless cost optimization.
Which is cheapest?
For a given workload the three are usually within a small margin, and the cheapest depends on the exact memory, duration, and volume, not a headline rate. Far more important is running functions on the cloud where their dependencies live, to avoid cross-cloud latency and egress, and configuring them efficiently. Choose the provider your architecture already uses, and optimize configuration, rather than picking a cloud for a marginal function-price difference.
Optimizing on any cloud
The levers are identical across providers: right-size memory to the cost-optimal point, cut duration with efficient code, reduce invocations through batching and caching, limit idle warm capacity, and move to provisioned compute when steady high volume makes per-request pricing more expensive. Because the models match, the same serverless-versus-provisioned crossover applies on all three.
FAQ
Which is cheapest: Lambda, Azure Functions, or Cloud Functions?
For a given workload they are usually within a small margin, and the cheapest depends on the exact memory, duration, and volume rather than a headline rate. Choosing a provider on function price alone rarely matters; running functions where their dependencies live, to avoid cross-cloud egress, and configuring them efficiently matters far more.
How do serverless function pricing models compare?
AWS Lambda, Azure Functions (Consumption), and Google Cloud Functions all charge per invocation plus per GB-second of memory-time, with a monthly free tier. Google separates CPU from memory in its model, and each has premium or provisioned tiers, but the core consumption pricing is close across the three.
What actually drives serverless cost differences?
Configuration and context, not the provider's headline rate. Memory sizing sets cost per invocation, idle warm capacity (provisioned concurrency, premium plans, minimum instances) adds always-on cost if misused, and the surrounding services the function calls often cost more than the function itself.
Should I choose a cloud based on function pricing?
No. The function rates are close, so the marginal difference rarely justifies choosing a cloud. Run functions on the cloud where their dependencies (databases, queues, APIs) live to avoid cross-cloud latency and egress, and choose the provider your architecture already uses, then optimize configuration.
How do I optimize serverless function cost on any cloud?
The levers are identical across providers: right-size memory to the cost-optimal point, cut duration with efficient code, reduce invocations through batching and caching, limit idle warm capacity, and move to provisioned compute when steady high volume makes per-request pricing more expensive than a reserved instance.
Does C3X estimate serverless function cost?
C3X prices the serverless function resources in your Terraform across clouds, so their configuration cost appears before deploy. Because invocation volume and duration are usage-driven, you model those to estimate the full function cost, plus the surrounding services they call.
What to do next
Compare serverless across clouds for your workload. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.