AWS · ServerlessIntermediate level36 min readOctober 16, 2026

AWS Lambda: pricing, memory and how to cut the bill

By Mathieu Kerbel

Key facts

Billing: Per 1 ms of duration, rounded up, at the memory you configure, plus each request [38]
Memory: 128–10,240 MB in 1 MB steps; CPU comes in proportion, one vCPU at 1,769 MB [9]
Timeout: 15 minutes at most per invocation, 3 seconds by default [12]
Concurrency: 1,000 concurrent executions per account and Region, by default [13]
Cold starts: Under 1% of invocations, typically, and their Init time is billed as duration [8]
Recursive loops: About 16 invocations in one chain through functions, SQS, S3, SNS or EventBridge before Lambda stops the next; detection is free [25]

AWS Lambda runs your code without a server to manage, and bills each function by its requests and by the time its code runs, measured in GB-seconds of the memory you give it. The requests and the GB-seconds are rarely the whole Lambda bill: the front door (Amazon API Gateway or a load balancer; a function URL adds no charge), the logs, the queue and the network around a function bill on other lines, and a function that is busy all day pays more per vCPU-hour than a container or an instance would. This article explains what runs a Lambda function under the hood, how AWS Lambda pricing works line by line, and the ways AWS documents to reduce Lambda costs, priced with the list prices of the Paris Region (eu-west-3). Four architectures show what the levers do to whole monthly bills, and the cost section opens with an index of the levers, in the order to work through them.

Prices in this article are AWS list prices for the EU (Paris) Region, in USD before tax, from the AWS Price List. The offer files and their publication dates are listed in the Sources section, and each table repeats the dates of its own prices. Lambda bills memory in MB and duration in GB-seconds, at 1,024 MB to the GB, as the pricing page's examples convert. Monthly amounts (730 hours), totals, percentages and break-evens are computed from these prices. The free tier is left out.

What AWS Lambda is

In AWS's words, "AWS Lambda is a serverless compute service. With Lambda, you can run code without provisioning or managing servers." Lambda "automatically manages the underlying infrastructure – including server maintenance, capacity provisioning, scaling, and patching", and the pricing page sums up the pay model in one line: "AWS Lambda is a serverless compute service that charges you only for what you use."

Lambda is now more than one kind of function. "Lambda provides three compute primitives, each designed for different workload patterns", and AWS has given the original one a name: "Event Functions is the name for the original Lambda function type that runs your code in response to events and API calls." The API and the templates keep the word function, "so you don't need to change any code, infrastructure templates, or IAM permissions". Two more ways to run Event Functions have joined them: Lambda Managed Instances, "on your current-generation Amazon EC2 instances", and durable functions, which "can run for up to one year when invoked asynchronously". Each bills on a different basis:

Lambda's ways to run code, and what each is billed for

Compute type	What it runs	Billed for
Event Functions	"Run code in response to events or API calls without managing servers"	"Per-request + GB-seconds of execution time"
Lambda Managed Instances	Event Functions on EC2 instances in your account, several requests at a time	Requests, the EC2 instances, and a management fee of 15% of their On-Demand price
Durable functions	Event Functions that checkpoint their progress and suspend while they wait	Requests and duration, plus durable operations and the data they write and keep
Web Functions	"Run web applications and API backends as HTTP servers"	"Per request, plus active CPU time (billed in 1 ms increments) and memory for each execution environment's lifetime"
MicroVMs	"Isolated compute environments with near-instant startup and a total lifespan of up to 8 hours (including both running and suspended time)"	"Per-second of compute while running + snapshot storage while suspended"

This article prices Event Functions in full, and Managed Instances, durable functions and Web Functions in a paragraph each. The Paris price list of October 14, 2026 has no MicroVMs row, so they get no price here. In AWS's words, "Lambda Event Functions are priced based on the number of requests served and the duration your code runs, measured in GB-seconds. You choose the memory allocated to your function and get proportional CPU and resources."

How Lambda works under the hood

AWS documents Lambda at the level of the function, its execution environments and their lifecycle, concurrency and the network, and each of them is a line of the bill: the request that invokes the function, the duration of every environment's work, the cold starts paid as duration, the environments kept ready with provisioned concurrency, the NAT gateway of a function in a VPC. How the fleet that hosts the environments is built and where an environment is placed are not in the pages this article cites, and are left out.

Functions, triggers and event source mappings

"A Lambda function is a piece of code that runs in response to events", such as a file uploaded to an Amazon S3 bucket, and "A Lambda function handler is the method in your function code that processes events." Events arrive in two ways. With a trigger, the function responds to events from another service, such as a call through API Gateway or an upload to Amazon S3: "To make your function respond to events, you set up a trigger." For streams and queues, an event source mapping fetches them: "Event source mappings poll the source for new data, batch records together, and then invoke your function with the batched events." Each invocation is a request on the bill, and how a function is invoked decides how many it bills:

How a function is invoked, and the requests it bills

Invocation	How it works	Requests billed
Synchronous	Lambda runs the function and waits for the response	One per call
Asynchronous	Lambda queues the event, then runs the function	One per event up to 256 KB, plus one per 64 KB above, up to 1 MB; each retry too, two by default
Event source mapping	Lambda polls a queue or a stream, then invokes with a batch	One per batch

Synchronously, "Lambda runs the function and waits for a response". Asynchronously, as Amazon S3 and Amazon SNS invoke, Lambda queues the event, and retries are invocations too: "If the function returns an error, by default Lambda attempts to run it two more times" (errors and retries). Size counts as well. "You are charged for 1 request per each asynchronous Event for first 256 KB. Individual event size beyond 256 KB is charged 1 additional request for each 64 KB of chunk upto 1 MB", says the pricing page. An event source mapping invokes once per batch, which is why the queue-worker pattern below starts there.

Execution environments: one microVM each, one request at a time

"Lambda invokes your function in an execution environment, which provides a secure and isolated runtime environment". The Lambda FAQs say what isolates it: "Every Lambda execution environment runs inside a dedicated Firecracker microVM with its own kernel, memory, and file system — no two environments share a kernel or memory space." And one environment serves one request: "Event Functions isolates each request in its own environment." The scaling guide draws the consequence, "For each concurrent request, Lambda provisions a separate instance of your execution environment", and an environment that is handling a request "is busy and cannot process other requests":

What happens when a request reaches a Lambda function

A request arrives through a trigger, here API Gateway, or through a direct invoke. Lambda sends it to a free execution environment of the function.
Each execution environment runs in its own Firecracker microVM and handles one request at a time. Concurrency is the number of environments busy at once: requests per second times the average duration.
If none is free, Lambda creates one: it downloads the code, starts the environment and runs the code outside the handler (the Init phase). That cold start adds latency and is billed as duration, $0.0000166667 per GB-second on x86.
After an invocation Lambda freezes the environment and keeps it for a while; the next request reuses it without Init. Lambda still replaces environments every few hours.
Every invocation writes its START and REPORT lines, plus the function's own logs, to CloudWatch Logs, billed per GB ingested ($0.5985 in the Standard class) and per GB-month stored.

That rule is the root of the bill. A request that waits for a database or another API keeps its environment busy, and the duration runs while it waits: on Event Functions you pay for waiting in GB-seconds. Lambda spreads the work for availability: it "runs your function in multiple Availability Zones to ensure that it is available to process events in case of a service interruption in a single zone" (Resilience in AWS Lambda).

Init, Invoke and Shutdown: what each phase bills

An environment's life has three phases. "In the Init phase, Lambda performs three tasks": it starts the extensions, bootstraps the runtime and runs the function's static code, and "The Init phase is limited to 10 seconds" for on-demand functions. Then each Invoke runs the handler, and "The function's timeout setting limits the duration of the entire Invoke phase." Between invocations, "Lambda freezes the execution environment when the runtime and each extension have completed and there are no pending events", and "When the function is invoked again, Lambda thaws the environment for reuse": objects declared outside the handler "remain initialized", and /tmp stays as "a transient cache that can be used for multiple invocations".

The bill follows the phases. "Duration charges apply to code that runs in the handler of a function as well as initialization code that is declared outside of the handler" (AWS Lambda pricing), and with extensions, "duration also includes the time it takes for code in the last running extension to finish executing during shutdown phase". Frozen time is not duration on demand. Shutdown lasts up to 2,000 ms "with one or more registered external extensions", and the environment does not live forever: "Lambda terminates execution environments every few hours to allow for runtime updates and maintenance—even for functions that are invoked continuously."

The life of an execution environment, and what is billed

Init starts the extensions, bootstraps the runtime and runs the function's static code, within 10 seconds for on-demand functions. Its time is part of the billed duration.
Each Invoke is billed from the moment the code starts until it returns, rounded up to the nearest millisecond, at the memory configured.
Between invocations Lambda freezes the environment. On demand, duration counts only the time code runs; with provisioned concurrency, the environment itself is billed for as long as it is configured.
Shutdown gives extensions up to 2 seconds to finish; that time counts as duration. Lambda also shuts environments down every few hours, so Init comes back even under steady traffic.

Cold starts are billed

A cold start is the Init phase of a new environment. When a request finds no free environment, "the service downloads your code, starts the environment, and runs any initialization code outside of the main handler", and the lifecycle guide is plain about the price:

You are charged for this time, and it adds latency to your overall invocation duration.

AWS, Understanding the Lambda execution environment lifecycle

AWS says how rare they are: "Cold starts typically occur in under 1% of invocations. The duration of a cold start varies from under 100 ms to over 1 second. In general, cold starts are typically more common in development and test functions than production workloads." What makes them long is the function's own start-up: "The largest contributor of latency before function execution comes from initialization code", driven by the size of the package and its layers, the amount of initialization work and the time to set up connections, so "It's important that functions only import the libraries and dependencies that they need." For functions using on-demand concurrency, Lambda "might occasionally initialize execution environments ahead of invocation requests". Trim the Init phase is the lever.

Memory sets the CPU

You choose one setting, and the CPU follows it: "Lambda allocates CPU power in proportion to the amount of memory configured". "You can configure memory between 128 MB and 10,240 MB in 1-MB increments. At 1,769 MB, a function has the equivalent of one vCPU (one vCPU-second of credits per second)." AWS calls memory "the principal lever for controlling the performance of a function", recommends "that you only use 128 MB for simple Lambda functions, such as those that transform and route events to other AWS services", and adds that "If a function is CPU, network or memory-bound, then increasing the memory setting can dramatically improve its performance."

Does more memory cost more? Duration is billed in memory times time, so not when the code is bound by its CPU: twice the memory buys twice the CPU, and if the code then runs in half the time, the GB-seconds are the same. The Serverless Applications Lens says it in billing terms, "the faster the initiation, the cheaper and more value your function produces due to 1-ms billing incremental dimension". An illustration, for CPU-bound code that does halve its time:

One million invocations a month of CPU-bound code in Paris, on x86: twice the memory, half the duration

1,024 MB, 400 ms each Illustrative

Line	A month
Compute	$6.87
Requests: 1 million a month1 M requests × $0.20 /M req	$0.20
Duration: 1 million a month × 0.4 s × 1 GB400,000 GB-s × $0.0000166667 /GB-s	$6.67
A month, computed	$6.87

2,048 MB, 200 ms each Illustrative

Line	A month
Compute	$6.87
Requests: 1 million a month1 M requests × $0.20 /M req	$0.20
Duration: 1 million a month × 0.2 s × 2 GB400,000 GB-s × $0.0000166667 /GB-s	$6.67
A month, computed	$6.87

