Book a demo
Cloud Efficiency Hub

Excessive Lambda Retries (Retry Storms)

The short version

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 mappings return a failed message to the queue after each visibility timeout until the queue's redrive policy (maxReceiveCount) moves it to a dead-letter queue or the message expires, and stream event source mappings (Kinesis, DynamoDB Streams) retry the entire batch until the records expire unless a retry limit is set.

Liam Greenamyre

Principal Product Manager (Technical - External Services) @ Amazon Web Services (AWS)

AWS service
AWS Lambda
Category
Compute
Reference
CER-0213
Type
Inefficient Configuration

Explanation

Why the waste happens and who it affects.

If the error is persistent and unhandled, retries can accumulate rapidly - often invisibly - creating a large volume of billable executions with no successful outcome. This is especially costly when functions run for extended durations or have high memory allocation.

Billing model

The pricing dimensions that drive this cost.

  • Each retry counts as a separate request
  • Billed per millisecond of execution time for each retry
  • Retries from failed invocations can exponentially increase cost if not controlled

How to detect

5 checks to find it in your estate.

  • Check for high error-to-success ratios in CloudWatch Metrics
  • Investigate spikes in invocation count after initial failure events
  • Correlate retries with common payloads and error messages
  • Review configurations for MaximumRetryAttempts and DLQs
  • Assess the presence of throttling, downstream timeouts, or missing exception handling

How to fix

6 ways to remove the waste.

  • Configure DLQs to isolate and inspect failed invocations
  • Implement exponential backoff or circuit breaker patterns in retry logic
  • Set appropriate retry limits for each source: MaximumRetryAttempts and MaximumRecordAgeInSeconds on stream event source mappings (Kinesis, DynamoDB Streams), MaximumRetryAttempts (0-2) and maximum event age on asynchronous invocation settings, and a redrive policy with maxReceiveCount and a dead-letter queue on SQS source queues
  • Improve exception handling and idempotency in function code
  • Utilize anomaly detection software to alert on abnormal retry patterns
  • Monitor CloudWatch for retry-specific metrics and alarms

Documentation

Vendor references for pricing and configuration.

Browse the library

  • AWS LambdaCER-0204

    Inefficient SnapStart Configuration in Lambda

    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...

    Compute

  • AWS LambdaCER-0230

    Excessive Lambda Duration from Synchronous Waiting

    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...

    Compute

  • AWS LambdaCER-0218

    Suboptimal Architecture Selection in AWS Lambda

    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.,...

    Compute