Pricing overview

AWS Lambda's pricing structure is designed around a pay-as-you-go model, where charges are incurred based on the actual consumption of resources rather than pre-provisioned capacity. This approach aligns with the serverless paradigm, wherein users only pay for the compute time and requests their functions process. The primary components of AWS Lambda costs are the number of requests made to a function and the duration for which the function executes, measured in milliseconds. Memory allocation for a function also directly influences its compute duration cost, as higher memory configurations result in a higher GB-second rate.

Beyond the core compute and request charges, other services integrated with Lambda, such as data transfer out from the AWS network, storage for logs in Amazon CloudWatch, and invocation of other AWS services (like S3 or DynamoDB), may contribute to the overall cost. AWS offers a detailed breakdown of Lambda pricing across different regions, as pricing can vary slightly depending on the AWS region where the Lambda function is deployed. Understanding these variables is key to forecasting costs for serverless applications.

For scenarios requiring consistent, low-latency performance, AWS Lambda also offers Provisioned Concurrency. This feature keeps functions initialized and ready to respond, eliminating cold starts. Provisioned Concurrency is billed separately based on the amount of memory and concurrency configured, in addition to the standard request and duration charges for the actual invocations. This allows developers to balance cost optimization with performance requirements for critical applications.

Plans and tiers

AWS Lambda does not operate with traditional 'plans' or 'tiers' in the sense of fixed monthly subscriptions that unlock specific features. Instead, it offers a single, consumption-based model that scales automatically with usage. The primary distinction comes down to the free tier and the subsequent metered usage. There are no premium versions or enterprise plans for Lambda itself; features are universally available, and pricing is purely based on the resources consumed. This model is typical for Function-as-a-Service (FaaS) offerings, emphasizing elasticity and cost efficiency for event-driven architectures.

The billing for AWS Lambda is granular, calculated down to the millisecond for compute duration and per request. This means that costs are directly proportional to the actual work performed by the functions, making it a cost-effective solution for workloads with unpredictable or intermittent traffic patterns. The memory configured for a Lambda function is a critical factor in its pricing. A function with 512 MB of memory running for one second consumes 512 MB-seconds, while a function with 1024 MB of memory running for one second consumes 1024 MB-seconds (or 1 GB-second). This relationship means optimizing memory allocation is a significant factor in cost management.

AWS Lambda Pricing Model Components
Component Price (Approx.) Key Limits/Details Best For
Requests $0.20 per 1 million requests First 1 million requests free per month. Billed in blocks of 1 million. Any invocation of a Lambda function, regardless of duration.
Compute Duration $0.0000166667 for every GB-second First 400,000 GB-seconds free per month. Billed in 1 ms increments, minimum 1 ms. Functions with varying execution times and memory requirements.
Provisioned Concurrency $0.0000041667 for every GB-second (allocated) Billed for the time concurrency is allocated, regardless of invocation. In addition to request/duration charges. Applications requiring low-latency responses and avoiding cold starts.
Data Transfer Out Varies by region and volume (e.g., $0.09 per GB for first 10 TB/month) Standard AWS data transfer rates apply. Free for data transfer in and some internal AWS transfers. Functions that send large amounts of data outside the AWS network.
Ephemeral Storage (Lambda Attachments) Included up to 512 MB for /tmp directory Additional storage (up to 10 GB) configured via Lambda ephemeral storage documentation. Charges apply for usage exceeding 512 MB. Functions requiring temporary local storage during execution.

Free tier and limits

AWS Lambda offers a significant free tier designed to allow developers to experiment and run small-scale applications without incurring costs. The free tier includes 1 million free requests per month and 400,000 GB-seconds of compute time per month. This free allowance is automatically applied to all AWS accounts and resets monthly. The GB-seconds calculation combines the memory allocated to a function and its execution duration. For example, a function configured with 128 MB of memory that runs for 1 second consumes 128 MB-seconds (0.125 GB-seconds). This means the 400,000 GB-seconds free tier is equivalent to approximately 3.2 million seconds (nearly 37 days) of compute time for a function configured with 128 MB of memory.

It is important to note that the free tier applies to the cumulative usage across all Lambda functions within an AWS account in a given month. If an application exceeds these free tier limits, standard pay-as-you-go rates apply immediately for the excess usage. The free tier does not cover all potential costs. For instance, data transfer out from the AWS network and storage costs for logs in Amazon CloudWatch are billed separately at their standard rates, even if your Lambda compute and requests remain within the free tier. Similarly, any usage of Provisioned Concurrency is billed at its specific rates from the first GB-second allocated.

Understanding these limits is crucial for cost management. For many smaller projects, the free tier can be sufficient to run operations without any direct charge for Lambda execution. For larger applications, the free tier acts as a baseline discount, reducing the overall bill. Developers can monitor their usage through the AWS Management Console to track their consumption against the free tier limits and estimate potential costs.

Real-world cost examples

Estimating AWS Lambda costs involves considering the number of invocations, average execution duration, and memory allocated per function. Here are a few illustrative scenarios:

Scenario 1: Simple API Backend

  • Function: A backend API endpoint that retrieves data from a database.
  • Invocations: 5 million requests per month.
  • Average Execution Duration: 50 ms.
  • Memory Allocation: 128 MB.

