AWS Lambda Pricing for High-Volume APIs in 2026

At 100 million API calls, Lambda’s $0.20 per million request fee adds only $20. For most busy endpoints, AWS Lambda pricing rises or falls on memory allocation, billed milliseconds, and warm capacity.

For bursty API workloads, Lambda provides serverless compute that can follow demand without requiring constant capacity. A reliable estimate starts with the workload you have, not a generic cost-per-request figure. These examples use gross costs, since the account-level free tier allowance may already be shared by other functions.

Region, processor architecture, response size, and concurrency pattern can each change the monthly bill. The calculations below show how to model those variables and prepare for a realistic invoice before a surprise reaches FinOps.

Key Takeaways

• Lambda API costs are driven mainly by billed compute duration in GB-seconds, while request charges remain relatively small at high volume.
• Memory, billed duration, and processor architecture should be tested together; choose the configuration with the lowest GB-second usage that still meets latency and reliability targets.
• Provisioned Concurrency can improve cold-start consistency but adds warm-capacity charges, so schedule it only during latency-sensitive traffic windows.
• API Gateway, NAT gateways, response streaming, logs, storage, and downstream services can exceed the Lambda charge, making a complete cost model essential.
• Use measured production workloads, regional pricing, Savings Plans, and realistic EC2 or container comparisons before changing the deployment model.

How AWS Lambda pricing builds an API bill

Lambda has a usage-based model, but a production API bill has more than one moving part. The official Lambda pricing schedule lists rates by region, architecture, and optional feature.

Unless a calculation says otherwise, examples use US East (N. Virginia), a 30-day month, x86 architecture, 1,024 MB memory, 100 ms average billed duration, 100 million synchronous API requests, 8 KB request payloads, and 12 KB buffered responses. They exclude the free tier, taxes, discounts, API Gateway, logging, Data Transfer, and other AWS services.

Request charges count each invocation

In US East (N. Virginia), Lambda charges $0.20 per one million requests. At 100 million invocations, the request portion is:

100,000,000 / 1,000,000 x $0.20 = $20.00

Payload size doesn’t change Lambda’s per-invocation request charge. A larger invocation payload can affect API Gateway, response streaming, data transfer, and downstream service costs.

AWS includes one million requests per month in the Lambda free tier. That allowance applies to the account’s remaining eligible usage, so don’t subtract it from every function estimate.

Compute duration usually drives the API cost

Lambda bills compute duration in GB-seconds. The calculation multiplies configured memory by execution duration. In US East (N. Virginia), on-demand x86 duration costs $0.0000166667 per GB-second. Arm/Graviton duration costs $0.0000133334 per GB-second.

For the baseline x86 API workload:

100,000,000 requests x 1 GB x 0.100 seconds = 10,000,000 GB-seconds

10,000,000 GB-seconds x $0.0000166667 = $166.67

The gross Lambda total is therefore $186.67 per month before free-tier credits and ancillary services. The 400,000 GB-second monthly free tier allowance is shared at the account level. It can lower a small share of that total only if no other eligible functions have consumed it.

A reusable formula for high-volume API estimates

A high-volume Lambda cost model should separate request charges, compute duration, concurrency charges, and attached-service costs. That separation makes it easier to identify what actually changed after a deployment.

For standard on-demand traffic, use these formulas:

Request cost = max(0, R – Freq) x $0.20 / 1,000,000

Duration cost = max(0, R x M x D – Fdur) x Pdur

Where:

• R is the monthly request count.
• Freq is the unused monthly allowance from the shared free tier, not a function-specific allowance.
• M is allocated memory in GB, so 1,024 MB equals 1 GB.
• D is average billed duration in seconds.
• Fdur is the unused 400,000 GB-second allowance.
• Pdur is the regional, architecture-specific duration rate.

Then add feature and service charges:

Total API cost = request cost + duration cost + Provisioned Concurrency + storage + streaming + networking + API and observability services

