最新资讯
bloomberg.com Google 接手 Crusoe 曾推介的怀俄明州数据中心 techxplore.com 三种新技术针对隐藏 AI 后门且不显著损失性能 unite.ai OpenAI CFO 称中期选举后数据中心建设仍将继续 techcrunch.com 数百个 Artex AI 黑客工具服务器暴露在公网 techcrunch.com Meta 推出 Spaces,为 Muse 智能体提供新协作方式 wired.com Wired:免费中国 AI 模型的黑客能力快速提升 unite.ai OpenAI 与 Hacktron 合作测试第三方服务连接安全 dev.to 如何将 PostgreSQL 接入 AI agent 并对写入操作设置审批 unite.ai AWS 在 SageMaker 推理端点加入 NVIDIA GPU 分区支持 unite.ai BMO 在信用卡客服引入 agentic AI 案件准备 theverge.com Meta 的 Muse AI 可创建自定义 spaces,按需生成应用式体验 thenewstack.io Meta 用最强 AI 模型训练多数用户实际使用的模型
多元动态
登录 注册
行业动态 dev.to · @Kevin Lupera

15 分钟限制终结:AWS Lambda 90 分钟超时深度分析

原文 我的收藏

文章分析 AWS Lambda 事件源映射(ESM)在托管实例(LMI)上的超时从 15 分钟提升至 90 分钟,回顾了 Lambda 超时限制的演进:2014 年 5 分钟、2018 年 15 分钟,并指出数据处理、大规模媒体转码和生成式 AI 推理等负载此前受 15 分钟限制。文中列举了五类超过 15 分钟的负载模式,但正文片段在列举处截断,未提供官方文档或实测数据。

AI推荐理由 文章围绕 AWS Lambda 事件源映射(ESM)在托管实例(LMI)上超时从 15 分钟提升至 90 分钟展开,梳理了 Lambda 超时限制从 2014 年 5 分钟、2018 年 15 分钟到当前变化的演进,并指出数据处理、媒体转码和生成式 AI 推理等负载此前受 15 分钟限制。内容有具体时间线和场景分析,但正文片段在列举五类超限负载时被截断,未给出官方文档链接或实测数据,属于开发者视角的解读而非官方首发。

72

正文

Hace 4 días vi un anuncio que me parecio muy interesante es que ya se incremento 6x el timeout de las funciones Lambda de AWS con origen de eventos (ESM) en instancias administradas (LMI), lo cual abre muchas posibilidades a considerar. Historia ¿Por qué Lambda necesitaba 90 minutos? Para comprender por qué esta actualización representa un punto de inflexión, analicemos cómo evolucionaron los límites de ejecución de Lambda junto con las cargas de trabajo en la nube: 2014: AWS Lambda se lanzó con un límite de tiempo de espera de 5 minutos. 2018: El tiempo de espera se amplió a 15 minutos, dando inicio a la era dorada de los microservicios basados ​​en eventos. 2025-2026: Las cargas de trabajo se orientaron drásticamente hacia el procesamiento de datos, la transcodificación de medios a gran escala y el razonamiento de IA generativa. El límite de 15 minutos se convirtió en un obstáculo persistente. Cinco patrones de carga de trabajo principales superaron el límite de 15 minutos: Procesamiento multimedia: La transcripción de voz a texto y la transcodificación de vídeo de alta definición requieren habitualmente entre 20 y 60 minutos de procesamiento ininterrumpido en CPU/GPU. Cálculos financieros: Simulaciones de riesgo Monte Carlo complejas, modelado de carteras y cálculos de rendimiento de bonos que exigen una gran cantidad de memoria y procesamiento continuo. ETL y canalizaciones de datos: Trabajos por lotes que ingieren archivos de varios gigabytes o extraen datos de API de socios externos lentos durante las horas pico. Inferencia y razonamiento de IA: Evaluaciones por lotes, cadenas de razonamiento LLM de varios pasos y tareas de generación de datos sintéticos que se ajustan perfectamente a las asignaciones de CPU y memoria de Lambda, pero superan el límite de tiempo. Extracción de datos web e ingesta de datos de proveedores: Rastreadores que extraen datos de catálogo no estructurados de puntos finales de terceros con ve locidad limitada o lentos. La letra pequeña: qué se admite (y qué no) El tiempo de espera de 90 minutos no es un interruptor universal para todas las funciones Lambda. Opera bajo límites arquitectónicos específicos: Invocaciones admitidas Compute Engine: solo instancias administradas (LMI) de Lambda. El Lambda On-Demand estándar sigue limitado al límite tradicional de 15 minutos. Tipo de invocación: asincrónica (InvocationType='Event') y mapeo de origen de eventos (ESM). Funciones duraderas: compatibles con pasos de ejecución individuales. Precios: Sin recargo. Se aplican tasas de cálculo de instancias administradas Lambda estándar. Límites y exclusiones cruciales Las invocaciones sincrónicas permanecen 15 minutos: si un cliente invoca su función sincrónicamente (RequestResponse), como a través de Amazon API Gateway, un balanceador de carga de aplicaciones o llamadas directas al SDK, Lambda aplica estrictamente el máximo de 15 minutos, incluso si el tiempo de espera de su función está configurado en 5400 segundos. La fase de inicio no ha cambiado: el contenedor de inicio en frío y la inicialización del tiempo de ejecución (Init) permanecen limitados a 15 minutos. Cobertura del servicio ESM: la ventana de 90 minutos se aplica a Amazon SQS, Amazon Kinesis, Amazon DynamoDB Streams, Amazon MSK y Apache Kafka autoadministrado. Sin embargo, las asignaciones de fuentes de eventos de Amazon MQ y Amazon DocumentDB siguen limitadas a 15 minutos. Configuración Consola AWS To modify the timeout for a function Abre la página Funciones de la consola Lambda. Selecciona una función. Selecciona la pestaña Configuración y luego Configuración general. Abre la pestaña Configuración en la consola Lambda. En Configuración general, selecciona Editar. En Tiempo de espera, establece un valor entre 1 y 5400 segundos (15 minutos). Selecciona Guardar. CLI AWS Para configurar el timeout lo puedes realizar con el comando (recuerda cambiar el nombre de la función y la región): aws lambda update-function-configuration \ --function-name my-data-processor \ --timeout 5400 \ --region us-east-1 Enter fullscreen mode Exit fullscreen mode AWS CloudFormation o AWS SAM Si utilizas AWS CloudFormation o AWS Serverless Application Model (AWS SAM) lo puedes configurar de la siguiente forma: MyFunction: Type: AWS::Serverless::Function Properties: FunctionName: my-data-processor Runtime: python3.12 Handler: app.handler Timeout: 5400 MemorySize: 10240 Enter fullscreen mode Exit fullscreen mode Resumen Para las funciones Lambda invocadas de forma asíncrona, el tiempo de espera se puede configurar hasta un máximo de 90 minutos. Esta verificación confirmó que la función se ejecutó durante 16 minutos, superando el límite de 15 minutos. Al ejecutar funciones Lambda durante periodos prolongados, recomendamos evaluar cuidadosamente la solución, teniendo en cuenta que el modelo de precios difiere del de Lambda estándar. AWS Lambda pricing Referencias: Post oficial: https://aws.amazon.com/es/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/

来源报道 · 1 篇 · 以下链接均前往原始媒体

← 返回精选动态 原文

更多内容