[Lambda] Memory Issue: Fail Faster

尚未确定任何仓库文件、测试或实现入口；请先查阅 AWS Lambda 文档中关于 ARM 和 x86 上 Python 托管运行时及 OCI-image 运行时内存耗尽行为的说明。定义可配置的 fail-fast 模式将如何区分内存不足与有意的内存使用，并将现有的 timeout 行为作为比较基准。

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