This approach matters because a function can process the same request volume at sharply different costs. A memory change affects every millisecond of every invocation. A NAT gateway can create a fixed monthly charge even when Lambda duration remains low.

At extreme scale, duration pricing can also change with AWS volume tiers. Use the actual architecture, region, and forecasted GB-seconds in the AWS Pricing Calculator rather than extending a small-volume rate indefinitely.

A 100 million request Lambda cost model

The baseline workload has 100 million requests, 1 GB of x86 memory, and a 100 ms average billed duration. Its gross on-demand Lambda charge is $186.67 per month.

The table shows how memory allocation interacts with billed duration and architecture. Every row uses US East (N. Virginia), 100 million requests, 8 KB request payloads, and 12 KB non-streamed responses. The comparison assumes no free-tier credits, Provisioned Concurrency, concurrency charges, or ancillary AWS charges.

The lower-memory x86 configuration costs less because its longer duration doesn’t outweigh its smaller memory allocation. Its average runtime rises from 100 ms to 280 ms, though, so that option may fail latency objectives or increase database connection pressure.

The 2 GB configuration completes faster, but its memory-time product is higher. Fast code isn’t automatically cheaper code.

Memory is cost-effective only when the reduction in duration is larger than the increase in allocated memory. Compare GB-seconds, then verify p95 and p99 latency.

If the account still has its entire Lambda free tier available, the baseline x86 calculation falls by $6.67 in duration allowance and $0.20 in request allowance. Shared production accounts often consume those credits elsewhere, so gross costs make safer planning numbers.

Memory tuning and Arm architecture savings

Memory allocation controls heap space while also affecting CPU capacity and related resources. A larger setting can shorten runtime enough to reduce total cost.

Test for the lowest GB-second result

Start with several realistic memory values, then load test each one against production-like dependencies. Record average duration, p95 duration, p99 duration, errors, throttles, and downstream saturation.

The decision rule is simple:

Choose the configuration with the lowest memory x billed-duration product that still meets your latency and reliability target.

For example, the 256 MB scenario in the table consumes 0.07 GB-seconds per request. The 1 GB baseline consumes 0.10 GB-seconds. The 2 GB option consumes 0.12 GB-seconds. That makes the 256 MB configuration cheapest on pure Lambda compute, despite its slower response.

Network waits, slow database queries, and serial external calls can make added memory a poor fix. Profile those dependencies before paying for more CPU.

Arm can lower rate and sometimes runtime

Arm-based Lambda functions use AWS Graviton processors and carry a lower US East duration rate. In the baseline model, moving from x86 to Arm lowers monthly duration cost from $166.67 to $133.33. The $33.34 difference comes before any performance improvement.

Arm is a practical choice for supported runtimes and dependencies. Check container images, Lambda layers, native Node.js modules, Python wheels, Java libraries, and security agents first. A function that silently falls back to incompatible binaries creates a reliability problem that outweighs the rate reduction.

Run equivalent traffic against x86 and Arm versions. Use measured GB-seconds and error rates, not the advertised percentage alone.

Provisioned Concurrency and cold start budgets

Provisioned Concurrency keeps a chosen number of environments initialized. It helps when request latency has little room for a cold start, such as authenticated API calls, checkout flows, or low-latency partner endpoints.

Price the warm pool separately

Provisioned Concurrency has two concurrency charges: capacity allocation for the warm pool and execution for requests it handles. In US East (N. Virginia), x86 allocation costs $0.0000041667 per GB-second. Execution through Provisioned Concurrency costs $0.0000097222 per GB-second, plus standard per-request fees.

Consider an x86 API with 1 GB memory, 100 ms average billed duration, 100 million 8 KB requests, 12 KB responses, and 50 provisioned environments. Assume all traffic stays within those 50 environments, with no on-demand spillover. Enable the pool for eight hours per business day across 22 days, or 633,600 seconds.

Allocation = 50 x 1 GB x 633,600 seconds x $0.0000041667 = $132.00