2,048 MB, 200 ms costs the same as 1,024 MB, 400 ms, computed.

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 14, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Code that waits on a database or another API does not finish sooner with more CPU: it pays the larger memory for the same wait. The same 120 ms at 3,008 MB instead of 1,024 MB costs 2.94 times as much, $293.75 against $100.00 of x86 duration for 50 million invocations, computed. Ephemeral storage is set apart from memory, "between 512 MB and 10,240 MB, in 1-MB increments". Right-size memory is the lever.

Arm or x86

Lambda runs on two architectures, x86_64 and "arm64 – 64-bit ARM architecture, for the AWS Graviton2 processor" (instruction set architectures). AWS's claim is qualitative, "Lambda functions that use arm64 architecture (AWS Graviton2 processor) can achieve significantly better price and performance than the equivalent function running on x86_64 architecture", and the pages this article cites give no percentage. The price list does: in Paris, a GB-second on Arm costs 20.0% less than on x86, computed, on every duration tier and for provisioned concurrency, while a request costs $0.20 per million on both. What Arm saves depends on the duration you measure on it: Move to Arm is the lever.

Concurrency: reserved and provisioned

"Concurrency is the number of in-flight requests that your AWS Lambda Event Function is handling at the same time", and AWS gives the formula: "Concurrency = (average requests per second) * (average request duration in seconds)". An account starts with "a total concurrency limit of 1,000 concurrent executions across all Event Functions in an AWS Region", and a function scales by "1,000 execution environment instances every 10 seconds"; requests beyond that "fail with a throttling error (429 status code)". Two settings change a function's share, and only one costs money:

Reserved and provisioned concurrency: what each does, and what it costs in Paris

What it does: Sets both the most and the fewest environments a function can use, out of the account's concurrency
What it costs: Nothing: there is no charge for configuring it
Cold starts: Possible, as on demand

What it does: Keeps a number of environments initialized before the requests arrive
What it costs: $0.0000048673 per GB-second configured on x86, used or not, plus the duration of the requests that run on it
Cold starts: Avoided while the environments last; still possible when Lambda resets one

What differs: a cap and a floor at no charge, against environments kept ready and billed for every second they are configured.

"There is no charge for configuring reserved concurrency for an Event Function", while "Configuring provisioned concurrency incurs additional charges to your AWS account" (Configuring provisioned concurrency). Provisioned concurrency goes on a version or an alias, "You cannot use provisioned concurrency with the $LATEST version of any Event Function", it takes "a minute or two of preparation", and it does not rule out every cold start: "you can still experience a cold start delay if Lambda has to reset the execution environment." Provisioned concurrency prices it in Paris.

SnapStart

SnapStart moves the Init phase to the moment you publish a version: "Lambda takes a Firecracker MicroVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and intelligently caches it to optimize retrieval latency." It is not a guarantee: "Functions that are invoked infrequently might not experience the same performance improvements", and "it works as a best-effort optimization, and does not guarantee elimination of cold starts" (Lambda FAQs). It runs on three runtimes, and is free on one of them: "For Java managed runtimes, there's no additional cost for SnapStart".

The runtimes SnapStart runs on, and what each pays for it

Runtime	SnapStart costs
Java 11 and later	No additional cost
Python 3.12 and later	The snapshot cache, and each restore
.NET 8 and later	The snapshot cache, and each restore

"SnapStart does not support provisioned concurrency, Amazon Elastic File System (Amazon EFS), Amazon S3 Files, or ephemeral storage greater than 512 MB." The cache and the restores are priced in SnapStart, ephemeral storage and the other options.

A function in a VPC

"By default, Lambda functions have access to the public internet. When you attach your function to a VPC, it can only access resources available within that VPC". Lambda connects it through "Hyperplane Elastic Network Interfaces, or Hyperplane ENIs", each supporting "up to 65,000 connections/ports", and "if a Lambda function remains idle for 14 days, Lambda reclaims any unused Hyperplane ENIs and sets the function state to Inactive." A public subnet is not a way out: "Connecting a function to a public subnet doesn't give it internet access or a public IP address." For IPv4, the documented way to reach the internet is a NAT gateway in a public subnet; for IPv6 traffic, the same guide (internet access for VPC-connected functions) routes dual-stack subnets through an egress-only internet gateway, and "There is no charge for an egress-only internet gateway". The guide also documents the Amazon S3 gateway endpoint. Each path bills its own way:

How a function attached to a VPC reaches what it calls, and what each path bills

Destination	Path	Billed
The internet, over IPv4	A NAT gateway in a public subnet	Per hour, and per GB processed
The internet, over IPv6	An egress-only internet gateway, from dual-stack subnets	Nothing for the gateway; data transfer out
Amazon S3	A gateway endpoint	Nothing: "There is no cost for this option"
Other AWS services	An interface endpoint, or the NAT gateway	Per hour in each Availability Zone, and per GB

The NAT gateway is billed "for each hour that your NAT gateway is available and each gigabyte of data that it processes" (Pricing for NAT gateways), which is why Keep AWS-service traffic off the NAT gateway is a lever of its own.

Managed Instances, Web Functions and durable functions

Lambda Managed Instances change the one-request rule: "Lambda Managed Instances support multi-concurrent invocations, where one execution environment can handle multiple invocations at the same time", and "Managed Instances use containers running on EC2 Nitro instances to provide isolation rather than Firecracker" (the EC2 article explains the Nitro System). Publishing a version "launches three instances by default for AZ resiliency", and AWS points them at "High volume-predictable workloads - Ideal for steady-state workloads without unexpected traffic spikes." Capacity providers group the instances, and "By default, Lambda chooses optimal instance types for your workload." Their timeout can reach "5,400 seconds (90 minutes)" for asynchronous and event source mapping invocations, Amazon MQ and Amazon DocumentDB ones excepted (function timeout).

An Event Function on demand against Lambda Managed Instances, in Paris

Requests per environment: One at a time
Isolation: A Firecracker microVM per environment
Billed: $0.20 per million requests and $0.0000133334 per GB-second on Arm, while code runs
While idle: Nothing

Requests per environment: Several at the same time
Isolation: Containers on EC2 Nitro instances in your account
Billed: $0.20 per million requests, the EC2 instances, and a fee of 15% of their On-Demand price
While idle: The instances, three by default, for as long as they run

What differs: a price per request and per millisecond of work, against instances that many requests share and that bill while they run.

Web Functions serve HTTP directly: "Your code listens on a network port and handles requests directly", and "You pay for requests, active CPU time, memory consumed over the life of each execution environment, and data transfer." The memory part is the trap of low traffic, as it "continues to accrue while the execution environment exists, including idle time between requests", and "AWS Lambda Web Functions currently support Node.js runtimes only." Durable functions "are regular Lambda functions using a checkpoint/replay mechanism to track progress and support long-running operations through user-defined suspension points", and while one waits, "for on-demand functions, does not incur duration charges until execution resumes" (AWS Lambda pricing). Their Paris prices are in Managed Instances, Web Functions and durable functions in Paris.

What Lambda is used for

AWS points each kind of work to a compute type or an option across its documentation: What is AWS Lambda?, the Event Functions guide, Lambda Managed Instances, provisioned concurrency, SnapStart and ephemeral storage:

Workloads and the Lambda compute type or option AWS points them to

Workload	Compute type or option
File processing, long-running workflows, database operations, scheduled and periodic tasks, stream processing, web, mobile and IoT backends	Event Functions
Request-response or event-driven workloads: APIs, data processing, automation	Event Functions
Web applications and API backends that serve HTTP traffic directly	Web Functions
Persistent environments running user or AI-produced untrusted code	MicroVMs
High-volume, predictable, steady workloads; performance-critical applications	Lambda Managed Instances
Interactive applications with users initiating requests, the most sensitive to latency	Provisioned concurrency
Latency-sensitive APIs, user flows and data processing	SnapStart
ETL jobs, machine learning inference, data and graphics processing	More ephemeral storage

For events, the FAQs draw the line plainly: "If your code is instead triggered by AWS events such as messages, streams, or storage changes (Amazon SQS, Amazon Kinesis, Amazon S3, or Amazon EventBridge), use an Event Function." When functions work with a relational database, AWS's advice is a pool: "Amazon RDS Proxy can help manage connection pooling and scaling from ephemeral consumers like Lambda functions". The Serverless Applications Lens ties it to the bill, since reusing connections "will increase performance and reduce execution time, which also reduces the cost". RDS Proxy is billed by Amazon RDS, per vCPU-hour of the database behind it: the RDS article prices it.

Lambda, Fargate or EC2

Is Lambda cheaper than EC2 or Fargate? The three bill different things. Lambda bills requests and the GB-seconds the code runs, to the millisecond, and nothing while no request runs. AWS Fargate bills a task's vCPU, memory and storage "from the time you start to download your container image (Docker pull) until the task terminates, rounded up to the nearest second", with "a 1-minute minimum", and each task has "its own isolation boundary" (AWS Fargate for Amazon ECS). Amazon EC2 bills an instance "by the hour or second (minimum of 60 seconds)" (On-Demand pricing), busy or not, and the EC2 article explains how. A container or an instance also serves as many requests at once as it can, where an Event Function's environment serves one. Per vCPU kept busy for an hour, in Paris:

One vCPU kept busy for an hour in Paris, on each compute service (computed)

Compute	Counted as	Per busy vCPU-hour, computed
Lambda, x86	1,769 MB for an hour, requests not counted	$0.10365
Lambda, Arm	1,769 MB for an hour, requests not counted	$0.08292
Lambda Managed Instances, m7g.large	half the instance, with the 15% fee	$0.05474
Fargate, x86	a task of 1 vCPU and 2 GB	$0.05920
Fargate, Arm	a task of 1 vCPU and 2 GB	$0.04736
EC2 c7g.large	half the instance (2 vCPUs, 4 GiB)	$0.04295

Computed from the AWS Price List, eu-west-3, offer files published September 11, 2026, October 12, 2026 and October 14, 2026, fetched October 15, 2026.

A busy vCPU-hour on Lambda Arm costs 1.75 times a Fargate Arm task's and 1.93 times half a c7g.large's, computed. That is the price of a busy vCPU, not of a workload: a task or an instance is paid while it waits for work, and a function is not. So the answer is a utilization: above a break-even share of busy time, provisioned compute costs less. Pattern 3 computes it for a steady service.

How Lambda pricing works

What a Lambda bill is made of

The pricing page prices an Event Function in two lines, and the options and the services around it add their own:

The lines of a Lambda bill, and what each charges for

Line	Billed by	Charged for
Requests	The million	Each invocation, retries included; an asynchronous event above 256 KB adds one request per 64 KB, up to 1 MB
Duration	The GB-second, by architecture, in three monthly tiers	Memory configured × time the code runs, Init included, rounded up to the millisecond
Provisioned concurrency	The GB-second configured, and the GB-second used	Environments kept initialized, used or not, and the duration that runs on them
SnapStart	The GB-second cached, the GB restored	Python and .NET snapshots; free on Java
Ephemeral storage	The GB-second	Storage configured above 512 MB
Around the function	Their own units	API Gateway or a load balancer, CloudWatch Logs, Amazon SQS, NAT gateways, data transfer

Duration "is calculated from the time your code begins executing until it returns or otherwise terminates, rounded up to the nearest 1ms", and "You may incur additional charges if your Lambda function utilizes other AWS services or transfers data." Put together, the two Lambda lines of an API's function look like this:

One API function for a month in Paris: 50 million requests of 120 ms at 1,024 MB, on x86 Illustrative

Line	A month
Compute	$110.00
Requests: 50 million50 M requests × $0.20 /M req	$10.00
Duration: 50 million × 0.12 s × 1 GB6,000,000 GB-s × $0.0000166667 /GB-s	$100.00
Not counted
The front door, CloudWatch Logs and data transfer	—
The free tier	—
A month, computed	$110.00

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 14, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Requests and duration in Paris

Duration tiers apply "to aggregate monthly duration of your functions running on the same architecture (x86 or Arm, respectively), in the same region, within the account", so a large account pays less per GB-second as its month grows:

Lambda Event Functions in Paris (eu-west-3): requests and duration

Item	List price	Unit
Requests
Requests, x86	$0.20	per million requests
Requests, Arm	$0.20	per million requests
Duration, x86
First 6 billion GB-seconds a month	$0.0000166667	per GB-second
Next 9 billion GB-seconds	$0.000015	per GB-second
Over 15 billion GB-seconds	$0.0000133334	per GB-second
Duration, Arm
First 7.5 billion GB-seconds a month	$0.0000133334	per GB-second
Next 11.25 billion GB-seconds	$0.0000120001	per GB-second
Over 18.75 billion GB-seconds	$0.0000106667	per GB-second

USD, before tax. AWS Price List, eu-west-3, offer file published October 14, 2026, fetched October 15, 2026.

The second tier costs 10.0% less than the first and the third 20.0% less, computed, on both architectures. A million invocations of 120 ms at 1,024 MB cost $2.00 of x86 duration and $0.20 of requests, computed. A GB-second is one GB of configured memory for one second: 1,024 MB for 120 ms is 0.12 GB-second, 512 MB for 200 ms is 0.1.

What duration counts

Duration is the wall-clock time of the code, at the memory you configure, so a few rules decide what lands on the line. Init counts, on demand as with provisioned concurrency: "For functions configured with Provisioned Concurrency, AWS Lambda periodically recycles the execution environments and re-runs your initialization code", and "Lambda bills you for initialization even if the environment instance never processes a request". The last extension's shutdown counts. Waiting counts on Event Functions, since the environment stays busy, and does not on a durable function's wait operation.

The timeout caps it: "The default value for this setting is 3 seconds", up to "900 seconds (15 minutes)". A dependency that hangs turns every call into a full timeout: 1,000 invocations that run to 900 seconds at 1,024 MB cost $15.00 of x86 duration, computed, where 1,000 calls of 120 ms cost a fraction of a cent. Set guardrails is the lever.

Provisioned concurrency

The pricing page bills it in two parts: "You pay for the amount of concurrency you configure, and for the period of time you configure it. When Provisioned Concurrency is enabled and executed for your function, you also pay for Requests and Duration based on the prices below." The period is "rounded up to the nearest five minutes", and "The Lambda free tier does not apply to functions enabling Provisioned Concurrency." In Paris, one GB of provisioned concurrency kept all month costs $12.79 on x86 before a single request runs on it, computed. Its duration rate is lower than the on-demand one, so is it ever cheaper? Only when it is almost fully used:

Computed from Paris list prices

91.7%the share of its configured time provisioned concurrency must be busy before it costs less than on-demand duration, on x86 as on Arm.

Computed from the AWS Price List · eu-west-3 · Oct 14, 2026

At utilization u, provisioned concurrency costs $0.0000048673 plus $0.0000113569 × u per configured GB-second, against $0.0000166667 × u on demand: it costs less only when u is above the first price divided by the difference of the two others. With the US East rates of the pricing page's examples, $0.0000041667 and $0.0000097222 per GB-second, the same formula gives 60.0%, the "about 60%" that other guides repeat; Paris rates are higher for provisioned concurrency and the same on demand. Per GB-second a request actually uses:

What a GB-second used costs on provisioned concurrency in Paris, by utilization, x86 (computed)

Utilization	Per GB-second used, computed	Against on demand
25.0%	$0.0000308261	85.0% more
50.0%	$0.0000210915	26.5% more
70.0%	$0.0000183102	9.9% more
90.0%	$0.0000167650	0.6% more
100.0%	$0.0000162242	2.7% less

Computed from the AWS Price List, eu-west-3, offer file published October 14, 2026, fetched October 15, 2026.

In Paris, provisioned concurrency is a latency purchase. The pricing page sells it as one, "Provisioned Concurrency keeps functions initialized and hyper-ready to respond in double-digit milliseconds", and the provisioned concurrency guide keeps it for latency too: "Asynchronous workloads, such as data processing pipelines, are often less latency sensitive and so do not usually need provisioned concurrency." Pattern 4 prices a schedule, set with AWS Application Auto Scaling, that keeps it to the hours that need it.

SnapStart, ephemeral storage and the other options

Other Lambda charges in Paris (eu-west-3)

Item	List price	Unit
SnapStart cachePer GB of memory, per second a version is active	$0.0000022468	per GB-second
SnapStart restorePer GB of memory, each time a snapshot resumes	$0.0002052964	per GB
Ephemeral storagePer GB-second configured above 512 MB	$0.0000000358	per GB-second
Response streamingPer GB streamed beyond 6 MB per request	$0.008	per GB
Tenant isolationPer GB of memory of each environment created, x86	$0.000166667	per GB
SQS event source mapping, provisioned modePer event poller unit-hour	$0.0108	per event poller unit-hour

USD, before tax. AWS Price List, eu-west-3, offer file published October 14, 2026, fetched October 15, 2026.

SnapStart bills a cache and restores: "You are charged for caching a snapshot over the period that your function version is active, for a minimum of 3 hours and per millisecond thereafter", and "You are also charged each time Lambda resumes an execution environment by restoring your snapshot." One version of 1 GB active all month costs $5.90 of cache, and one restore of 1 GB costs as much as 12.3 seconds of 1 GB of x86 duration, computed. Ephemeral storage is free up to 512 MB: "512 MB of ephemeral storage is available to each Lambda function at no additional cost. You only pay for the additional ephemeral storage you configure." Response streaming is free for "the first 6 MB per request". The provisioned mode of an SQS event source mapping bills its pollers by the hour, and "Each SQS ESM requires a minimum of 2 event pollers": $15.77 a month at the minimum, computed. In the standard mode the mapping has no charge of its own, but its polls are Amazon SQS requests.

The costs around the function

A function rarely runs alone, and the services around it bill on their own lines:

What runs around a Lambda function, in Paris (eu-west-3)

Item	List price	Unit
Front door
API Gateway HTTP APIFirst 300 million requests a month	$1.17	per million requests
API Gateway REST APIFirst 333 million requests a month	$3.50	per million requests
Application Load BalancerPer load balancer	$0.02646	per hour
Application Load Balancer capacityPer load balancer capacity unit used	$0.0084	per LCU-hour
Logs
CloudWatch Logs ingestion, Lambda logsStandard class, first 10 TB a month	$0.5985	per GB
CloudWatch Logs storageCompressed	$0.0315	per GB-month
CloudWatch Logs InsightsPer GB scanned	$0.0059	per GB
Queue and network
Amazon SQS standard queuePer million requests	$0.40	per million requests
NAT gatewayPer hour	$0.05	per hour
NAT gateway data processedPer GB	$0.05	per GB
Interface VPC endpointPer hour, in each Availability Zone	$0.011	per hour
Data transfer out to the internetFirst 10 TB a month	$0.09	per GB

USD, before tax. AWS Price List, eu-west-3, offer files published September 11, 2026, September 16, 2026, September 17, 2026, October 7, 2026, October 12, 2026 and October 13, 2026, fetched October 15, 2026.

The front door can cost more than the function. One REST API request costs 17.50 times a Lambda request, and an HTTP API request 5.85 times, computed; a function URL has none, since "Function URLs follow the standard Lambda pricing model – you only pay for function invocations and compute time." Lambda's logs are CloudWatch vended logs, "available at volume tiered pricing" (CloudWatch pricing), and "There is no additional charge for using Lambda logs; however, standard CloudWatch Logs charges apply" (Sending logs to CloudWatch Logs). Stored logs are billed compressed, "0.15 compression ratio for each uncompressed byte", and "By default, log data is stored in CloudWatch Logs indefinitely" (log groups). On Amazon SQS, "Every Amazon SQS action counts as a request". Lastly, data transfer is free between Lambda and Amazon S3, DynamoDB, SQS, SNS, Kinesis, ECR and EFS in the same Region; the S3 article prices the requests a function makes to S3.

Managed Instances, Web Functions and durable functions in Paris

Lambda Managed Instances, Web Functions and durable functions in Paris (eu-west-3)

Item	List price	Unit
Lambda Managed Instances
Requests	$0.20	per million requests
Management fee, m7g.largePer instance-hour, on top of the EC2 instance	$0.01428	per hour
EC2 m7g.large, On-DemandThe instance itself	$0.0952	per hour
Web Functions, Arm
Requests	$0.30	per million requests
Active vCPU time	$0.000040121	per vCPU-second
MemoryOver each environment's life, idle time included	$0.0000053119	per GB-second
Durable functions
Durable operations	$12.50	per million operations
Data written	$0.39	per GB
Data retained	$0.23	per GB-month

USD, before tax. AWS Price List, eu-west-3, offer files published October 12, 2026 and October 14, 2026, fetched October 15, 2026.

On Managed Instances, "Lambda Managed Instances uses EC2-based pricing with a 15% management fee on top of the EC2 instance cost", requests cost what Event Functions' requests cost, and there is no duration line: these functions "will not be paying separately for the execution duration of each request unlike Lambda (default) compute type functions." Commitments reach the instances only: "EC2 pricing discounts only apply to the underlying EC2 compute, not to the management fee." In Paris, an m7g.large's fee is $0.01428 per hour, 15% of the instance's $0.0952 On-Demand. The Paris price list has Web Functions rows for Arm only. Durable functions add operations, "such as starting executions, completing steps, and creating waits", to the usual requests and duration, "including for sub-invocations from replays", and keep their data for a retention period "configurable from 1 to 90 days (default 14 days)".

Compute Savings Plans

"Compute Savings Plans provide the most flexibility and prices that are up to 66% off of On-Demand rates", and "They also apply to your Fargate and Lambda usage." The Savings Plans FAQ gives no Lambda figure. The Paris rates do:

Compute Savings Plans in Paris, No Upfront: what each plan takes off On-Demand (computed)

Usage	1-year plan	3-year plan
Lambda duration, x86	10.0% less	10.0% less
Lambda duration, Arm	10.0% less	10.0% less
Lambda provisioned concurrency, x86	10.0% less	10.0% less
AWS Fargate, Arm vCPU	21.2% less	46.0% less
Amazon EC2, c7g.large	21.0% less	44.0% less

Computed from the AWS Price List, eu-west-3, offer files published September 11, 2026, October 12, 2026, October 13, 2026 and October 14, 2026, fetched October 15, 2026.

In Paris, a Compute Savings Plan takes the same share off Lambda duration and provisioned concurrency for one year as for three, and nothing off requests, whose plan rate is the On-Demand $0.20 per million. The same commitment goes about twice as deep on Fargate and EC2 for one year, and more than four times as deep for three, computed; the the EC2 article prices it. For Lambda, a plan is the last lever, after the ones that shrink the GB-seconds it would cover.