Calculations:

  • Requests:
    • Free requests: 1,000,000
    • Paid requests: 5,000,000 - 1,000,000 = 4,000,000
    • Request cost: 4,000,000 / 1,000,000 * $0.20 = $0.80
  • Compute Duration:
    • Total compute (MB-seconds): 5,000,000 requests * 50 ms/request * 128 MB = 32,000,000,000 MB-ms
    • Convert to GB-seconds: 32,000,000,000 MB-ms / 1,000 MB/GB / 1,000 ms/second = 32,000 GB-seconds
    • Free GB-seconds: 400,000
    • Since 32,000 GB-seconds is less than the free tier, the compute duration cost is $0.00.
  • Total Estimated Monthly Cost: $0.80 (additional costs for data transfer, logging, etc., not included).

Scenario 2: Data Processing Workflow

  • Function: Image thumbnail generation triggered by S3 uploads.
  • Invocations: 2 million requests per month.
  • Average Execution Duration: 2 seconds.
  • Memory Allocation: 1024 MB (1 GB).

Calculations:

  • Requests:
    • Free requests: 1,000,000
    • Paid requests: 2,000,000 - 1,000,000 = 1,000,000
    • Request cost: 1,000,000 / 1,000,000 * $0.20 = $0.20
  • Compute Duration:
    • Total compute (GB-seconds): 2,000,000 requests * 2 seconds/request * 1 GB = 4,000,000 GB-seconds
    • Free GB-seconds: 400,000
    • Paid GB-seconds: 4,000,000 - 400,000 = 3,600,000 GB-seconds
    • Compute duration cost: 3,600,000 GB-seconds * $0.0000166667/GB-second = $60.00
  • Total Estimated Monthly Cost: $0.20 + $60.00 = $60.20 (excluding S3 storage, data transfer, etc.).

Scenario 3: High-Volume, Low-Latency Service with Provisioned Concurrency

  • Function: Real-time bidding service.
  • Invocations: 100 million requests per month.
  • Average Execution Duration: 20 ms.
  • Memory Allocation: 256 MB.
  • Provisioned Concurrency: 100 instances, 24/7 (730 hours/month).

Calculations:

  • Requests:
    • Free requests: 1,000,000
    • Paid requests: 100,000,000 - 1,000,000 = 99,000,000
    • Request cost: 99,000,000 / 1,000,000 * $0.20 = $19.80
  • Compute Duration (On-demand invocations):
    • Total compute (GB-seconds): 100,000,000 requests * 20 ms/request * 0.25 GB = 500,000 GB-seconds
    • Free GB-seconds: 400,000
    • Paid GB-seconds: 500,000 - 400,000 = 100,000 GB-seconds
    • Compute duration cost: 100,000 GB-seconds * $0.0000166667/GB-second = $1.67
  • Provisioned Concurrency Cost:
    • Total allocated GB-seconds: 100 instances * 0.25 GB/instance * 730 hours/month * 3600 seconds/hour = 65,700,000 GB-seconds
    • Provisioned concurrency cost: 65,700,000 GB-seconds * $0.0000041667/GB-second = $273.75
  • Total Estimated Monthly Cost: $19.80 + $1.67 + $273.75 = $295.22 (excluding data transfer, logging, etc.).

These examples illustrate how different usage patterns and architectural choices, such as employing Provisioned Concurrency, directly impact the total cost. It's vital to use the AWS Pricing Calculator for Lambda for precise estimates based on specific project parameters and region-specific pricing.

How the pricing compares

When comparing AWS Lambda's pricing with alternatives like Google Cloud Functions, Azure Functions, and Cloudflare Workers, several factors come into play, primarily revolving around the billing granularity, free tier generosity, and the ecosystem integrations. All major serverless function providers follow a similar pay-as-you-go model, charging for invocations and compute time, but the specifics of their free tiers and per-unit costs can differ.

  • Google Cloud Functions: Google's offering also provides a free tier, typically including 2 million invocations and 400,000 GB-seconds per month, similar to Lambda's. Post-free-tier pricing for compute duration can be competitive, often slightly varying based on region and memory configuration. Google Cloud Functions also bills for network egress and other integrated services. Developers can explore Google Cloud Functions pricing details for specific comparisons.
  • Azure Functions: Microsoft Azure Functions also has a consumption plan that bills based on execution time and memory, alongside a fixed charge per million executions. Their free grant includes 1 million requests and 400,000 GB-seconds of resource consumption per month. Azure also offers a dedicated plan for more predictable costs, which can be useful for steady-state workloads but moves away from the pure serverless billing model. Detailed pricing is available on the Azure Functions pricing page.
  • Cloudflare Workers: Cloudflare Workers stand out with a different pricing model, focusing on requests and CPU time rather than GB-seconds. They offer a generous free tier of 100,000 requests per day and 10 ms of CPU time per request. This model can be particularly cost-effective for extremely high-volume, low-compute edge functions. Their pricing structure for paid tiers is also request-driven, with additional charges for CPU time beyond the free allowance. Cloudflare's Workers pricing information provides a transparent overview.

A key differentiator often lies in the integrated ecosystem. While the core function execution costs might be similar, the total cost of ownership can vary significantly based on how well the FaaS platform integrates with other services (databases, queues, storage, monitoring) and the pricing of those complementary services. For example, AWS Lambda's deep integration with other AWS services like S3, DynamoDB, and CloudWatch can simplify architecture but may also incur additional costs for those services. Organizations often choose a platform not solely on FaaS pricing but on the overall value and cost of the entire solution stack. An evaluation by an independent organization like Gartner's analysis of serverless computing might offer further insights into market positioning and value propositions.