Provisioned execution = 10,000,000 GB-seconds x $0.0000097222 = $97.22

Requests = $20.00

That workload totals $249.22 per month, before ancillary services. The same baseline on-demand model costs $186.67. Here, the extra $62.55 buys pre-initialized capacity during business hours.

Schedule Provisioned Concurrency around known traffic windows. A pool left active overnight or all weekend continues accruing concurrency charges.

SnapStart is a different startup strategy

SnapStart improves initialization performance for supported Java functions by restoring an execution environment from a snapshot. AWS documents SnapStart cache and restoration billing based on allocated memory, while its current pricing materials list no additional SnapStart charge for Java managed runtimes.

Review AWS SnapStart documentation for runtime support and initialization requirements. SnapStart and Provisioned Concurrency cannot run together, as AWS explains in its Lambda concurrency guidance.

Provisioned Concurrency fits predictable latency-sensitive traffic. SnapStart fits eligible Java workloads that need better startup behavior without paying for a standing pool. Neither replaces right-sizing memory or reducing slow initialization code.

Ancillary API costs can outweigh Lambda requests

A Lambda estimate that stops at requests and duration is incomplete. API Gateway, Application Load Balancer, WAF, CloudWatch Logs, X-Ray, DynamoDB, RDS Proxy, and Data Transfer each bill independently.

VPC routing can create a large fixed charge

Lambda functions have public internet access by default when they are not attached to a VPC. Once attached, they can access only resources available in that VPC unless you configure outbound routing. AWS warns that placing a function in a public subnet does not give it internet access. Private subnets need a route such as a NAT gateway, as described in AWS VPC-connected Lambda guidance.

In US East (N. Virginia), one NAT gateway costs $0.045 per hour plus $0.045 per GB processed. A separate network model with one gateway running for 730 hours and processing 1,000 GB costs:

730 hours x $0.045 = $32.85

1,000 GB x $0.045 = $45.00

NAT gateway total = $77.85

Architecture, Lambda memory, duration, and API payload size do not change those NAT line items. The Amazon VPC pricing page also requires a fresh check for regional rates and cross-Availability Zone traffic.

Streaming, temporary storage, and logs add up

Lambda charges $0.008 per GB for response streaming in US East after the first 6 MB per response. For a separate x86, 1 GB, 100 ms workload with 10 million 8 KB requests and 10 MB streamed responses, each response has 4 MB subject to the charge. The first 6 MB allowance leaves that remaining payload billable.

That equals 40,000 GB using decimal units, or $320.00 before applicable allowances and data-transfer charges. Large payloads can therefore cost more to stream than to compute.

Lambda includes 512 MB of ephemeral storage. Extra storage costs $0.0000000309 per GB-second in US East. On the 100 million-request, 1 GB, 100 ms baseline, configuring 1 GB of ephemeral storage adds 0.5 GB of paid storage per invocation, or about $0.15 per month. It is usually a small line item, but it should still appear in the model.

Compute Savings Plans and the EC2 comparison

Lambda is often cost-effective for uneven demand because idle time doesn’t generate on-demand duration charges. The comparison changes when traffic holds steady for long periods, or when a warm pool becomes permanent.

Apply Savings Plans to the right usage

Compute Savings Plans offer one-year or three-year spending commitments that can cover eligible AWS Lambda duration and Provisioned Concurrency usage, along with services such as EC2 and Fargate. They don’t turn every Lambda bill component into discounted compute, so model requests, streaming, logs, networking, and concurrency charges separately.

Buy against a stable baseline of eligible hourly spend, not an anticipated traffic spike. An oversized commitment reduces flexibility, while an undersized one simply leaves part of the workload at on-demand rates.

Review AWS Savings Plans terms and coverage before treating a discount estimate as a contractual rate.

Compare continuous work with realistic infrastructure

