AWSAWS LambdaServerless

`aws_lambda_function` cost estimation

A serverless function billed by request count and execution duration. Free tier covers 1M requests and 400,000 GB-seconds per month.

An aws_lambda_function runs code on demand without provisioning servers. Pricing has two main dimensions: requests and compute duration.

Requests are billed at a flat per-invocation rate. The first million requests per month are free at the account level (across all functions); beyond that, each invocation costs a tiny but cumulative amount.

Duration is the more interesting dimension. Lambda bills in GB-seconds, calculated as the function's memory size (in GB) multiplied by execution time (rounded up to the nearest millisecond). A function with 512 MB memory that runs for 200 ms is billed as 0.5 GB × 0.2 s = 0.1 GB-seconds. The same function with 1 GB memory that runs for 100 ms (because more memory often means more CPU) is also 0.1 GB-seconds but finishes twice as fast. The free tier covers 400,000 GB-seconds per month.

Because Lambda's cost is usage-based by definition, c3x cannot estimate it from the Terraform configuration alone. The Terraform resource sets the memory and timeout, but the actual monthly invocation count and average duration come from a c3x-usage.yml file. Without that file, c3x reports Lambda costs as "depends on usage" and shows the per-unit rate.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "aws_lambda_function" "image_processor" {
  function_name = "image-processor"
  role          = aws_iam_role.lambda_exec.arn
  handler       = "index.handler"
  runtime       = "nodejs20.x"
  memory_size   = 1024
  timeout       = 30

  filename         = "lambda.zip"
  source_code_hash = filebase64sha256("lambda.zip")
}

Pricing dimensions

What you actually pay for when you provision aws_lambda_function.

Dimension	Unit	What's being charged
Requests	per request	Flat per-invocation rate. First 1M requests per month free at the account level. $0.20 per 1M requests beyond the free tier
Compute duration	per GB-second	Memory size (GB) multiplied by execution time, rounded up to the nearest millisecond. First 400,000 GB-seconds per month free. $0.0000166667/GB-second for x86_64; $0.0000133334/GB-second for arm64 (Graviton)
Provisioned concurrency	per GB-second	If aws_lambda_provisioned_concurrency_config is set, you pay a continuous rate to keep workers warm. Cheaper than on-demand for predictable high-volume workloads.
Data transfer out	per GB	Bytes returned from Lambda to clients outside AWS. Standard AWS egress rates apply.

Sample C3X output

With c3x-usage.yml specifying 10M monthly requests and 200 ms average duration:

aws_lambda_function.image_processor
├─ Requests                    9.0M (after free tier)    $1.80
└─ Duration                   1.6M GB-sec               $26.67

OVERALL TOTAL                                            $28.47

Optimization tips

Common ways to reduce aws_lambda_function cost without changing the workload.

Switch to arm64 (Graviton)

20%

Set architectures = ["arm64"] on the function. Graviton is 20% cheaper per GB-second than x86_64 and typically performs as well or better for Node, Python, Go, and Rust workloads.

Right-size memory using power tuning

Workload-dependent, often 30-60%

More memory often means a faster runtime, which can lower total GB-seconds even though the per-second rate is higher. Run the AWS Lambda Power Tuning tool to find the sweet spot for each function.

Switch from on-demand to provisioned concurrency for hot paths

10-40% on high-volume functions

If a function fires more than ~1M times per hour and cold starts hurt, provisioned concurrency is cheaper per request than on-demand. For low-volume functions, stay on-demand.

Cache external calls inside the function handler

Latency-driven

A function that fetches the same secret or config on every invocation pays duration cost for that fetch. Cache outside the handler (in the module scope) and the fetch happens once per warm worker.

FAQ

Why does c3x show Lambda cost as zero or 'depends on usage'?

Lambda is usage-based. Without a c3x-usage.yml file specifying expected requests and duration, c3x cannot produce a meaningful number. Add the function under monthly_requests and request_duration_ms in the usage file.

Does c3x handle Lambda Layers or container images differently?

No. Layers and container images affect cold-start time and storage, but Lambda's billed cost is still just requests and GB-seconds. Container images stored in ECR incur a separate aws_ecr_repository charge.

What about provisioned concurrency?

If you also define an aws_lambda_provisioned_concurrency_config, c3x picks up the provisioned amount and bills it as a continuous GB-second rate at the provisioned-concurrency price tier.

Does c3x estimate EventBridge or API Gateway invocations?

Those are separate resources (aws_cloudwatch_event_rule, aws_api_gateway_rest_api). c3x estimates each independently. Lambda's invocation cost is the same regardless of trigger; the trigger has its own per-event cost.

Can I model Lambda Free Tier in c3x?

Yes. c3x deducts 1M requests and 400,000 GB-seconds from the first Lambda function's monthly cost in each estimate. If you have many functions, the free tier applies once per account, so c3x's per-function estimate is slightly conservative.