Paris and the US East examples

The pricing page's worked examples use US East rates. For on-demand functions they hold in Paris; for the rest, they do not:

Paris list prices, against the US East rates of the Lambda pricing page's examples (computed)

Price	Paris	Against the US East examples
Duration on demand, per GB-second	$0.0000166667	the same
Provisioned concurrency, per GB-second	$0.0000048673	16.8% more
Duration on provisioned concurrency, per GB-second	$0.0000113569	16.8% more
Ephemeral storage above 512 MB, per GB-second	$0.0000000358	15.9% more
SnapStart cache, per GB-second	$0.0000022468	49.3% more
SnapStart restore, per GB	$0.0002052964	46.9% more
SQS event poller unit, per hour	$0.0108	16.8% more

Computed from the AWS Price List, eu-west-3, offer file published October 14, 2026, fetched October 15, 2026.

The difference that matters most is the break-even of provisioned concurrency, 91.7% in Paris against 60.0% at the examples' rates, computed: a rule of thumb from a US guide would buy it at a utilization where Paris loses money.

Reading the Lambda lines of a bill

Lambda's usage types carry the Region's code, EUW3- in Paris, and the architecture. Among them, from the Paris price list:

Lambda usage types on a bill in Paris

Usage type	What it counts
`EUW3-Request`, `EUW3-Request-ARM`	Requests, x86 and Arm
`EUW3-Lambda-GB-Second`, `EUW3-Lambda-GB-Second-ARM`	On-demand duration
`EUW3-Lambda-Provisioned-Concurrency`, `EUW3-Lambda-Provisioned-GB-Second`	Provisioned concurrency configured, and the duration that runs on it (`-ARM` for Arm)
`EUW3-Lambda-Storage-GB-Second`	Ephemeral storage above 512 MB
`EUW3-Lambda-SnapStart-Cached-GB-S`, `EUW3-Lambda-SnapStart-Restored-GB`	SnapStart cache and restores
`EUW3-Lambda-SQS-Event-Poller-Unit-Hour`	Provisioned mode of SQS event source mappings
`EUW3-Lambda-Managed-Instances-m7g.large-Management-Hours`	The Managed Instances fee, by instance type
`Global-Request`, `Global-Lambda-GB-Second`	The free tier, on global usage types

The logs are on the CloudWatch line, not the Lambda line: EUW3-VendedLog-Bytes for ingestion, EUW3-TimedStorage-ByteHrs for storage. To see the bill by function, tag the functions: "Tags apply at the function level, not to versions or aliases", and with them, "You can allocate costs from your AWS bill to individual functions and APIs and obtain a granulated view of your costs and usage per project in AWS Cost Explorer".

Architecture patterns around Lambda and what they cost

Four illustrative configurations in Paris, each priced before and after the levers of the next section, line by line from the AWS Price List: a public API whose front door and logs cost more than its function, a queue worker invoked once per message, a steady service paying Lambda's price for a busy vCPU, and an API that keeps provisioned concurrency all night. None is a client case; every amount is computed, and each card lists its assumptions and what it leaves out. The EC2 patterns price the instance side the same way.

Pattern 1 of 4 · Illustrative configuration

A public API on API Gateway and Lambda

A public API in Paris serves 50 million requests a month through Amazon API Gateway to one Lambda function of 1,024 MB that runs 120 ms per request: on a REST API, on x86, logging at INFO forever, then on an HTTP API, on Arm, logging at WARN for 30 days.

A public API on API Gateway and Lambda Illustrative configuration in Paris, not a client case.

An HTTP API costs $1.17 per million requests in Paris. A REST API costs $3.50 and adds API keys, per-client throttling, request validation, AWS WAF and private endpoints.
Each request is one Lambda request, $0.20 per million, plus its duration: $0.0000133334 per GB-second on Arm against $0.0000166667 on x86.
The table's reads and writes are billed by DynamoDB; data transfer between Lambda and DynamoDB in the same Region is free.
Log ingestion costs $0.5985 per GB in the Standard class. A WARN log level sends less, and a 30-day retention stops the stored logs from growing every month.

Before the levers, API Gateway is 49.9% of the bill, the function 31.4% and its logs 18.7%, computed: the front door is the largest line. Without a retention, the stored logs grow by $0.47 more every month. A function URL instead of the HTTP API, for an API that needs only IAM authentication or none, brings the bill to $96.04 a month, computed.

With the levers: $195.98 a month less (55.9% less), computed.

A public API on API Gateway and Lambda, one lever at a time: the bill a month, computed

Step	A month, computed	Change
REST API, x86, INFO logs kept foreverBefore the levers	$350.52	—
WARN logs kept 30 daysLever: Log less, keep logs shorter	$291.04	−$59.48
The function on ArmLever: Move to Arm	$271.04	−$20.00
HTTP API instead of RESTLever: Pick the front door by need	$154.54	−$116.50

USD, before tax. AWS Price List, eu-west-3, offer files published October 7, 2026, October 13, 2026 and October 14, 2026, fetched October 15, 2026.

Levers

Log less, keep logs shorter
Move to Arm
Pick the front door by need

The bills line by line, the assumptions and the sources

A public API on API Gateway and Lambda, before: REST API, x86, INFO logs kept forever Illustrative

An API Gateway REST API in front of an x86 function, logging at INFO into a log group that never expires, in its twelfth month.

Line	A month
Compute	$110.00
Lambda requests, x8650 M requests × $0.20 /M req	$10.00
Lambda duration, x86: 50 million × 0.12 s × 1 GB6,000,000 GB-s × $0.0000166667 /GB-s	$100.00
Storage
CloudWatch Logs storage, 12 months kept, compressed180 GB × $0.0315 /GB-mo	$5.67
Network
API Gateway REST API, 50 million requests50 M requests × $3.50 /M req	$175.00
Other
CloudWatch Logs ingestion, INFO level100 GB × $0.5985 /GB	$59.85
A month, computed	$350.52

A public API on API Gateway and Lambda, with the levers: HTTP API, Arm, WARN logs kept 30 days Illustrative

An API Gateway HTTP API in front of the same function on arm64, logging at WARN in JSON into a log group with a 30-day retention.

Line	A month
Compute	$90.00
Lambda requests, Arm50 M requests × $0.20 /M req	$10.00
Lambda duration, Arm: 50 million × 0.12 s × 1 GB6,000,000 GB-s × $0.0000133334 /GB-s	$80.00
Storage
CloudWatch Logs storage, 30 days kept, compressed1.5 GB × $0.0315 /GB-mo	$0.05
Network
API Gateway HTTP API, 50 million requests50 M requests × $1.17 /M req	$58.50
Other
CloudWatch Logs ingestion, WARN level10 GB × $0.5985 /GB	$5.99
A month, computed	$154.54

A function URL instead of the HTTP API: $96.04 a month, 72.6% less than before, computed.

Assumptions

Illustrative configuration in Paris (eu-west-3), not a client case.
50 million requests a month (about 19 a second on average), each a billed duration of 120 ms at 1,024 MB, Init included: 6,000,000 GB-seconds.
The API uses none of the REST-only features (API keys, per-client throttling, request validation, AWS WAF, private endpoints), and its responses stay under 512 KB, so each is one metered HTTP API request.
The function runs as fast on arm64 as on x86_64: an assumption to measure, with an alias that splits traffic between the two versions.
At the INFO level the function writes 100 GB of logs a month (about 2 KB per request, START and REPORT lines included); at WARN, 10 GB.
Logs are stored compressed at the pricing page's 0.15 ratio. Before: the log group keeps the default "Never Expire" retention, and the bill is read in its 12th month, with 180 GB stored. After: a 30-day retention keeps one month of WARN logs, 1.5 GB.

Not counted

The DynamoDB table's reads, writes and storage (the same in both variants); data transfer between Lambda and DynamoDB in the Region is free.
Data transfer out to the users (the same in both) and the free tiers of Lambda, API Gateway and CloudWatch.

Sources

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published October 7, 2026, October 13, 2026 and October 14, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Pattern 2 of 4 · Illustrative configuration

A queue worker: one message per invocation, or filtered batches

Producers send 300 million messages a month to an Amazon SQS standard queue in Paris, and a Lambda function of 512 MB processes them: one message per invocation on x86, then on Arm with a filter that drops the messages it ignores and batches of 10.

A queue worker: messages filtered and batched before they invoke Illustrative configuration in Paris, not a client case.

Each SendMessage call is one Amazon SQS request, $0.40 per million (a SendMessageBatch call carries up to 10 messages); each 64 KB of payload counts as one request.
Lambda polls the queue for the function. It reads up to 10 messages by default, can wait up to 5 minutes for a batch to fill (the batch window), and invokes the function once per batch.
A message that matches none of the filters is removed from the queue without invoking the function: no request charge and no duration for it.
One Lambda request per batch, $0.20 per million, instead of one per message; the fixed work of each invocation is paid once per batch.

The Lambda lines alone fall from $185.00 to $42.00 a month (77.3% less), computed; the producers' Amazon SQS requests stay the same. Fewer invocations also mean fewer START and REPORT log lines, which this card does not count.

With the levers: $143.00 a month less (46.9% less), computed.

A queue worker: one message per invocation, or filtered batches, one lever at a time: the bill a month, computed

Step	A month, computed	Change
One message per invocation, x86Before the levers	$305.00	—
The function on ArmLever: Move to Arm	$280.00	−$25.00
A filter drops the ignored messagesLever: Batch and filter events before they invoke	$216.00	−$64.00
Batches of 10Lever: Batch and filter events before they invoke	$162.00	−$54.00

USD, before tax. AWS Price List, eu-west-3, offer files published September 11, 2026 and October 14, 2026, fetched October 15, 2026.

Levers

Move to Arm
Batch and filter events before they invoke

The bills line by line, the assumptions and the sources

A queue worker: one message per invocation, or filtered batches, before: One message per invocation, x86 Illustrative

Batch size 1, no filter, on x86: 300 million invocations of 50 ms.

Line	A month
Compute	$185.00
Lambda requests, x86: 300 million invocations300 M requests × $0.20 /M req	$60.00
Lambda duration, x86: 300 million × 0.05 s × 0.5 GB7,500,000 GB-s × $0.0000166667 /GB-s	$125.00
Other
Amazon SQS requests: the producers' 300 million SendMessage calls300 M requests × $0.40 /M req	$120.00
A month, computed	$305.00

A queue worker: one message per invocation, or filtered batches, with the levers: Filtered, batches of 10, Arm Illustrative

A filter that drops the ignored types, batches of 10, on arm64: 18 million invocations of 320 ms.

Line	A month
Compute	$42.00
Lambda requests, Arm: 18 million invocations18 M requests × $0.20 /M req	$3.60
Lambda duration, Arm: 18 million × 0.32 s × 0.5 GB2,880,000 GB-s × $0.0000133334 /GB-s	$38.40
Other
Amazon SQS requests: the producers' 300 million SendMessage calls300 M requests × $0.40 /M req	$120.00
A month, computed	$162.00

Batches of 10 on Arm, without the filter: $190.00 a month, 37.7% less than before, computed.

Assumptions