For a 30-day US East x86 example, assume 1 GB memory, one sequential request at a time, 1-second average billed duration, 2,592,000 requests, 8 KB requests, and 12 KB responses. For a gross estimate excluding allowances and ancillary services, Lambda duration costs $43.20 and requests cost $0.52, for a gross total of $43.72.

That number doesn’t establish an EC2 break-even point. A valid comparison must include enough EC2 instances for peak concurrency, multi-AZ availability, load balancing, storage, patching, observability, and idle headroom. Spot instances can cut costs for interruptible asynchronous work, but they aren’t a reliable like-for-like option for synchronous, latency-sensitive APIs.

Move a stable API to EC2, ECS, or Fargate when committed capacity produces a lower total cost and the team can operate it safely. Keep Lambda when traffic remains bursty, work is short-lived, and scaling per request prevents substantial idle capacity.

Cost controls that protect latency and reliability

Cost optimization should reduce waste without raising error rates or tail latency. A lower invoice is not a win if users experience timeouts.

Measure cost by route and version

Track invocations, billed duration, errors, throttles, concurrency, and memory settings for each function version. Pair these metrics with API route data, because a low-cost health endpoint can hide an expensive export route.

If a warm pool is active, reconcile concurrency charges against the active capacity schedule. This can reveal idle capacity or unexpected scaling patterns.

Watch duration after dependency changes. A slower database query or external API can increase billed milliseconds across every active function version. CloudWatch Logs also deserve a retention policy and a review of verbose request logging, especially on endpoints with large bodies.

Set budget alerts and anomaly alerts. Alert on sudden invocation growth, because recursive calls and retry storms can multiply invocation and duration costs quickly.

Keep the business logic portable

Put HTTP parsing, authentication adapters, and Lambda-specific event handling at the edge of the codebase. Keep domain logic in testable modules that do not depend on Lambda event objects.

That structure makes it easier to move a consistently busy route to a container without rewriting the entire API. It also discourages long invocation chains. One inbound request can trigger several functions, each with its own invocation cost, duration, logs, and downstream calls.

Reserved concurrency can limit the blast radius of an unexpected workload. Set it with care, because a limit can also throttle valid production traffic.

Frequently Asked Questions

How much does AWS Lambda cost for 100 million API requests?

In the article’s baseline US East example, 100 million requests cost $20 in request charges and $166.67 in x86 compute charges. The gross Lambda total is therefore $186.67 before free-tier credits, taxes, and ancillary services.

What has the greatest effect on Lambda API pricing?

Memory allocation and billed duration usually have the greatest effect because Lambda charges for GB-seconds. A higher memory setting can reduce runtime, but it is cheaper only when the resulting memory-time product is lower and still meets latency requirements.

Can Arm reduce Lambda costs?

Yes. Arm-based Lambda duration has a lower rate than x86 in the example region, reducing the baseline duration cost from $166.67 to $133.33. Test runtime compatibility, performance, error rates, and measured GB-seconds before switching architectures.

Is Provisioned Concurrency worth the additional cost?

Provisioned Concurrency can be worthwhile for APIs with strict latency targets and predictable traffic windows because it keeps execution environments initialized. It adds allocation and execution charges, so schedule the warm pool carefully and compare its cost with the value of avoiding cold starts.

Which additional services should be included in a Lambda API cost estimate?

Include API Gateway, data transfer, CloudWatch Logs, WAF, X-Ray, storage, streaming, databases, and VPC networking. NAT gateways in particular can create substantial fixed and per-GB charges that do not appear in Lambda’s duration estimate.

Final cost perspective

High-volume Lambda APIs become predictable when teams model GB-seconds, warm-capacity schedules, payload sizes, and attached services separately. Request volume alone rarely explains the bill.

Use measured production durations and realistic payload sizes to compare a portable business logic layer with continuously provisioned infrastructure. Add a regional estimate before changing memory, architecture, or deployment model. The right choice meets the API’s latency target without paying for capacity or network paths the workload doesn’t need.