AWS Lambda Pricing: The Bill Beyond Per-Millisecond

You already know the AWS Lambda pricing pitch: pay per request and per millisecond. What you don't know, until the bill lands, is what that adds up to for your memory size, traffic, and architecture. That gap is where most serverless cost surprises start.

This post closes it. You'll get a reference table for your monthly cost, three worked examples across free-tier, typical, and high-volume workloads, and every cost that doesn't show up on the front page of the pricing docs: CloudWatch Logs, cold-start billing, SnapStart, and two pricing surfaces AWS shipped in the last year.

What AWS Lambda Actually Costs

Before the mechanics, here's the number most people want: what does an hour or a month of Lambda cost at your memory size? The table below uses AWS's confirmed tier-1 duration rates for both architectures in US East (N. Virginia), assuming a function runs continuously all month. Real functions run in bursts, so treat "per month" as a ceiling, not a typical bill.

These are US East (N. Virginia) tier-1, compute-only rates: no request charges, no free tier applied. Other Regions price differently. Once your workload doesn't fit one of these six sizes, or you want request charges and free-tier deductions folded in, the Lambda Pricing Calculator does the math for your Region, architecture, and traffic.

How Lambda Pricing Works

Two dimensions drive nearly every Lambda bill: requests and duration.

Requests and duration, the two dimensions

You pay $0.20 per 1 million requests after the free tier, charged every time your function is invoked, whether by an event (S3, EventBridge) or a direct invoke (API Gateway, SDK, console).

Duration is billed in GB-seconds: execution time, rounded up to the nearest millisecond, multiplied by your configured memory. Memory runs from 128 MB to 10,240 MB and sets proportional CPU, not just RAM. At 1,769 MB you get one full vCPU. That's why the reference table above doesn't scale linearly, and why right-sizing (covered later) is the single most effective cost lever you have.

The base on-demand duration rate in US East (N. Virginia) is $0.0000166667/GB-second for x86 and $0.0000133334/GB-second for arm64.

Tiered duration discounts and the Graviton (arm64) price cut

Two things lower your effective duration rate as usage grows.

arm64 (Graviton2) functions get a duration rate 20% lower than x86, with AWS citing up to 19% better raw performance on top. Functions without architecture-specific native binaries typically migrate with no code changes.

Tiered duration pricing also discounts your compute charge automatically as monthly GB-seconds climb, no opt-in required:

Confirmed x86 rates are $0.0000166667, $0.0000150000, and $0.0000133333/GB-second across the three tiers. arm64 gets its own tiered discounts at higher thresholds, but AWS's public pricing page doesn't expose exact tier-2/3 arm64 rates as plain text. Check the live Lambda pricing page before forecasting a high-volume arm64 workload, rather than assuming a flat 20%-off-x86 calculation.

These tiers are scoped per account, per Region, per architecture. Splitting an equivalent workload across x86 and arm64 in the same Region delays reaching the higher discount tiers on either one.

Lambda's Free Tier in 2026

"Is Lambda free" has two different correct answers, and mixing them up is the fastest way to misjudge what a new project will actually cost.

The Always Free allotment (1M requests + 400,000 GB-seconds)

Every AWS account gets 1,000,000 free requests and 400,000 free GB-seconds every month, permanently, across both x86 and arm64. Provisioned Concurrency narrows that, but not evenly across the bill. AWS's own worked pricing example shows the request allowance still applies to your total monthly invocations, PC-backed or not. Duration is where PC actually loses the free tier: GB-seconds billed while PC is active are charged in full from the first invocation, while duration billed during any part of the month PC is disabled on that function still draws from your normal 400,000 GB-second allowance. The PC allocation charge itself, what you pay to keep environments warm, never touches the free tier, whether or not a single request arrives.

The new $200 sign-up credit, and where it's genuinely unclear

Accounts created after July 15, 2025 also get up to $200 in sign-up and activity credits ($100 at sign-up, up to $100 more for completing specific service activities), valid for 12 months, on top of the Always Free allotment above.