Illustrative configuration in Paris (eu-west-3), not a client case.
300 million messages a month (about 114 a second), on a standard queue.
Each invocation spends 20 ms on fixed work (handler start, clients, the commit) and 30 ms per message, at 512 MB: 50 ms for one message, 320 ms for a batch of 10. Both durations are illustrative.
40.0% of the messages are of a type this function ignores; a filter on the event source mapping removes them from the queue without an invocation.
Batches stay full: at this rate a short batch window fills them. No failures: a failed batch would return to the queue and run again.
The function runs as fast on arm64 as on x86_64 (to measure).

Not counted

The ReceiveMessage and DeleteMessage calls of the event source mapping, billed by Amazon SQS: their number in standard mode is not documented.
CloudWatch Logs (fewer invocations also mean fewer START and REPORT lines), the producers, and the free tiers.

Sources

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 11, 2026 and October 14, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Pattern 3 of 4 · Illustrative configuration

Steady, CPU-bound traffic: Lambda against Fargate, EC2 and Managed Instances

A service in Paris receives 200 requests a second around the clock, each 100 ms of CPU-bound work at 1,769 MB, the memory of one vCPU: it keeps 20 vCPUs busy all month, on Lambda on Arm, then on Amazon ECS tasks on AWS Fargate, Arm, sized to run at 70% on average.

Steady traffic: Lambda or containers behind the same load balancer Illustrative configuration in Paris, not a client case.

An Application Load Balancer can send requests to a Lambda function or to containers, so the front door and its price can stay the same when the compute changes.
Lambda bills each request and only the time code runs. At 1,769 MB a function has the equivalent of one vCPU: $0.0000133334 per GB-second on Arm.
Each Fargate task is billed for its vCPU and memory from the start of its image download until it stops, busy or idle: $0.03888 per vCPU-hour and $0.00424 per GB-hour on Arm.
Busy enough on average, the tasks cost less than the same work on Lambda; the pattern computes where the two cross.

The 29 tasks are busy 69.0% of the time. The same work fits on up to 38 tasks, each busy 52.6% of the time, before Fargate costs more than Lambda; the break-even utilizations against every option are in Move steady load where it costs less. On EC2 with a three-year Compute Savings Plan, the same work costs the least of every option priced here, and asks the most of you: instances to patch and scale, and a commitment of three years.

With the levers: $313.18 a month less (23.8% less), computed.

The same work, 20 busy vCPUs all month: Lambda on Arm against Fargate Arm tasks of 1 vCPU and 2 GB, by the number of tasks, a month, computed

Fargate tasks	Lambda on Arm	Fargate Arm	Change, computed
20 tasks, busy 100.0%	$1,315.79	$691.46	47.4% less
25 tasks, busy 80.0%	$1,315.79	$864.32	34.3% less
29 tasks, busy 69.0%This pattern	$1,315.79	$1,002.61	23.8% less
34 tasks, busy 58.8%	$1,315.79	$1,175.47	10.7% less
38 tasks, busy 52.6%The most tasks that still cost less	$1,315.79	$1,313.77	0.2% less
39 tasks, busy 51.3%One task more: Lambda costs less	$1,315.79	$1,348.34	2.5% more
50 tasks, busy 40.0%	$1,315.79	$1,728.64	31.4% more

The work is the same on every row; only the number of tasks that carry it changes. Lambda's bill does not depend on it.

USD, before tax. AWS Price List, eu-west-3, offer files published September 11, 2026, October 12, 2026, October 13, 2026 and October 14, 2026, fetched October 15, 2026.

Levers

Move steady load where it costs less

The bills line by line, the assumptions and the sources

Steady, CPU-bound traffic: Lambda against Fargate, EC2 and Managed Instances, before: Lambda on Arm, on demand Illustrative

One function on arm64 at 1,769 MB, on demand, billed per request and per GB-second.

Line	A month
Compute	$1,315.79
Lambda requests: 525.6 million525.6 M requests × $0.20 /M req	$105.12
Lambda duration, Arm: 525.6 million × 0.1 s × 1,769 MB90,799,453.13 GB-s × $0.0000133334 /GB-s	$1,210.67
A month, computed	$1,315.79

Steady, CPU-bound traffic: Lambda against Fargate, EC2 and Managed Instances, with the levers: Amazon ECS on AWS Fargate, Arm, on demand Illustrative

29 Fargate tasks on Arm of 1 vCPU and 2 GB, running all month, on demand.

Line	A month
Compute	$1,002.61
Fargate Arm vCPU: 29 tasks × 1 vCPU × 730 h21,170 vCPU-h × $0.03888 /vCPU-h	$823.09
Fargate Arm memory: 29 tasks × 2 GB × 730 h42,340 GB-h × $0.00424 /GB-h	$179.52
A month, computed	$1,002.61

Lambda on x86, on demand: $1,618.45 a month, 23.0% more than before, computed.

Lambda on Arm with a Compute Savings Plan (1 or 3 years): $1,194.72 a month, 9.2% less than before, computed.

Lambda Managed Instances on 15 m7g.large, on demand: $1,303.93 a month, 0.9% less than before, computed.

Fargate Arm with a 1-year Compute Savings Plan: $789.65 a month, 40.0% less than before, computed.

Lambda Managed Instances, a 3-year plan on the instances: $808.99 a month, 38.5% less than before, computed.

EC2 c7g.large × 15, on demand: $951.75 a month, 27.7% less than before, computed.

EC2 c7g.large × 15, 1-year Compute Savings Plan: $754.65 a month, 42.6% less than before, computed.

Fargate Arm with a 3-year Compute Savings Plan: $541.53 a month, 58.8% less than before, computed.

EC2 c7g.large × 15, 3-year Compute Savings Plan: $537.84 a month, 59.1% less than before, computed.

Assumptions

Illustrative configuration in Paris (eu-west-3), not a client case.
200 requests a second, every hour of the month: 525.6 million requests, each 100 ms of CPU-bound work at 1,769 MB, where a function has the equivalent of one vCPU. Concurrency is 200 × 0.1 s = 20 environments busy at all times.
The work runs at the same speed per vCPU on Lambda at 1,769 MB, on a Fargate vCPU, on a c7g.large vCPU and on an m7g.large vCPU: an assumption to measure with a load test.
The provisioned options are sized for 70.0% average CPU, across at least two Availability Zones: 29 Fargate tasks of 1 vCPU and 2 GB (20 / 0.7 = 28.57, rounded up), or 15 instances of 2 vCPUs.
One Application Load Balancer, which can target a Lambda function or containers, is the front door of every option: the same in all, not counted.
Each EC2 instance has an 8 GB gp3 root volume. The EBS volumes of Lambda Managed Instances are not counted: the pages read do not say how they are billed.
The Managed Instances management fee is not discounted by Savings Plans: a plan applies to the instances only.

Not counted

The load balancer (shared), logs, container image storage, headroom for peaks above the average, and the work of running containers or instances that Lambda does for you.

Sources

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 11, 2026, October 12, 2026, October 13, 2026 and October 14, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Pattern 4 of 4 · Illustrative configuration

A latency-sensitive API on provisioned concurrency

An API function in Paris of 1,024 MB on x86 needs a cold-start latency that SnapStart does not meet: provisioned concurrency for its peak all month, then the same on a schedule that lowers it outside business hours.

Provisioned concurrency on a schedule Illustrative configuration in Paris, not a client case.

Provisioned concurrency is set on a version or an alias, never on $LATEST. Lambda keeps that many environments initialized, ready in double-digit milliseconds.
It is billed per GB-second for as long as it is configured, used or not: $0.0000048673 in Paris, plus $0.0000113569 per GB-second of duration when requests run on it.
Application Auto Scaling changes the number with scheduled actions (business hours, nights) or keeps its utilization near a target with target tracking.
Requests above the provisioned number still invoke the same alias and version, on on-demand environments, with possible cold starts, at $0.0000166667 per GB-second.

The provisioned environments are busy 28.7% of their configured time before the schedule and 65.7% after, computed: both below the 91.7% at which provisioned concurrency costs less than on demand in Paris. Without it, on demand, the same traffic costs $1,193.62 a month (39.3% less than before), with cold starts possible: the schedule makes the latency cheaper, it does not make it free.

With the levers: $634.13 a month less (32.2% less), computed.

Levers

Use provisioned concurrency only where latency needs it

The bills line by line, the assumptions and the sources

A latency-sensitive API on provisioned concurrency, before: 88 provisioned around the clock Illustrative

Provisioned concurrency of 88 on the function's alias, all month.

Line	A month
Compute	$1,967.15
Provisioned concurrency, 88 × 1 GB, all month231,264,000 GB-s × $0.0000048673 /GB-s	$1,125.63
Duration of the invocations on provisioned concurrency, x8666,312,000 GB-s × $0.0000113569 /GB-s	$753.10
Lambda requests: 442.08 million442.08 M requests × $0.20 /M req	$88.42
A month, computed	$1,967.15

A latency-sensitive API on provisioned concurrency, with the levers: Provisioned concurrency on a schedule Illustrative

88 environments in business hours and 11 at night, set by Application Auto Scaling scheduled actions.

Line	A month
Compute	$1,333.02
Provisioned concurrency, 88 × 1 GB for 260 business hours, 11 for 470 hours100,980,000 GB-s × $0.0000048673 /GB-s	$491.50
Duration of the invocations on provisioned concurrency, x8666,312,000 GB-s × $0.0000113569 /GB-s	$753.10
Lambda requests: 442.08 million442.08 M requests × $0.20 /M req	$88.42
A month, computed	$1,333.02

No provisioned concurrency (on demand, cold starts possible): $1,193.62 a month, 39.3% less than before, computed.

On a schedule, with a 1-year Compute Savings Plan sized to the night-time usage: $1,300.69 a month, 33.9% less than before, computed.

Assumptions

Illustrative configuration in Paris (eu-west-3), not a client case.
400 requests a second during business hours (12 hours a day, 5 days a week: 260 hours a month) and 40 a second the other 470 hours, 150 ms each at 1,024 MB: 442.08 million requests and 66,312,000 GB-seconds a month.
Concurrency averages 60 by day and 6 at night; the measured peaks are 80 and 10. Provisioned concurrency is each peak plus the 10% buffer Lambda suggests: 88 and 11.
Every invocation runs on a provisioned environment: concurrency never exceeds the configured number.
Application Auto Scaling changes the number with two scheduled actions a day; each change takes a minute or two and is not counted. No price for Application Auto Scaling itself is in the pages read.
The product team's cold-start target is one SnapStart does not meet (an assumption): otherwise SnapStart, or on-demand environments, would be the first answer.
The Savings Plan alternative commits $0.39377 an hour for a year, the night-time usage at the plan's rates: each hour's commitment is used within that hour or lost, so a larger one would go partly unused every night. Its lines count the commitment against the night-time usage in every hour; AWS applies a plan to the usage with the highest savings percentage first (here the duration), and priced in that order the month costs $0.10 less, computed.

Not counted

The API in front of the function, logs, and the free tier (which does not apply to functions with provisioned concurrency).

Sources

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published October 13, 2026 and October 14, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Want the same levers on your own bill?

Get a free audit

How to reduce Lambda costs

Each lever below comes from AWS documentation; their order is this article's. A Compute Savings Plan is a commitment of dollars per hour for one or three years, so it comes last, once the usage it covers is as small as it will get: see the bill first, remove what is billed but serves nothing, reshape the functions and their configuration, route their traffic through the cheapest path, and commit to what remains. The levers, in that order:

Lever 01,SeeSee the Lambda bill by functionAlways, and first
Lever 02,TrimDelete unused functions and versionsOld versions that carry a charge
Lever 03,TrimLog less, keep logs shorterINFO logs kept forever
Lever 04,TrimTrim the Init phaseLong or frequent cold starts
Lever 05,TrimSet guardrails: timeouts, retries and loopsAlways; loops through other services
Lever 06,ReshapeRight-size memoryMemory never measured
Lever 07,ReshapeMove to ArmCode and dependencies built for arm64
Lever 08,ReshapeBatch and filter events before they invokeOne invocation per record
Lever 09,ReshapeRemove functions that only pass data alongFunctions with no logic of their own
Lever 10,ReshapeUse provisioned concurrency only where latency needs itInteractive APIs with a cold-start target
Lever 11,ReshapeMove steady load where it costs lessBusy, steady, predictable load
Lever 12,RoutePick the front door by needA public HTTP endpoint
Lever 13,RouteKeep AWS-service traffic off the NAT gatewayFunctions in a VPC that call AWS APIs
Lever 14,CommitCommit with Compute Savings Plans, lastSteady duration, after the levers
Lever 15,ReviewReview on a cadenceQuarterly or yearly

Lever 01 · See

See the Lambda bill by function

When it applies: Always, and first: before any function is resized, moved or committed.
Watch out: Tags apply to a function, not to its versions or aliases; logs, the front door, NAT gateways and the event sources bill on other services' lines; Cost Anomaly Detection works on data up to 24 hours old.
Tools: Cost ExplorerCost allocation tagsAWS Cost Anomaly Detection

Split the Lambda line by usage type, then by function with cost allocation tags, and put an alarm on surprises: the best practices say "Use AWS Cost Anomaly Detection to detect unusual activity on your account", with the caveat that "Cost Anomaly Detection uses data from AWS Cost Explorer, which has a delay of up to 24 hours." Look beyond the Lambda line too: the logs are on CloudWatch's, the front door on API Gateway's or the load balancer's, the network on the NAT gateway's, the queue on Amazon SQS's. In pattern 1, the function is 31.4% of the bill, computed.

Lever 02 · Trim

Delete unused functions and versions

When it applies: Function versions with SnapStart on Python or .NET, provisioned concurrency left on old aliases, functions nobody calls.
Watch out: An idle function on demand costs nothing: the saving is in what is configured on it, the SnapStart cache and provisioned concurrency.
Tools: ListVersionsByFunctionDeleteFunction

"Delete Lambda Event Functions that you are no longer using", say the best practices. An idle function on demand costs nothing, but what is configured on it can: SnapStart caches every active version, and "You continue to be charged as long as your function remains active".

One 1 GB SnapStart version left active

$5.90 a monthof snapshot cache, on Python or .NET, in Paris, computed; free on Java.

Computed from the AWS Price List · eu-west-3 · Oct 14, 2026

The SnapStart guide gives the way: "Use the ListVersionsByFunction API action to identify function versions, and then use DeleteFunction to delete unused versions." Provisioned concurrency left on an old alias bills the same way, every second it is configured.

Lever 03 · Trim

Log less, keep logs shorter

When it applies: Functions that log at INFO or DEBUG in production, into log groups at the default "Never Expire" retention.
Watch out: Log-level filtering needs the JSON log format; a level set in code wins over the configuration; logs delivered to Amazon S3 still pay the CloudWatch delivery charge.
Tools: Lambda logging configurationCloudWatch Logs retention

The Serverless Applications Lens gives both halves: "Set appropriate logging levels and remove unnecessary logging information to optimize log ingestion", and "Set log retention periods for new and existing CloudWatch Logs groups." Lambda filters by level when the function logs in JSON: "To use log-level filtering, your Event Function must be configured to use the JSON log format. The default log format for all Lambda managed runtimes is currently plain text", and "if you set your Event Function's log level in your code, this setting takes precedence over any other log level settings you configure." Logs can also leave CloudWatch, at their own prices:

Where Lambda logs can go, and their Paris list prices

Destination	Ingestion or delivery, per GB	Then
CloudWatch Logs, Standard class	$0.5985	Storage at $0.0315 per GB-month, compressed
CloudWatch Logs, Infrequent Access class	$0.25	Fewer features: no metric or subscription filters, no Live Tail
Amazon S3, through a Delivery log group	$0.25	S3 storage, $0.024 per GB-month in S3 Standard
Amazon Data Firehose	$0.25	Firehose's own charges

USD, before tax. AWS Price List, eu-west-3, offer files published October 7, 2026 and October 14, 2026, fetched October 15, 2026.

Vended logs into the Infrequent Access class cost 58.2% less to ingest than into Standard, computed; the CloudWatch pricing page lists that class among the destinations of vended logs, while the Lambda guide documents Standard log groups, Amazon S3 and Firehose. The log classes guide has two catches: "After a log group is created, its log class can't be changed", and log events in a Delivery log group "are kept in CloudWatch Logs for two days." Delivery to S3 still pays CloudWatch: "Even when you publish logs directly to Amazon S3 or Firehose, CloudWatch delivery charges apply" (Enable logging from AWS services), and "Latency is typically higher" there. Pattern 1 prices WARN logs kept 30 days against INFO logs kept forever.

Lever 04 · Trim

Trim the Init phase

When it applies: Functions with a long Init Duration on their REPORT lines and many cold starts: scale-outs, development and test.
Watch out: Init is billed as duration, and runs again each time Lambda recycles an environment, provisioned concurrency included; SnapStart moves it to publish time, then bills its cache and restores outside Java.
Tools: REPORT log lines (Init Duration)Lambda SnapStart

Init is billed as duration, at the memory configured, and cold starts add up:

1 million cold starts of 1 second at 1,024 MB

$16.67 a monthof Init, billed as x86 duration in Paris, computed: an illustrative 1% of 100 million invocations.

Computed from the AWS Price List · eu-west-3 · Oct 14, 2026

The best practices put the saving in words: "Initialize SDK clients and database connections outside of the function handler, and cache static assets locally in the /tmp directory", because "This saves cost by reducing function run time." Import only what the function uses, as the lifecycle guide asks, and find the long starts on the REPORT lines, whose Init Duration measures them. With provisioned concurrency, Init runs again at every recycle and is billed each time. SnapStart moves Init to publish time; on Python and .NET, "duration charges also apply to initialization code that's declared outside of the handler, the time it takes for the runtime to load, and any code that runs in a runtime hook", and the cache and restores of SnapStart come on top.

Lever 05 · Trim

Set guardrails: timeouts, retries and loops

When it applies: Every function, and first those that write to the service that triggers them or call slow dependencies.
Watch out: A timeout too close to the usual duration cuts real requests; a failed asynchronous invocation is retried twice by default, each retry an invocation; loop detection covers loops through functions, SQS, S3, SNS and EventBridge only.
Tools: Function timeoutRecursive loop detectionReserved concurrencyRetry attempts

Four settings stop a bill from running away. The first is a realistic timeout, since a hung call bills the whole timeout (What duration counts):

1,000 invocations that hang to the 15-minute timeout

$15.00 of durationat 1,024 MB on x86 in Paris, computed.

Computed from the AWS Price List · eu-west-3 · Oct 14, 2026

The second is recursive loop detection, left on: "Unintentional recursive loops can result in unexpected charges being billed to your AWS account", and "If your function is invoked approximately 16 times in the same chain of requests, then Lambda automatically stops the next function invocation in that request chain and notifies you" (recursive loop detection); "There is no charge to use the feature." It covers loops between functions, Amazon SQS, Amazon S3, Amazon SNS and EventBridge custom event buses, for functions that use a supported AWS SDK: "When another AWS service such as Amazon DynamoDB forms part of the loop, Lambda can't currently detect and stop it." That is where the third comes in, reserved concurrency as the emergency brake:

If you see an unintended volume of invocations, set the function reserved concurrency to 0 immediately to throttle all invocations to the function, while you update the code.

AWS, Best practices for working with AWS Lambda Event Functions

The fourth caps retries. By default Lambda retries a failed asynchronous invocation twice, so it runs three times in all, and each retry is billed as an invocation. The Retry attempts setting (0 to 2) and the Maximum age of event setting (up to 6 hours) reduce that, and a function that fails fast fails cheap.

Lever 06 · Reshape

Right-size memory

When it applies: Functions left at the 128 MB default with CPU-bound code, and functions configured with far more memory than their Max Memory Used.
Watch out: Duration rarely falls exactly in proportion to memory: measure. Compute Optimizer covers x86_64 functions of 1,792 MB or less, invoked 50 times in 14 days.
Tools: AWS Compute OptimizerAWS Lambda Power TuningCloudWatch

"Performance testing your Lambda Event Function is a crucial part in ensuring you pick the optimum memory size configuration" (best practices), and the REPORT line gives the first answer: "By analyzing the Max Memory Used: field, you can determine if your function needs more memory or if you over-provisioned your function's memory size." AWS Compute Optimizer "generates memory size recommendations for AWS Lambda functions", from "the specifications and utilization metrics of the current function over a period of the last 14 days", for functions whose "configured memory is less than or equal to 1,792 MB" and that "were invoked at least 50 times in the last 14 days" (resource requirements); and "Compute Optimizer supports only functions that use x86_64 architecture" (memory guide). For the rest, AWS Lambda Power Tuning "uses AWS Step Functions to run multiple concurrent versions of a Lambda function at different memory allocations and measure the performance." The Serverless Applications Lens points to Compute Optimizer too.

What sizes a Lambda function's memory, and what each tool covers

Tool	Covers	What it gives
The REPORT line of each invocation	Every function	Max Memory Used, against the memory configured
AWS Compute Optimizer	x86_64 functions of 1,792 MB or less, invoked 50 times in 14 days	Memory size recommendations, from the last 14 days of metrics
AWS Lambda Power Tuning	The functions you run it on	The function run at several memory sizes, its performance measured

The arithmetic is in Memory sets the CPU: CPU-bound code can run faster for the same price, while code that waits only pays more.

Lever 07 · Reshape

Move to Arm

When it applies: Functions whose code, libraries, layers and extensions exist for arm64.
Watch out: Requests cost the same on both architectures; the duration on Arm must be measured, not assumed; Compute Optimizer does not cover arm64 functions.
Tools: Alias weighted routing

A function moves to arm64 when its code allows it: "If the function code includes third-party dependencies, each library or package provides an arm64 version" (instruction set architectures), and layers, extensions and container images must be arm64 too. At the same duration, a GB-second costs 20.0% less on Arm, computed, on every duration tier and for provisioned concurrency, while requests cost the same:

Arm against x86, Lambda in Paris: each pair drawn against its x86 price

Price	x86, per GB-second	Arm, per GB-second	Change, computed
Duration, first tier	$0.0000166667	$0.0000133334	20.0% less
Duration, second tier	$0.000015	$0.0000120001	20.0% less
Duration, third tier	$0.0000133334	$0.0000106667	20.0% less
Provisioned concurrency	$0.0000048673	$0.0000038938	20.0% less
Duration on provisioned concurrency	$0.0000113569	$0.0000090855	20.0% less

USD, before tax. AWS Price List, eu-west-3, offer file published October 14, 2026, fetched October 15, 2026.

Then measure: "use alias routing configuration to split traffic between the x86 and arm64 versions of the function, and compare the performance and latency". The Serverless Applications Lens insists, "We always recommend load testing as results might vary for each use case, dependency, and runtime." Pattern 1 and pattern 2 price the move. The EC2 article weighs Graviton for instances.

Lever 08 · Reshape

