Decoding Serverless Pricing: A Comprehensive Guide to AWS, Azure, and Google Cloud

Cloud computing has fundamentally shifted how organizations architect, deploy, and scale applications. Among the most transformative offerings is serverless computing, which abstracts infrastructure management entirely and bills only for resources consumed during execution. This pay-per-use model can dramatically reduce costs compared to traditional provisioning, but only if you understand the nuanced pricing structures behind it. Misinterpreting a pricing table or overlooking an obscure charge can quickly turn a lean serverless architecture into a budget line item that spirals out of control. This guide breaks down the serverless pricing models of the three major cloud providers—Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)—and offers actionable strategies to keep your serverless costs predictable and manageable.

Before diving into provider specifics, it is important to note that serverless pricing is rarely a simple per-invocation cost. Every provider layers in dimensions such as execution duration, memory allocation, provisioned concurrency, network egress, and even the number of resources used (like storage or APIs). A thorough understanding of these dimensions is essential for accurate cost forecasting.

AWS Lambda: The Market Leader

AWS Lambda, launched in 2014, set the standard for Function-as-a-Service (FaaS) pricing. Its model is straightforward on the surface but includes critical nuances that impact real-world bills.

Core Pricing Components

  • Requests: AWS charges per million requests. The first 1 million requests per month are free. After that, the rate is $0.20 per million requests across most regions. This component scales linearly with your invocation count.
  • Duration: This is the largest cost driver for many workloads. Duration is measured in GB-seconds, which multiplies the memory allocated (in GB) by the execution time (in seconds), rounded up to the nearest millisecond. The typical price is $0.0000166667 per GB-second for x86 architecture. With 128 MB (0.125 GB) of memory, one million seconds of execution costs about $2.08. With 1 GB of memory, the same duration costs $16.67. Crucially, AWS now charges in millisecond increments—previously rounds of two milliseconds were standard—giving finer granularity for short-running functions.
  • Provisioned Concurrency: If you need to pre-warm functions to avoid cold starts, you pay for provisioned concurrency even when the function is idle. This is charged per GB-second of provisioned capacity, regardless of actual usage, plus standard request and duration charges when the function runs.

Additional Costs Often Overlooked

  • Network Egress: Data transferred out of AWS to the internet or to other regions is billed at standard EC2 data transfer rates (typically $0.09 per GB for the first 10 TB). For a serverless application handling large files or frequent API responses, egress can dominate the total cost.
  • External Storage and APIs: Lambda often works in concert with DynamoDB, S3, or API Gateway. Each of these services has its own pricing (e.g., DynamoDB read/write capacity units, S3 PUT/GET requests). API Gateway charges per API call, with costs ranging from $1.00 to $3.50 per million requests depending on the region and caching.
  • Lambda@Edge: When running functions at CloudFront edge locations, the pricing differs. Requests cost $0.60 per million, and duration is $0.00005001 per 128 MB-second, which is about three times the standard Lambda rate.

For a detailed breakdown, always consult the official AWS Lambda pricing page.

Azure Functions: Consumption and Premium Plans

Azure Functions uses a similar consumption-based model but adds a Premium plan that eliminates cold starts and offers dedicated instances. Understanding which plan you choose is critical to cost accuracy.

Consumption Plan Pricing

  • Execution Count: The first 1 million executions per month are free. After that, $0.20 per million executions.
  • Resource Consumption (GB-seconds): The free tier includes 400,000 GB-seconds per month. Beyond that, the rate is $0.000016 per GB-second. This is nearly identical to AWS Lambda's duration pricing, but note that Azure rounds execution time to the nearest 100 milliseconds (for durations under 10 seconds) or to the nearest second (for longer durations). This can slightly inflate costs for functions that run repeatedly in short bursts.

Premium Plan Pricing

Azure Functions Premium is ideal for workloads that require predictable latency, more powerful instances, or virtual network connectivity. Under this plan:

  • You pay for a baseline number of always-ready instances (minimum 1) at a fixed hourly rate per vCPU and memory (around $0.076 per vCPU-hour and $0.009 per GB-hour for the first 1 vCPU and 2 GB).
  • Additional instances scale on demand with burst pricing that is higher than consumption but lower than always-on instances.
  • Execution count and duration are also billed, but at reduced rates (for example, $0.01 per million executions for Premium).