Here's the honest caveat: AWS doesn't fully document what happens to Always Free Lambda usage once a newer account's 12-month credit window closes. Marketing pages describe usage "beyond these monthly limits" as drawing from the credit pool, implying Always Free applies first, but that interaction isn't spelled out in full anywhere. If you're budgeting a long-lived project on a newer account, verify current Free Tier terms directly rather than assume.

Real-World Lambda Cost Examples

Formulas only get you so far. Here's what three workload shapes actually cost, using AWS's own confirmed worked examples.

Staying inside the free tier

A low-traffic function, a scheduled job, a lightly used internal API, that stays under 1,000,000 requests and 400,000 GB-seconds a month costs $0. That's the common outcome for side projects and early-stage services. This only holds for standard on-demand duration: turn on Provisioned Concurrency and its standing allocation charge starts billing immediately, with the GB-seconds it serves billed in full alongside it, regardless of how much of your monthly free tier sits unused.

A typical API backend

A mobile app backend at 1,536 MB x86, 3,000,000 requests/month, 120 ms average duration:

• Compute: 540,000 GB-seconds total, minus 400,000 free = 140,000 billable × $0.0000166667 = $2.33
• Requests: 2,000,000 billable × $0.20/million = $0.40
• Total: $2.73/month

Your real traffic pattern and average duration will differ, so treat this as a shape to compare against, not a universal answer.

High-volume, tiered-discount territory

A 2,048 MB x86 workload at 75,000,000 invocations/month, 60-second average duration, 9 billion GB-seconds total:

• Without tiering: $150,000.30 compute + $15.00 requests = $150,015.30
• With tiering: 6B GB-seconds at the base rate plus 3B at tier 2 = $145,000.29 compute + $15.00 requests
• Total: $145,015.29/month, a $5,000.01 saving from tiering alone, with zero configuration changes required

These figures come straight from AWS's own tiered-pricing worked example, and they don't net out the free tier the way the mobile-app-backend example above does. At this volume that's a rounding error, not an omission: the 1,000,000 free requests would trim $0.20 off the request charge, and the 400,000 free GB-seconds would trim about $6.67 off compute, under 0.005% of the $145,015.29 total combined. Below a few million monthly GB-seconds, always subtract the free tier first, the way the API-backend example does; above it, the free tier stops moving the number.

Tiered discounts apply automatically once your account crosses these monthly GB-second thresholds in a given Region and architecture. Splitting comparable workloads across architectures or Regions delays reaching the higher tiers.

These three shapes bracket most workloads. For yours, the Lambda Pricing Calculator folds requests, free tier, and Region into one estimate instead of three hand calculations. It's a requests-and-duration estimate, not a full bill: it applies a single tier-1 duration rate regardless of volume, so it won't reproduce the tiered-discount math above at multi-billion-GB-second scale, and it doesn't add CloudWatch Logs, SnapStart, Managed Instances, or Durable Functions costs. Use it to size the requests-and-duration core of your bill, then layer the hidden costs below on top by hand.

Hidden Costs That Don't Show Up in the Rate Card

The requests-plus-duration model is real, but it's not the whole bill.

The August 2025 change to cold-start billing

Effective August 1, 2025, AWS standardized INIT-phase (cold-start) billing. Before this, ZIP-packaged functions on managed runtimes didn't have INIT duration counted in Billed Duration; Provisioned Concurrency, custom runtimes, and container-image functions already did. After the change, INIT duration counts for every configuration type. A CloudWatch REPORT line shows the shift:

Before: Duration: 250.06 ms  Billed Duration: 251 ms   Init Duration: 100.77 ms
After:  Duration: 250.06 ms  Billed Duration: 351 ms   Init Duration: 100.77 ms

AWS found the INIT phase occurs in under 1% of invocations for most production workloads, so the impact is usually small, though not zero for cold-start-heavy functions. Re-check cost models built before August 2025 for ZIP-packaged, managed-runtime functions. Mitigations: trim package size with a bundler like esbuild, or use SnapStart or Provisioned Concurrency, both of which already billed INIT duration before this change.

CloudWatch Logs: your invisible second Lambda bill

Every function that logs to CloudWatch, the default, generates ingestion and storage charges separate from your Lambda bill. Since May 2025, these logs bill as Vended Logs with volume-tiered pricing:

Storage after compression bills separately at $0.03/GB-month. Tiering only helps at genuinely large volume: a low-traffic function still pays the top-tier $0.50/GB rate on every byte, making unmanaged debug logging a real cost even at small scale. CloudWatch log groups retain data indefinitely by default unless you set a retention policy. Check every log group for one; AWS's Config rule, cw-loggroup-retention-period-check, flags groups missing it.

Ephemeral storage and SnapStart line items

Ephemeral storage (/tmp) gives 512 MB free, configurable up to 10,240 MB. You're billed only above that, at roughly $0.0000000309/GB-second (AWS's own sources show a small rounding discrepancy here, so verify the live figure before a large-scale forecast).

SnapStart adds two charges: a caching charge (minimum 3 hours per published function version) and a restoration charge each time Lambda resumes from a snapshot. Both are free for Java managed runtimes, chargeable for other runtimes. In one documented AWS example, SnapStart's cache and restore charges made up roughly 50% of total monthly cost at low invocation volume, driven mainly by that fixed 3-hour minimum. Model the cache charge explicitly before assuming SnapStart is a free latency win.

Provisioned Concurrency is the other always-on line item: $0.0000041667 per GB-second (US East, N. Virginia) for every second it's enabled, whether or not requests arrive, and that allocation charge never draws from the free tier. Duration billed while PC is active skips the free tier too; only your request charges keep pulling from the normal monthly allowance. CloudBurn's Provisioned Concurrency cost guide covers when that standing charge is actually worth paying.

New Lambda Pricing Surfaces: Managed Instances and Durable Functions

Two newer surfaces, Managed Instances and Durable Functions, layer their own pricing on top of standard Requests and Duration. If you're only sizing a standard function, skip ahead. If you're evaluating steady-state EC2-backed compute or long-running workflows, here's what each adds.

Lambda Managed Instances

Generally available since November 2025, Managed Instances runs functions on fully managed EC2 instances in your VPC, built for steady-state, high-volume workloads. Pricing: standard request charges ($0.20/million), a 15% management fee on the EC2 on-demand price, and the EC2 charge itself, reducible via Savings Plans or Reserved Instances. You skip Lambda's per-invocation duration charge, you pay for EC2 capacity instead.

Worked example (Graviton3 m7g.xlarge, 100M requests/month, 200 ms average, 3-year Compute Savings Plan): $20.00 requests + $91.40 EC2 (72% CSP discount) + $48.96 management fee = $160.36/month. This depends entirely on instance type and Savings Plan coverage, so treat it as illustrative, and confirm Regional availability before planning around it.

Lambda Durable Functions

Generally available since December 2025, Durable Functions extends Lambda to multi-step, long-running workflows using "steps" and "waits" as checkpoints, pausing for up to a year without incurring duration charges. Pricing adds durable operations ($8.00/million), data written ($0.25/GB), and data retention ($0.15/GB-month, 14-day default) on top of standard compute and requests.

Worked example (1M claims/month, arm64, 1 GB memory, 14-day retention): $421.34 compute + $0.20 requests + $32.00 operations + $26.00 data written + $10.92 data retained = $490.46/month. This depends heavily on your workflow's steps and waits, so treat it as one shape, not a general rate.

Lambda vs Fargate vs Managed Instances

Rather than a rate-by-rate shootout, the more useful framing is workload shape: which compute model fits how your traffic actually behaves.

Spiky, unpredictable traffic

Bursty traffic with long idle periods favors standard on-demand Lambda. You pay only for what actually runs, and the reference table and worked examples above already show what that costs at common memory sizes.

Steady-state, high-volume traffic

Once traffic is steady and high-concurrency enough that you're running close to full-time anyway, the economics shift. Fargate and Managed Instances both let Savings Plans and Reserved Instances apply directly to compute, which Lambda's per-invocation pricing doesn't offer the same way. Managed Instances pairs Lambda's developer experience with EC2's pricing flexibility. For Fargate's own rate tables and hidden fees, see CloudBurn's Fargate pricing breakdown rather than re-deriving those numbers here.