Batch and filter events before they invoke

When it applies: Queue and stream consumers invoked once per message or record, and functions that discard part of what they receive.
Watch out: The timeout must cover a whole batch; a failed batch is retried whole unless partial batch responses are on; a batch window adds latency; code must be idempotent.
Tools: Event source mapping batch size and windowEvent filtering

A queue consumer invoked once per message pays its fixed work and a request for every message. Larger batches spread them: "A larger batch size can often more efficiently absorb the invoke overhead across a larger set of records, increasing your throughput". Filters drop what the function would ignore before it runs: "For Amazon SQS, if a message doesn't satisfy your filter criteria, Lambda automatically removes the message from the queue". The settings of an SQS event source mapping, from its configuration guide and Using Lambda with Amazon SQS:

The settings of an SQS event source mapping, and what each does to the bill

Setting	What it does	On the bill
Batch size, up to 10,000 messages on a standard queue	Hands the function several messages per invocation	One request and one start of the handler per batch
Batch window, up to 5 minutes	Waits for a batch to fill	Fuller batches, at the cost of latency
Filter criteria, up to five by default	Removes the messages that no filter matches	No request and no duration for them
Partial batch responses	Returns only the failed messages to the queue	Retries what failed, not the whole batch

The timeout must then cover a whole batch; on a quiet queue, "Lambda might wait for up to 20 seconds before invoking your function"; and messages can arrive twice, so the code must be idempotent. In provisioned mode, "Each event poller uses long polling to your SQS queue with up to 10 polls per second, which incur SQS API requests cost" (SQS scaling). Pattern 2 prices a filter and batches of 10.

Lever 09 · Reshape

Remove functions that only pass data along

When it applies: Functions that take data from one AWS service and hand it to another unchanged.
Watch out: Mapping templates and direct integrations can be harder to debug and test than a function.
Tools: API Gateway service integrationsAmazon EventBridgeAWS Step Functions

"If your Lambda function is not performing custom logic while integrating with other AWS services, chances are that it may be unnecessary": API Gateway can call many AWS services directly, and Amazon EventBridge, AWS Step Functions and Amazon SNS filters can route events without a function in between. The function's requests, duration and logs go with it. The same page names the cost on the other side: "Adding mapping templates might introduce extra complexity on the debugging and testing side versus using a Lambda function instead."

Lever 10 · Reshape

Use provisioned concurrency only where latency needs it

When it applies: Synchronous, user-facing functions whose cold-start latency target SnapStart cannot meet.
Watch out: In Paris it costs less than on demand only near full use; its hours are billed used or not; the free tier does not apply; idle periods can freeze target tracking.
Tools: Application Auto ScalingProvisionedConcurrencyUtilization

Keep provisioned concurrency on the latency-sensitive aliases, sized as Lambda suggests, "adding a 10% buffer on top of the amount of concurrency your Event Function typically needs", since every GB configured bills whether a request uses it or not:

1 GB of provisioned concurrency kept all month

$12.79 a monthon x86 in Paris, before a single request runs on it, computed.

Computed from the AWS Price List · eu-west-3 · Oct 14, 2026

Then let it follow the traffic: "If your Event Function receives predictable traffic patterns, use scheduled scaling. If you want your Event Function to maintain a specific utilization percentage, use a target tracking scaling policy." AWS Application Auto Scaling does both: "You can scale AWS Lambda provisioned concurrency using target tracking scaling policies and scheduled scaling", the latter with scheduled actions. Target tracking has a gap that the guide spells out: "During periods of inactivity, no metrics are emitted, and your auto-scaling alarms enter the INSUFFICIENT_DATA state. As a result, Application Auto Scaling won't be able to adjust your Event Function's provisioned concurrency. This might lead to unexpected billing."

SnapStart or provisioned concurrency: two answers to cold starts, priced in Paris

How: A snapshot of the initialized environment, taken when you publish a version
Billed: Nothing on Java; on Python and .NET, $0.0000022468 per GB-second cached and $0.0002052964 per GB restored
Limits: Java 11, Python 3.12, .NET 8 and later; not with provisioned concurrency, Amazon EFS or ephemeral storage above 512 MB
Promise: A best-effort optimization: cold starts are not guaranteed to go

How: Environments kept initialized on a version or an alias
Billed: $0.0000048673 per GB-second configured on x86, used or not, plus the duration that runs on it
Limits: Not on $LATEST; a minute or two to allocate; the free tier does not apply
Promise: Ready in double-digit milliseconds, unless Lambda resets an environment

What differs: a snapshot paid only when it is cached and restored, and free on Java, against environments paid for every second they stand ready.

Try SnapStart first where the runtime has it, since the two do not combine on a version. And keep the Paris arithmetic in view: below 91.7% utilization, provisioned concurrency costs more than the same requests on demand. Pattern 4 prices a schedule against the same provisioned concurrency around the clock.

Lever 11 · Reshape

Move steady load where it costs less

When it applies: Functions that keep their environments busy most of the time, around the clock, without sudden spikes.
Watch out: Provisioned capacity bills while it is idle; containers bring their scaling, patching and load balancer back to you; the break-even depends on a utilization you must measure.
Tools: Lambda Managed InstancesAWS FargateAmazon EC2

For work that keeps its environments busy around the clock, a container, an instance or Managed Instances can cost less, from a utilization each option sets. Against Lambda on Arm, at 1,769 MB, for requests of 100 ms:

Break-even utilization against Lambda on Arm, by provisioned option, in Paris (computed)

Provisioned option	Per vCPU-hour, computed	Break-even, duration only	With Lambda's requests
Fargate Arm, on demand	$0.04736	57.1%	52.6%
EC2 c7g.large, on demand	$0.04295	51.8%	47.7%
Lambda Managed Instances, m7g.large, on demand	$0.05474	66.0%	66.0%
Fargate Arm, 1-year plan	$0.03730	45.0%	41.4%
EC2 c7g.large, 1-year plan	$0.03395	40.9%	37.7%
Lambda Managed Instances, 3-year plan on the instances	$0.03214	38.8%	38.8%
Fargate Arm, 3-year plan	$0.02558	30.8%	28.4%
EC2 c7g.large, 3-year plan	$0.02405	29.0%	26.7%

Computed from the AWS Price List, eu-west-3, offer files published September 11, 2026, October 12, 2026, October 13, 2026 and October 14, 2026, fetched October 15, 2026.

Read a row as: if the option's vCPUs are busy more than that share of the time on average, they cost less than the same work on Lambda. Managed Instances pay Lambda's request charge too, so theirs cancel out; Fargate on x86 against Lambda on x86 breaks even at 57.1% (53.4% with requests). The trade has a cost the table does not show: provisioned capacity bills idle, Managed Instances start "three instances by default", and containers bring back the scaling and the load balancer that Lambda ran for you, even if Fargate means "you no longer have to provision, configure, or scale clusters of virtual machines". AWS's own pointer for the case is Managed Instances, for "steady-state workloads without unexpected traffic spikes". Pattern 3 prices eleven options for one service.

Lever 12 · Route

Pick the front door by need

When it applies: Any function behind API Gateway, a function URL or an Application Load Balancer.
Watch out: API keys, per-client throttling, request validation, AWS WAF and private endpoints need a REST API; function URLs offer only basic authentication; HTTP APIs meter 512 KB per request.
Tools: API Gateway HTTP APILambda function URLs

Choose the cheapest entry that has the features the API uses. "HTTP APIs are designed with minimal features so that they can be offered at a lower price", and "Choose REST APIs if you need features such as API keys, per-client throttling, request validation, AWS WAF integration, or private API endpoints." In Paris, an HTTP API request costs 66.6% less than a REST API request, computed, and "HTTP APIs are metered in 512 KB increments" (API Gateway pricing). Either costs more than the request to the function behind it:

What one million requests cost at the front door and at the function, in Paris

Per request of		List price, per million requests
API Gateway REST APIFirst 333 million a month		$3.50
API Gateway HTTP APIFirst 300 million a month		$1.17
Lambda requestx86 or Arm		$0.20

USD, before tax. AWS Price List, eu-west-3, offer files published October 13, 2026 and October 14, 2026, fetched October 15, 2026.

A function URL adds nothing to the Lambda request, "There are no additional charges for the URL endpoint itself", and suits APIs "where you only need basic authentication methods and request/response handling and where you want to keep costs and complexity to a minimum". An Application Load Balancer can target functions as well as containers, at its hourly and capacity-unit prices. Pattern 1 prices the REST API, the HTTP API and a function URL.

Lever 13 · Route

Keep AWS-service traffic off the NAT gateway

When it applies: VPC-connected functions that reach Amazon S3, DynamoDB or other AWS services through a NAT gateway.
Watch out: Interface endpoints bill per hour, per Availability Zone and per GB; a function that needs no private resource need not be in a VPC at all.
Tools: Gateway endpointsInterface endpoints

A function attached to a VPC that calls AWS APIs through a NAT gateway pays the gateway by the hour and by the GB. The Serverless Applications Lens points at endpoints: "Leveraging VPC endpoints will most likely contribute to cost savings if you are leveraging NAT and Internet gateways for the sole purpose of accessing Serverless APIs from AWS resources that do not have access to the internet." Gateway endpoints serve Amazon S3 and DynamoDB, and of the S3 one the Lambda guide says "There is no cost for this option"; interface endpoints, for the other services, bill per hour in each zone and per GB:

1,024 GB a month from VPC-connected functions to an AWS service, across two Availability Zones, in Paris, where the NAT gateways carry nothing else

Through two NAT gateways Illustrative

Line	A month
Network	$124.20
Two NAT gateways, 730 h each1,460 h × $0.05 /h	$73.00
Data processed1,024 GB × $0.05 /GB	$51.20
A month, computed	$124.20

Through one interface endpoint in two zones Illustrative

Line	A month
Network	$26.30
Endpoint hours, two zones × 730 h1,460 h × $0.011 /h	$16.06
Data processed1,024 GB × $0.01 /GB	$10.24
A month, computed	$26.30

An interface endpoint costs $97.90 a month less than two NAT gateways (78.8% less), computed.

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published September 17, 2026 and October 12, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

If the functions also reach the internet, the NAT gateways stay, and the endpoint replaces only their data processing: $51.20 against $16.06 plus $10.24, computed. The VPC guide gives the same advice for any workload, and the S3 article prices the S3 gateway endpoint. And a function that needs no private resource need not be in a VPC: by default it reaches the internet without one.

Lever 14 · Commit

Commit with Compute Savings Plans, last

When it applies: A steady base of GB-seconds that remains once the levers above have run.
Watch out: In Paris the plan's rate for Lambda duration is the same for one year as for three, requests are not discounted, and the same commitment discounts Fargate and EC2 much more.

A Compute Savings Plan covers Lambda duration and provisioned concurrency along with EC2 and Fargate (Savings Plans types). In Paris, Arm duration on the plan costs 10.0% less than On-Demand, computed, the same for one year as for three, and requests cost the same (Compute Savings Plans): with Lambda on Arm at the plan's rate, pattern 3's service costs $1,194.72 a month instead of its $1,315.79. Buy it for the GB-seconds that remain after the other levers, steady month after month, and remember that the same commitment discounts EC2 and Fargate much more: for an account that runs both, the lever that moves the most money may be Move steady load where it costs less.

Lever 15 · Review

Review on a cadence

