12 documented AWS Lambda cost inefficiencies, each with how to detect it and how to fix it.
AWS LambdaCER-0296
A function has steady, high-volume traffic (or predictable load) but continues running on default Lambda pricing, where costs scale with execution duration. Lambda Managed Instances runs Lambda on EC2 capacity managed by Lambda and...
AWS LambdaCER-0290
Provisioned Concurrency is enabled for Lambda functions that do not require consistently low latency or steady traffic. In such cases, provisioned concurrency remains allocated and billed during idle periods, creating ongoing cost without...
AWS LambdaCER-0209
Many teams publish new Lambda versions frequently (e.g., through CI/CD pipelines) but do not clean up old ones. When SnapStart is enabled on Python or .NET functions, each of these versions retains a cached snapshot, generating ongoing...
AWS LambdaCER-0204
SnapStart reduces cold-start latency, but when configured inefficiently, it can increase costs. For Python and .NET functions, high-traffic workloads can trigger frequent snapshot restorations, multiplying costs. Slow initialization code...
AWS LambdaCER-0124
Lambda is designed for simplicity and elasticity, but its pricing model becomes expensive at scale. When a function runs frequently (e.g., millions of invocations per day) or for extended durations, the cumulative cost may exceed that of...
AWS LambdaCER-0230
Some Lambda functions perform synchronous calls to other services, APIs, or internal microservices and wait for the response before proceeding. During this time, the Lambda is idle from a compute perspective but still fully billed. This...
AWS LambdaCER-0218
Lambda functions default to the x86_64 architecture, which is more expensive than Arm64. For many workloads, especially those written in interpreted languages (e.g., Python, Node.js) or compiled to architecture-neutral bytecode (e.g.,...
AWS LambdaCER-0213
Retry storms occur when a function fails and is automatically retried repeatedly by the service that invoked it: asynchronous invocations (e.g., EventBridge, SNS, S3) are retried twice by default after function errors, SQS event source...
AWS LambdaCER-0165
Recursive invocation occurs when a Lambda function triggers itself directly or indirectly, often through an event source like SQS, SNS, or another Lambda. This loop can be unintentional - for example, when the function writes output to a...
AWS LambdaCER-0207
When a Lambda function processes messages from an SQS queue but fails to handle certain messages properly, the same messages may be returned to the queue and retried repeatedly. In some cases, especially if the Lambda is also writing...
AWS LambdaCER-0103
Each Lambda function must be configured with a memory setting, which indirectly controls the amount of CPU and networking performance allocated. In many environments, memory settings are defined arbitrarily or left unchanged as functions...
AWS LambdaCER-0358
A Lambda invocation that hits its configured timeout is stopped by the runtime and returned as a function error, but the time it ran up to that limit is still billed. The work it was doing is usually lost, so the invocation is paid for in...