Hidden Costs to Watch

  • Storage and Blob Triggers: Azure Functions often use Blob Storage for triggers. Each blob scan adds to storage transaction costs, which can accumulate for high-volume event streams.
  • Azure App Service Plan: If you host your Functions on an App Service plan (dedicated infrastructure), you are billed for the plan’s compute and memory regardless of function execution. This is not truly serverless pricing, but it offers predictable costs.
  • Data Transfer: Like AWS, Azure charges for outbound data transfers. Rates start at $0.087 per GB for the first 10 TB, but can vary by region.

Always refer to the Azure Functions pricing page for current rates.

Google Cloud Functions and Cloud Run: A Containerized Approach

Google Cloud offers two primary serverless compute services: Cloud Functions (similar to Lambda and Azure Functions) and Cloud Run (serverless containers). Pricing for both shares a common framework centered on invocations and compute time.

Cloud Functions (1st and 2nd Gen)

  • Invocations: The free tier includes 2 million invocations per month. After that, $0.40 per million invocations.
  • Compute Time (CPU-seconds and GB-seconds): Billed separately for CPU and memory. For 1st gen, the rate is $0.0000025 per GHz-second and $0.0000025 per GB-second. For 2nd gen, the pricing is more granular: $0.000016 per vCPU-second and $0.0000025 per GB-second. This means a 1 vCPU, 2 GB function running for 1 second would cost $0.000021 in compute time alone (plus invocation).
  • Networking: Google Cloud includes a generous free tier for network egress (1 GB per month to all destinations combined). After that, egress to the internet costs $0.12 per GB for the first 10 TB, which is higher than AWS and Azure. Consider this if your function serves externally-facing APIs with significant payload sizes.

Cloud Run (Fully Managed)

Cloud Run abstracts the container runtime and charges only for resources consumed during request processing, plus a small fee for idle instances that are kept around for a few minutes after the last request (request-based pricing is $0.000016 per vCPU-second and $0.0000025 per GB-second, identical to Cloud Functions 2nd gen). Note that Cloud Run also charges for container startup time if a cold start occurs, which is not billed for on Cloud Functions unless using concurrency. For always-on scheduled jobs, Cloud Run Jobs offers per-second billing with a 1-minute minimum.

Common Cost Pitfalls

  • Memory Oversizing: Google Cloud’s pricing is directly proportional to memory and CPU. Over-provisioning memory for trivial functions can double your compute costs.
  • VPC Connector: If your serverless function needs to access resources inside a VPC, you must provision a VPC connector which costs $0.026 per hour plus data processing fees.
  • Cloud Scheduler & Pub/Sub: Triggering a function via Cloud Scheduler or Pub/Sub incurs additional costs per job execution and per message, respectively.

For exact pricing, visit Google Cloud Functions pricing and Cloud Run pricing.

Comparing the Three: Where Do the Real Differences Lie?

While the base pricing of all three providers is remarkably similar—around $0.20 per million requests and $0.000016 per GB-second—the real cost differences emerge from:

  • Free tier generosity: Google Cloud offers 2 million invocations per month free, double the 1 million from AWS and Azure. For low-traffic applications, Google Cloud can be the cheapest.
  • Granularity of billing: AWS now bills per millisecond, Azure rounds to 100ms (or 1s), and Google rounds to 100ms for Cloud Functions but per-second for Cloud Run. For functions that run for a few milliseconds, AWS has an edge.
  • Provisioned concurrency costs: AWS’s provisioned concurrency pricing is relatively high; Azure Premium plan offers a more predictable hourly rate; Google Cloud’s Cloud Run allows min-instance settings with no extra charge for idle capacity (though you pay for allocated CPU/Memory even when idle).
  • Egress pricing: Google Cloud is the most expensive for outbound data ($0.12/GB vs $0.09 for AWS and $0.087 for Azure). If your functions frequently respond with large payloads, consider AWS or Azure.

Financial and Architectural Strategies for Cost Control

Understanding pricing is only half the battle. The following tactics will help you keep serverless costs predictable, especially as your application scales.

1. Profile Your Functions with Tracing