When it applies: Every workload, at the frequency its share of the bill warrants.
Watch out: Lambda's compute types have multiplied (Managed Instances, durable functions, Web Functions, MicroVMs): each review checks whether a function belongs on another compute type.

"The review effort should reflect potential benefit", in AWS's words (COST10-BP01):

How often AWS suggests reviewing a workload

Workload	Reviewed
Core workloads, or workloads over ten percent of the bill	Quarterly or every six months
Workloads below ten percent of the bill	Annually

Lambda gives a reason of its own to look again: its compute types have multiplied, with Managed Instances, durable functions, Web Functions and MicroVMs now beside Event Functions, so each review asks whether a function still belongs on the type it runs on, and whether its memory, architecture and front door still fit its traffic.

In short: Commit last: see the bill by function, delete and guard what costs for nothing, size memory, architecture, batching and provisioned concurrency to the work, route traffic through the cheapest door, and only then buy a plan for the GB-seconds that remain.

FAQ

How is AWS Lambda billed?

Per request and per GB-second of duration: the memory you configure times the time your code runs, Init included, rounded up to the millisecond, at $0.0000166667 per GB-second on x86 in Paris for the first tier and $0.20 per million requests. Provisioned concurrency, SnapStart outside Java and ephemeral storage above 512 MB add their own lines (What a Lambda bill is made of).

Do Lambda cold starts cost money?

Yes: the Init phase of a new environment is billed as duration, on demand as with provisioned concurrency, and AWS says cold starts typically occur in under 1% of invocations. Smaller packages and fewer imports shorten it (Cold starts are billed).

Is Lambda cheaper than EC2 or Fargate?

It depends on how busy the work keeps the compute: Lambda bills nothing while no request runs, where a task or an instance bills while it waits. For steady, busy work, Fargate Arm tasks in Paris cost less than the same CPU-bound work on Lambda on Arm once they are busy more than 52.6% of the time, computed (pattern 3).

Is provisioned concurrency worth it?

For latency, where SnapStart is not enough. For money, rarely: in Paris it costs less than on demand only above 91.7% utilization, computed, against 60.0% at the US East rates of the pricing page's examples (Provisioned concurrency).

Do Compute Savings Plans cover Lambda?

Yes, duration and provisioned concurrency, but not requests, and in Paris at the same rate for one year as for three, a smaller discount than the same plan gives EC2 and Fargate (Compute Savings Plans).

Sources

What is AWS Lambda? AWS, documentation, accessed October 15, 2026.
AWS Lambda Event Functions (formerly Lambda functions) AWS, documentation, accessed October 15, 2026.
How Lambda works AWS, documentation, accessed October 15, 2026.
Invoke a Lambda Event Function synchronously AWS, documentation, accessed October 16, 2026.
Invoking a Lambda Event Function asynchronously AWS, documentation, accessed October 16, 2026.
How Lambda handles errors and retries with asynchronous invocation AWS, documentation, accessed October 16, 2026.
Configuring error handling settings for Lambda asynchronous invocations AWS, documentation, accessed October 16, 2026.
Understanding the Lambda execution environment lifecycle AWS, documentation, accessed October 15, 2026.
Configure Lambda Event Function memory AWS, documentation, accessed October 15, 2026.
Selecting and configuring an instruction set architecture for your Lambda function AWS, documentation, accessed October 15, 2026.
Configure ephemeral storage for Lambda Event Functions AWS, documentation, accessed October 15, 2026.
Configure Lambda Event Function timeout AWS, documentation, accessed October 15, 2026.
Understanding Lambda Event Function scaling AWS, documentation, accessed October 15, 2026.
Configuring provisioned concurrency for an Event Function AWS, documentation, accessed October 15, 2026.
Event Function scaling behavior AWS, documentation, accessed October 15, 2026.
Improving startup performance with Lambda SnapStart AWS, documentation, accessed October 15, 2026.
Giving Lambda Event Functions access to resources in an Amazon VPC AWS, documentation, accessed October 15, 2026.
Enable internet access for VPC-connected Lambda Event Functions AWS, documentation, accessed October 15, 2026.
Working with Lambda Event Function logs AWS, documentation, accessed October 15, 2026.
Sending Lambda Event Function logs to CloudWatch Logs AWS, documentation, accessed October 15, 2026.
Log-level filtering AWS, documentation, accessed October 15, 2026.
Sending Lambda Event Function logs to Amazon S3 AWS, documentation, accessed October 15, 2026.
Best practices for working with AWS Lambda Event Functions AWS, documentation, accessed October 15, 2026.
Control which events Lambda sends to your Event Function AWS, documentation, accessed October 15, 2026.
Use Lambda recursive loop detection to prevent infinite loops AWS, documentation, accessed October 15, 2026.
Using Lambda with Amazon SQS AWS, documentation, accessed October 15, 2026.
Creating and configuring an Amazon SQS event source mapping AWS, documentation, accessed October 15, 2026.
Configuring scaling behavior for SQS event source mappings AWS, documentation, accessed October 15, 2026.
Select a method to invoke your Lambda Event Function using an HTTP request AWS, documentation, accessed October 15, 2026.
Process Application Load Balancer requests with Lambda AWS, documentation, accessed October 15, 2026.
Lambda Managed Instances AWS, documentation, accessed October 15, 2026.
Capacity providers AWS, documentation, accessed October 15, 2026.
Lambda durable functions AWS, documentation, accessed October 15, 2026.
AWS Lambda Web Functions AWS, documentation, accessed October 15, 2026.
Using tags on Lambda Event Functions AWS, documentation, accessed October 15, 2026.
Resilience in AWS Lambda AWS, documentation, accessed October 15, 2026.
Creating event-driven architectures with Lambda AWS, documentation, accessed October 15, 2026.
AWS Lambda pricing AWS, pricing page, accessed October 15, 2026.
AWS Lambda FAQs AWS, product page, accessed October 15, 2026.
AWS Fargate pricing AWS, pricing page, accessed October 15, 2026.
AWS Fargate for Amazon ECS AWS, documentation, accessed October 15, 2026.
Amazon EC2 On-Demand Pricing AWS, pricing page, accessed October 15, 2026.
Savings Plans types AWS, documentation, accessed October 15, 2026.
Savings Plans FAQ AWS, product page, accessed October 15, 2026.
Amazon CloudWatch pricing AWS, pricing page, accessed October 15, 2026.
Log classes AWS, documentation, accessed October 15, 2026.
Supported log destinations and permissions AWS, documentation, accessed October 15, 2026.
Enable logging from AWS services AWS, documentation, accessed October 15, 2026.
Working with log groups and log streams AWS, documentation, accessed October 15, 2026.
Choose between REST APIs and HTTP APIs AWS, documentation, accessed October 15, 2026.
Amazon API Gateway pricing AWS, pricing page, accessed October 15, 2026.
Amazon SQS pricing AWS, pricing page, accessed October 15, 2026.
Pricing for NAT gateways AWS, documentation, accessed October 15, 2026.
Enable outbound IPv6 traffic using an egress-only internet gateway AWS, documentation, accessed October 16, 2026.
Understanding how Savings Plans apply to your usage AWS, documentation, accessed October 16, 2026.
Viewing Lambda function recommendations AWS, documentation, accessed October 15, 2026.
Resource requirements (AWS Compute Optimizer) AWS, documentation, accessed October 15, 2026.
AWS Lambda and Application Auto Scaling AWS, documentation, accessed October 15, 2026.
Scheduled scaling for Application Auto Scaling AWS, documentation, accessed October 15, 2026.
Cost-effective resources (Serverless Applications Lens) AWS, whitepaper, accessed October 15, 2026.
Lambda cost and performance optimization (Serverless Applications Lens) AWS, whitepaper, accessed October 15, 2026.
Logging ingestion and storage (Serverless Applications Lens) AWS, whitepaper, accessed October 15, 2026.
Leverage VPC endpoints (Serverless Applications Lens) AWS, whitepaper, accessed October 15, 2026.
Direct integrations (Serverless Applications Lens) AWS, whitepaper, accessed October 15, 2026.
Expenditure and usage awareness (Serverless Applications Lens) AWS, whitepaper, accessed October 15, 2026.
Code optimization (Serverless Applications Lens) AWS, whitepaper, accessed October 15, 2026.
COST10-BP01 Develop a workload review process AWS, whitepaper, accessed October 15, 2026.
AWS Price List: AWS Lambda, eu-west-3 (offer file of October 14, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Compute Savings Plans, eu-west-3 (offer file of October 13, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Amazon API Gateway, eu-west-3 (offer file of October 13, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Amazon CloudWatch, eu-west-3 (offer file of October 7, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Amazon ECS (AWS Fargate), eu-west-3 (offer file of September 11, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Amazon EC2, eu-west-3 (offer file of October 12, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Amazon SQS, eu-west-3 (offer file of September 11, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Elastic Load Balancing, eu-west-3 (offer file of September 11, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Amazon VPC, eu-west-3 (offer file of September 17, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: AWS Data Transfer, eu-west-3 (offer file of September 16, 2026) AWS, price list, accessed October 15, 2026.
AWS Price List: Amazon S3, eu-west-3 (offer file of October 14, 2026) AWS, price list, accessed October 15, 2026.

Quotations from AWS documentation are used under CC BY-SA 4.0.

Amazon Web Services, AWS and the names of AWS services are trademarks of Amazon.com, Inc. or its affiliates. Diagrams use the AWS Architecture Icons, unaltered.

AWS Lambda: pricing, memory and how to cut the bill

Key facts

What AWS Lambda is

How Lambda works under the hood

Functions, triggers and event source mappings

Execution environments: one microVM each, one request at a time

Init, Invoke and Shutdown: what each phase bills

Cold starts are billed

Memory sets the CPU

Arm or x86

Concurrency: reserved and provisioned

SnapStart

A function in a VPC

Managed Instances, Web Functions and durable functions

What Lambda is used for

Lambda, Fargate or EC2

How Lambda pricing works

What a Lambda bill is made of

Requests and duration in Paris

What duration counts

Provisioned concurrency

SnapStart, ephemeral storage and the other options

The costs around the function

Managed Instances, Web Functions and durable functions in Paris

Compute Savings Plans

Paris and the US East examples

Reading the Lambda lines of a bill

Architecture patterns around Lambda and what they cost

A public API on API Gateway and Lambda

Assumptions

Not counted

Sources

A queue worker: one message per invocation, or filtered batches

Assumptions

Not counted

Sources

Steady, CPU-bound traffic: Lambda against Fargate, EC2 and Managed Instances

Assumptions

Not counted

Sources

A latency-sensitive API on provisioned concurrency

Assumptions

Not counted

Sources

How to reduce Lambda costs

See the Lambda bill by function

Delete unused functions and versions

Log less, keep logs shorter

Trim the Init phase

Set guardrails: timeouts, retries and loops

Right-size memory

Move to Arm

Batch and filter events before they invoke

Remove functions that only pass data along

Use provisioned concurrency only where latency needs it

Move steady load where it costs less

Pick the front door by need

Keep AWS-service traffic off the NAT gateway

Commit with Compute Savings Plans, last

Review on a cadence

FAQ

How is AWS Lambda billed?

Do Lambda cold starts cost money?

Is Lambda cheaper than EC2 or Fargate?

Is provisioned concurrency worth it?

Do Compute Savings Plans cover Lambda?

Sources

More articles

Amazon Bedrock pricing: how to cut the bill

AWS Cost Explorer: reading your bill

Amazon EKS: pricing, extended support and how to cut the bill