Function URLs vs API Gateway: your entry point changes the bill

How you expose your function changes the bill too. Function URLs add no charge beyond standard Requests and Duration, AWS recommends them for simple, low-traffic APIs. API Gateway adds its own per-call pricing on top of the same Lambda backend cost: REST APIs run $3.50/million down to $1.51/million at volume, HTTP APIs run $1.00/million down to $0.90/million, both with a 1 million call/month free tier. Need auth, throttling, or transformation features? That charge is additive; otherwise a Function URL avoids it entirely.

Lowering Your Lambda Bill

Once you know what you're paying and why, a few levers move the number most.

Right-size memory before anything else

More memory costs more per GB-second, but it also buys more CPU, and a faster run can offset the higher rate. In one AWS example, cost per 1,000 invocations stayed nearly flat ($0.024628 to $0.024638) while duration dropped tenfold (11.722s to 1.465s) between 128 MB and 1024 MB. Don't guess: AWS Lambda Power Tuning tests your function across memory configurations against real payloads and can compare arm64 against x86 cost. AWS Compute Optimizer gives ML-based recommendations once a function has at least 50 invocations over the trailing 14 days.

Smaller levers compound with right-sizing: realistic timeouts (AWS recommends under 29 seconds for synchronous invocations, since a hung execution bills for its full elapsed time), event filtering on event-source-mapped functions so you're not paying to invoke the function just to discard the event, and standardizing on one architecture per Region to concentrate GB-seconds into a single tiered-pricing bucket instead of two.

Compute Savings Plans, and when the commitment isn't worth it

Compute Savings Plans have covered Lambda Duration and Provisioned Concurrency, not Requests, since February 2020: up to 17% off for a 1- or 3-year commitment, no code changes required. See CloudBurn's Compute Savings Plans guide for the full commitment mechanics across Lambda and Fargate.

Here's the nuance most rate-card summaries skip: a Savings Plan commits you to a fixed hourly spend for one to three years, whether or not usage stays there every month. If your duration cost is small or swings widely, run the numbers on your actual baseline before committing. AWS's own sizing guidance is to commit to your steady floor, not your busiest month. A fixed commitment on unpredictable, low-volume spend can cost more than the discount saves. The same applies to Provisioned Concurrency: AWS puts the PC utilization breakeven around 60%; below that, on-demand pricing tends to be cheaper. Use Application Auto Scaling to scale PC down outside known traffic windows instead of leaving it static.

Catch this before it deploys

Over-provisioned memory, missing log retention policies, an always-on Provisioned Concurrency setting nobody revisited, all of it is visible in Terraform or CloudFormation before you deploy. In my experience, waiting for the bill to flag these is the expensive way to find out; shifting cost review left into the pull request is the cheap way. CloudBurn is an open-source policy engine that checks for these patterns during code review, then runs the same rules against your live AWS account. Catching a missing retention policy in a pull request costs nothing; catching it three months into a bill does not.

That estimate covers requests, duration at the tier-1 rate, ephemeral storage, data transfer, and Provisioned Concurrency allocation. It doesn't add CloudWatch Logs, SnapStart, Managed Instances, Durable Functions costs, or the tiered duration discounts covered earlier in this post, so add those in by hand once your volume gets there.

Conclusion: Key Takeaways

AWS Lambda pricing comes down to requests and duration for most workloads, and arm64 cuts duration cost 20% with little to no code change. The free tier is genuinely permanent for standard usage, but a separate $200 credit now applies to new accounts on top of it, know which one is covering your traffic. CloudWatch Logs, cold-start billing, and SnapStart are the line items teams most consistently underestimate, and each is checkable against your own CloudWatch data. The newer surfaces, Managed Instances and Durable Functions, change the pricing model entirely for steady-state or long-running workloads. Above all, right-sizing memory beats almost every other lever you could reach for first.

Run your own numbers through the Lambda Pricing Calculator rather than eyeballing the table for anything outside those six sizes. If cold starts are pushing you toward Provisioned Concurrency, read when it's actually worth the always-on charge before you turn it on.

Frequently Asked Questions