# Tiempos de ejecución de Lambda
Lambda admite múltiples idiomas a través del uso de *tiempos de ejecución*. Un tiempo de ejecución proporciona un entorno específico del lenguaje que transmite eventos de invocación, información de contexto y respuestas entre Lambda y la función. Puede usar tiempos de ejecución que Lambda proporcione, o crear los suyos propios.
Lambda es independiente del tiempo de ejecución que elija. Para funciones sencillas, los lenguajes interpretados como Python y Node.js ofrecen el rendimiento más rápido. Para las funciones con cálculos más complejos, los lenguajes compilados como Java suelen ser más lentos a la hora de inicializarse, pero se ejecutan rápidamente en el controlador de Lambda. La elección del tiempo de ejecución también depende de las preferencias del desarrollador y de su familiaridad con el lenguaje.
Cada versión principal del lenguaje de programación tiene un tiempo de ejecución independiente, con un *identificador de tiempo de ejecución* único, como `nodejs24.x` o `python3.14`. Para configurar una función a fin de que utilice una nueva versión principal del lenguaje, debe cambiar el identificador del tiempo de ejecución. Como AWS Lambda no puede garantizar la compatibilidad con versiones anteriores entre las versiones principales, esta es una operación que depende del cliente.
Para una [función definida como una imagen de contenedor](images-create.md), se elige un tiempo de ejecución y la distribución de Linux al crear la imagen contenedor. Para cambiar el tiempo de ejecución, cree una nueva imagen contenedor.
Cuando se utiliza un archivo de archivo .zip para el paquete de implementación, se elige un tiempo de ejecución al crear la función. Para cambiar el tiempo de ejecución, puede [actualizar la configuración de su función](configuration-function-zip.md). El tiempo de ejecución está emparejado con una de las distribuciones de Amazon Linux. El entorno de ejecución subyacente ofrece [variables de entorno](configuration-envvars.md) y bibliotecas adicionales a las que puede acceder desde el código de función.
Lambda invoca la función en un [entorno de ejecución](lambda-runtime-environment.md). El entorno de ejecución proporciona un entorno en tiempo de ejecución seguro y aislado que administra los recursos necesarios para ejecutar la función. Lambda reutiliza el entorno de ejecución de una invocación previa, si la hay, o puede crear un nuevo entorno de ejecución.
Para usar otros lenguajes en Lambda, como [Go](lambda-golang.md) o [Rust](lambda-rust.md), utilice un [tiempo de ejecución exclusivo del sistema operativo](runtimes-provided.md). El entorno de ejecución de Lambda proporciona una [interfaz de tiempo de ejecución](runtimes-api.md) para obtener eventos de invocación y enviar respuestas. Puede implementar otros lenguajes mediante un [tiempo de ejecución personalizado](runtimes-custom.md) junto con su código de función, o en una [capa](chapter-layers.md).
## Tiempos de ejecución admitidos
En la siguiente tabla se enumeran los tiempos de ejecución de Lambda admitidos y las fechas de caducidad proyectadas. Incluso cuando un tiempo de ejecución está obsoleto, puede seguir creando y actualizando funciones durante un período limitado. Para obtener más información, consulte [Uso del tiempo de ejecución después de la obsolescencia](#runtime-deprecation-levels). En la siguiente tabla se muestran las fechas previstas actualmente para la caducidad del tiempo de ejecución en función de nuestra [Política de obsolescencia del tiempo de ejecución](#runtime-support-policy). Estas fechas se proporcionan para fines de planificación y están sujetas a cambios.
**importante**
El final de la vida útil de Amazon Linux 2 está programado para el 30 de junio de 2026. Los tiempos de ejecución de Lambda e imágenes base de contenedor para Java 8 (AL2), Java 11, Java 17, Python 3.10, Python 3.11 y provided.al2 seguirá recibiendo parches para problemas de seguridad [críticos y determinados problemas importantes](https://alas.aws.amazon.com/faqs.html) en Amazon Linux 2, además de los parches del tiempo de ejecución del lenguaje, hasta las fechas de caducidad que se muestran en la tabla siguiente.
Recomendamos a los clientes que se actualicen a un tiempo de ejecución basado en Amazon Linux 2023 lo antes posible. Para los clientes que se actualicen a Java 21 o Java 25, pueden utilizar la opción [AWS Transform personalizada](https://docs.aws.amazon.com/transform/latest/userguide/custom.html) para facilitar estas actualizaciones. Para los clientes que no puedan actualizar su versión de Java, tenemos previsto lanzar tiempos de ejecución basados en Amazon Linux 2023 para Java 8, Java 11 y Java 17 antes de que finalice el segundo trimestre de 2026.
| Nombre | Identificador | Sistema operativo | Fecha de baja | Bloqueo de la función Crear | Bloqueo de la función Actualizar |
| --- | --- | --- | --- | --- | --- |
| Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 30 de abril de 2028 | 1 de junio de 2028 | 1 de julio de 2028 |
| Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 30 de abril de 2027 | 1 de junio de 2027 | 1 de julio de 2027 |
| Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 30 de abril de 2026 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
| Python 3.14 | `python3.14` | Amazon Linux 2023 | 30 de junio de 2029 | 31 de julio de 2029 | 31 de agosto de 2029 |
| Python 3.13 | `python3.13` | Amazon Linux 2023 | 30 de junio de 2029 | 31 de julio de 2029 | 31 de agosto de 2029 |
| Python 3.12 | `python3.12` | Amazon Linux 2023 | 31 de octubre de 2028 | 30 de noviembre de 2028 | 10 de enero de 2029 |
| Python 3.11 | `python3.11` | Amazon Linux 2 | 30 de junio de 2027 | 31 de julio de 2027 | 31 de agosto de 2027 |
| Python 3.10 | `python3.10` | Amazon Linux 2 | 31 de octubre de 2026 | 30 de noviembre de 2026 | 15 de enero de 2027 |
| Java 25 | `java25` | Amazon Linux 2023 | 30 de junio de 2029 | 31 de julio de 2029 | 31 de agosto de 2029 |
| Java 21 | `java21` | Amazon Linux 2023 | 30 de junio de 2029 | 31 de julio de 2029 | 31 de agosto de 2029 |
| Java 17 | `java17` | Amazon Linux 2 | 30 de junio de 2027 | 31 de julio de 2027 | 31 de agosto de 2027 |
| Java 11 | `java11` | Amazon Linux 2 | 30 de junio de 2027 | 31 de julio de 2027 | 31 de agosto de 2027 |
| Java 8 | `java8.al2` | Amazon Linux 2 | 30 de junio de 2027 | 31 de julio de 2027 | 31 de agosto de 2027 |
| .NET 10 | `dotnet10` | Amazon Linux 2023 | 14 de noviembre de 2028 | 14 de diciembre de 2028 | 15 de enero de 2029 |
| .NET 9 (solo contenedor) | `dotnet9` | Amazon Linux 2023 | 10 de noviembre de 2026 | No programado | No programado |
| .NET 8 | `dotnet8` | Amazon Linux 2023 | 10 de noviembre de 2026 | 10 de diciembre de 2026 | 11 de enero de 2027 |
| Ruby 3.4 | `ruby3.4` | Amazon Linux 2023 | 31 de marzo de 2028 | 30 de abril de 2028 | 31 de mayo de 2028 |
| Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 31 de marzo de 2027 | 30 de abril de 2027 | 31 de mayo de 2027 |
| Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 31 de marzo de 2026 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
| Tiempo de ejecución exclusivo del sistema operativo | `provided.al2023` | Amazon Linux 2023 | 30 de junio de 2029 | 31 de julio de 2029 | 31 de agosto de 2029 |
| Tiempo de ejecución exclusivo del sistema operativo | `provided.al2` | Amazon Linux 2 | 31 de julio de 2026 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
**nota**
Para las nuevas regiones, Lambda no admitirá tiempos de ejecución que queden obsoletos dentro de los seis meses posteriores.
Lambda mantiene los tiempos de ejecución administrados y sus imágenes de base de contenedor correspondientes actualizados con parches y la compatibilidad con lanzamientos de versiones menores. Para obtener más información, consulte [Actualizaciones de tiempo de ejecución de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html).
Para interactuar mediante programación con otros Servicios de AWS y recursos de su función Lambda, puede utilizar uno de los SDK de AWS. Los tiempos de ejecución de Node.js, Python y Ruby incluyen una versión del SDK de AWS. Sin embargo, para mantener el control total de sus dependencias y maximizar la [compatibilidad con versiones anteriores](runtimes-update.md#runtime-update-compatibility) durante las actualizaciones del tiempo de ejecución, le recomendamos que incluya siempre los módulos del SDK que utiliza su código (junto con cualquier dependencia) en el paquete de implementación de la función o en una [capa de Lambda](chapter-layers.md).
Le recomendamos que utilice la versión del SDK incluida en el tiempo de ejecución solo cuando no pueda incluir paquetes adicionales en la implementación. Por ejemplo, cuando se crea la función mediante la consola de editor de código de Lambda o mediante código de función en línea en una plantilla de CloudFormation.
Lambda actualiza de manera periódica las versiones de los SDK de AWS incluidas en los tiempos de ejecución de Node.js, Python y Ruby. Para encontrar la versión del SDK de AWS que se incluye en el tiempo de ejecución, consulte las siguientes secciones:
+ [Versiones del SDK incluidas en el tiempo de ejecución (Node.js)](lambda-nodejs.md#nodejs-sdk-included)
+ [Versiones del SDK incluidas en el tiempo de ejecución (Python)](lambda-python.md#python-sdk-included)
+ [Versiones del SDK incluidas en el tiempo de ejecución (Ruby)](lambda-ruby.md#ruby-sdk-included)
Lambda sigue siendo compatible con el lenguaje de programación Go tras la caducidad del tiempo de ejecución de Go 1.x. Para obtener más información, consulte [Migración de las funciones de AWS Lambda del tiempo de ejecución de Go1.x al tiempo de ejecución personalizado en Amazon Linux 2](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/) en el *Blog de computación de AWS*.
Todos los tiempos de ejecución compatibles de Lambda admiten tanto arquitecturas x86\$164 como arm64.
## Nuevas versiones de tiempo de ejecución
Para las nuevas versiones de los lenguajes, Lambda solo proporciona tiempos de ejecución administrados cuando la versión llega a la fase de soporte a largo plazo (LTS) del ciclo de lanzamiento del lenguaje. Por ejemplo, para el [ciclo de lanzamiento de Node.js](https://nodejs.org/en/about/previous-releases), cuando la versión llega a la fase de LTS activa.
Antes de que la versión alcance la fase de soporte a largo plazo, permanece en desarrollo y puede estar sujeta a cambios importantes. Lambda aplica las actualizaciones del tiempo de ejecución automáticamente de forma predeterminada, por lo que interrumpir los cambios en una versión del tiempo de ejecución podría alterar el funcionamiento esperado de las funciones.
Lambda no proporciona tiempos de ejecución administrados para las versiones de lenguajes que no tendrán una versión de LTS.
La siguiente lista muestra el mes de lanzamiento previsto para los próximos tiempos de ejecución de Lambda. Estas fechas son solo indicativas y están sujetas a cambios.
+ **Ruby 3.5**: marzo de 2026
+ **Java 8, 11 y 17 en AL2023**: segundo trimestre de 2026
+ **Node.js 26**: noviembre de 2026
+ **Python 3.15**: noviembre de 2026
## Política de obsolescencia del tiempo de ejecución
Los tiempos de ejecución de Lambda para archivos .zip se crean en torno a una combinación de bibliotecas de sistemas operativos, lenguaje de programación y software que están sujetos a actualizaciones de mantenimiento y seguridad. La política de obsolescencia estándar de Lambda consiste en dejar obsoleto un tiempo de ejecución cuando algún componente importante de este llegue al final del soporte comunitario a largo plazo (LTS) y las actualizaciones de seguridad ya no estén disponibles. Por lo general, este es el tiempo de ejecución del lenguaje, aunque en algunos casos, un tiempo de ejecución puede quedar obsoleto porque el sistema operativo (SO) llega al final del LTS.
Cuando un tiempo de ejecución queda obsoleto, AWS puede dejar de aplicar revisiones de seguridad o actualizaciones a ese tiempo de ejecución y las funciones que utilizan ese tiempo de ejecución dejan de ser aptas para recibir asistencia técnica. Estos tiempos de ejecución obsoletos se proporcionan “tal cual”, sin garantía alguna, y pueden contener errores, defectos u otras vulnerabilidades.
Para obtener más información sobre la administración de las actualizaciones y la caducidad del tiempo de ejecución, consulte las próximas secciones y el artículo [Administración de las actualizaciones de los tiempos de ejecución de AWS Lambda](https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/) en el *Blog de informática de AWS*.
**importante**
A veces Lambda retrasa la obsolescencia de un tiempo de ejecución de Lambda durante un periodo limitado luego de la fecha de finalización del soporte de la versión del lenguaje compatible con el tiempo de ejecución. Durante este periodo, Lambda solo aplica parches de seguridad al sistema operativo del tiempo de ejecución. Lambda no aplica parches de seguridad a los tiempos de ejecución de los lenguajes de programación una vez que llegan a la fecha de finalización del soporte.
## Modelo de responsabilidad compartida
Lambda es responsable de seleccionar y publicar las actualizaciones de seguridad para todos los tiempos de ejecución administrados y las imágenes base de contenedores compatibles. De forma predeterminada, Lambda aplicará estas actualizaciones a las funciones de forma automática mediante tiempos de ejecución administrados. Si se ha modificado la configuración predeterminada de actualización automática del tiempo de ejecución, consulte el [modelo de responsabilidad compartida de los controles de administración del tiempo de ejecución](runtime-management-shared.md). En el caso de las funciones implementadas mediante imágenes de contenedor, es responsable de volver a crear la imagen del contenedor de la función a partir de la imagen base más reciente y volver a implementar la imagen del contenedor.
Cuando un tiempo de ejecución queda obsoleto, Lambda deja de ser responsable de actualizar el tiempo de ejecución administrado y las imágenes base del contenedor. Es responsable de actualizar sus funciones para utilizar un tiempo de ejecución o una imagen base compatibles.
En todos los casos, es responsable de aplicar las actualizaciones al código de la función, incluidas las de sus dependencias. Sus responsabilidades en virtud del modelo de responsabilidad compartida se resumen en la siguiente tabla.
| Fase del ciclo de vida del tiempo de ejecución | Responsabilidades de Lambda | Sus responsabilidades |
| --- | --- | --- |
| Tiempo de ejecución administrado compatible | Proporcionar actualizaciones periódicas del tiempo de ejecución con revisiones de seguridad y otras actualizaciones. Aplicar las actualizaciones del tiempo de ejecución automáticamente de forma predeterminada (consulte los comportamientos no predeterminados en [Modos de actualización del tiempo de ejecución](runtimes-update.md#runtime-management-controls)). | Actualizar el código de la función, incluidas las dependencias, para corregir cualquier vulnerabilidad de seguridad. |
| Imagen de contenedor compatible | Proporcionar actualizaciones periódicas en la imagen base del contenedor con revisiones de seguridad y otras actualizaciones. | Actualizar el código de la función, incluidas las dependencias, para corregir cualquier vulnerabilidad de seguridad. Volver a compilar e implementar la imagen del contenedor con regularidad utilizando la imagen base más reciente. |
| El tiempo de ejecución administrado está a punto de quedar obsoleto | Notificar a los clientes antes de que el tiempo de ejecución quede obsoleto mediante la documentación, Panel de estado, el correo electrónico y Trusted Advisor. La responsabilidad de las actualizaciones del tiempo de ejecución finaliza cuando queda obsoleto. | Supervisar la documentación de Lambda, Panel de estado, el correo electrónico o Trusted Advisor para consultar la información sobre la obsolescencia del tiempo de ejecución. Actualizar las funciones a un tiempo de ejecución compatible antes de que el tiempo de ejecución anterior quede obsoleto. |
| La imagen del contenedor está a punto de quedar obsoleta | Las notificaciones de obsolescencia no están disponibles para las funciones que utilizan imágenes de contenedores. La responsabilidad de las actualizaciones de la imagen base del contenedor finaliza cuando queda obsoleta. | Tenga en cuenta los programas de obsolescencia y actualice las funciones a una imagen base compatible antes de que la imagen anterior quede obsoleta. |
## Uso del tiempo de ejecución después de la obsolescencia
Cuando un tiempo de ejecución queda obsoleto, AWS puede dejar de aplicar revisiones de seguridad o actualizaciones a ese tiempo de ejecución y las funciones que utilizan ese tiempo de ejecución dejan de ser aptas para recibir asistencia técnica. Aunque puede seguir invocando sus funciones indefinidamente, AWS recomienda encarecidamente migrar a un tiempo de ejecución compatible. Los tiempos de ejecución obsoletos se proporcionan “tal cual”, sin garantía alguna, y pueden contener errores, defectos u otras vulnerabilidades. Las funciones que utilizan un tiempo de ejecución obsoleto también pueden tener un rendimiento inferior u otros problemas, como la caducidad del certificado, lo que puede provocar que no funcionen de forma correcta.
Puede actualizar una función para usar un tiempo de ejecución compatible más reciente en cualquier momento luego de que un tiempo de ejecución quede obsoleto. Recomendamos probar la función con el nuevo tiempo de ejecución antes de aplicar cambios en los entornos de producción. No podrá volver al tiempo de ejecución obsoleto una vez que se bloqueen las actualizaciones de la función. Se recomienda utilizar [versiones](configuration-versions.md) y [alias](configuration-aliases.md) de las funciones para permitir una implementación segura con reversión.
La siguiente cronología describe lo que ocurre cuando un tiempo de ejecución queda obsoleto:
| Fase del ciclo de vida del tiempo de ejecución | Cuando | Qué |
| --- | --- | --- |
| Período de aviso de obsolescencia | Al menos 180 días antes de la obsolescencia | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/lambda-runtimes.html) |
| Obsolescencia | Fecha de baja | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/lambda-runtimes.html) |
| Bloqueo de la función Crear | Al menos 30 días después de la obsolescencia | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/lambda-runtimes.html) |
| Bloqueo de la función Actualizar | Al menos 60 días después de la obsolescencia | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/lambda-runtimes.html) |
**nota**
Para algunos tiempos de ejecución, AWS está retrasando las fechas de creación y de actualización de la función de bloqueo a más de los 30 y 60 días habituales posteriores a la obsolescencia. AWS ha realizado este cambio en respuesta a los comentarios de los clientes para que se disponga de más tiempo para actualizar sus funciones. Consulte las tablas en [Tiempos de ejecución admitidos](#runtimes-supported) y [Tiempos de ejecución obsoletos](#runtimes-deprecated) para poder ver las fechas de su tiempo de ejecución. Lambda no comenzará a bloquear la creación o actualización de funciones antes de las fechas que se indican en estas tablas.
## Recepción de notificaciones de caducidad de un tiempo de ejecución
Cuando un tiempo de ejecución se acerca a su fecha de caducidad, Lambda le envía una alerta por correo electrónico si alguna de las funciones de su Cuenta de AWS utiliza ese tiempo de ejecución. Las notificaciones también se muestran en Panel de estado y en AWS Trusted Advisor.
+ Recepción de notificaciones por correo electrónico:
Lambda le envía una alerta por correo electrónico al menos **180 días** antes de que el tiempo de ejecución caduque. En este correo electrónico se enumeran las versiones \$1LATEST de todas las funciones que utilizan el tiempo de ejecución. Para ver una lista completa de las versiones de funciones afectadas, utilice Trusted Advisor o consulte [Recuperar datos sobre las funciones de Lambda que utilizan un tiempo de ejecución obsoleto](runtimes-list-deprecated.md).
Lambda envía una notificación por correo electrónico al contacto de su cuenta principal de Cuenta de AWS. Para obtener información sobre cómo ver o actualizar las direcciones de correo electrónico de su cuenta, consulte [Actualización de la información de contacto](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html) en la *Referencia general de AWS*.
+ Recepción de notificaciones a través del Panel de estado:
El Panel de estado muestra una notificación al menos **180 días** antes de que el tiempo de ejecución caduque. Las notificaciones aparecen en la página de **Estado de cuenta**, en [Otras notificaciones](https://health.aws.amazon.com/health/home#/account/dashboard/other-notifications). En la pestaña **Recursos afectados** de la notificación se enumeran las versiones \$1LATEST de todas las funciones que utilizan el tiempo de ejecución.
**nota**
Para ver una lista completa de las versiones de funciones afectadas, utilice Trusted Advisor o consulte [Recuperar datos sobre las funciones de Lambda que utilizan un tiempo de ejecución obsoleto](runtimes-list-deprecated.md).
Las notificaciones de Panel de estado caducan 90 días luego de que el tiempo de ejecución afectado caduque.
+ Uso de AWS Trusted Advisor
Trusted Advisor muestra una notificación al menos **180 días** antes de que el tiempo de ejecución caduque. Las notificaciones aparecen en la página [Seguridad](https://console.aws.amazon.com/trustedadvisor/home#/category/security). En **Funciones de AWS Lambda que utilizan tiempos de ejecución obsoletos** se muestra una lista las funciones afectadas. Esta lista de funciones muestra tanto las versiones \$1LATEST como las publicadas y se actualiza automáticamente para reflejar el estado actual de las funciones.
Puede activar las notificaciones semanales por correo electrónico desde Trusted Advisor, en la página [Preferencias](https://console.aws.amazon.com/trustedadvisor/home?#/preferences) de la consola de Trusted Advisor.
## Tiempos de ejecución obsoletos
Los siguientes tiempos de ejecución han quedado obsoletos:
| Nombre | Identificador | Sistema operativo | Fecha de baja | Bloqueo de la función Crear | Bloqueo de la función Actualizar |
| --- | --- | --- | --- | --- | --- |
| Python 3.9 | python3.9 | Amazon Linux 2 | 15 de diciembre de 2025 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
| Node.js 18 | nodejs18.x | Amazon Linux 2 | 1 de septiembre de 2025 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
| .NET 6 | dotnet6 | Amazon Linux 2 | 20 de diciembre de 2024 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
| Python 3.8 | python3.8 | Amazon Linux 2 | 14 de octubre de 2024 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
| Node.js 16 | nodejs16.x | Amazon Linux 2 | 12 de junio de 2024 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
| .NET 7 (solo contenedor) | dotnet7 | Amazon Linux 2 | 14 de mayo de 2024 | N/A | N/A |
| Java 8 | java8 | Amazon Linux | 8 de enero de 2024 | 8 de febrero de 2024 | 30 de septiembre de 2026 |
| Go 1.x | go1.x | Amazon Linux | 8 de enero de 2024 | 8 de febrero de 2024 | 30 de septiembre de 2026 |
| Tiempo de ejecución exclusivo del sistema operativo | provided | Amazon Linux | 8 de enero de 2024 | 8 de febrero de 2024 | 30 de septiembre de 2026 |
| Ruby 2.7 | ruby2.7 | Amazon Linux 2 | 7 de diciembre de 2023 | 9 de enero de 2024 | 30 de septiembre de 2026 |
| Node.js 14 | nodejs14.x | Amazon Linux 2 | 4 de diciembre de 2023 | 9 de enero de 2024 | 30 de septiembre de 2026 |
| Python 3.7 | python3.7 | Amazon Linux | 4 de diciembre de 2023 | 9 de enero de 2024 | 30 de septiembre de 2026 |
| .NET Core 3.1 | dotnetcore3.1 | Amazon Linux 2 | 3 de abril de 2023 | 3 de abril de 2023 | 3 de mayo de 2023 |
| Node.js 12 | nodejs12.x | Amazon Linux 2 | 31 de marzo de 2023 | 31 de marzo de 2023 | 30 de abril de 2023 |
| Python 3.6 | python3.6 | Amazon Linux | 18 de julio de 2022 | 18 de julio de 2022 | 29 de agosto de 2022 |
| .NET 5 (solo contenedor) | dotnet5.0 | Amazon Linux 2 | 10 de mayo de 2022 | N/A | N/A |
| .NET Core 2.1 | dotnetcore2.1 | Amazon Linux | 5 de enero de 2022 | 5 de enero de 2022 | 13 de abril de 2022 |
| Node.js 10 | nodejs10.x | Amazon Linux 2 | 30 de julio de 2021 | 30 de julio de 2021 | 14 de febrero de 2022 |
| Ruby 2.5 | ruby2.5 | Amazon Linux | 30 de julio de 2021 | 30 de julio de 2021 | 31 de marzo de 2022 |
| Python 2.7 | python2.7 | Amazon Linux | 15 de julio de 2021 | 15 de julio de 2021 | 30 de mayo de 2022 |
| Node.js 8.10 | nodejs8.10 | Amazon Linux | 6 de marzo de 2020 | 4 de febrero de 2020 | 6 de marzo de 2020 |
| Node.js 4.3 | nodejs4.3 | Amazon Linux | 5 de marzo de 2020 | 3 de febrero de 2020 | 5 de marzo de 2020 |
| Node.js 4.3 edge | nodejs4.3-edge | Amazon Linux | 5 de marzo de 2020 | 31 de marzo de 2019 | 30 de abril de 2019 |
| Node.js 6.10 | nodejs6.10 | Amazon Linux | 12 de agosto de 2019 | 12 de julio de 2019 | 12 de agosto de 2019 |
| .NET Core 1.0 | dotnetcore1.0 | Amazon Linux | 27 de junio de 2019 | 30 de junio de 2019 | 30 de julio de 2019 |
| .NET Core 2.0 | dotnetcore2.0 | Amazon Linux | 30 de mayo de 2019 | 30 de abril de 2019 | 30 de mayo de 2019 |
| Node.js 0.10 | nodejs | Amazon Linux | 30 de agosto de 2016 | 30 de septiembre de 2016 | 31 de octubre de 2016 |
En casi todos los casos, la fecha de fin de vida útil de una versión de un lenguaje o un sistema operativo se conoce con mucha antelación. Los enlaces que aparecen a continuación indican los cronogramas de fin de vida útil de cada lenguaje que Lambda admite como tiempo de ejecución administrado.
**Políticas de soporte de lenguajes y marcos**
+ **Node.js**: [github.com](https://github.com/nodejs/Release#release-schedule)
+ **Python**: [devguide.python.org](https://devguide.python.org/versions/#versions)
+ **Ruby**: [www.ruby-lang.org](https://www.ruby-lang.org/en/downloads/branches/)
+ **Java**: [www.oracle.com](https://www.oracle.com/java/technologies/java-se-support-roadmap.html) y [Preguntas frecuentes de Corretto](https://aws.amazon.com/corretto/faqs/)
+ **Go** – [golang.org](https://golang.org/doc/devel/release.html)
+ **.NET**: [dotnet.microsoft.com](https://dotnet.microsoft.com/platform/support/policy/dotnet-core)
# Cómo entender la forma en que Lambda administra las actualizaciones de las versiones de tiempo de ejecución
Lambda mantiene todos los tiempos de ejecución gestionados al día con actualizaciones de seguridad, correcciones de errores, nuevas funciones, mejoras de rendimiento y soporte para versiones menores. Estas actualizaciones del tiempo de ejecución se publican como *versiones del tiempo de ejecución*. Lambda aplica las actualizaciones del tiempo de ejecución a las funciones mediante la migración de la función de una versión de tiempo de ejecución anterior a una nueva versión del tiempo de ejecución.
De forma predeterminada, para las funciones que utilizan tiempos de ejecución administrados, Lambda aplica las actualizaciones del tiempo de ejecución de forma automática. Con las actualizaciones automáticas en tiempo de ejecución, Lambda asume la carga operativa de aplicar parches a las versiones en tiempo de ejecución. Para la mayoría de los clientes, las actualizaciones automáticas son la opción correcta. Puede cambiar este comportamiento predeterminado [configurando los ajustes de administración del tiempo de ejecución](runtime-management-configure-settings.md).
Lambda también publica cada nueva versión en tiempo de ejecución como una imagen de contenedor. Para actualizar las versiones del tiempo de ejecución de las funciones basadas en contenedores, debe [crear una nueva imagen de contenedor](images-create.md) a partir de la imagen base actualizada y volver a implementar la función.
Cada versión en tiempo de ejecución está asociada a un número de versión y un ARN (Amazon Resource Name). Los números de versión del tiempo de ejecución utilizan un esquema de numeración definido por Lambda, de forma independiente de los números de versión que utiliza el lenguaje de programación. Los números de versión en tiempo de ejecución no siempre siguen una secuencia. Por ejemplo, es posible que la versión 42 vaya seguida de la 45. El ARN de la versión en tiempo de ejecución es un identificador único para cada versión del tiempo de ejecución. Puede ver el ARN de la versión del tiempo de ejecución actual de la función en la consola de Lambda y en la [línea `INIT_START` de los registros de la función](runtime-management-identify.md).
Las versiones del tiempo de ejecución no deben confundirse con los identificadores de tiempo de ejecución. Cada tiempo de ejecución tiene un **identificador de tiempo de ejecución** único, como `python3.14` o `nodejs24.x`. Se corresponden con cada versión principal del lenguaje de programación. Las versiones del tiempo de ejecución describen la versión de parche de un entorno de ejecución individual.
**nota**
El ARN para el mismo número de versión de tiempo de ejecución puede variar entre las arquitecturas de CPU y Regiones de AWS.
**Topics**
+ [
## Compatibilidad con versiones anteriores
](#runtime-update-compatibility)
+ [
## Modos de actualización del tiempo de ejecución
](#runtime-management-controls)
+ [
## Lanzamiento de la versión del tiempo de ejecución bifásico
](#runtime-management-two-phase)
+ [
# Configuración de los ajustes de administración del tiempo de ejecución de Lambda
](runtime-management-configure-settings.md)
+ [
# Restauración de una versión del tiempo de ejecución de Lambda
](runtime-management-rollback.md)
+ [
# Identificación de los cambios de versión del tiempo de ejecución de Lambda
](runtime-management-identify.md)
+ [
# Cómo entender el modelo de responsabilidad compartida para la administración del tiempo de ejecución de Lambda
](runtime-management-shared.md)
+ [
# Control de los permisos de actualización del tiempo de ejecución de Lambda para aplicaciones de alta conformidad
](runtime-management-hc-applications.md)
## Compatibilidad con versiones anteriores
Lambda se esfuerza por proporcionar actualizaciones de tiempo de ejecución que sean compatibles con versiones anteriores a las funciones existentes. Sin embargo, al igual que ocurre con los parches de software, hay casos excepcionales en los que una actualización del tiempo de ejecución puede afectar negativamente a una función ya existente. Por ejemplo, los parches de seguridad pueden exponer un problema subyacente con una función existente que depende del comportamiento inseguro anterior.
Al crear e implementar la función, es importante entender cómo administrar las dependencias para evitar posibles incompatibilidades con una futura actualización del tiempo de ejecución. Por ejemplo, supongamos que la función depende del paquete A, que a su vez depende del paquete B. Ambos paquetes se incluyen en el entorno de ejecución de Lambda (por ejemplo, podrían ser partes del SDK o sus dependencias, o partes de las bibliotecas del sistema del tiempo de ejecución).
Considere los siguientes escenarios:
| Implementación | Compatible con parches | Motivo |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/runtimes-update.html) | Sí | Las futuras actualizaciones del tiempo de ejecución de los paquetes A y B son compatibles con versiones anteriores. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/runtimes-update.html) | Sí | Su implementación tiene prioridad, por lo que las futuras actualizaciones del tiempo de ejecución de los paquetes A y B no tienen ningún efecto. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/runtimes-update.html) | Sí\$1 | Las futuras actualizaciones del tiempo de ejecución del paquete B son compatibles con versiones anteriores. \$1Si A y B están estrechamente acoplados, pueden producirse problemas de compatibilidad. Por ejemplo, los paquetes `boto3` y `botocore` en el SDK de AWS para Python deben implementarse juntos. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/runtimes-update.html) | No | Es posible que las futuras actualizaciones del tiempo de ejecución del paquete A requieran una versión actualizada del paquete B. Sin embargo, la versión implementada del paquete B tiene prioridad y es posible que no sea compatible con versiones posteriores de la versión actualizada del paquete A. |
Para mantener la compatibilidad con futuras actualizaciones del tiempo de ejecución, siga estas prácticas recomendadas:
+ **Cuando sea posible, empaquete todas las dependencias:** incluya todas las bibliotecas necesarias, incluido el SDK de AWS y sus dependencias, en su paquete de implementación. Esto garantiza un conjunto de componentes estable y compatible.
+ **Utilice los SDK proporcionados en el tiempo de ejecución con moderación:** confíe únicamente en el SDK proporcionado en el tiempo de ejecución cuando no pueda incluir paquetes adicionales (por ejemplo, cuando utilice el editor de código de la consola de Lambda o el código en línea en una plantilla de AWS CloudFormation).
+ **Evite anular las bibliotecas del sistema:** no implemente bibliotecas de sistemas operativos personalizadas que puedan entrar en conflicto con las futuras actualizaciones del tiempo de ejecución.
## Modos de actualización del tiempo de ejecución
Lambda se esfuerza por proporcionar actualizaciones de tiempo de ejecución que sean compatibles con versiones anteriores a las funciones existentes. Sin embargo, al igual que ocurre con los parches de software, hay casos excepcionales en los que una actualización del tiempo de ejecución puede afectar negativamente a una función ya existente. Por ejemplo, los parches de seguridad pueden exponer un problema subyacente con una función existente que depende del comportamiento inseguro anterior. Los controles de administración del tiempo de ejecución de Lambda ayudan a reducir el riesgo de que las cargas de trabajo se vean afectadas en el caso de que se produzca una incompatibilidad entre las versiones en tiempo de ejecución. Para cada [versión de función](configuration-versions.md) (`$LATEST` o versión publicada), puede elegir uno de los siguientes modos de actualización en tiempo de ejecución:
+ **Auto(predeterminado)**: actualice de forma automática la versión de ejecución más reciente y segura mediante [Lanzamiento de la versión del tiempo de ejecución bifásico](#runtime-management-two-phase). Recomendamos este modo a la mayoría de los clientes para que siempre se beneficien de las actualizaciones del tiempo de ejecución.
+ **Actualización de función**: actualiza a la versión del tiempo de ejecución más reciente y segura cuando actualice su función. Cuando actualiza la función, Lambda actualiza el tiempo de ejecución de la función a la versión de ejecución más reciente y segura. Este enfoque sincroniza las actualizaciones en tiempo de ejecución con las implementaciones de funciones, lo que le permite controlar cuándo Lambda aplica las actualizaciones en tiempo de ejecución. Con este modo, puede detectar y mitigar con anticipación las incompatibilidades poco frecuentes entre las actualizaciones en tiempo de ejecución. Al utilizar este modo, debe actualizar periódicamente las funciones para mantener su tiempo de ejecución actualizado.
+ **Manual**: actualice de forma manual la versión del tiempo de ejecución. Se especifica una versión del tiempo de ejecución en la configuración de la función. La función utiliza esta versión del tiempo de ejecución de forma indefinida. En el caso de que una nueva versión del tiempo de ejecución sea incompatible con una función existente, puede utilizar este modo para restaurar la función a una versión anterior en tiempo de ejecución. Recomendamos no utilizar el modo **Manual** para intentar lograr la coherencia del tiempo de ejecución en todas las implementaciones. Para obtener más información, consulte [Restauración de una versión del tiempo de ejecución de Lambda](runtime-management-rollback.md).
La responsabilidad de aplicar las actualizaciones de tiempo de ejecución a las funciones varía según el modo de actualización del tiempo de ejecución que elija. Para obtener más información, consulte [Cómo entender el modelo de responsabilidad compartida para la administración del tiempo de ejecución de Lambda](runtime-management-shared.md).
## Lanzamiento de la versión del tiempo de ejecución bifásico
Lambda presenta nuevas versiones del tiempo de ejecución en el siguiente orden:
1. En la primera fase, Lambda aplica la nueva versión del tiempo de ejecución cada vez que se crea o se actualiza una función. La función se actualiza al llamar a las operaciones de la API [updateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) o [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html).
1. En la segunda fase, Lambda actualiza cualquier función que utilice el modo de actualización **Auto** (Automático) del tiempo de ejecución y que aún no se haya actualizado a la nueva versión del tiempo de ejecución.
La duración total del proceso de implementación varía en función de varios factores, incluida la gravedad de los parches de seguridad incluidos en la actualización del tiempo de ejecución.
Si está desarrollando e implementando sus funciones de forma activa, lo más probable es que aprendas nuevas versiones del tiempo de ejecución durante la primera fase. Esto sincroniza las actualizaciones del tiempo de ejecución con las actualizaciones de funciones. En el caso excepcional de que la última versión del tiempo de ejecución afecte de forma negativa a la aplicación, este enfoque le permite tomar medidas correctivas inmediatas. Las funciones que no están en desarrollo activo siguen recibiendo la ventaja operativa de las actualizaciones automáticas del tiempo de ejecución durante la segunda fase.
Este enfoque no afecta a las funciones configuradas en modo **Function update** (Actualización de funciones) o **Manual**. Las funciones que utilizan el modo **Function update** (Actualización de funciones) reciben las actualizaciones de ejecución más recientes solo cuando se crean o actualizan. Las funciones que utilizan el modo **Manual** no reciben actualizaciones en tiempo de ejecución.
Lambda publica nuevas versiones en tiempo de ejecución de forma gradual a través de las Regiones de AWS. Si tus funciones están configuradas en modo **Function update** (Actualización de funciones) o **Auto** (Automático), es posible que estas se desplieguen al mismo tiempo en diferentes regiones, o en diferentes momentos de la misma región, elijan versiones de ejecución diferentes. Los clientes que necesiten garantizar la coherencia de las versiones del tiempo de ejecución en sus entornos deben [utilizar imágenes de contenedores para implementar sus funciones de Lambda](images-create.md). El modo **Manual** está diseñado como una mitigación temporal para permitir la reversión de la versión del tiempo de ejecución en el caso excepcional de que una versión del tiempo de ejecución sea incompatible con la función.
# Configuración de los ajustes de administración del tiempo de ejecución de Lambda
Puede configurar los ajustes de administración del tiempo de ejecución mediante la consola de Lambda o AWS Command Line Interface (AWS CLI).
**nota**
Puede configurar los ajustes de administración del tiempo de ejecución por separado para cada [versión de la función](configuration-versions.md).
**Configuración de la versión de tiempo de ejecución de Lambda (consola)**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija el nombre de una función.
1. En la pestaña **Code** (Código), en **Runtime settings** (Configuración del tiempo de ejecución), seleccione **Edit runtime management configuration** (Editar la configuración de administración del tiempo de ejecución).
1. En **Runtime management configuration** (Configuración de la administración del tiempo de ejecución), elija una de las siguientes opciones:
+ Para que la función se actualice automáticamente a la última versión de ejecución, seleccione **Auto** (Automático).
+ Para que la función se actualice a la última versión del tiempo de ejecución al cambiarla, seleccione **Function update** (Actualización de función).
+ Para que la función se actualice a la última versión del tiempo de ejecución solo cuando cambie el ARN de la versión en tiempo de ejecución, seleccione **Manual**. Encontrará el ARN de la versión de tiempo de ejecución en **Runtime management configuration** (Configuración de la administración del tiempo de ejecución). También puede encontrar el ARN en la línea `INIT_START` de sus registros de funciones.
Para obtener más información sobre estas opciones, consulte [Modos de actualización en tiempo de ejecución](runtimes-update.md#runtime-management-controls).
1. Seleccione **Save** (Guardar).
**Para configurar cómo Lambda actualiza su versión del tiempo de ejecución (AWS CLI)**
Para configurar la administración del tiempo de ejecución de una función, ejecute el comando de AWS CLI [put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html). Cuando utilice el modo `Manual`, también debe proporcionar el ARN de la versión en tiempo de ejecución.
```
aws lambda put-runtime-management-config \
--function-name my-function \
--update-runtime-on Manual \
--runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1
```
Debería ver una salida similar a esta:
```
{
"UpdateRuntimeOn": "Manual",
"FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function",
"RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1"
}
```
# Restauración de una versión del tiempo de ejecución de Lambda
En el caso de que una nueva versión del tiempo de ejecución sea incompatible con la función existente, puede restaurar su versión en tiempo de ejecución a una anterior. Esto mantiene la aplicación en funcionamiento y minimiza las interrupciones, lo que proporciona tiempo para corregir la incompatibilidad antes de volver a la última versión del tiempo de ejecución.
Lambda no impone un límite de tiempo para el uso de una versión de ejecución determinada. Sin embargo, le recomendamos actualizar a la última versión del tiempo de ejecución lo antes posible para disfrutar de los parches de seguridad, las mejoras de rendimiento y las funciones más recientes. Lambda ofrece la opción de restaurar a una versión anterior del tiempo de ejecución únicamente como medida de mitigación temporal en el caso de que surja un problema de compatibilidad con las actualizaciones del tiempo de ejecución. Las funciones que utilizan una versión anterior del tiempo de ejecución durante un periodo prolongado pueden presentar problemas o tener un rendimiento inferior, como la caducidad del certificado, lo que puede provocar que no funcionen de forma correcta.
Puede restaurar a una versión del tiempo de ejecución de las siguientes maneras:
+ [Uso de modo de actualización Manual en tiempo de ejecución](#runtime-management-rollback-manual)
+ [Uso de versiones de funciones publicadas](#runtime-management-rollback-published)
Para obtener más información, consulte [Introducción a los controles de administración de los tiempos de ejecución de AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/) en el Blog de computación de AWS.
## Restaurar una versión del tiempo de ejecución mediante el modo de actualización Manual
Si utiliza el modo de actualización **Auto** (Automático) de la versión del tiempo de ejecución o utiliza la versión `$LATEST` del tiempo de ejecución, puede restaurar su versión del tiempo de ejecución mediante el modo **Manual**. Para la [versión de la función](configuration-versions.md) que desea restaurar, cambie el modo de actualización de la versión del tiempo de ejecución a **Manual** y especifique el ARN de la versión del tiempo de ejecución anterior. Para obtener más información sobre cómo encontrar el ARN de la versión anterior del tiempo de ejecución, consulte [Identificación de los cambios de versión del tiempo de ejecución de Lambda](runtime-management-identify.md).
**nota**
Si la versión `$LATEST` de la función está configurada para usar el modo **Manual**, no puede cambiar la arquitectura del CPU ni la versión de tiempo de ejecución que usa la función. Para realizar estos cambios, debe cambiar al modo **Auto** (Automático) o **Function update** (Actualización de funciones).
## Deshacer una versión en tiempo de ejecución por medio de las versiones de funciones publicadas
Las [versiones de funciones](configuration-versions.md) publicadas son una instantánea inmutable del código y la configuración de la función `$LATEST` en el momento en que se crearon. En el modo **Auto** (Automático), Lambda actualiza de forma automática la versión del tiempo de ejecución de las versiones de funciones publicadas durante la segunda fase del despliegue de la versión del tiempo de ejecución. En el modo de **Function update** (Actualización de funciones), Lambda no actualiza la versión del tiempo de ejecución de las versiones de funciones publicadas.
Por lo tanto, las versiones de funciones publicadas mediante el modo **Function update** (Actualización de funciones) crean una instantánea estática del código de la función, la configuración y la versión del tiempo de ejecución. Al utilizar el modo **Function update** (Actualización de funciones) con las versiones de las funciones, puede sincronizar las actualizaciones del tiempo de ejecución con sus implementaciones. También puede coordinar la reversión de las versiones de código, configuración y tiempo de ejecución redirigiendo el tráfico a una versión de función publicada anteriormente. Puede integrar este enfoque en su sistema de integración y entrega continuas (CI/CD) para lograr una reversión completamente automática en el caso de que se produzca una incompatibilidad entre las actualizaciones del tiempo de ejecución. Al utilizar este enfoque, debe actualizar la función con regularidad y publicar nuevas versiones de la función para obtener las actualizaciones más recientes del tiempo de ejecución. Para obtener más información, consulte [Cómo entender el modelo de responsabilidad compartida para la administración del tiempo de ejecución de Lambda](runtime-management-shared.md).
# Identificación de los cambios de versión del tiempo de ejecución de Lambda
El [número de versión del tiempo de ejecución](runtimes-update.md) y el ARN se registran en la línea de registro `INIT_START`, que Lambda emite a los Registros de CloudWatch cada vez que crea un nuevo [entorno de ejecución](concepts-basics.md#gettingstarted-concepts-runtime). Dado que el entorno de ejecución utiliza la misma versión de tiempo de ejecución para todas las invocaciones de funciones, Lambda emite la línea de registro `INIT_START` solo cuando ejecuta la fase inicial. Lambda no emite esta línea de registro para cada invocación de función. Lambda emite la línea de registro a los Registros de CloudWatch, pero no aparece visible en la consola.
**nota**
Los números de versión en tiempo de ejecución no siempre siguen una secuencia. Por ejemplo, es posible que la versión 42 vaya seguida de la 45.
**Example Ejemplo de línea de registro INIT\$1START**
```
INIT_START Runtime Version: python:3.13.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I
```
En lugar de trabajar directamente con los registros, puede utilizar [Información de colaboradores de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html) para identificar las transiciones entre las versiones en tiempo de ejecución. La siguiente regla cuenta las distintas versiones del tiempo de ejecución de cada línea de registro `INIT_START`. Para usar la regla, sustituya el nombre del grupo de registro de ejemplo `/aws/lambda/*` por el prefijo adecuado para su función o grupo de funciones.
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "eventType",
"In": [
"INIT_START"
]
}
],
"Keys": [
"runtimeVersion",
"runtimeVersionArn"
]
},
"LogFormat": "CLF",
"LogGroupNames": [
"/aws/lambda/*"
],
"Fields": {
"1": "eventType",
"4": "runtimeVersion",
"8": "runtimeVersionArn"
}
}
```
El siguiente informe de Información de colaboradores de CloudWatch muestra un ejemplo de una transición de versión del tiempo de ejecución tal como se recoge en la regla anterior. La línea naranja muestra la inicialización del entorno de ejecución para la versión anterior del tiempo de ejecución (**python:3.13.v12**) y la línea azul muestra la inicialización del entorno de ejecución para la nueva versión del tiempo de ejecución (**python:3.13.v14**).
![\[\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/runtime_version_graph.png)
# Cómo entender el modelo de responsabilidad compartida para la administración del tiempo de ejecución de Lambda
Lambda es responsable de seleccionar y publicar las actualizaciones de seguridad para todos los tiempos de ejecución administrados y las imágenes de contenedores compatibles. La responsabilidad de actualizar las funciones existentes para utilizar la última versión del tiempo de ejecución varía según el modo de actualización en tiempo de ejecución que utilice.
Lambda es responsable de aplicar las actualizaciones del tiempo de ejecución a todas las funciones configuradas para usar el modo de actualización **Auto** (Automático) del tiempo de ejecución.
En el caso de las funciones configuradas con el modo de actualización del tiempo de ejecución **Function update** (Actualización de función), usted es responsable de actualizar regularmente su función. Lambda es responsable de aplicar las actualizaciones del tiempo de ejecución al realizar dichas actualizaciones. Si no actualiza la función, Lambda no actualizará el tiempo de ejecución. Si no actualiza la función con regularidad, le recomendamos que la configure para que se actualice de forma automática en tiempo de ejecución para que siga recibiendo actualizaciones de seguridad.
En el caso de las funciones configuradas para usar el modo de actualización **Manual** en tiempo de ejecución, usted es responsable de actualizar la función para que utilice la versión más reciente en tiempo de ejecución. Le recomendamos encarecidamente que utilice este modo solo para revertir la versión en tiempo de ejecución como medida de mitigación temporal en el raro caso de que se produzca una incompatibilidad entre las actualizaciones en tiempo de ejecución. También le recomendamos que cambie al modo **Auto** (Automático) lo antes posible para minimizar el tiempo en el que las funciones no se parchean.
Si [utiliza imágenes de contenedores para implementar sus funciones](images-create.md), Lambda es responsable de publicar las imágenes base actualizadas. En este caso, es responsable de reconstruir la imagen del contenedor de la función a partir de la imagen de base más reciente y volver a implementar la imagen del contenedor.
Esto se resume en la siguiente tabla:
****
| Modo de implementación | Responsabilidad de Lambda | Responsabilidades del cliente |
| --- | --- | --- |
| Tiempo de ejecución gestionado, modo Auto (Automático) | Publique nuevas versiones en tiempo de ejecución que contengan los parches más recientes. Aplique parches de ejecución a las funciones existentes. | Vuelva a una versión anterior en tiempo de ejecución en el caso de que surja un problema de compatibilidad con las actualizaciones en tiempo de ejecución. Siga las prácticas recomendadas para la [compatibilidad con versiones anteriores](runtimes-update.md#runtime-update-compatibility). |
| Tiempo de ejecución gestionado, modo Function update (Actualización de funciones) | Publique nuevas versiones en tiempo de ejecución que contengan los parches más recientes. | Actualice las funciones con regularidad para obtener la última versión en tiempo de ejecución. Cambie una función a modo **Auto** (Automático) cuando no la actualice de forma regular. Vuelva a una versión anterior en tiempo de ejecución en el caso de que surja un problema de compatibilidad con las actualizaciones en tiempo de ejecución. Siga las prácticas recomendadas para la [compatibilidad con versiones anteriores](runtimes-update.md#runtime-update-compatibility). |
| Tiempo de ejecución gestionado, modo Manual | Publique nuevas versiones en tiempo de ejecución que contengan los parches más recientes. | Utilice este modo solo para revertir temporalmente el tiempo de ejecución en el caso de que surja un problema de compatibilidad con las actualizaciones en tiempo de ejecución. Cambie las funciones al modo **Auto** (Automático) o **Function update** (Actualización de funciones) y a la última versión de ejecución lo antes posible. |
| Imagen de contenedor | Publique nuevas imágenes de contenedores que contengan los parches más recientes. | Vuelva a implementar las funciones con regularidad utilizando la imagen base del contenedor más reciente para obtener los parches más recientes. |
Para obtener más información sobre la responsabilidad compartida con AWS, consulte [Modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/).
# Control de los permisos de actualización del tiempo de ejecución de Lambda para aplicaciones de alta conformidad
Para cumplir con los requisitos de parches, los clientes de Lambda suelen confiar en las actualizaciones automáticas en tiempo de ejecución. Si su aplicación está sujeta a estrictos requisitos de actualización de parches, es posible que desee limitar el uso de versiones anteriores en tiempo de ejecución. Puede restringir los controles de administración del tiempo de ejecución de Lambda mediante AWS Identity and Access Management (IAM) para denegar a los usuarios de su cuenta AWS el acceso a la operación de la API [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html). Esta operación se utiliza para elegir el modo de actualización en tiempo de ejecución de una función. Al denegar el acceso a esta operación, todas las funciones pasarán a modo **Auto** (Automático) de forma predeterminada. Puede aplicar esta restricción en toda su organización mediante [políticas de control de servicios (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Si debe revertir una función a una versión anterior en tiempo de ejecución, puede admitir una excepción de política caso por caso.
# Recuperar datos sobre las funciones de Lambda que utilizan un tiempo de ejecución obsoleto
Cuando un tiempo de ejecución de Lambda está a punto de quedar obsoleto, Lambda lo informa por correo electrónico y envía notificaciones en Panel de estado y Trusted Advisor. En estos correos electrónicos y notificaciones se enumeran las versiones \$1LATEST de las funciones que utilizan el tiempo de ejecución. Para enumerar todas las versiones de las funciones que utilizan un tiempo de ejecución determinado, puede usar la AWS Command Line Interface (AWS CLI) o uno de los AWS SDK.
Si tiene una gran cantidad de funciones que utilizan un tiempo de ejecución obsoleto, también puede utilizar la AWS CLI o los AWS SDK como ayuda para priorizar las actualizaciones de las funciones que más se invocan.
Consulte las siguientes secciones para aprender a usar la AWS CLI y los AWS SDK para recopilar datos sobre las funciones que utilizan un tiempo de ejecución determinado.
## Lista de las versiones de funciones que utilizan un tiempo de ejecución determinado
Para usar la AWS CLI para obtener una lista de todas las versiones de las funciones que utilizan un tiempo de ejecución determinado, ejecute el siguiente comando: Reemplace `RUNTIME_IDENTIFIER` por el nombre del tiempo de ejecución que está por caducar y elija su propio Región de AWS. Para mostrar solo las versiones de la función \$1LATEST, omita `--function-version ALL` en el comando.
```
aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='RUNTIME_IDENTIFIER'].FunctionArn"
```
**sugerencia**
El comando de ejemplo muestra las funciones de la región `us-east-1` para un determinado Cuenta de AWS. Deberá repetir este comando para cada región en la que su cuenta tenga funciones y para cada uno de sus Cuentas de AWS.
También puede obtener una lista de las funciones que utilizan un tiempo de ejecución determinado mediante uno de los AWS SDK. El siguiente código de ejemplo utiliza la V3 del AWS SDK para JavaScript y el AWS SDK para Python (Boto3) para devolver una lista de los ARN de funciones de las funciones que utilizan un tiempo de ejecución determinado. El código de ejemplo también devuelve el grupo de registro de CloudWatch para cada una de las funciones de la lista. Puede usar este grupo de registro para buscar la fecha de la última invocación de la función. Consulte la siguiente sección [Identificación de las funciones invocadas más recientemente y con mayor frecuencia](#runtimes-list-deprecated-statistics) para obtener más información.
------
#### [ Node.js ]
**Example Código JavaScript para obtener una lista de las funciones que utilizan un tiempo de ejecución determinado**
```
import { LambdaClient, ListFunctionsCommand } from "@aws-sdk/client-lambda";
const lambdaClient = new LambdaClient();
const command = new ListFunctionsCommand({
FunctionVersion: "ALL",
MaxItems: 50
});
const response = await lambdaClient.send(command);
for (const f of response.Functions){
if (f.Runtime == ''){ // Use the runtime id, e.g. 'nodejs24.x' or 'python3.14'
console.log(f.FunctionArn);
// get the CloudWatch log group of the function to
// use later for finding the last invocation date
console.log(f.LoggingConfig.LogGroup);
}
}
// If your account has more functions than the specified
// MaxItems, use the returned pagination token in the
// next request with the 'Marker' parameter
if ('NextMarker' in response){
let paginationToken = response.NextMarker;
}
```
------
#### [ Python ]
**Example Código Python para obtener una lista de las funciones que utilizan un tiempo de ejecución determinado**
```
import boto3
from botocore.exceptions import ClientError
def list_lambda_functions(target_runtime):
lambda_client = boto3.client('lambda')
response = lambda_client.list_functions(
FunctionVersion='ALL',
MaxItems=50
)
if not response['Functions']:
print("No Lambda functions found")
else:
for function in response['Functions']:
if function['PackageType']=='Zip' and function['Runtime'] == target_runtime:
print(function['FunctionArn'])
# Print the CloudWatch log group of the function
# to use later for finding last invocation date
print(function['LoggingConfig']['LogGroup'])
if 'NextMarker' in response:
pagination_token = response['NextMarker']
if __name__ == "__main__":
# Replace python3.12 with the appropriate runtime ID for your Lambda functions
list_lambda_functions('python3.12')
```
------
Para obtener más información sobre el uso de un AWS SDK para enumerar las funciones mediante la acción [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html), consulte la [documentación del SDK](https://aws.amazon.com/developer/tools/) del lenguaje de programación que prefiera.
También puede utilizar la característica Consultas avanzadas del AWS Config para enumerar todas las funciones que utilizan un tiempo de ejecución afectado. Esta consulta solo devuelve las versiones \$1LATEST de la función, pero puede agregar consultas para enumerar funciones en todas las regiones y en varios Cuentas de AWS con un solo comando. Para obtener más información, lea [Consulta sobre el estado de la configuración actual de los recursos del AWS Auto Scaling](https://docs.aws.amazon.com/config/latest/developerguide/querying-AWS-resources.html) en la *Guía del AWS Config para desarrolladores*.
## Identificación de las funciones invocadas más recientemente y con mayor frecuencia
Si su Cuenta de AWS incluye funciones que utilizan un tiempo de ejecución que está por quedar obsoleto, quizá desee priorizar la actualización de las funciones que se invocan con frecuencia o que se invocaron recientemente.
Si solo dispone de unas pocas funciones, puede utilizar la consola de los registros de CloudWatch para recopilar esta información consultando los flujos de registro de sus funciones. Para obtener más información, consulte [Ver datos de registro enviados a los registros de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData).
Para ver la cantidad de invocaciones de funciones recientes, también puede utilizar la información de métricas de CloudWatch que se muestra en la consola de Lambda. Para ver esta información, siga estas instrucciones:
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Seleccione la función de la que desee consultar las estadísticas de invocación.
1. Elija la pestaña **Supervisar**.
1. Establezca el periodo del que desea ver las estadísticas utilizando el selector de rango de fechas. Las invocaciones recientes se muestran en el panel **Invocaciones**.
Para las cuentas con una mayor cantidad de funciones, puede ser más eficiente recopilar estos datos mediante programación con la AWS CLI o uno de los AWS SDK mediante las acciones de la API [DescribelogStreams](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DescribeLogStreams.html) y [GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html).
En los siguientes ejemplos, se proporcionan fragmentos de código que utilizan la V3 del AWS SDK para JavaScript y el AWS SDK para Python (Boto3) para identificar la fecha de la última invocación de una función determinada y establecer la cantidad de invocaciones de una función determinada en los últimos 14 días.
------
#### [ Node.js ]
**Example Código JavaScript para encontrar la hora de la última invocación de una función**
```
import { CloudWatchLogsClient, DescribeLogStreamsCommand } from "@aws-sdk/client-cloudwatch-logs";
const cloudWatchLogsClient = new CloudWatchLogsClient();
const command = new DescribeLogStreamsCommand({
logGroupName: '',
orderBy: 'LastEventTime',
descending: true,
limit: 1
});
try {
const response = await cloudWatchLogsClient.send(command);
const lastEventTimestamp = response.logStreams.length > 0 ?
response.logStreams[0].lastEventTimestamp : null;
// Convert the UNIX timestamp to a human-readable format for display
const date = new Date(lastEventTimestamp).toLocaleDateString();
const time = new Date(lastEventTimestamp).toLocaleTimeString();
console.log(`${date} ${time}`);
} catch (e){
console.error('Log group not found.')
}
```
------
#### [ Python ]
**Example Código Python para encontrar la hora de la última invocación de una función**
```
import boto3
from datetime import datetime
cloudwatch_logs_client = boto3.client('logs')
response = cloudwatch_logs_client.describe_log_streams(
logGroupName='',
orderBy='LastEventTime',
descending=True,
limit=1
)
try:
if len(response['logStreams']) > 0:
last_event_timestamp = response['logStreams'][0]['lastEventTimestamp']
print(datetime.fromtimestamp(last_event_timestamp/1000)) # Convert timestamp from ms to seconds
else:
last_event_timestamp = None
except:
print('Log group not found')
```
------
**sugerencia**
Puede encontrar el nombre del grupo de registro de la función mediante la operación de la API [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html). Para ver ejemplos de cómo hacerlo, consulte el código en [Lista de las versiones de funciones que utilizan un tiempo de ejecución determinado](#runtimes-list-deprecated-versions).
------
#### [ Node.js ]
**Example Código JavaScript para encontrar la cantidad de invocaciones en los últimos 14 días**
```
import { CloudWatchClient, GetMetricStatisticsCommand } from "@aws-sdk/client-cloudwatch";
const cloudWatchClient = new CloudWatchClient();
const command = new GetMetricStatisticsCommand({
Namespace: 'AWS/Lambda',
MetricName: 'Invocations',
StartTime: new Date(Date.now()-86400*1000*14), // 14 days ago
EndTime: new Date(Date.now()),
Period: 86400 * 14, // 14 days.
Statistics: ['Sum'],
Dimensions: [{
Name: 'FunctionName',
Value: ''
}]
});
const response = await cloudWatchClient.send(command);
const invokesInLast14Days = response.Datapoints.length > 0 ?
response.Datapoints[0].Sum : 0;
console.log('Number of invocations: ' + invokesInLast14Days);
```
------
#### [ Python ]
**Example Código Python para encontrar la cantidad de invocaciones en los últimos 14 días**
```
import boto3
from datetime import datetime, timedelta
cloudwatch_client = boto3.client('cloudwatch')
response = cloudwatch_client.get_metric_statistics(
Namespace='AWS/Lambda',
MetricName='Invocations',
Dimensions=[
{
'Name': 'FunctionName',
'Value': ''
},
],
StartTime=datetime.now() - timedelta(days=14),
EndTime=datetime.now(),
Period=86400 * 14, # 14 days
Statistics=[
'Sum'
]
)
if len(response['Datapoints']) > 0:
invokes_in_last_14_days = int(response['Datapoints'][0]['Sum'])
else:
invokes_in_last_14_days = 0
print(f'Number of invocations: {invokes_in_last_14_days}')
```
------
# Modificación del entorno de tiempo de ejecución
Puede utilizar [extensiones internas](lambda-extensions.md) para modificar el proceso de tiempo de ejecución. Las extensiones internas no son procesos independientes, se ejecutan como parte del proceso de tiempo de ejecución.
Lambda proporciona específica [variables de entorno](configuration-envvars.md) específicas del lenguaje que puede configurar para agregar opciones y herramientas al tiempo de ejecución. Lambda también proporciona [scripts de encapsulador](#runtime-wrapper), que permiten a Lambda delegar el inicio del tiempo de ejecución a su script. Puede crear un script de encapsulador para personalizar el comportamiento de inicio del tiempo de ejecución.
## Variables de entorno específicas del lenguaje
Lambda admite formas de solo configuración para habilitar la precarga del código durante la inicialización de la función a través de las siguientes variables de entorno específicas del lenguaje:
+ `JAVA_TOOL_OPTIONS`: en Java, Lambda admite esta variable de entorno para establecer variables de línea de comandos adicionales en Lambda. Esta variable de entorno le permite especificar la inicialización de herramientas, específicamente el lanzamiento de agentes de lenguaje de programación nativo o Java utilizando las opciones `agentlib` o `javaagent`. Para obtener más información, consulte la [variable de entorno de `JAVA_TOOL_OPTIONS`](https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html#java-tool-options).
+ `NODE_OPTIONS`: disponible en los [tiempos de ejecución de Node.js](lambda-nodejs.md).
+ `DOTNET_STARTUP_HOOKS`: en .NET Core 3.1 y superior, esta variable de entorno especifica una ruta a un ensamblado (dll) que Lambda puede usar.
El uso de variables de entorno específicas del lenguaje es la forma preferida de establecer propiedades de inicio.
## Scripts de encapsulador
Puede crear un *script del encapsulador* para personalizar el comportamiento de inicio en tiempo de ejecución de su función de Lambda. Un script de encapsulador le permite establecer parámetros de configuración que no se pueden establecer mediante variables de entorno específicas del lenguaje.
**nota**
Las invocaciones pueden producir un error si el script de encapsulador no comienza correctamente el proceso de tiempo de ejecución.
Los scripts de encapsulador son compatibles con todos los [tiempos de ejecución de Lambda](lambda-runtimes.md) nativos. Los scripts de encapsulador no son compatibles con [Tiempos de ejecución exclusivos del sistema operativo](runtimes-provided.md) (la familia de tiempos de ejecución de `provided`).
Cuando utiliza un script de encapsulador para su función, Lambda inicia el tiempo de ejecución utilizando el script. Lambda envía al script la ruta al intérprete y todos los argumentos originales para el inicio de tiempo de ejecución estándar. El script puede ampliar o transformar el comportamiento de inicio del programa. Por ejemplo, el script puede inyectar y modificar argumentos, establecer variables de entorno o capturar métricas, errores y otra información de diagnóstico.
Para especificar el script mediante el establecimiento del valor de la variable de entorno `AWS_LAMBDA_EXEC_WRAPPER` como la ruta del sistema de archivos de un binario o script ejecutable.
### Ejemplo: crear y usar un script de encapsulador como capa de Lambda
En el ejemplo siguiente, se crea un script de encapsulador para comenzar el intérprete de Python con la opción `-X importtime`. Cuando ejecuta la función, Lambda genera una entrada de registro para mostrar la duración del tiempo de importación para cada importación.
**Cómo crear y usar un script de encapsulador como capa**
1. Cree un directorio para la capa:
```
mkdir -p python-wrapper-layer/bin
cd python-wrapper-layer/bin
```
1. En el directorio `bin`, pegue el siguiente código en un nuevo archivo denominado `importtime_wrapper`. Este es el script de encapsulador.
```
#!/bin/bash
# the path to the interpreter and all of the originally intended arguments
args=("$@")
# the extra options to pass to the interpreter
extra_args=("-X" "importtime")
# insert the extra options
args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}")
# start the runtime with the extra options
exec "${args[@]}"
```
1. Conceda permisos ejecutables al script:
```
chmod +x importtime_wrapper
```
1. Cree un archivo .zip para la capa:
```
cd ..
zip -r ../python-wrapper-layer.zip .
```
1. Compruebe que el archivo .zip tiene la siguiente estructura de directorios:
```
python-wrapper-layer.zip
└ bin
└ importtime_wrapper
```
1. [Cree una capa](creating-deleting-layers.md#layers-create) con el paquete .zip.
1. Luego, se crea una función con la consola de Lambda.
1. Abra la [consola de Lambda](https://console.aws.amazon.com/lambda).
1. Seleccione **Creación de función**.
1. Escriba un **nombre para la función**.
1. En **Tiempo de ejecución**, elija la opción de tiempo de ejecución de Phyton **Último compatible**.
1. Seleccione **Creación de función**.
1. Agregue la capa a la función.
1. Elija su función y, a continuación, elija la pestaña **Código** si aún no está seleccionada.
1. Desplácese hacia abajo hasta la sección **Capas** y, a continuación, elija **Agregar una capa**.
1. En **Origen de la capa**, seleccione **Capas personalizadas** y, a continuación, elija su capa de la lista desplegable **Capas personalizadas**.
1. En **Version (Versión)**, elija **1**.
1. Elija **Añadir**.
1. Agregue la variable de entorno del encapsulador.
1. Elija la pestaña **Configuración** y, a continuación, elija **Variables de entorno**.
1. En **Variables de entorno**, elija **Editar**.
1. Elija **Add environment variable** (Añadir variable de entorno).
1. En **Clave**, escriba `AWS_LAMBDA_EXEC_WRAPPER`.
1. En **Valor**, introduzca `/opt/bin/importtime_wrapper` (`/opt/` \$1 la estructura de carpetas de la capa .zip).
1. Seleccione **Save** (Guardar).
1. Pruebe el script de encapsulador.
1. Elija la pestaña **Test** (Prueba).
1. En **Evento de prueba**, elija **Probar**. No es necesario crear un evento de prueba; el evento predeterminado es suficiente.
1. Desplácese hacia abajo hasta **Resultado de registros**. Debido a que el script de encapsulador comenzó el intérprete de Python con la opción `-X importtime`, los registros muestran el tiempo necesario para cada importación. Por ejemplo:
```
532 | collections
import time: 63 | 63 | _functools
import time: 1053 | 3646 | functools
import time: 2163 | 7499 | enum
import time: 100 | 100 | _sre
import time: 446 | 446 | re._constants
import time: 691 | 1136 | re._parser
import time: 378 | 378 | re._casefix
import time: 670 | 2283 | re._compiler
import time: 416 | 416 | copyreg
```
# Uso de la API de tiempo de ejecución de Lambda para tiempos de ejecución personalizados
AWS Lambda proporciona una API HTTP para que los [tiempos de ejecución personalizados](runtimes-custom.md) puedan recibir eventos de invocación desde Lambda y enviar los datos de respuesta dentro del [entorno de ejecución](lambda-runtimes.md) de Lambda. Esta sección contiene la referencia de la API para la API de tiempo de ejecución de Lambda.
**Las instancias administradas de Lambda admiten solicitudes simultáneas.**
Las instancias administradas de Lambda utilizan la misma API de tiempo de ejecución que las funciones de Lambda (predeterminadas). La diferencia clave es que las instancias administradas pueden aceptar solicitudes de `/next` y `/response` simultáneas hasta el límite configurado de `AWS_LAMBDA_MAX_CONCURRENCY`. Esto permite procesar varias invocaciones simultáneamente en un único entorno de ejecución. Para obtener más información acerca de las instancias administradas, consulte [Descripción del entorno de ejecución de instancias administradas de Lambda](lambda-managed-instances-execution-environment.md).
![\[Diagrama de arquitectura del entorno de ejecución.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
La especificación de OpenAPI para la versión de la API de tiempo de ejecución **2018-06-01** está disponible en: [runtime-api.zip](samples/runtime-api.zip).
Para crear una URL de solicitud de API, los tiempos de ejecución obtienen el punto de enlace de la API de la variable de entorno `AWS_LAMBDA_RUNTIME_API`; agregue la versión de la API y la ruta de recurso deseada.
**Example Solicitud**
```
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next"
```
**Topics**
+ [
## Siguiente invocación
](#runtimes-api-next)
+ [
## Respuesta de la invocación
](#runtimes-api-response)
+ [
## Error de inicialización
](#runtimes-api-initerror)
+ [
## Error de invocación
](#runtimes-api-invokeerror)
## Siguiente invocación
**Ruta** – `/runtime/invocation/next`
**Método**: **GET**
El tiempo de ejecución envía este mensaje a Lambda para solicitar un evento de invocación. El cuerpo de la respuesta contiene la carga a partir de la invocación, la cual es un documento JSON que contiene datos de eventos del desencadenador de la función. Los encabezados de la respuesta contienen datos adicionales sobre la invocación.
**Encabezados de respuesta**
+ `Lambda-Runtime-Aws-Request-Id`: el ID de solicitud, el cual identifica la solicitud que ha desencadenado la invocación de la función.
Por ejemplo, `8476a536-e9f4-11e8-9739-2dfe598c3fcd`.
+ `Lambda-Runtime-Deadline-Ms`: la fecha en la que la función agota su tiempo de espera en milisegundos de tiempo Unix.
Por ejemplo, `1542409706888`.
+ `Lambda-Runtime-Invoked-Function-Arn`: el ARN de la función de Lambda, la versión o el alias especificado en la invocación.
Por ejemplo, `arn:aws:lambda:us-east-2:123456789012:function:custom-runtime`.
+ `Lambda-Runtime-Trace-Id`: el [encabezado de rastreo AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader).
Por ejemplo, `Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1`.
+ `Lambda-Runtime-Client-Context`: en invocaciones desde AWS Mobile SDK, datos sobre la aplicación cliente y el dispositivo.
+ `Lambda-Runtime-Cognito-Identity`: para invocaciones desde AWS Mobile SDK, datos sobre el proveedor de identidades de Amazon Cognito.
No establezca un tiempo de espera en la solicitud `GET`, ya que la respuesta puede retrasarse. Mientras Lambda arranca el tiempo de ejecución y mientras el tiempo de ejecución tiene un evento para devolver, el proceso de tiempo de ejecución se congela durante varios segundos.
El ID de solicitud hace un seguimiento de la invocación dentro de Lambda. Utilícelo para especificar la invocación al enviar la respuesta.
El encabezado de rastreo contiene el ID de rastreo, el ID principal y la decisión de muestreo. Si se muestrea la solicitud, lo hace Lambda o un servicio ascendente. El tiempo de ejecución deberá definir el valor `_X_AMZN_TRACE_ID` con el valor del encabezado. El X-Ray SDK lee esto para obtener los ID y determinar si hay que rastrear la solicitud.
## Respuesta de la invocación
**Ruta** – `/runtime/invocation/AwsRequestId/response`
**Método**: **POST**
Después de que la función se ha ejecutado hasta su finalización, el tiempo de ejecución envía una respuesta de invocación a Lambda. En el caso de invocaciones síncronas, Lambda envía la respuesta al cliente.
**Example Solicitud correcta**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS"
```
## Error de inicialización
Si la función devuelve un error o el tiempo de ejecución encuentra un error durante la inicialización, el tiempo de ejecución utiliza este método para informar del error a Lambda.
**Ruta** – `/runtime/init/error`
**Método**: **POST**
**Encabezados**
`Lambda-Runtime-Function-Error-Type`: tipo de error que encontró el tiempo de ejecución. Obligatorio: no
Este encabezado consta de un valor de cadena. Lambda acepta cualquier cadena, pero recomendamos un formato de . Por ejemplo:
+ Runtime.NoSuchHandler
+ Runtime.APIKeyNotFound
+ Runtime.ConfigInvalid
+ Runtime.UnknownReason
**Body parameters (Parámetros del cuerpo**
`ErrorRequest`: información sobre el error. Obligatorio: no
Este campo es un objeto JSON con la siguiente estructura:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Tenga en cuenta que Lambda acepta cualquier valor para `errorType`.
En el ejemplo siguiente, se muestra un mensaje de error de función de Lambda en el que la función no pudo analizar los datos de evento proporcionados en la invocación.
**Example Error de la función**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Parámetros del cuerpo de la respuesta**
+ `StatusResponse` – Cadena. Información de estado, enviada con códigos de respuesta 202.
+ `ErrorResponse`: información adicional sobre el error, enviada con los códigos de respuesta de error. ErrorResponse contiene un tipo de error y un mensaje de error.
**Códigos de respuesta**
+ 202: aceptada
+ 403: prohibido
+ 500: error en contenedor. Estado no recuperable. El tiempo de ejecución debe salir rápidamente.
**Example Solicitud de error de inicialización**
```
ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
## Error de invocación
Si la función devuelve un error o el tiempo de ejecución encuentra un error, el tiempo de ejecución utiliza este método para informar del error a Lambda.
**Ruta** – `/runtime/invocation/AwsRequestId/error`
**Método**: **POST**
**Encabezados**
`Lambda-Runtime-Function-Error-Type`: tipo de error que encontró el tiempo de ejecución. Obligatorio: no
Este encabezado consta de un valor de cadena. Lambda acepta cualquier cadena, pero recomendamos un formato de . Por ejemplo:
+ Runtime.NoSuchHandler
+ Runtime.APIKeyNotFound
+ Runtime.ConfigInvalid
+ Runtime.UnknownReason
**Body parameters (Parámetros del cuerpo**
`ErrorRequest`: información sobre el error. Obligatorio: no
Este campo es un objeto JSON con la siguiente estructura:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Tenga en cuenta que Lambda acepta cualquier valor para `errorType`.
En el ejemplo siguiente, se muestra un mensaje de error de función de Lambda en el que la función no pudo analizar los datos de evento proporcionados en la invocación.
**Example Error de la función**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Parámetros del cuerpo de la respuesta**
+ `StatusResponse` – Cadena. Información de estado, enviada con códigos de respuesta 202.
+ `ErrorResponse`: información adicional sobre el error, enviada con los códigos de respuesta de error. ErrorResponse contiene un tipo de error y un mensaje de error.
**Códigos de respuesta**
+ 202: aceptada
+ 400: solicitud errónea
+ 403: prohibido
+ 500: error en contenedor. Estado no recuperable. El tiempo de ejecución debe salir rápidamente.
**Example Solicitud errónea**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
# Cuándo utilizar los tiempos de ejecución exclusivos del sistema operativo de Lambda
Lambda proporciona [tiempos de ejecución gestionados](lambda-runtimes.md) para Java, Python, Node.js, .NET y Ruby. Para crear funciones de Lambda en un lenguaje de programación que no esté disponible como tiempo de ejecución gestionado, utilice un tiempo de ejecución exclusivo del sistema operativo (la familia de tiempos de ejecución `provided`). Existen tres casos de uso principales para los tiempos de ejecución exclusivos del sistema operativo:
+ **Compilación nativa anticipada (AOT):** lenguajes como Go, Rust, Swift y C\$1\$1 se compilan de forma nativa en un binario ejecutable, que no requiere un tiempo de ejecución de lenguaje específico. Estos lenguajes solo necesitan un entorno de sistema operativo en el que se pueda ejecutar el binario compilado. También puede usar tiempos de ejecución exclusivos del sistema operativo de Lambda para implementar binarios compilados con .NET Native AOT y Java GraalVM Native Image.
Debe incluir un cliente de interfaz de tiempo de ejecución en el binario. El cliente de la interfaz del tiempo de ejecución llama a [Uso de la API de tiempo de ejecución de Lambda para tiempos de ejecución personalizados](runtimes-api.md) para recuperar las invocaciones de funciones y, a continuación, llama al controlador de funciones. Lambda proporciona clientes de interfaz de tiempo de ejecución para [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) y [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (experimental).
Debe compilar el binario para un entorno Linux y para la misma arquitectura de conjunto de instrucciones que planea usar para la función (x86\$164 o arm64).
+ **Tiempos de ejecución de terceros**: puede ejecutar funciones de Lambda con tiempos de ejecución listos para usar, como [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) para PHP.
+ **Tiempos de ejecución personalizados**: puede crear su propio tiempo de ejecución para un lenguaje (o una versión de un lenguaje) para el que Lambda no proporcione un tiempo de ejecución gestionado, como Node.js 19. Para obtener más información, consulte [Creación de un tiempo de ejecución personalizado para AWS Lambda](runtimes-custom.md). Este es el caso de uso menos común para los tiempos de ejecución exclusivos del sistema operativo.
Lambda admite los siguientes tiempos de ejecución exclusivos del sistema operativo de Ruby.
| Nombre | Identificador | Sistema operativo | Fecha de baja | Bloqueo de la función Crear | Bloqueo de la función Actualizar |
| --- | --- | --- | --- | --- | --- |
| Tiempo de ejecución exclusivo del sistema operativo | `provided.al2023` | Amazon Linux 2023 | 30 de junio de 2029 | 31 de julio de 2029 | 31 de agosto de 2029 |
| Tiempo de ejecución exclusivo del sistema operativo | `provided.al2` | Amazon Linux 2 | 31 de julio de 2026 | 31 de agosto de 2026 | 30 de septiembre de 2026 |
El tiempo de ejecución de Amazon Linux 2023 (`provided.al2023`) ofrece varias ventajas con respecto a Amazon Linux 2, incluida una huella de implementación más reducida y versiones actualizadas de bibliotecas como `glibc`.
El tiempo de ejecución `provided.al2023` utiliza `dnf` como administrador de paquetes en lugar de `yum`, que es el administrador de paquetes predeterminado en Amazon Linux 2. Para obtener más información sobre las diferencias entre `provided.al2023` y `provided.al2`, consulte [Presentación del tiempo de ejecución de Amazon Linux 2023 AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) en el Blog de informática de AWS.
# Creación de un tiempo de ejecución personalizado para AWS Lambda
Puede implementar tiempos de ejecución de AWS Lambda con cualquier lenguaje de programación. El tiempo de ejecución es un programa que ejecuta un método de controlador de función de Lambda cuando se invoca la función. El tiempo de ejecución se puede incluir en el paquete de implementación de la función o se puede distribuir en una [capa](chapter-layers.md). Cuando cree la función de Lambda, elija un [tiempo de ejecución exclusivo del sistema operativo](runtimes-provided.md) (la familia de tiempos de ejecución `provided`).
**nota**
La creación de un tiempo de ejecución personalizado es un caso de uso avanzado. Si busca información sobre la compilación en un binario nativo o el uso de un tiempo de ejecución estándar de terceros, consulte [Cuándo utilizar los tiempos de ejecución exclusivos del sistema operativo de Lambda](runtimes-provided.md).
Para ver un recorrido por el proceso de implementación de un tiempo de ejecución personalizado, consulte [Tutorial: cómo crear un tiempo de ejecución personalizado](runtimes-walkthrough.md).
**Topics**
+ [
## Requisitos
](#runtimes-custom-build)
+ [
## Implementación de la transmisión de respuestas en un entorno de ejecución personalizado
](#runtimes-custom-response-streaming)
+ [
## Creación de tiempos de ejecución personalizados para instancias administradas de Lambda
](#runtimes-custom-managed-instances)
## Requisitos
Los tiempos de ejecución personalizados deben completar determinadas tareas de inicialización y procesamiento. El tiempo de ejecución ejecuta el código de configuración de la función, lee el nombre del controlador a partir de una variable de entorno y lee los eventos de invocación desde la API de tiempo de ejecución de Lambda. El tiempo de ejecución transfiere los datos de los eventos al controlador de la función y publica la respuesta desde el controlador de vuelta a Lambda.
### Tareas de inicialización
Las tareas de inicialización se ejecutan una vez [por instancia de la función](lambda-runtime-environment.md) para preparar el entorno para gestionar invocaciones.
+ **Retrieve settings (Recuperar opciones de configuración)**: leer variables de entorno para obtener detalles acerca de la función y el entorno.
+ `_HANDLER`: la ubicación del controlador, a partir de la configuración de la función. El formato estándar es `file.method`, donde `file` es el nombre del archivo sin extensión, y `method` es el nombre de un método o una función que se define en el archivo.
+ `LAMBDA_TASK_ROOT`: el directorio que contiene el código de la función.
+ `AWS_LAMBDA_RUNTIME_API`: el host y el puerto de la API de tiempo de ejecución.
Para obtener una lista completa de variables disponibles, consulte [Variables definidas de entorno de tiempo de ejecución](configuration-envvars.md#configuration-envvars-runtime).
+ **Inicializar la función**: cargar el archivo de controlador y ejecutar cualquier código global o estático en él. Las funciones deben crear los recursos estáticos, como clientes SDK y conexiones de bases de datos, una vez, y después volver a utilizarlos para varias invocaciones.
+ **Administración de errores**: si se produce un error, llamar a la API de [error de inicialización](runtimes-api.md#runtimes-api-initerror) y salir de forma inmediata.
La inicialización se tiene en cuenta al calcular el tiempo de ejecución y el tiempo de espera que se factura. Cuando una ejecución activa la inicialización de una nueva instancia de la función, puede ver el tiempo de inicialización en los registros y el [rastreo de AWS X-Ray](services-xray.md).
**Example registro**
```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB
```
### Procesamiento de tareas
Mientras se ejecuta, el tiempo de ejecución utiliza la [interfaz de tiempo de ejecución de Lambda](runtimes-api.md) para administrar eventos entrantes e informar sobre errores. Después de completar las tareas de inicialización, el tiempo de ejecución procesa los eventos entrantes en bucle. En el código de tiempo de ejecución, realice los siguientes pasos en orden.
+ **Get an event (Obtener un evento)**: llamar a la API de la [siguiente invocación](runtimes-api.md#runtimes-api-next) para obtener el siguiente evento. El cuerpo de la respuesta contiene los datos del evento. Los encabezados de respuesta contienen el ID de la solicitud y otra información.
+ **Propagate the tracing header (Propagar el encabezado de rastreo)**: obtenga el encabezado de rastreo de X-Ray desde el encabezado `Lambda-Runtime-Trace-Id` en la respuesta de la API. Establezca localmente la variable de entorno `_X_AMZN_TRACE_ID` con el mismo valor. El SDK de X-Ray utiliza este valor para conectar datos de rastreo entre servicios.
+ **Create a context object (Crear un objeto context)**: cree un objeto con información de contexto a partir de las variables de entorno y los encabezados en la respuesta de la API.
+ **Invoke the function handler (Invocar el controlador de la función)**: transfiera el evento y el objeto context al controlador.
+ **Handle the response (Administrar la respuesta)**: llame a la API de [respuesta de invocación](runtimes-api.md#runtimes-api-response) para publicar la respuesta desde el controlador.
+ **Handle errors (Administrar errores)**: si se produce un error, llamar a la API de [error de invocación](runtimes-api.md#runtimes-api-invokeerror).
+ **Cleanup (Limpiar)**: libere recursos no utilizados, envíe datos a otros servicios o realice tareas adicionales antes de obtener el siguiente evento.
### Punto de entrada
El punto de entrada de un tiempo de ejecución personalizado es un archivo ejecutable llamado `bootstrap`. El archivo de arranque puede ser el tiempo de ejecución o puede invocar otro archivo que cree el tiempo de ejecución. Si la raíz del paquete de implementación no contiene un archivo con el nombre `bootstrap`, Lambda busca el archivo en las capas de la función. Si el archivo `bootstrap` no existe o no es ejecutable, la función devuelve el error `Runtime.InvalidEntrypoint` tras la invocación.
Este es un ejemplo de un archivo `bootstrap` que utiliza una versión empaquetada de Node.js para ejecutar un tiempo de ejecución de JavaScript en un archivo aparte llamado `runtime.js`.
**Example arranque**
```
#!/bin/sh
cd $LAMBDA_TASK_ROOT
./node-v11.1.0-linux-x64/bin/node runtime.js
```
## Implementación de la transmisión de respuestas en un entorno de ejecución personalizado
Para las [funciones de transmisión de respuestas](configuration-response-streaming.md), los puntos de conexión de `response` y `error` han modificado ligeramente su comportamiento, lo que permite que el tiempo de ejecución transmita respuestas parciales al cliente y devuelva las cargas en fragmentos. Para obtener más información sobre el comportamiento específico, consulte lo siguiente:
+ `/runtime/invocation/AwsRequestId/response`: propaga el encabezado `Content-Type` desde el tiempo de ejecución para enviarlo al cliente. Lambda devuelve la carga de respuesta en fragmentos mediante la codificación de transferencia fragmentada de HTTP/1.1. Para transmitir la respuesta a Lambda, el tiempo de ejecución debe realizar lo siguiente:
+ Establecer el encabezado HTTP `Lambda-Runtime-Function-Response-Mode` en `streaming`.
+ Establezca el encabezado `Transfer-Encoding` en `chunked`.
+ Escribir la respuesta de acuerdo con la especificación de codificación de transferencia fragmentada de HTTP/1.1.
+ Cerrar la conexión subyacente después de que la respuesta se haya escrito correctamente.
+ `/runtime/invocation/AwsRequestId/error`: el tiempo de ejecución puede utilizar este punto de conexión para informar sobre errores de función o tiempo de ejecución a Lambda, que también acepta el encabezado `Transfer-Encoding`. Solo se puede llamar a este punto de conexión antes de que el tiempo de ejecución comience a enviar una respuesta de invocación.
+ Informe los errores intermedios mediante los tráileres de errores en `/runtime/invocation/AwsRequestId/response`: el tiempo de ejecución puede adjuntar opcionalmente los encabezados finales de HTTP con los nombres `Lambda-Runtime-Function-Error-Type` y`Lambda-Runtime-Function-Error-Body` para informar sobre los errores que se producen después de haber empezado a escribir la respuesta de invocación. Lambda trata esto como una respuesta correcta y reenvía los metadatos de error proporcionados por el tiempo de ejecución al cliente.
**nota**
Para adjuntar encabezados finales, el tiempo de ejecución debe establecer el valor del encabezado `Trailer` al principio de la solicitud HTTP. Este es un requisito de la especificación de codificación de transferencia fragmentada de HTTP/1.1.
+ `Lambda-Runtime-Function-Error-Type`: el tipo de error que encontró el tiempo de ejecución. Este encabezado consta de un valor de cadena. Lambda acepta cualquier cadena, pero recomendamos un formato de **. Por ejemplo, `Runtime.APIKeyNotFound`.
+ `Lambda-Runtime-Function-Error-Body`: información sobre el error codificada en Base64.
## Creación de tiempos de ejecución personalizados para instancias administradas de Lambda
Las instancias administradas de Lambda utilizan la misma API de tiempo de ejecución que las funciones de Lambda (predeterminadas). Sin embargo, existen diferencias clave en la forma en que se deben implementar los tiempos de ejecución personalizados para admitir el modelo de ejecución simultánea de las instancias administradas.
### Gestión de solicitudes simultáneas
La principal diferencia a la hora de crear tiempos de ejecución personalizados para las instancias administradas es la compatibilidad con las invocaciones simultáneas. A diferencia de las funciones de Lambda (predeterminadas), en las que el tiempo de ejecución procesa una invocación a la vez, las instancias administradas pueden procesar varias invocaciones simultáneamente en un único entorno de ejecución.
Su tiempo de ejecución personalizado debe cumplir con lo siguiente:
+ **Admitir solicitudes simultáneas de `/next`:** el tiempo de ejecución puede realizar varias llamadas simultáneas a la [siguiente API de invocación](runtimes-api.md#runtimes-api-next), hasta el límite especificado por la variable de entorno de `AWS_LAMBDA_MAX_CONCURRENCY`.
+ **Gestionar solicitudes simultáneas de `/response`**: varias invocaciones pueden llamar a la [API de respuesta a la invocación](runtimes-api.md#runtimes-api-response) simultáneamente.
+ **Implementar una gestión de solicitudes segura para subprocesos**: asegúrese de que las invocaciones simultáneas no interfieran entre sí mediante la administración adecuada de los recursos y el estado compartidos.
+ **Usar identificadores de solicitud únicos**: realice un seguimiento de cada invocación por separado mediante el encabezado `Lambda-Runtime-Aws-Request-Id` para hacer coincidir las respuestas con las solicitudes correspondientes.
### Patrón de implementación
Un patrón de implementación típico para los tiempos de ejecución de las instancias administradas implica la creación de subprocesos o procesos de trabajo para gestionar las invocaciones simultáneas:
1. **Lectura del límite de concurrencia**: en la inicialización, lea la variable de entorno de `AWS_LAMBDA_MAX_CONCURRENCY` para determinar el número de invocaciones simultáneas que se admitirán.
1. **Creación de un grupo de trabajo**: inicialice un grupo de trabajo (subprocesos, procesos o tareas asíncronas) igual al límite de concurrencia.
1. **Bucle de procesamiento de trabajo**: cada trabajo realiza lo siguiente de forma independiente:
+ Llama a `/runtime/invocation/next` para obtener un evento de invocación.
+ Invoca al controlador de funciones con los datos del evento.
+ Publica la respuesta en `/runtime/invocation/AwsRequestId/response`.
+ Repite el bucle.
### Consideraciones adicionales
+ **Formato de registro**: las instancias administradas solo admiten el formato de registro JSON. Asegúrese de que el tiempo de ejecución respete la variable de entorno de `AWS_LAMBDA_LOG_FORMAT` y solo utilice el formato JSON. Para obtener más información, consulte [Configuración de los formatos de registro JSON y de texto sin formato](monitoring-cloudwatchlogs-logformat.md).
+ **Recursos compartidos**: use con precaución los recursos compartidos, como el directorio de `/tmp`, con invocaciones simultáneas. Implemente los mecanismos de bloqueo adecuados para evitar condiciones de carrera.
Para obtener más información acerca de los entorno de ejecución de instancias administradas de Lambda, consulte [Descripción del entorno de ejecución de instancias administradas de Lambda](lambda-managed-instances-execution-environment.md).
# Tutorial: cómo crear un tiempo de ejecución personalizado
En este tutorial creará una función de Lambda con un tiempo de ejecución personalizado. Para empezar incluirá el tiempo de ejecución en el paquete de implementación de la función. A continuación, lo migrará a una capa que gestiona independientemente de la función. Por último, compartirá la capa de tiempo de ejecución globalmente actualizando su política de permisos basados en recursos.
## Requisitos previos
En este tutorial, se presupone que tiene algunos conocimientos sobre las operaciones básicas de Lambda y la consola de Lambda. Si aún no lo ha hecho, siga las instrucciones de [Cree una función de Lambda con la consola.](getting-started.md#getting-started-create-function) para crear su primera función de Lambda.
Para completar los siguientes pasos, necesita la [versión 2 de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Los comandos y la salida esperada se enumeran en bloques separados:
```
aws --version
```
Debería ver los siguientes datos de salida:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Para comandos largos, se utiliza un carácter de escape (`\`) para dividir un comando en varias líneas.
En Linux y macOS, use su administrador de intérprete de comandos y paquetes preferido.
**nota**
En Windows, algunos comandos de la CLI de Bash que se utilizan habitualmente con Lambda (por ejemplo, `zip`) no son compatibles con los terminales integrados del sistema operativo. Para obtener una versión de Ubuntu y Bash integrada con Windows, [instale el subsistema de Windows para Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Los comandos de la CLI de ejemplo de esta guía utilizan el formato Linux. Los comandos que incluyen documentos JSON en línea deben reformatearse si utiliza la CLI de Windows.
Necesita un rol de IAM para crear una función de Lambda. El rol necesita permiso para enviar registros a los Registros de CloudWatch y acceder a los Servicios de AWS que utiliza su función. Si no tiene un rol de para el desarrollo de funciones, cree uno.
**Para crear un rol de ejecución**
1. Abra la [página Roles](https://console.aws.amazon.com/iam/home#/roles) en la consola de IAM.
1. Elija **Creación de rol**.
1. Cree un rol con las propiedades siguientes.
+ **Trusted entity (Entidad de confianza).**–**Lambda:**.
+ **Permisos**: **AWSLambdaBasicExecutionRole**.
+ **Nombre de rol**: **lambda-role**.
La política **AWSLambdaBasicExecutionRole** tiene permisos que la función necesita para escribir registros a Registros de CloudWatch.
## Crear una función
Cree una función de Lambda con un tiempo de ejecución personalizado. En este ejemplo se incluyen dos archivos: un archivo `bootstrap` de tiempo de ejecución y un controlador de la función. Ambos se implementan en Bash.
1. Cree un directorio para el proyecto y, a continuación, cambie a ese directorio.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. Cree un nuevo archivo denominado `bootstrap`. Este es el tiempo de ejecución personalizado.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
El tiempo de ejecución carga un script de función desde el paquete de implementación. Utiliza dos variables para localizar el script. `LAMBDA_TASK_ROOT` le indica dónde se extrajo el paquete y `_HANDLER` incluye el nombre del script.
Luego de que el tiempo de ejecución carga el script de la función, utiliza la API de tiempo de ejecución para recuperar un evento de invocación de Lambda, pasa el evento al controlador y publica la respuesta de vuelta en Lambda. Para obtener el ID de la solicitud, el tiempo de ejecución guarda los encabezados de la respuesta de la API en un archivo temporal y lee el encabezado `Lambda-Runtime-Aws-Request-Id` del archivo.
**nota**
Los tiempos de ejecución se encargan de algunas cosas más, como gestionar errores y proporcionar información de contexto al controlador. Para obtener más información, consulte [Requisitos](runtimes-custom.md#runtimes-custom-build).
1. Cree un script para la función. El script del ejemplo a continuación, define una función de controlador que toma datos de eventos, los registra en `stderr` y los devuelve.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
El directorio `runtime-tutorial` debe tener ahora el siguiente aspecto:
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. Haga los archivos ejecutables y añádalos a un archivo .zip. Este es el paquete de implementación.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. Cree una función llamada `bash-runtime`. Para `--role`, introduzca el ARN de su [rol de ejecución](lambda-intro-execution-role.md) de Lambda.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. Invoque la función.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
La opción **cli-binary-format** es obligatoria si va a utilizar la versión 2 de la AWS CLI. Para que esta sea la configuración predeterminada, ejecute `aws configure set cli-binary-format raw-in-base64-out`. Para obtener más información, consulte [Opciones de la línea de comandos globales compatibles con AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) en la *Guía del usuario de la AWS Command Line Interface versión 2*.
Debería ver una respuesta como la siguiente:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Verifique la respuesta.
```
cat response.txt
```
Debería ver una respuesta como la siguiente:
```
Echoing request: '{"text":"Hello"}'
```
## Crear una capa
Para separar el código de tiempo de ejecución del código de la función, cree una capa que solo contenga el tiempo de ejecución. Las capas le permiten desarrollar las dependencias de la función de forma independiente y, si utiliza la misma capa con varias funciones, podrá hacer un menor uso del almacenamiento. Para obtener más información, consulte [Administración de las dependencias de Lambda con capas](chapter-layers.md).
1. Cree un archivo .zip que contenga el archivo `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Cree una capa con el comando [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x).
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
Esto crea la primera versión de la capa.
## Actualización de la función
Para utilizar la capa de tiempo de ejecución con la función, configure la función para que use la capa, y elimine de ella el código de tiempo de ejecución.
1. Actualice la configuración de la función para incluir la capa.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
Esto agrega el tiempo de ejecución a la función en el directorio `/opt`. Para garantizar que Lambda utilice el tiempo de ejecución de la capa, debe eliminar el `boostrap` del paquete de implementación de la función, como se muestra en los dos pasos a continuación.
1. Cree un archivo .zip que contenga el código de la función.
```
zip function-only.zip function.sh
```
1. Actualice el código de la función para que incluya solo el script del controlador.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. Invoque la función para confirmar que funciona con la capa de tiempo de ejecución.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
La opción **cli-binary-format** es obligatoria si va a utilizar la versión 2 de la AWS CLI. Para que esta sea la configuración predeterminada, ejecute `aws configure set cli-binary-format raw-in-base64-out`. Para obtener más información, consulte [Opciones de la línea de comandos globales compatibles con AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) en la *Guía del usuario de la AWS Command Line Interface versión 2*.
Debería ver una respuesta como la siguiente:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Verifique la respuesta.
```
cat response.txt
```
Debería ver una respuesta como la siguiente:
```
Echoing request: '{"text":"Hello"}'
```
## Actualización del tiempo de ejecución
1. Para registrar información sobre el entorno de ejecución, actualice el script de tiempo de ejecución para emitir variables de entorno.
**Example bootstrap**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. Cree un archivo .zip que contenga la nueva versión del archivo `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Cree una nueva versión de la capa `bash-runtime`.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. Configure la función para utilizar la nueva versión de la capa.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## Uso compartido de la capa
Para compartir una función con otra Cuenta de AWS, agregue una declaración de permisos entre cuentas a la [política basada en los recursos](access-control-resource-based.md) de la capa. Ejecute el comando [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) y especifique el ID de la cuenta como `principal`. En cada instrucción, puede conceder permiso a una única cuenta, a todas las cuentas o a una organización en [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
El siguiente ejemplo concede a la cuenta 111122223333 acceso a la versión 2 de la capa `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Debería ver una salida similar a esta:
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Los permisos solo se aplican a una única versión de una capa. Repita el proceso cada vez que cree una nueva versión de la capa.
## Limpieza
Elimine cada versión de la capa.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
Puesto que la función contiene una referencia a la versión 2 de la capa, esta sigue existiendo en Lambda. Si bien la función sigue funcionando, ya no se pueden configurar funciones para que utilicen la versión eliminada. Si modifica la lista de capas de la función, deberá especificar una nueva versión u omitir la capa eliminada.
Elimine la función con el comando [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).
```
aws lambda delete-function --function-name bash-runtime
```
# Repositorios de código abierto
AWS Lambda proporciona diversas herramientas, bibliotecas y componentes de código abierto para ayudarlo a crear, personalizar y optimizar sus aplicaciones sin servidor. Estos recursos incluyen clientes de interfaz de tiempo de ejecución, bibliotecas de eventos, imágenes base de contenedores, herramientas de desarrollo y proyectos de muestra mantenidos por AWS y están disponibles en GitHub. Al aprovechar estos repositorios de código abierto, se pueden ampliar las capacidades de Lambda, crear tiempos de ejecución personalizados, procesar eventos de varios servicios de AWS y obtener información más detallada sobre el rendimiento de su función. En esta página se proporciona información general de los proyectos de código abierto clave que admiten el desarrollo de Lambda.
## Clientes de interfaz de tiempo de ejecución
Los clientes de interfaz de tiempo de ejecución (RIC) de Lambda son bibliotecas de código abierto que implementan la [API de tiempo de ejecución](runtimes-api.md) y administran la interacción entre el código de la función y el servicio de Lambda. Estos clientes se encargan de recibir eventos de invocación, de transmitir información contextual y de notificar errores.
Los clientes de interfaz de ejecución que utilizan los tiempos de ejecución administrados y las imágenes base de contenedores de Lambda se publican como código abierto. Al crear tiempos de ejecución personalizados o ampliar los existentes, se pueden utilizar estas bibliotecas de código abierto para simplificar la implementación. Los siguientes repositorios de GitHub de código abierto contienen el código fuente de los RIC de Lambda:
+ [Clientes de interfaz de tiempo de ejecución Node.js](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client)
+ [Clientes de interfaz de tiempo de ejecución de Python](https://github.com/aws/aws-lambda-python-runtime-interface-client)
+ [Clientes de interfaz de tiempo de ejecución Java](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-runtime-interface-client)
+ [Clientes de interfaz de tiempo de ejecución de Ruby](https://github.com/aws/aws-lambda-ruby-runtime-interface-client)
+ [Clientes de interfaz de tiempo de ejecución .NET.](https://github.com/aws/aws-lambda-dotnet)
+ [Cliente de interfaz de tiempo de ejecución de Rust](https://github.com/aws/aws-lambda-rust-runtime)
+ [Cliente de interfaz de tiempo de ejecución de Go](https://github.com/aws/aws-lambda-go)
+ [Cliente de interfaz de tiempo de ejecución de Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (experimental)
+ [Cliente de interfaz de tiempo de ejecución de C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (experimental)
+ [Imágenes base de Lambda](https://github.com/aws/aws-lambda-base-images)
Para obtener más información acerca del uso de estos clientes para crear tiempos de ejecución personalizados, consulte [Creación de un tiempo de ejecución personalizado para AWS Lambda](runtimes-custom.md).
## Bibliotecas de eventos
Las bibliotecas de eventos de Lambda proporcionan definiciones de tipos y utilidades auxiliares para el procesamiento de eventos de varios servicios de AWS. Estas bibliotecas ayudan con el análisis y la administración de los datos de eventos de manera segura, lo que facilita el trabajo con eventos de servicios como Amazon S3, Amazon DynamoDB y Amazon API Gateway.
Para los lenguajes compilados, AWS proporciona las siguientes bibliotecas de eventos:
+ [Biblioteca de eventos de Java](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events)
+ [.Bibliotecas de eventos de .NET](https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src)
+ [Biblioteca de eventos de Go](https://github.com/aws/aws-lambda-go/tree/main/events)
+ [Biblioteca de eventos de Java](https://github.com/awslabs/aws-lambda-rust-runtime)
Para lenguajes interpretados como Node.js, Python y Ruby, los eventos se pueden analizar directamente como objetos JSON sin necesidad de una biblioteca independiente. Sin embargo, los desarrolladores que utilizan Node.js y Python pueden aprovechar powertools for AWS Lambda, que proporciona esquemas integrados para eventos de AWS que ofrecen sugerencias de tipos, validación de datos y funcionalidades similares a las que ofrecen las bibliotecas de lenguajes compilados.
+ [Powertools para TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/parser/#built-in-schemas)
+ [Powertools para Python](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/#built-in-models)
## Imágenes de base de contenedores
AWS proporciona imágenes base de contenedores de código abierto que se pueden utilizar como punto de partida para crear imágenes de contenedores para las funciones de Lambda. Estas imágenes base incluyen el cliente de la interfaz del tiempo de ejecución y otros componentes necesarios para ejecutar las funciones en el entorno de ejecución de Lambda.
Para obtener más información sobre las imágenes base disponibles y cómo utilizarlas, consulte el repositorio de [imágenes base de AWS Lambda](https://github.com/aws/aws-lambda-base-images) y [Crear una función de Lambda con una imagen de contenedor](images-create.md).
## Herramientas de desarrollo
AWS proporciona herramientas de desarrollo de código abierto adicionales para ayudarle a crear y optimizar sus funciones de Lambda:
### Powertools para AWS Lambda
Powertools para AWS Lambda simplifica el desarrollo sin servidor con utilidades esenciales para evitar el procesamiento duplicado y el procesamiento por lotes para la gestión de varios registros y la biblioteca de consumo de Kafka. Estas funciones ayudan a minimizar la complejidad del código y la sobrecarga operativa.
También se puede aprovechar la validación de esquemas de eventos integrada, el registro y seguimiento estructurados y la integración del almacén de parámetros, que están diseñados para acelerar la creación de funciones de Lambda listas para la producción y, al mismo tiempo, seguir las prácticas recomendadas estipuladas en AWS well-architected.
Repositorios de GitHub:
+ [Python](https://github.com/aws-powertools/powertools-lambda-python)
+ [TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript)
+ [Java](https://github.com/aws-powertools/powertools-lambda-java)
+ [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet)
### Herramientas de desarrollo de Java
+ [Java Profiler (experimental)](https://github.com/aws/aws-lambda-java-libs/tree/main/experimental/aws-lambda-java-profiler): herramienta para perfilar funciones de Lambda en Java.
+ [Bibliotecas de Java](https://github.com/aws/aws-lambda-java-libs): un repositorio que contiene una colección completa de bibliotecas y herramientas de Java para el desarrollo de Lambda, que incluye proyectos clave como las utilidades de pruebas JUnit y las herramientas de creación de perfiles.
+ [Contenedor de Java sin servidor](https://github.com/aws/serverless-java-container): biblioteca que permite ejecutar aplicaciones Java existentes en Lambda con cambios mínimos.
### Herramientas de desarrollo de .NET
El [repositorio AWS Lambda.NET](https://github.com/aws/aws-lambda-dotnet) proporciona bibliotecas y herramientas de .NET para el desarrollo de Lambda, incluidos proyectos clave, como herramientas AWS Lambda para la CLI de .NET y el servidor .NET Core para alojar aplicaciones de .NET Core.
## Proyectos de ejemplo
Explore una colección completa de ejemplos de proyectos y aplicaciones de Lambda en los [repositorios de Serverless Land](https://serverlessland.com/repos). Estos ejemplos muestran varios casos de uso, patrones de integración y prácticas recomendadas de Lambda para ayudar a trabajar con las aplicaciones sin servidor.