Use distributed tracing tools (AWS X-Ray, Azure Application Insights, Google Cloud Trace) to identify functions with unexpectedly long durations or excessive memory usage. A single inefficient function can dominate your bill. Once identified, optimize code (e.g., use connection pooling, reduce dependency loading) or increase memory to speed up execution—sometimes a memory increase lowers total cost because duration decreases disproportionately.

2. Implement On-Demand Scaling with Care

Serverless platforms auto-scale, but uncontrolled scaling can lead to cost spikes during traffic bursts. Set concurrency limits per function to cap maximum concurrent invocations. For AWS, use reserved concurrency; for Azure, set function app scale limits; for Google Cloud, configure max instances per service. This protects against runaway costs from a misconfigured function.

3. Use Pay-as-You-Go with Reserved or Commitment Discounts

AWS offers Compute Savings Plans that apply to Lambda duration (at a discount of 17–40% in exchange for a 1- or 3-year commitment). Azure offers Reserved Instance pricing for Premium plan functions, and Google Cloud has committed use discounts for Cloud Run (if you use GKE or Compute Engine as well). For stable workloads, committing to an annual plan can cut compute costs significantly.

4. Design for Batch Efficiency

If you process many small events (e.g., messages from a queue), batch them into fewer invocations. For example, AWS Lambda can process batches of up to 10,000 SQS messages per invocation. This reduces the request count, saving on the per-invocation fee, while duration cost increases only slightly. Similarly, Azure Functions can batch Event Hub events, and Google Cloud Functions can use Pub/Sub with batch settings.

5. Monitor and Alert on Anomalies

Set up budget alerts and cost anomaly detection. Most cloud providers allow you to set monthly budget thresholds and trigger alerts when spending exceeds 50%, 80%, or 100% of the budget. Use cloud-native monitoring tools (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing) to track serverless spend per function or service.

Real-World Scenarios: When Serverless Pricing Surprises

To illustrate, consider a simple image-resizing function that processes 10 million images per month. On AWS Lambda with 1 GB memory and an average execution time of 200 ms:

  • Requests: (10M – 1M free) * $0.20/M = $1.80
  • Duration: 10M * 0.2s = 2M seconds. GB-seconds = 1 GB * 2M = 2M. Cost = 2M * $0.000016667 = $33.33
  • Total compute: ≈ $35.13 per month (plus S3 costs for source and output).

On Google Cloud Functions with same specs (2M free invocations, 2M seconds duration):

  • Requests: (10M – 2M) * $0.40/M = $3.20
  • GB-seconds: 2M * $0.0000025 = $5.00
  • CPU-seconds: assume 1 GHz = 2M * $0.0000025 = $5.00
  • Total compute: ≈ $13.20

Google Cloud would be cheaper for this workload. But if the image processing involves downloading a 5 MB file from an external source, the egress on Google Cloud could add $6 per GB (5 MB * 10M = 50,000 GB? Wait: 5 MB per image * 10 million = 50 terabytes; that would be astronomically high. More realistic: function outputs a 200 KB thumbnail. Then egress is 2 TB. On AWS egress: first 1 TB $0.09/GB = $90, next 1 TB $0.085 = $85, total $175. On Google: first 1 TB free? Actually Google's free egress is 1 GB per month to all destinations, so you pay $0.12/GB for first 10 TB = $240+. So the cheaper compute on Google is dwarfed by egress. This scenario highlights that egress costs must be factored into the total cost of ownership.

Bringing It All Together

Serverless computing offers tremendous cost advantages over traditional infrastructure when patterns align—low and variable traffic, short-lived functions, and efficient code. But the pricing models are not monolithic. AWS Lambda excels with fine-grained billing and a mature ecosystem. Azure Functions offers flexibility through consumption and premium plans, with strong integration into the Microsoft ecosystem. Google Cloud Functions and Cloud Run provide a generous free tier and container-centric options that can be more cost-effective for high-invocation, short-duration workloads, provided egress is minimal.

To make an informed choice, model your expected usage across all three providers, including ancillary services like storage, databases, and data transfer. Use the official pricing calculators (each provider offers one), and test with real workloads in a sandbox environment. By understanding these pricing models at a granular level, you can design a serverless architecture that remains not only scalable and responsive but also financially sustainable as your business grows.