[Lambda] Memory Issue: Fail Faster

No repository files, tests, or implementation entry points are identified; start by reviewing AWS Lambda’s documented memory-exhaustion behavior for Python managed and OCI-image runtimes on ARM and x86. Define how a configurable fail-fast mode would distinguish insufficient memory from intentional memory use, and consider the existing timeout behavior as the comparison point.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
When insufficient memory is allocated to an AWS Lambda function, the function executes until it times out, even though it cannot complete successfully. This results in unnecessary billed duration. A configurable option to fail fast or fail directly when memory is insufficient would be beneficial.

Which service(s) is this request for?
AWS Lambda

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
When a Lambda function lacks sufficient memory, it continues running until the timeout duration is reached. This leads to wasted execution time and higher costs, as users are billed for the full timeout duration. Detecting and stopping such executions earlier would save time and reduce costs.

However, this behavior may not be relevant in all cases. For example, some developers might intentionally use all available memory for caching purposes, or runtimes like Java JVM could utilize all memory without necessarily indicating a failure. For Python runtimes, however, insufficient memory often results in this timeout behavior. Providing an option to configure the default behavior—either fail fast or continue until timeout—would allow developers to tailor Lambda execution to their specific use case.

Are you currently working around this issue?
The current workaround involves setting shorter timeout durations or waiting for the execution to complete to identify memory-related issues. Both approaches are inefficient and do not address the root problem.

Additional context
This issue has been observed with Python runtimes (both managed and OCI-image-based) on ARM and x86 architectures.

Attachments
N/A