# ¿Qué es AWS Lambda?
**sugerencia**
Participe con expertos en tecnologías sin servidor en talleres prácticos gratuitos para aprender a crear aplicaciones sin servidor con las mejores prácticas. [Haga clic aquí](https://aws-experience.com/amer/smb/events/series/Get-Hands-On-With-Serverless?trk=188abe3e-9f94-4e84-aefb-398d944ad567%26sc_channel%3Del) para inscribirse.
AWS Lambda es un servicio de computación que ejecuta código sin necesidad de administrar servidores. El código se ejecuta, y escala verticalmente y se reduce de manera automática, con precios de pago por uso. Para empezar, consulte [Creación de su primera función](getting-started.md).
Puede utilizar Lambda para los siguientes procesos:
+ **Procesamiento de archivos**: procese los archivos de manera automática cuando los cargue en Amazon Simple Storage Service. Consulte los [ejemplos de procesamiento de archivos](example-apps.md#examples-apps-file) para obtener más información.
+ **Flujos de trabajo de larga duración:** utilice [funciones duraderas de Lambda](durable-functions.md) para crear flujos de trabajo de varios pasos y con estado que puedan ejecutarse durante 1 año como máximo. Es perfecto para el procesamiento de pedidos, los flujos de trabajo de aprobación, los procesos con intervención humana y las canalizaciones de datos complejas que necesitan recordar su progreso.
+ **Ejemplos de operaciones e integración de bases de datos**: responda a los cambios en la base de datos y automatice los flujos de trabajo de datos. Consulte los [ejemplos de bases de datos](example-apps.md#examples-apps-database) para obtener más información.
+ **Tareas programadas y periódicas**: ejecute operaciones automatizadas de forma regular mediante EventBridge. Consulte los [ejemplos de tareas programadas](example-apps.md#examples-apps-scheduled) para obtener más información.
+ **Procesamiento de flujos**: procese flujos de datos en tiempo real para análisis y supervisión. Consulte [Kinesis Data Streams](with-kinesis.md) para obtener más información.
+ **Aplicaciones web**: cree aplicaciones web escalables que se ajusten automáticamente a la demanda.
+ **Backends móviles**: cree backends de API seguros para aplicaciones móviles y web.
+ **Backends de IoT**: gestione solicitudes de API web, móviles, de IoT y de terceros. Consulte [IoT](services-iot.md) para obtener más detalles.
Para obtener información acerca de los precios, consulte [Precios de AWS Lambda](https://aws.amazon.com/lambda/pricing/).
## Cómo funciona Lambda
Cuando se utiliza Lambda, solo es necesario preocuparse por el código. Lambda ejecuta el código en una infraestructura informática de alta disponibilidad y administra todos los recursos informáticos, incluidos el mantenimiento del servidor y del sistema operativo, el aprovisionamiento de capacidad, el escalado automático y el registro.
Dado que Lambda es un servicio de computación sin servidor y basado en eventos, utiliza un paradigma de programación diferente al de las aplicaciones web tradicionales. El siguiente modelo ilustra cómo funciona Lambda:
1. Usted escribe y organiza su código en [funciones de Lambda](concepts-basics.md#gettingstarted-concepts-function), que son los componentes básicos que se utilizan para crear una aplicación Lambda.
1. Usted controla la seguridad y el acceso mediante los [permisos de Lambda](lambda-permissions.md), utilizando [roles de ejecución](lambda-intro-execution-role.md) para administrar con qué servicios de AWS pueden interactuar sus funciones y qué políticas de recursos pueden interactuar con su código.
1. Las fuentes de eventos y los servicios de AWS [desencadenan](concepts-event-driven-architectures.md) sus funciones de Lambda, pasando los datos de eventos en formato JSON, que sus funciones procesan (esto incluye las asignaciones de orígenes de eventos).
1. [Lambda ejecuta su código](concepts-how-lambda-runs-code.md) con tiempos de ejecución específicos del lenguaje (como Node.js y Python) en entornos de ejecución que empaquetan el tiempo de ejecución, las capas y las extensiones.
**sugerencia**
Para obtener información sobre cómo crear **soluciones sin servidor**, consulte la [Guía para desarrolladores sin servidor](https://docs.aws.amazon.com/serverless/latest/devguide/).
## Características principales de
**Configure, controle e implemente aplicaciones seguras:**
+ [Variables de entorno](configuration-envvars.md) modifica el comportamiento de las aplicaciones sin nuevas implementaciones de código.
+ [Versiones](configuration-versions.md) prueba nuevas características de forma segura mientras mantiene entornos de producción estables.
+ [Capas de Lambda](chapter-layers.md) optimiza la reutilización y el mantenimiento del código al compartir componentes comunes en múltiples funciones.
+ [Firma de código](configuration-codesigning.md) refuerza el cumplimiento de la seguridad garantizando que solo el código aprobado llegue a los sistemas de producción.
**Escale y funcione de forma fiable:**
+ Los [controles de concurrencia y escalado](lambda-concurrency.md) gestionan con precisión la capacidad de respuesta de las aplicaciones y la utilización de los recursos durante los picos de tráfico.
+ [Lambda SnapStart](snapstart.md) reduce significativamente los tiempos de inicio en frío. Lambda SnapStart puede ofrecer un rendimiento de inicio en menos de un segundo, normalmente sin cambios en el código de la función.
+ [Transmisión de respuestas](configuration-response-streaming.md) optimiza el rendimiento de la función mediante la entrega de grandes cargas útiles de forma incremental para su procesamiento en tiempo real.
+ [Imágenes de contenedor](images-create.md) empaqueta funciones con dependencias complejas mediante flujos de trabajo de contenedores.
**Conéctese e intégrese sin problemas:**
+ Las [redes de VPC](configuration-vpc.md) protegen los recursos confidenciales y los servicios internos.
+ [Sistema de archivos](configuration-filesystem.md) integración que comparte datos persistentes y gestiona las operaciones con estado en todas las invocaciones de funciones.
+ [URL de funciones](urls-configuration.md) crea API y puntos de conexión públicos sin servicios adicionales.
+ [Extensiones de Lambda](lambda-extensions.md) aumenta las funciones con herramientas de monitorización, seguridad y operativas.
## Información relacionada
+ Para obtener información sobre cómo funciona Lambda, consulte [Cómo funciona Lambda](concepts-basics.md).
+ Para empezar a usar Lambda, consulte [Creación de su primera función de Lambda](getting-started.md).
+ Para obtener una lista de ejemplos de aplicaciones, consulte [Cómo empezar con ejemplos de aplicaciones y patrones](example-apps.md).
# Cómo funciona Lambda
Las funciones de Lambda son los componentes básicos que se utilizan para crear aplicaciones de Lambda. Para escribir funciones, es esencial comprender los conceptos y componentes principales que componen el modelo de programación Lambda. Esta sección lo guiará a través de los elementos fundamentales que necesita conocer para empezar a crear aplicaciones sin servidor con Lambda.
+ **[Funciones de Lambda y controladores de funciones](#gettingstarted-concepts-function)**: una función de Lambda es un pequeño bloque de código que se ejecuta en respuesta a eventos. Las funciones pueden ser estándar (hasta 15 minutos) o [duraderas](durable-functions.md) (hasta 1 año). Las funciones son los componentes básicos que se utilizan para crear aplicaciones. Los controladores de funciones son el punto de entrada para los objetos de eventos que procesa el código de función de Lambda.
+ **[Tiempos de ejecución y entorno de ejecución de Lambda](#gettingstarted-concepts-runtime)** - los entornos de ejecución administran los recursos necesarios para ejecutar la función. En el caso de las [funciones duraderas](durable-functions.md), el entorno de ejecución incluye capacidades de administración automática de estados y creación de puntos de control. Los tiempos de ejecución son los entornos específicos del lenguaje en los que se ejecutan las funciones.
+ **[Eventos y desencadenadores](#gettingstarted-concepts-event)**: otros Servicios de AWS pueden invocan sus funciones en respuesta a eventos específicos. En el caso de las funciones duraderas, los eventos también pueden desencadenar la reanudación de los flujos de trabajo pausados.
+ **[Permisos y roles de Lambda](#gettingstarted-concepts-permissions)**: controle quién puede acceder a sus funciones y con qué otros Servicios de AWS pueden interactuar sus funciones. Las funciones duraderas requieren permisos adicionales para la gestión del estado y la ejecución prolongada.
**sugerencia**
Si desea comenzar por comprender el desarrollo sin servidor de manera más general, consulte [Comprensión de la diferencia entre el desarrollo tradicional y sin servidor](https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift-mindset.html) en la *Guía para desarrolladores de AWS sin servidor*.
## Funciones de Lambda y controladores de funciones
En Lambda, las **funciones** son los componentes básicos que se utilizan para crear aplicaciones. Una función de Lambda es una porción de código que se ejecuta en respuesta a eventos, como un usuario que hace clic en un botón de un sitio web o un archivo que se carga en un bucket de Amazon Simple Storage Service (Amazon S3). Gracias a las funciones duraderas, el código puede pausar la ejecución entre pasos y mantener el estado automáticamente, lo que las hace ideales para flujos de trabajo de larga duración, como el procesamiento de pedidos o la moderación de contenido. Una función es una especie de programa autónomo con las siguientes propiedades.
Un **controlador de la función** de Lambda es el método del código de la función que procesa eventos. Cuando una función se ejecuta en respuesta a un evento, Lambda ejecuta el controlador de la función. Los datos sobre el evento que provocó la ejecución de la función se transmiten directamente al controlador. Mientras que el código de una función de Lambda puede contener más de un método o función, las funciones de Lambda solo pueden tener un controlador.
Para crear una función de Lambda, se combinan el código de la función y sus dependencias en un paquete de implementación. Lambda admite dos tipos de paquetes de implementación: [archivos .zip](configuration-function-zip.md) e [imágenes de contenedores](images-create.md).
+ Cada función tiene un cometido u objetivo específico
+ Se ejecutan únicamente cuando es necesario en respuesta a eventos específicos
+ Se dejan de ejecutar automáticamente cuando terminan
## Tiempos de ejecución y entorno de ejecución de Lambda
Las funciones de Lambda se ejecutan en un *[entorno de ejecución](lambda-runtime-environment.md)* seguro y aislado que Lambda administra en su nombre. En el caso de las [funciones duraderas](durable-functions.md), el entorno de ejecución incluye componentes adicionales para la coordinación del flujo de trabajo y la administración del estado. El entorno de ejecución administra los procesos y recursos que se necesitan para ejecutar la función. Cuando se invoca una función por primera vez, Lambda crea un nuevo entorno de ejecución para que la función se ejecute en este. Una vez que la función termina de ejecutarse, Lambda no detiene el entorno de ejecución de inmediato; si la función se invoca de nuevo, Lambda puede reutilizar el entorno de ejecución existente.
El entorno de ejecución de Lambda también contiene un *tiempo de ejecución*, un entorno específico del lenguaje que transmite información de eventos y respuestas entre Lambda y la función. Lambda proporciona una serie de [tiempos de ejecución administrados](lambda-runtimes.md#runtimes-supported) para los lenguajes de programación más conocidos, o puede crear los suyos propios.
En el caso de los tiempos de ejecución administrados, Lambda aplica automáticamente actualizaciones y revisiones de seguridad a las funciones que utilizan el tiempo de ejecución.
## Eventos y desencadenadores
Además, puede invocar una función de Lambda directamente mediante la consola de Lambda, [AWS CLI](https://aws.amazon.com/cli/), o uno de los [kits de desarrollo de software (SDK) de AWS](https://aws.amazon.com/developer/tools/). Lo más habitual en una aplicación de producción es que su función sea invocada por otro Servicio de AWS en respuesta a un evento concreto. Por ejemplo, es posible que desee que una función se ejecute cada vez que se agregue un elemento a una tabla de Amazon DynamoDB.
Para que su función responda a los eventos, configure un **desencadenador**. Un desencadenador conecta su función a una fuente de eventos, y su función puede tener varios desencadenadores. Cuando se produce un evento, Lambda recibe los datos del evento como un documento JSON y los convierte en un objeto que su código puede procesar. Puede definir el siguiente formato JSON para su evento y el tiempo de ejecución de Lambda convierte este JSON en un objeto antes de pasarlo al controlador de su función.
**Example evento de Lambda personalizado**
```
{
"Location": "SEA",
"WeatherData":{
"TemperaturesF":{
"MinTempF": 22,
"MaxTempF": 78
},
"PressuresHPa":{
"MinPressureHPa": 1015,
"MaxPressureHPa": 1027
}
}
}
```
Los servicios de flujo y cola, como Amazon Kinesis o Amazon SQS, utilizan [asignaciones de orígenes de eventos](invocation-eventsourcemapping.md) en lugar de un activador estándar. Las asignaciones de orígenes de eventos sondean la fuente en busca de nuevos datos, agrupan los registros y, a continuación, invocan su función con los eventos agrupados. Para obtener más información, consulte [En qué se diferencian las asignaciones de orígenes de eventos de los desencadenadores directos](invocation-eventsourcemapping.md#eventsourcemapping-trigger-difference).
Para entender cómo funciona un desencadenador, comience completando el tutorial [Uso de un desencadenador de Amazon S3](with-s3-example.md), o para obtener una descripción general del uso de desencadenadores e instrucciones sobre cómo crear un desencadenador utilizando la consola de Lambda, consulte [Integración de otros servicios](lambda-services.md).
## Permisos y roles de Lambda
En el caso de Lambda, existen dos tipos principales de [permisos](permissions-granting-access.md) que debe configurar:
+ Permisos que la función necesita para acceder a otros Servicios de AWS
+ Permisos que otros usuarios y Servicios de AWS necesitan para acceder a la función
En las siguientes secciones se describen estos dos tipos de permisos y se analizan las prácticas recomendadas para aplicar los permisos de privilegio mínimo.
### Permisos para que las funciones accedan a otros recursos de AWS
Con frecuencia, las funciones de Lambda necesitan acceder a otros recursos de AWS y realizar acciones en estos. Por ejemplo, una función puede leer elementos de una tabla de DynamoDB, almacenar un objeto en un bucket de S3 o escribir en una cola de Amazon SQS. Para conceder a las funciones los permisos que necesitan para realizar estas acciones, se utiliza un *[rol de ejecución](lambda-intro-execution-role.md)*.
Un rol de ejecución de Lambda es un tipo especial de [rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) de AWS Identity and Access Management (IAM), una identidad que crea en la cuenta y que tiene asociados permisos específicos definidos en una *política*.
Cada función de Lambda debe tener un rol de ejecución, y un mismo rol puede ser utilizado por más de una función. Cuando se invoca una función, Lambda asume el rol de ejecución de la función y se le concede permiso para realizar las acciones definidas en la política del rol.
Al crear una función en la consola de Lambda, Lambda crea automáticamente un rol de ejecución para la función. La política del rol concede a la función permisos básicos para escribir salidas de registros en Registros de Amazon CloudWatch. Para conceder a la función permiso para realizar acciones en otros recursos de AWS, es necesario editar el rol para agregar los permisos adicionales. La forma más sencilla de agregar permisos es utilizar una [política administrada](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) por AWS. Las políticas administradas son creadas y administradas por AWS y proporcionan permisos para numerosos casos de uso habituales. Por ejemplo, si la función realiza operaciones CRUD en una tabla de DynamoDB, puede agregar la política [AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) al rol.
### Permisos para que otros usuarios y recursos accedan a la función
Para conceder permiso a otro Servicio de AWS para acceder a la función de Lambda, se utilizan *[políticas basadas en recursos](access-control-resource-based.md)*. En IAM, las políticas basadas en recursos se asocian a un recurso (en este caso, la función de Lambda) y definen tanto quién puede acceder al recurso como qué acciones puede realizar.
Para que otro Servicio de AWS invoque la función a través de un desencadenador, la política basada en recursos de la función debe conceder a dicho servicio permiso para utilizar la acción `lambda:InvokeFunction`. Si crea el desencadenador con la consola, Lambda agregará automáticamente este permiso en su nombre.
Para conceder permiso a otros usuarios de AWS para acceder a la función, puede definirlo en la política basada en recursos de la función exactamente del mismo modo que para otro Servicio de AWS o recurso. También puede utilizar una *[política basada en identidades](access-control-identity-based.md)* que esté asociada al usuario.
### Prácticas recomendadas para los permisos de Lambda
Cuando se establecen permisos mediante políticas de IAM, la [práctica recomendada en materia de seguridad](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) consiste en conceder únicamente los permisos necesarios para realizar una tarea. Esto se conoce como principio de *privilegio mínimo*. Para comenzar a conceder permisos para la función, puede optar por utilizar una política administrada por AWS. Las políticas administradas pueden ser la forma más rápida y sencilla de conceder permisos para realizar una tarea, pero es posible que también incluyan otros permisos que no sean necesarios. A medida que avance del desarrollo inicial a las pruebas y la producción, recomendamos que reduzca los permisos a únicamente aquellos que sean necesarios. Para ello, defina [políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) propias.
El mismo principio se aplica cuando se conceden permisos para acceder a la función mediante una política basada en recursos. Por ejemplo, si desea conceder permiso a Amazon S3 para invocar la función, la práctica recomendada consiste en limitar el acceso a buckets individuales o buckets en Cuentas de AWS específicas, en lugar de conceder permisos generales al servicio de S3.
# Ejecución de código con Lambda
Cuando escribe una función de Lambda, está creando código que se ejecutará en un entorno sin servidor único. Comprender cómo Lambda ejecuta realmente el código implica dos aspectos clave: el modelo de programación que define la forma en que el código interactúa con Lambda, y el ciclo de vida del entorno de ejecución que determina cómo Lambda gestiona el entorno del tiempo de ejecución del código.
## El modelo de programación de Lambda
El modelo de programación funciona como un conjunto común de reglas sobre cómo Lambda trabaja con su código, independientemente de si está escribiendo en Python, Java o cualquier otro lenguaje compatible. El modelo de programación incluye el tiempo de ejecución y el controlador.
**En el caso de funciones estándar:**
1. Lambda recibe un evento.
1. Lambda utiliza el tiempo de ejecución para preparar el evento en un formato que pueda usar el código.
1. El tiempo de ejecución envía el evento formateado a su controlador.
1. Su controlador procesa el evento mediante el código que ha escrito.
**En el caso de funciones duraderas:**
1. Lambda recibe un evento.
1. El tiempo de ejecución prepara tanto el evento como DurableContext.
1. El controlador puede realizar lo siguiente:
+ Procesar los pasos con creación automática de puntos de control.
+ Pausar la ejecución sin consumir recursos.
+ Continuar desde el último punto de control exitoso.
+ Mantener el estado entre pasos.
Un elemento esencial de este modelo es el *controlador*, donde Lambda envía los eventos para que los procese su código. Considérelo como el punto de entrada a su código. Cuando Lambda recibe un evento, pasa este evento y parte de la información de contexto a su controlador. A continuación, el controlador ejecuta su código para procesar estos eventos; por ejemplo, puede leer un archivo cuando se carga en Amazon S3, analizar una imagen o actualizar una base de datos. Una vez que su código termina de procesar un evento, el controlador está listo para procesar el siguiente.
## El modelo de ejecución de Lambda
Mientras que el modelo de programación define cómo Lambda interactúa con su código, el entorno de ejecución es donde Lambda realmente ejecuta la función: es un espacio de cómputo seguro y aislado creado específicamente para su función.
**Cada entorno sigue un ciclo de vida que varía entre funciones estándar y duraderas:**
**Funciones estándar (hasta 15 minutos):**
1. **Inicialización:** configuración del entorno y carga de código.
1. **Invocación:** ejecución única del código de la función.
1. **Cierre:** limpieza del entorno.
**Funciones duraderas (hasta 1 año):**
1. **Inicialización:** configuración de entorno y estado duradero.
1. **Invocación:** varios pasos con creación automática de puntos de control.
1. **Estados de espera:** pausan la ejecución sin consumir recursos.
1. **Reanudación:** reinicia desde el último punto de control.
1. **Cierre:** limpieza del estado duradero.
Este entorno gestiona aspectos importantes de la ejecución de su función. Proporciona memoria a la función y un directorio `/tmp` para el almacenamiento temporal. **En el caso de las funciones duraderas, también administra lo siguiente:**
+ Persistencia automática del estado entre pasos
+ Almacenamiento y recuperación de puntos de control
+ Coordinación del estado de espera
+ Seguimiento del progreso en las ejecuciones de larga duración
# Comprensión del modelo de programación de Lambda
Lambda ofrece dos modelos de programación: funciones estándar que se ejecutan durante 15 minutos como máximo y funciones duraderas que pueden ejecutarse durante 1 año como máximo. Si bien ambos comparten conceptos básicos, las funciones duraderas añaden capacidades para flujos de trabajo con estado y de larga duración.
Lambda proporciona un modelo de programación que es común a todos los tiempos de ejecución. El modelo de programación define la interfaz entre el código y el sistema de Lambda. Le indica a Lambda el punto de entrada a la función al definir un *controlador* en la configuración de la función. El runtime se pasa en forma de objetos al controlador que contiene el *evento* de invocación y el *contexto*, como el nombre de la función y el ID de la solicitud.
**En el caso de las funciones duraderas, el controlador también recibe un objeto DurableContext que proporciona lo siguiente:**
+ Capacidades de creación de puntos de control mediante step()
+ Administración del estado de espera mediante wait() y waitForCallback()
+ Persistencia automática del estado entre invocaciones
Cuando el controlador termina de procesar el primer evento, el runtime le envía otro. En el caso de las funciones duraderas, el controlador puede pausar la ejecución entre pasos, y Lambda guardará y restaurará el estado automáticamente cuando se reanude la función. La clase de la función permanece en la memoria, por lo que se pueden reutilizar los clientes y las variables declarados fuera del método del controlador en *código de inicialización*. Para ahorrar tiempo de procesamiento en eventos posteriores, cree recursos reutilizables como clientes AWSSDK durante la inicialización. Una vez inicializada, cada instancia de su función puede procesar miles de solicitudes.
La función también tiene acceso al almacenamiento local en el directorio de `/tmp`, una caché transitoria que se puede utilizar para múltiples invocaciones. Para obtener más información, consulte [Entorno de ejecución](lambda-runtime-environment.md).
Cuando se habilita el [seguimiento de AWS X-Ray](services-xray.md), el tiempo de ejecución registra subsegmentos separados para la inicialización y la ejecución.
El tiempo de ejecución captura la salida de registro de la función y la envía a Amazon CloudWatch Logs. Además de registrar la salida de la función, el tiempo de ejecución también registra las entradas cuando comienza y finaliza la invocación. Esto incluye un registro de informe con el ID de solicitud, la duración facturada, la duración de inicialización y otros detalles. Si la función genera un error, el runtime devuelve ese error al invocador.
**nota**
El registro está sujeto a [Cuotas de CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html). Los datos de registro se pueden perder debido a una limitación controlada o, en algunos casos, cuando se detiene una instancia de su función.
**Diferencias clave con funciones duraderas:**
+ El estado se mantiene automáticamente entre los pasos.
+ Las funciones pueden pausar la ejecución sin consumir recursos.
+ Los pasos se reintentan automáticamente en caso de error.
+ Se sigue el progreso a través de puntos de control.
Lambda escala la función ejecutando instancias adicionales a medida que aumenta la demanda y deteniendo instancias a medida que disminuye la demanda. Este modelo conduce a variaciones en la arquitectura de la aplicación, por ejemplo:
+ A menos que se indique lo contrario, las solicitudes entrantes pueden procesarse de forma desordenada o simultánea.
+ Almacene el estado de la aplicación en otra parte; no confíe en que las instancias de la función tendrán una larga vida útil.
+ Utilice el almacenamiento local y los objetos de nivel de clase para aumentar el rendimiento, pero mantenga al mínimo el tamaño del paquete de implementación y la cantidad de datos que transfiere al entorno de ejecución.
Para obtener una introducción práctica sobre estos conceptos en su lenguaje de programación preferido, consulte los siguientes capítulos.
+ [Creación de funciones de Lambda con Node.js](lambda-nodejs.md)
+ [Creación de funciones de Lambda con Python](lambda-python.md)
+ [Creación de funciones de Lambda con Ruby](lambda-ruby.md)
+ [Creación de funciones de Lambda con Java](lambda-java.md)
+ [Creación de funciones de Lambda con Go](lambda-golang.md)
+ [Creación de funciones Lambda con C\$1](lambda-csharp.md)
+ [Creación de funciones de Lambda con PowerShell](lambda-powershell.md)
# Comprender el ciclo de vida del entorno de ejecución de Lambda
Los entornos de ejecución Lambda admiten funciones estándar (hasta 15 minutos) y funciones duraderas (hasta 1 año). Si bien ambos tipos de funciones comparten el mismo ciclo de vida básico, las funciones duraderas añaden capacidades de administración del estado para flujos de trabajo de larga duración.
Lambda invoca la función en un entorno de ejecución, que proporciona un entorno en tiempo de ejecución seguro y aislado. El entorno de ejecución administra los recursos necesarios para ejecutar la función. El entorno de ejecución también proporciona compatibilidad del ciclo de vida para el tiempo de ejecución de la función y cualquier [extensión externa](lambda-extensions.md) asociada a la función.
**En el caso de las funciones duraderas, el entorno de ejecución incluye componentes adicionales para lo siguiente:**
+ Persistencia del estado entre pasos
+ Administración de creación de puntos de control
+ Coordinación del estado de espera
+ Seguimiento del progreso
**Entorno de ejecución de instancias administradas de Lambda**
Si utiliza [instancias administradas de Lambda](lambda-managed-instances-execution-environment.md), el entorno de ejecución presenta diferencias importantes en comparación con las funciones de Lambda (predeterminadas). Las instancias administradas admiten invocaciones simultáneas, utilizan un modelo de ciclo de vida diferente y se ejecutan en una infraestructura propiedad del cliente. Para obtener información detallada sobre el entorno de ejecución de las instancias administradas, consulte [Descripción del entorno de ejecución de instancias administradas de Lambda](lambda-managed-instances-execution-environment.md).
El tiempo de ejecución de la función de Lambda se comunica con la [API de tiempo de ejecución](runtimes-api.md). Las extensiones se comunican con Lambda mediante la [API de extensiones](runtimes-extensions-api.md). Las extensiones también pueden recibir mensajes de registro y otros datos de telemetría de la función mediante la [API de telemetría](telemetry-api.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)
Al crear una función de Lambda, se debe especificar información de configuración, como la cantidad de memoria y el tiempo máximo de ejecución asignados a su función. Lambda utiliza esta información para configurar el entorno de ejecución.
El tiempo de ejecución de la función y cada extensión externa son procesos que se ejecutan dentro del entorno de ejecución. Los permisos, recursos, credenciales y variables de entorno se comparten entre la función y las extensiones.
**Topics**
+ [
## Ciclo de vida del entorno de ejecución de Lambda
](#runtimes-lifecycle)
+ [
## Latencia y arranques en frío
](#cold-start-latency)
+ [
## Reducción de los arranques en frío con simultaneidad aprovisionada
](#cold-starts-pc)
+ [
## Optimización de la inicialización estática
](#static-initialization)
## Ciclo de vida del entorno de ejecución de Lambda
![\[Fases del ciclo de vida de Lambda: Init, Invoke, Shutdown\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/Overview-Successful-Invokes.png)
Cada fase comienza con un evento que Lambda envía al tiempo de ejecución y a todas las extensiones registradas. El tiempo de ejecución y cada extensión registrada indica la finalización mediante el envío de una solicitud API `Next`. Lambda congela el entorno de ejecución cuando el tiempo de ejecución y cada extensión se han completado y no hay eventos pendientes.
**Las fases del ciclo de vida de las funciones duraderas incluyen lo siguiente:**
+ **Inicio:** inicialización estándar más configuración de estado duradero.
+ **Invocación:** puede incluir ejecuciones en varios pasos con creación automática de puntos de control.
+ **Espera:** la función puede pausar la ejecución sin consumir recursos.
+ **Reanudación:** la función se reinicia desde el último punto de control.
+ **Cierre:** limpieza del estado duradero y los recursos.
**Topics**
+ [
### Fase "init"
](#runtimes-lifecycle-ib)
+ [
### Errores durante la fase Init
](#runtimes-lifecycle-init-errors)
+ [
### Fase Restore (solo Lambda SnapStart)
](#runtimes-lifecycle-restore)
+ [
### Fase "invoke"
](#runtimes-lifecycle-invoke)
+ [
### Errores durante la fase Invoke
](#runtimes-lifecycle-invoke-with-errors)
+ [
### Fase "shutdown"
](#runtimes-lifecycle-shutdown)
### Fase "init"
En la fase `Init`, Lambda realiza tres tareas:
+ Comenzar todas las extensiones (`Extension init`)
+ Bootstrap del tiempo de ejecución (`Runtime init`)
+ Ejecutar el código estático de la función (`Function init`)
+ Ejecute cualquier [enlace de tiempo de ejecución](snapstart-runtime-hooks.md) antes del punto de comprobación (solo Lambda SnapStart)
La fase `Init` finaliza cuando el tiempo de ejecución y todas las extensiones señalan que están listas mediante el envío de una solicitud `Next` a la API. La fase `Init` está limitada a 10 segundos. Si las tres tareas no se completan en 10 segundos, Lambda vuelve a intentar la fase `Init` en el momento de la primera invocación de la función con el tiempo de espera de la función configurado.
Si [Lambda SnapStart](snapstart.md) está activada, la fase `Init` ocurre cuando publica una versión de la función. Lambda guarda una instantánea del estado de la memoria y del disco del entorno de ejecución iniciado, conserva la instantánea cifrada y la almacena en caché para acceder a ella con baja latencia. Si tiene un [enlace de tiempo de ejecución](snapstart-runtime-hooks.md) antes del punto de comprobación, el código se ejecuta al final de la fase `Init`.
**nota**
El tiempo de espera de 10 segundos no se aplica a las funciones que utilizan la concurrencia aprovisionada, SnapStart o las instancias administradas de Lambda. Para la concurrencia aprovisionada, SnapStart y las funciones de las instancias administradas, el código de inicialización puede ejecutarse durante un máximo de 15 minutos. El límite de tiempo es de 130 segundos o el tiempo de espera de la función configurado (máximo de 900 segundos), lo que sea mayor.
Cuando utiliza la [simultaneidad aprovisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html), Lambda inicializa el entorno de ejecución al configurar los ajustes del equipo para una función. Lambda también garantiza que los entornos de ejecución inicializados se encuentren siempre disponibles antes de las invocaciones. Es posible que vea intervalos entre las fases de inicialización e invocación de la función. Dependiendo del tiempo de ejecución y la configuración de memoria de su función, es posible que también vea variabilidad de latencia en la primera invocación en un entorno de ejecución inicializado.
En el caso de las funciones que utilizan la simultaneidad bajo demanda, Lambda puede, en ocasiones, inicializar los entornos de ejecución antes de las solicitudes de invocación. Cuando esto ocurre, también puede observar un intervalo de tiempo entre las fases de inicialización e invocación de la función. Se recomienda que no dependa de este comportamiento.
### Errores durante la fase Init
Si una función se bloquea o agota el tiempo de espera durante la fase `Init`, Lambda emite la información sobre el error en el registro `INIT_REPORT`.
**Example — Registro INIT\$1REPORT para el tiempo de espera**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
```
**Example — Registro INIT\$1REPORT para un error en la extensión**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash
```
Si la fase de `Init` se realiza correctamente, Lambda no emite el registro de `INIT_REPORT` a menos que [SnapStart](snapstart.md) o la [simultaneidad aprovisionada](provisioned-concurrency.md) estén habilitados. Las funciones SnapStart y de simultaneidad aprovisionada siempre emiten `INIT_REPORT`. Para obtener más información, consulte [Monitoreo para Lambda SnapStart](snapstart-monitoring.md).
### Fase Restore (solo Lambda SnapStart)
Cuando se invoca por primera vez una función [SnapStart](snapstart.md) y, a medida que la función escala, Lambda vuelve a activar los nuevos entornos de ejecución a partir de la instantánea conservada, en lugar de activar la función desde cero. Si tiene un [enlace de tiempo de ejecución](snapstart-runtime-hooks.md) posterior a la restauración, el código se ejecuta al final de la fase `Restore`. Se le cobrará por la duración de los enlaces de tiempo de ejecución posteriores a la restauración. El tiempo de ejecución debe cargarse, y los enlaces del tiempo de ejecución posteriores a la restauración deben completarse antes de que transcurra el tiempo de espera (10 segundos). De lo contrario, obtendrá una excepción SnapStartTimeoutException. Cuando se completa la fase `Restore`, Lambda invoca el controlador de funciones (la fase [Fase "invoke"](#runtimes-lifecycle-invoke)).
#### Errores durante la fase de Restauración
Si la fase `Restore` falla, Lambda emite la información sobre el error en el registro `RESTORE_REPORT`.
**Example — Registro RESTORE\$1REPORT para el tiempo de espera**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
```
**Example — Registro RESTORE\$1REPORT para errores en el enlace del tiempo de ejecución**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError
```
Para obtener más información sobre el registro `RESTORE_REPORT`, consulte [Monitoreo para Lambda SnapStart](snapstart-monitoring.md).
### Fase "invoke"
Cuando se invoca una función de Lambda en respuesta a una solicitud API `Next`, Lambda envía un evento `Invoke` al tiempo de ejecución y a cada extensión.
La configuración de tiempo de espera de la función limita la duración de toda la fase `Invoke`. Por ejemplo, si establece el tiempo de espera de la función en 360 segundos, la función y todas las extensiones deben completarse en 360 segundos. Tenga en cuenta que no hay una fase posterior a "invoke" independiente. La duración es la suma de todo el tiempo de invocación (tiempo de ejecución \$1 extensiones) y no se calcula hasta que la función y todas las extensiones han terminado la ejecución.
La fase "invoke" finaliza después de que el tiempo de ejecución y todas las extensiones indiquen que se han terminado mediante el envío de una solicitud `Next` a la API.
### Errores durante la fase Invoke
Si la función Lambda se bloquea o agota el tiempo de espera durante la fase `Invoke`, Lambda restablece el entorno de ejecución. El siguiente diagrama ilustra el comportamiento del entorno de ejecución de Lambda cuando se produce un error de invocación:
![\[Ejemplo de entorno de ejecución: Init, Invoke, Invoke with Error, Invoke, Shutdown\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
En el diagrama anterior:
+ La primera fase es la fase **INIT**, que se ejecuta sin errores.
+ La segunda fase es la fase **INVOKE**, que se ejecuta sin errores.
+ En algún momento, supongamos que tu función sufre un error de invocación (las causas más comunes incluyen tiempos de espera de la función, errores de tiempo de ejecución, agotamiento de la memoria, problemas de conectividad de la VPC, errores de permisos, límites de simultaneidad y varios problemas de configuración). Para obtener una lista completa de posibles errores de invocación, consulta [Solucionar problemas de invocación en Lambda](troubleshooting-invocation.md). La tercera fase, denominada **INVOKE WITH ERROR**, ilustra este escenario. Cuando esto sucede, el servicio de Lambda efectúa un reinicio. El restablecimiento se comporta como un evento `Shutdown`. Primero, Lambda apaga el tiempo de ejecución, luego envía un evento `Shutdown` a cada extensión externa registrada. El evento incluye el motivo del apagado. Si este entorno se utiliza para una nueva invocación, Lambda reinicia la extensión y el tiempo de ejecución juntos como parte de la siguiente invocación.
Tenga en cuenta que el restablecimiento de Lambda no borra el contenido del directorio `/tmp` antes de la siguiente fase Init. Este comportamiento es coherente con la fase de apagado regular.
**nota**
AWS está implementando cambios en el servicio Lambda. Debido a estos cambios, es posible que vea pequeñas diferencias entre la estructura y el contenido de los mensajes de registro del sistema y los segmentos de rastreo emitidos por diferentes funciones de Lambda en su Cuenta de AWS.
Si la configuración de registro del sistema de su función está configurada como texto sin formato, este cambio afectará a los mensajes de registro capturados en CloudWatch Logs cuando su función experimente un error de invocación. En los siguientes ejemplos, se muestran los resultados de los registros en formatos antiguos y nuevos.
Estos cambios se implementarán en las próximas semanas, y todas las funciones en todas las Regiones de AWS, excepto en las regiones de China y GovCloud, pasarán a utilizar el nuevo formato de mensajes de registro y segmentos de rastreo.
**Example Resultado del Registro de CloudWatch (bloqueo de la extensión o el tiempo de ejecución): estilo antiguo**
```
START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
```
**Example Resultado del Registro de CloudWatch (se acabó el tiempo de espera de la función): estilo antiguo**
```
START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3117 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms
```
El nuevo formato de los registros de CloudWatch incluye un campo `status` adicional en la línea `REPORT`. En caso de que se bloquee la extensión o el tiempo de ejecución, la línea `REPORT` también incluye un campo `ErrorType`.
**Example Resultado del Registro de CloudWatch (bloqueo de la extensión o el tiempo de ejecución): estilo nuevo**
```
START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 214 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError
```
**Example Resultado del Registro de CloudWatch (se acabó el tiempo de espera de la función): estilo nuevo**
```
START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3101 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout
```
+ La cuarta fase representa la fase de **INVOKE** que sigue de inmediato a un error de invocación. Aquí, Lambda vuelve a inicializar el entorno al volver a ejecutar la fase **INIT**. Esto se denomina *inicio suprimido*. Cuando se producen inicializaciones suprimidas, Lambda no informa explícitamente de una fase **INIT** adicional en Registros de CloudWatch. En cambio, puede observar que la duración de la línea INFORME incluye una duración **INIT** adicional \$1 la duración de **INVOKE**. Por ejemplo, supongamos que visualiza los siguientes registros en CloudWatch:
```
2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST
2022-12-20T01:00:02.500-08:00 END RequestId: XXX
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB
```
En este ejemplo, la diferencia entre las marcas de tiempo de INFORME e INICIO es de 2,5 segundos. Esto no coincide con la duración reportada de 3022,91 milisegundos, porque no tiene en cuenta el tiempo **INIT** adicional (inicio suprimido) que realizó Lambda. En este ejemplo, puede inferir que la fase de **INVOKE** real tardó 2,5 segundos.
Para obtener más información sobre este comportamiento, puede utilizar la [Acceso a datos de telemetría en tiempo real para extensiones mediante la API de telemetría](telemetry-api.md). La API de telemetría emite eventos de `INIT_START`, `INIT_RUNTIME_DONE` y `INIT_REPORT` con `phase=invoke` siempre que se supriman inicializaciones entre las fases de invocación.
+ La quinta fase representa la fase **SHUTDOWN**, que se ejecuta sin errores.
### Fase "shutdown"
Cuando Lambda está a punto de cerrar el tiempo de ejecución, envía un evento `Shutdown` a cada extensión externa registrada. Las extensiones pueden utilizar este tiempo para las tareas de limpieza finales. El evento `Shutdown` es una respuesta a una solicitud `Next` a la API.
**Límite de duración**: la duración máxima de la fase `Shutdown` depende de la configuración de las extensiones registradas:
+ 0 ms: una función sin extensiones registradas
+ 500 ms: una función con una extensión interna registrada.
+ 2000 ms: una función con una o más extensiones externas registradas.
Si el tiempo de ejecución o una extensión no responde al evento `Shutdown` dentro del límite, Lambda termina el proceso mediante una señal `SIGKILL`.
Después de que la función y todas las extensiones se hayan completado, Lambda mantiene el entorno de ejecución durante algún tiempo en previsión de otra invocación de función. Sin embargo, Lambda finaliza los entornos de ejecución cada pocas horas para permitir las actualizaciones y el mantenimiento del tiempo de ejecución, incluso para las funciones que se invocan de forma continua. No debe suponer que el entorno de ejecución durará de manera indefinida. Para obtener más información, consulte [Implementación de la ausencia de estado en las funciones](concepts-application-design.md#statelessness-functions).
Cuando se invoca de nuevo la función, Lambda descongela el entorno para su reutilización. La reutilización del entorno de ejecución tiene las siguientes implicaciones:
+ Los objetos declarados fuera del método del controlador de la función permanecen inicializados, lo que proporciona una optimización adicional cuando la función se invoca de nuevo. Por ejemplo, si la función de Lambda establece una conexión con una base de datos, en lugar de volver a establecer la conexión, se utiliza la conexión original en posteriores invocaciones. Le recomendamos que agregue lógica al código para comprobar si existe una conexión antes de crear una nueva.
+ Cada entorno de ejecución proporciona entre 512 MB y 10 240 MB en incrementos de 1 MB de espacio en disco en el directorio de `/tmp`. El contenido del directorio se conserva al congelar el entorno de ejecución, proporcionando una caché transitoria que se puede utilizar para varias invocaciones. Puede agregar código adicional para comprobar si la caché dispone de los datos que se almacenaron. Para obtener más información sobre los límites de tamaño de implementación, consulte [Cuotas de LambdaCuotas de Lambda](gettingstarted-limits.md).
+ Los procesos en segundo plano o devoluciones de llamada iniciados por la función de Lambda y no completados cuando la función finalizó se reanudan si reutiliza el entorno de ejecución. Asegúrese de que los procesos en segundo plano o las devoluciones de llamada del código se completen antes de que este finalice.
## Latencia y arranques en frío
Cuando Lambda recibe una solicitud para ejecutar una función mediante la API de Lambda, el servicio primero prepara un entorno de ejecución. Durante esta fase de inicialización, el servicio descarga el código, inicia el entorno y ejecuta cualquier código de inicialización fuera del controlador principal. Por último, Lambda ejecuta el código del controlador.
![\[optimización del rendimiento (figura 1)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/perf-optimize-figure-1.png)
En este diagrama, los dos primeros pasos de descarga del código y configuración del entorno se denominan generalmente “arranque en frío”. Se [cobra por este tiempo](https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/), y se agrega latencia a la duración total de la invocación.
Una vez finalizada la invocación, el entorno de ejecución se congelará. Para mejorar la administración de recursos y el rendimiento, Lambda retiene el entorno de ejecución durante un periodo. Durante este tiempo, si llega otra solicitud para la misma función, Lambda puede reutilizar el entorno. Esta segunda solicitud normalmente finaliza más rápido, puesto que el entorno de ejecución ya se encuentra plenamente configurado. Esto se denomina “arranque en caliente”.
Los arranques en frío por lo general se producen en menos del 1 % de las invocaciones. La duración de un arranque en frío varía desde menos de 100 ms hasta más de 1 segundo. Normalmente, los arranques en frío son más habituales en las funciones de desarrollo y pruebas que en las cargas de trabajo de producción. Esto se debe a que las funciones de desarrollo y prueba suelen invocarse con menos frecuencia.
## Reducción de los arranques en frío con simultaneidad aprovisionada
Si necesita tiempos de inicio de función predecibles para la carga de trabajo, la [simultaneidad aprovisionada](provisioned-concurrency.md) resulta la solución recomendada para garantizar la menor latencia posible. Esta función preinicializa los entornos de ejecución, lo que reduce los arranques en frío.
Por ejemplo, una función con una simultaneidad aprovisionada de 6 tiene 6 entornos de ejecución precalentados.
![\[optimización del rendimiento (figura 4)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/perf-optimize-figure-4.png)
## Optimización de la inicialización estática
La inicialización estática se produce antes de que el código del controlador comience a ejecutarse en una función. Este es el código de inicialización que deberá proporcionar, que se encuentra fuera del controlador principal. Este código se utiliza con frecuencia para importar bibliotecas y dependencias, realizar configuraciones e inicializar conexiones con otros servicios.
El siguiente ejemplo de Python muestra la importación y configuración de módulos y la creación del cliente de Amazon S3 durante la fase de inicialización, antes de que la función `lambda_handler` se ejecute durante la invocación.
```
import os
import json
import cv2
import logging
import boto3
s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
# Handler logic...
```
El factor que más contribuye a la latencia antes de la ejecución de una función corresponde al código de inicialización. Este código se ejecuta cuando un nuevo entorno de ejecución se crea por primera vez. El código de inicialización no se vuelve a ejecutar si la invocación utiliza un entorno de ejecución en caliente. Estos son algunos de los factores que afectan a la latencia del código de inicialización:
+ El tamaño del paquete de funciones, en términos de bibliotecas y dependencias importadas y capas de Lambda.
+ La cantidad de código y el trabajo de inicialización.
+ El rendimiento de las bibliotecas y otros servicios a la hora de configurar las conexiones y otros recursos.
Los desarrolladores pueden tomar una serie de medidas para optimizar la latencia de inicialización estática. Si una función tiene muchos objetos y conexiones, es posible que pueda rediseñar una sola función para convertirla en varias funciones especializadas. Estos son más pequeños individualmente y cada uno tiene menos código de inicialización.
Es importante que las funciones solo importen las bibliotecas y dependencias que necesiten. Por ejemplo, si solo usa Amazon DynamoDB en el AWS SDK, puede necesitar un servicio individual en lugar de todo el SDK. Compare los tres ejemplos siguientes:
```
// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')
// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')
// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)
```
La inicialización estática también suele ser el mejor lugar para abrir las conexiones de bases de datos y permitir que una función pueda reutilizar las conexiones en múltiples invocaciones en el mismo entorno de ejecución. Sin embargo, es posible que tenga un gran número de objetos que solo se utilicen en determinadas rutas de ejecución de la función. En este caso, puede cargar variables de forma lenta en el ámbito global para reducir la duración de la inicialización estática.
Evite las variables globales para la información específica del contexto. Si su función tiene una variable global que se usa solo durante la duración de una única invocación y se restablece para la siguiente invocación, use un ámbito de variable que sea local para el controlador. Esto no solo evita las filtraciones de variables globales entre las invocaciones, sino que también mejora el rendimiento de la inicialización estática.
# Creación de arquitecturas basadas en eventos con Lambda
Un evento es cualquier cosa que desencadene la ejecución de una función de Lambda. Hay dos formas en las que los eventos pueden activar una función de Lambda: mediante la invocación directa (enviar) y mediante las asignaciones de orígenes de eventos (extraer).
Varios servicios de AWS pueden invocar directamente las funciones de Lambda. Estos servicios *envían* eventos a la función de Lambda. Los eventos que activan funciones pueden ser casi cualquier cosa, desde una solicitud HTTP a través de API Gateway, una programación administrada por una regla de EventBridge, un evento de AWS IoT o de Amazon S3. Con la asignación de orígenes de eventos, Lambda busca (o *extrae*) eventos de forma activa de una cola o flujo. Configure Lambda para comprobar los eventos de un servicio compatible y Lambda se encarga del sondeo y la invocación de su función.
Cuando se transmiten a la función, los eventos están estructurados en formato JSON. La estructura JSON varía en función del servicio que lo genera y del tipo de evento. Si bien las invocaciones de funciones de Lambda estándar pueden durar hasta 15 minutos (o hasta 1 año con las [funciones duraderas](durable-functions.md)), Lambda es más adecuada para invocaciones breves que duren un segundo o menos. Esto es especialmente cierto en el caso de arquitecturas basada en eventos, en donde cada función de Lambda se trata como un microservicio responsable de ejecutar un conjunto limitado de instrucciones específicas.
**nota**
Las arquitecturas basadas en eventos se comunican entre diferentes sistemas mediante redes, que introducen una latencia variable. Para las cargas de trabajo que requieren una latencia muy baja, como los sistemas de negociación en tiempo real, este diseño puede que no sea la mejor opción. Sin embargo, para cargas de trabajo altamente escalables y disponibles, o aquellas con patrones de tráfico impredecibles, las arquitecturas basadas en eventos pueden proporcionar una forma eficaz de satisfacer estas demandas.
**Topics**
+ [
## Ventajas de las arquitecturas basadas en eventos
](#event-driven-benefits)
+ [
## Desventajas de las arquitecturas basadas en eventos
](#event-driven-tradeoffs)
+ [
## Antipatrones en aplicaciones basadas en eventos de Lambda
](#event-driven-anti-patterns)
## Ventajas de las arquitecturas basadas en eventos
Lambda admite dos métodos de invocación en arquitecturas basadas en eventos:
1. Invocación directa (método de envío): los servicios de AWS desencadenan directamente las funciones de Lambda. Por ejemplo:
+ Amazon S3 desencadena una función cuando se carga un archivo
+ API Gateway desencadena una función cuando recibe una solicitud HTTP
1. Asignación de orígenes de eventos (método de extracción): Lambda recupera eventos e invoca funciones. Por ejemplo:
+ Lambda recupera mensajes de una cola de Amazon SQS e invoca una función
+ Lambda lee los registros de un flujo de DynamoDB e invoca una función
Ambos métodos contribuyen a las ventajas de las arquitecturas basadas en eventos, tal como se describe a continuación.
### Sustitución de los sondeos y los webhooks con eventos
Muchas arquitecturas tradicionales utilizan mecanismos de sondeo y webhook para comunicar el estado entre los diferentes componentes. El sondeo puede resultar muy ineficiente a la hora de obtener actualizaciones, ya que hay un desfase entre la disponibilidad de nuevos datos y la sincronización con los servicios posteriores. Los webhooks no siempre son compatibles con otros microservicios con los que desea integrarse. También puede que requieran configuraciones personalizadas de autorización y autenticación. En ambos casos, estos métodos de integración son difíciles de escalar bajo demanda sin trabajo adicional por parte de los equipos de desarrollo.
![\[arquitecturas basadas en eventos figura 7\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-7.png)
Ambos mecanismos se pueden reemplazar por eventos, que se pueden filtrar, enrutar y transferir a los microservicios que consumen. Este enfoque puede reducir el consumo de ancho de banda y la utilización de la CPU y, potencialmente, reducir los costos. Estas arquitecturas también pueden reducir la complejidad, ya que cada unidad funcional es más pequeña y, a menudo, hay menos código.
![\[arquitecturas basadas en eventos figura 8\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-8.png)
Las arquitecturas basadas en eventos también pueden facilitar el diseño de sistemas prácticamente en tiempo real, lo que ayuda a las organizaciones a dejar de lado el procesamiento por lotes. Los eventos se generan en el momento en que cambia el estado de la aplicación, por lo que el código personalizado de un microservicio debe diseñarse para gestionar el procesamiento de un solo evento. Dado que el escalado lo gestiona el servicio de Lambda, esta arquitectura puede gestionar aumentos significativos del tráfico sin cambiar el código personalizado. A medida que los eventos se escalan verticalmente, también lo hace la capa de cómputo que procesa los eventos.
### Reducción de la complejidad
Los microservicios permiten a los desarrolladores y arquitectos simplificar flujos de trabajo complejos. Por ejemplo, un monolito del comercio electrónico puede dividirse en procesos de aceptación de pedidos y pago con servicios independientes de inventario, logística y contabilidad. Lo que puede resultar complejo de administrar y orquestar en un monolito se convierte en una serie de servicios disociados que se comunican de forma asíncrona con los eventos.
![\[arquitecturas basadas en eventos figura 9\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-9.png)
Este enfoque también permite reunir servicios que procesan datos a diferentes velocidades. En este caso, un microservicio de aceptación de pedidos puede almacenar grandes volúmenes de pedidos entrantes almacenando los mensajes en una cola de Amazon SQS.
Un servicio de procesamiento de pagos, que suele ser más lento debido a la complejidad de la gestión de los pagos, puede recibir un flujo constante de mensajes de la cola de Amazon SQS. Puede orquestar una lógica compleja de reintentos y gestión de errores mediante AWS Step Functions, así como coordinar los flujos de trabajo de pago activos para cientos de miles de pedidos.
**Enfoque alternativo:** para la orquestación mediante lenguajes de programación estándar, puede utilizar [funciones duraderas de Lambda](durable-functions.md). Las funciones duraderas permiten escribir en código la lógica de aceptación de pedidos, procesamiento de pagos y notificaciones mediante puntos de control automáticos y reintentos. Este enfoque resulta adecuado cuando el flujo de trabajo se basa principalmente en funciones de Lambda y se prefiere mantener la lógica de orquestación en el código.
### Mejora de la escalabilidad y la extensibilidad
Los microservicios generan eventos que normalmente se publican en servicios de mensajería como Amazon SNS y Amazon SQS. Se comportan como un búfer elástico entre los microservicios y ayudan a gestionar el escalado cuando aumenta el tráfico. De este modo, servicios como Amazon EventBridge pueden filtrar y enrutar los mensajes en función del contenido del evento, tal y como se define en las reglas. Como resultado, las aplicaciones basadas en eventos pueden ser más escalables y ofrecer una mayor redundancia que las aplicaciones monolíticas.
Este sistema también es muy extensible, lo que permite a otros equipos ampliar las características y agregar funciones sin afectar a los microservicios de procesamiento de pedidos y pagos. Al publicar eventos mediante EventBridge, esta aplicación se integra con los sistemas existentes, como el microservicio de inventario, pero también permite que cualquier aplicación futura se integre como consumidor de eventos. Los productores de eventos no conocen a los consumidores de eventos, lo que puede ayudar a simplificar la lógica de los microservicios.
## Desventajas de las arquitecturas basadas en eventos
### Latencia variable
A diferencia de las aplicaciones monolíticas, que pueden procesar todo lo que esté dentro del mismo espacio de memoria en un solo dispositivo, las aplicaciones basadas en eventos se comunican entre redes. Este diseño introduce una latencia variable. Si bien es posible diseñar aplicaciones para minimizar la latencia, las aplicaciones monolíticas casi siempre se pueden optimizar para reducir la latencia a expensas de la escalabilidad y la disponibilidad.
Las cargas de trabajo que requieren un rendimiento uniforme con baja latencia, como las aplicaciones de operaciones bursátiles de alta frecuencia en bancos o la automatización robótica con tiempos inferiores a un milisegundo en almacenes, no son buenos candidatos para arquitecturas basadas en eventos.
### Consistencia final
Un evento representa un cambio de estado y, dado que muchos eventos fluyen a través de diferentes servicios de una arquitectura en un momento dado, dichas cargas de trabajo suelen ser [coherentes en el tiempo](https://en.wikipedia.org/wiki/Eventual_consistency). Esto hace que sea más complejo procesar las transacciones, gestionar los duplicados o determinar el estado general exacto de un sistema.
Algunas cargas de trabajo contienen una combinación de requisitos que, en última instancia, son coherentes (por ejemplo, el total de pedidos en la hora actual) o muy coherentes (por ejemplo, el inventario actual). Para las cargas de trabajo que requieren una sólida coherencia de datos, existen patrones de arquitectura diseñados para respaldarla. Por ejemplo:
+ DynamoDB puede proporcionar [lecturas altamente coherentes](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html), a veces con una latencia más alta, lo que consume un rendimiento mayor que el modo predeterminado. DynamoDB también es [compatible con transacciones](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html) para ayudar a mantener la coherencia de datos.
+ Puede utilizar Amazon RDS para las características que necesiten [propiedades ACID](https://en.wikipedia.org/wiki/ACID), aunque las bases de datos relacionales suelen ser menos escalables que las bases de datos NoSQL, como DynamoDB. [Amazon RDS Proxy](https://aws.amazon.com/rds/proxy/) puede ayudar a administrar la agrupación y el escalado de conexiones de consumidores efímeros, como las funciones de Lambda.
Las arquitecturas basadas en eventos suelen diseñarse en función de eventos individuales y no de grandes lotes de datos. Por lo general, los flujos de trabajo están diseñados para administrar los pasos de un evento individual o un flujo de ejecución, en lugar de funcionar en varios eventos simultáneamente. En el caso de la tecnología sin servidor, se prefiere el procesamiento de eventos en tiempo real al procesamiento por lotes: los lotes se deben sustituir por muchas actualizaciones incrementales más pequeñas. Si bien esto puede mejorar la disponibilidad y escalabilidad de las cargas de trabajo, también complica la capacidad de los eventos para tener conocimiento de otros eventos.
### Devolución de valores a las llamadas de los servicios
En muchos casos, las aplicaciones basadas en eventos son asíncronas. Esto significa que los servicios que hacen una llamada no esperan las solicitudes de otros servicios para continuar con otras tareas. Esta es una característica fundamental de las arquitecturas basadas en eventos que permite la escalabilidad y la flexibilidad. Esto significa que transmitir valores de retorno o el resultado de un flujo de trabajo ser más complejo que en los flujos de ejecución sincrónica.
La mayoría de las invocaciones de Lambda en los sistemas de producción son [asíncronas](invocation-async.md) y responden a eventos de servicios, como Amazon S3 o Amazon SQS. En estos casos, el éxito o el fracaso del procesamiento de un evento suele ser más importante que la devolución de un valor. Lambda incluye características como la [cola de mensajes fallidos](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) (DLQ) para garantizar que pueda identificar y volver a intentar los eventos fallidos sin necesidad de avisar a quien llama.
### Depuración de errores en todos los servicios y funciones
La depuración de sistemas basados en eventos también es diferente en comparación con una aplicación monolítica. Dado que diferentes sistemas y servicios transmiten eventos, no es posible registrar y reproducir el estado exacto de varios servicios cuando se producen errores. Dado que cada invocación de servicios y funciones tiene archivos de registro independientes, puede resultar más complicado determinar qué ocurrió con un evento específico que provocó un error.
Existen tres requisitos importantes para crear un enfoque de depuración exitoso en los sistemas basados en eventos. En primer lugar, es fundamental contar con un sistema de registro sólido y Amazon CloudWatch lo proporciona en todos los servicios de AWS y lo integra en las funciones de Lambda. En segundo lugar, en estos sistemas, es importante asegurarse de que cada evento tenga un identificador de transacción que se registre en cada paso de la transacción, para facilitar la búsqueda de registros.
Por último, se recomienda automatizar el análisis de los registros mediante un servicio de depuración y supervisión, como AWS X-Ray. Esto puede consumir registros en múltiples invocaciones y servicios de Lambda, lo que facilita la identificación de la causa raíz de los problemas. Consulte la [Guía de solución de problemas](lambda-troubleshooting.md) para obtener una descripción detallada sobre el uso de X-Ray en la resolución de problemas.
## Antipatrones en aplicaciones basadas en eventos de Lambda
Al crear arquitecturas basadas en eventos con Lambda, evite los siguientes antipatrones comunes. Estos patrones funcionan, pero pueden aumentar los costos y la complejidad.
### El monolito de Lambda
En muchas aplicaciones migradas desde servidores tradicionales, como instancias de Amazon EC2 o aplicaciones de Elastic Beanstalk, los desarrolladores pueden migrar mediante “lift-and-shift” el código existente. Con frecuencia, esto da como resultado una única función de Lambda que contiene toda la lógica de la aplicación que se activa para todos los eventos. Para una aplicación web básica, una función de Lambda monolítica gestionaría todas las rutas de API Gateway y se integraría con todos los recursos descendentes necesarios.
![\[arquitecturas basadas en eventos figura 13\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-13.png)
Este enfoque tiene varios inconvenientes:
+ **Tamaño de los paquetes**: la función de Lambda puede ser mucho más grande porque contiene todo el código posible para todas las rutas, lo que hace que la ejecución del servicio de Lambda sea más lenta.
+ **Dificultad para aplicar el mínimo privilegio**: el [rol de ejecución](lambda-intro-execution-role.md) de la función debe permitir permisos a todos los recursos necesarios para todas las rutas, lo que hace que los permisos sean muy amplios. Se trata de un problema de seguridad. Muchas rutas del monolito funcional no necesitan todos los permisos que se han concedido.
+ **Más difícil de actualizar**: en un sistema de producción, cualquier actualización de una única función es más arriesgada y podría afectar a toda la aplicación. La actualización de una sola ruta en la función de Lambda es una actualización de toda la función.
+ **Más difícil de mantener**: es más difícil contar con varios desarrolladores que trabajen en el servicio, ya que se trata de un repositorio de código monolítico. También aumenta la carga cognitiva de los desarrolladores y dificulta la creación de una cobertura de prueba adecuada para el código.
+ **Más difícil reutilizar el código**: es más difícil separar las bibliotecas reutilizables de los monolitos, lo que dificulta la reutilización del código. A medida que desarrolle y respalde más proyectos, esto puede dificultar la compatibilidad con el código y escalar la velocidad de su equipo.
+ **Más difícil de probar**: conforme aumentan las líneas de código, resulta más difícil realizar pruebas unitarias de todas las combinaciones posibles de entradas y puntos de entrada en el código base. Por lo general, es más fácil implementar pruebas unitarias para servicios más pequeños con menos código.
La alternativa preferida es desglosar la función de Lambda monolítica en microservicios individuales y asignar una sola función de Lambda a una sola tarea bien definida. En esta sencilla aplicación web con unos pocos puntos de conexión de API, la arquitectura resultante basada en microservicios puede basarse en las rutas de API Gateway.
![\[arquitecturas basadas en eventos figura 14\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-14.png)
### Patrones recursivos que provocan pérdidas de control en las funciones de Lambda
Los servicios de AWS generan eventos que invocan funciones de Lambda y las funciones de Lambda pueden enviar mensajes a los servicios de AWS. Por lo general, el servicio o recurso que invoca una función de Lambda debe ser diferente del servicio o recurso al que se envía la función. Si no se administra esto, se pueden producir bucles infinitos.
Por ejemplo, una función de Lambda escribe un objeto en un objeto de Amazon S3, que a su vez invoca la misma función de Lambda mediante un evento put. La invocación hace que se escriba un segundo objeto en el bucket, que invoca la misma función de Lambda:
![\[arquitecturas basadas en eventos figura 15\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-15.png)
Si bien en la mayoría de los lenguajes de programación existe la posibilidad de crear bucles infinitos, este antipatrón tiene el potencial de consumir más recursos en las aplicaciones sin servidor. Tanto Lambda como Amazon S3 se escalan automáticamente según el tráfico, lo que puede hacer que Lambda se escale y consuma toda la simultaneidad disponible, mientras que Amazon S3 continúa escribiendo objetos y genera más eventos para Lambda.
En este ejemplo se usa S3, pero el riesgo de bucles recursivos también existe en Amazon SNS, Amazon SQS, DynamoDB y otros servicios. Puede utilizar la [detección de bucles recursivos](invocation-recursion.md) para encontrar y evitar este antipatrón.
### Funciones de Lambda que llaman a funciones de Lambda
Las funciones permiten la encapsulación y la reutilización del código. La mayoría de los lenguajes de programación son compatibles con el concepto de código que llama sincrónicamente a funciones dentro de una base de código. En este caso, el servicio que llama espera hasta que la función devuelve una respuesta.
**nota**
Si bien el hecho de que las funciones de Lambda llamen directamente a otras funciones de Lambda suele considerarse un antipatrón debido a cuestiones de costo y complejidad, esto no se aplica a las [funciones duraderas](durable-functions.md), que están diseñadas específicamente para orquestar flujos de trabajo de varios pasos mediante la invocación de otras funciones.
Cuando esto ocurre en un servidor tradicional o en una instancia virtual, el programador del sistema operativo cambia a otro trabajo disponible. El hecho de que la CPU funcione al 0 % o al 100 % no afecta al costo total de la aplicación, ya que usted paga el costo fijo de poseer y operar un servidor.
Este modelo no suele adaptarse bien al desarrollo sin servidor. Por ejemplo, consideremos una aplicación de comercio electrónico sencilla que consta de tres funciones de Lambda que procesan un pedido:
![\[arquitecturas basadas en eventos figura 16\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-16.png)
En este caso, la función de *Crear pedido* llama a la función de *Procesar pago*, que a su vez llama a la función de *Crear factura*. Si bien este flujo sincrónico puede funcionar dentro de una sola aplicación en un servidor, presenta varios problemas evitables en una arquitectura sin servidor distribuida:
+ **Costo**: con Lambda, pagará por la duración de una invocación. En este ejemplo, mientras se ejecuta la función *Crear factura*, otras dos funciones también se ejecutan en estado de espera, como se muestra en rojo en el diagrama.
+ **Gestión de errores**: en las invocaciones anidadas, la gestión de errores puede resultar mucho más compleja. Por ejemplo, si se produce un error en *Crear factura*, es posible que la función *Procesar pago* deba anular el cargo o que, en su lugar, vuelva a intentar el proceso *Crear factura*.
+ **Acoplamiento ajustado**: procesar un pago suele llevar más tiempo que crear una factura. En este modelo, la disponibilidad de todo el flujo de trabajo está limitada por la función más lenta.
+ **Escalado**: la [simultaneidad](lambda-concurrency.md) de las tres funciones debe ser igual. En un sistema ocupado, se utiliza más simultaneidad de la que se necesitaría de otro modo.
En las aplicaciones sin servidor, hay dos enfoques comunes para evitar este patrón. En primer lugar, utilice una cola de Amazon SQS entre las funciones de Lambda. Si un proceso descendente es más lento que uno ascendente, la cola conserva los mensajes de forma duradera y desacopla las dos funciones. En este ejemplo, la función *Crear pedido* publicaría un mensaje en una cola de Amazon SQS y la función *Procesar pago* consume los mensajes de la cola.
El segundo enfoque consiste en utilizar AWS Step Functions. Para procesos complejos con múltiples tipos de errores y lógica de reintento, Step Functions puede ayudar a reducir la cantidad de código personalizado necesario para orquestar el flujo de trabajo. Como resultado, Step Functions orquesta el trabajo y gestiona los errores y los reintentos sin problemas, mientras que las funciones de Lambda solo contienen lógica empresarial.
### Espera sincrónica dentro de una sola función de Lambda
Asegúrese de que las actividades potencialmente simultáneas no se programen de forma sincrónica dentro de una sola función de Lambda. Por ejemplo, una función de Lambda podría escribir en un bucket de S3 y, después, escribir en una tabla de DynamoDB:
![\[arquitecturas basadas en eventos figura 17\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-17.png)
En este diseño, los tiempos de espera se acumulan porque las actividades son secuenciales. En los casos en los que la segunda tarea depende de la finalización de la primera, puede reducir el tiempo de espera total y el costo de ejecución al tener dos funciones de Lambda separadas:
![\[arquitecturas basadas en eventos figura 19\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-19.png)
En este diseño, la primera función de Lambda responde inmediatamente después de colocar el objeto en el bucket de Amazon S3. El servicio S3 invoca la segunda función de Lambda, que luego escribe los datos en la tabla de DynamoDB. Este enfoque minimiza el tiempo total de espera en las ejecuciones de la función de Lambda.
# Diseño de aplicaciones Lambda
Una aplicación basada en eventos bien diseñada utiliza una combinación de AWS servicios y código personalizado para procesar y administrar las solicitudes y los datos. Este capítulo se enfoca en aspectos específicos de Lambda en el diseño de aplicaciones. Hay muchas consideraciones importantes que los arquitectos sin servidor deben tener en cuenta a la hora de diseñar aplicaciones para sistemas de producción con gran actividad.
Muchas de las prácticas recomendadas que se aplican al desarrollo de software y a los sistemas distribuidos también se aplican al desarrollo de aplicaciones sin servidor. El objetivo general es desarrollar cargas de trabajo que sean:
+ **Fiables**: ofrecen a los usuarios finales un alto nivel de disponibilidad. Los servicios sin servidor de AWS son fiables porque también están diseñados para tolerar errores.
+ **Duraderas**: ofrecen opciones de almacenamiento que satisfacen las necesidades de durabilidad de la carga de trabajo.
+ **Seguras**: siguen las prácticas recomendadas y usan las herramientas proporcionadas para proteger el acceso a las cargas de trabajo y limitar el radio de impacto.
+ **De buen rendimiento**: usan los recursos de computación de forma eficiente y satisfacen las necesidades de rendimiento de los usuarios finales.
+ **Rentables:** diseñan arquitecturas que eviten costos innecesarios, capaces de escalar sin incurrir en gastos excesivos y que se puedan retirar del servicio sin sobrecargas significativas.
Los siguientes principios de diseño resultan útiles a la hora de crear cargas de trabajo que cumplan estos objetivos. Aunque no todos los principios se aplican a todas las arquitecturas, sirven de guía a la hora de tomar decisiones generales en materia de arquitectura.
**Topics**
+ [
## Uso de servicios en lugar de código personalizado
](#services-custom-code)
+ [
## Comprensión de los niveles de abstracción de Lambda
](#level-abstraction)
+ [
## Implementación de la ausencia de estado en las funciones
](#statelessness-functions)
+ [
## Reducción al mínimo del acoplamiento
](#minimize-coupling)
+ [
## Creación basada en datos bajo demanda en lugar de lotes
](#on-demand-batches)
+ [
## Elija una opción de orquestación para flujos de trabajo complejos
](#orchestration)
+ [
## Implementación de la idempotencia
](#retries-failures)
+ [
## Uso de varias cuentas de AWS para administrar las cuotas
](#multiple-accounts)
## Uso de servicios en lugar de código personalizado
Las aplicaciones sin servidor suelen incluir varios servicios de AWS, integrados con código personalizado que se ejecuta en funciones de Lambda. Si bien Lambda se puede integrar con la mayoría de los servicios de AWS, los servicios que se utilizan con más frecuencia en las aplicaciones sin servidor son:
| Categoría | Servicio de AWS |
| --- | --- |
| Computación | AWS Lambda |
| Almacenamiento de datos | Amazon S3 Amazon DynamoDB Amazon RDS |
| API | Amazon API Gateway |
| Integración de aplicaciones | Amazon EventBridge Amazon SNS Amazon SQS |
| Orquestación | Funciones duraderas de Lambda AWS Step Functions |
| Datos y análisis de transmisión | Amazon Data Firehose |
**nota**
Muchos servicios sin servidor proporcionan replicación y compatibilidad con varias regiones, incluidas DynamoDB y Amazon S3. Las funciones de Lambda se pueden implementar en varias regiones como parte de una canalización de implementación y API Gateway se puede configurar para que sea compatible con esta configuración. Consulte este [ejemplo de arquitectura](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/serverless-architecture-for-global-applications-ra.pdf?did=wp_card&trk=wp_card) que muestra cómo se puede lograr esto.
Existen muchos patrones comunes y bien establecidos en las arquitecturas distribuidas que puede crear usted mismo o implementar mediante servicios de AWS. Para la mayoría de los clientes, invertir tiempo en desarrollar estos patrones partiendo de cero tiene poco valor comercial. Cuando su aplicación necesite uno de estos patrones, utilice el servicio de AWS correspondiente:
| Pattern | Servicio de AWS |
| --- | --- |
| Cola | Amazon SQS |
| Bus de eventos | Amazon EventBridge |
| Publicar/suscribir (desplegable) | Amazon SNS |
| Orquestación | Funciones duraderas de Lambda AWS Step Functions |
| API | Amazon API Gateway |
| Secuencias de eventos | Amazon Kinesis |
Estos servicios están diseñados para integrarse con Lambda y puede utilizar infraestructura como código (IaC) para crear y descartar recursos en los servicios. Puede utilizar cualquiera de estos servicios a través del [AWS SDK](https://aws.amazon.com/tools/) sin necesidad de instalar aplicaciones ni configurar servidores. Dominar el uso de estos servicios mediante código en las funciones de Lambda es un paso importante para producir aplicaciones sin servidor bien diseñadas.
## Comprensión de los niveles de abstracción de Lambda
El servicio de Lambda limita el acceso a los sistemas operativos, hipervisores y equipo subyacentes que ejecutan las funciones de Lambda. El servicio mejora y cambia continuamente la infraestructura para agregar características, reducir los costos y aumentar el rendimiento del servicio. El código debe asumir que no conoce la arquitectura de Lambda y que no tiene afinidad por el equipo.
Del mismo modo, AWS administra las integraciones de Lambda con otros servicios con tan solo una cantidad reducida de opciones de configuración expuestas a usted. Por ejemplo, cuando API Gateway y Lambda interactúan, no hay ningún concepto de equilibrio de carga, ya que los servicios administran esto en su totalidad. Tampoco tendrá control directo sobre qué [zonas de disponibilidad](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) utilizan los servicios al invocar funciones en un momento dado, ni sobre cómo Lambda determina cuándo escalar o desescalar verticalmente la cantidad de entornos de ejecución.
Esta abstracción le ayuda a centrarse en los aspectos de integración de la aplicación, el flujo de datos y la lógica empresarial, en los que la carga de trabajo aporta valor a los usuarios finales. Permitir que los servicios administren la mecánica subyacente lo ayuda a desarrollar aplicaciones con mayor rapidez y con menos código personalizado que mantener.
## Implementación de la ausencia de estado en las funciones
En el caso de las funciones estándar de Lambda, debe asumir que el entorno existe solo para una única invocación. La función debe inicializar cualquier estado necesario cuando se inicia por primera vez. Por ejemplo, es posible que la función requiera obtener datos de una tabla de DynamoDB. Debe confirmar cualquier cambio de datos permanente en un almacén duradero, como Amazon S3, DynamoDB o Amazon SQS antes de salir. No se debe basar en ninguna estructura de datos ni en archivos temporales existentes, así como en ningún estado interno susceptible de ser administrado por múltiples invocaciones.
Cuando se utilizan funciones duraderas, el estado se conserva automáticamente entre las invocaciones, lo que elimina la necesidad de conservar manualmente el estado en el almacenamiento externo. Sin embargo, debe seguir los principios sin estado para cualquier dato que no se gestione de forma explícita a través del DurableContext.
Para inicializar las conexiones y bibliotecas de la base de datos, o cargar el estado, se puede aprovechar la [inicialización estática](lambda-runtime-environment.md#static-initialization). Dado que los entornos de ejecución se reutilizan siempre que es posible para mejorar el rendimiento, puede amortizar el tiempo necesario para inicializar estos recursos en varias invocaciones. Sin embargo, no debe almacenar ninguna variable o dato utilizado en la función dentro de este ámbito global.
## Reducción al mínimo del acoplamiento
La mayoría de las arquitecturas deberían preferir muchas funciones más cortas a menos funciones más grandes. El objetivo de cada función debe ser gestionar el evento transferido a la función, sin conocer ni esperar nada del flujo de trabajo general ni del volumen de transacciones. Esto hace que la función sea independiente del origen del evento con un acoplamiento mínimo a otros servicios.
Cualquier constante de alcance global que cambie con poca frecuencia debe implementarse como variable de entorno para permitir las actualizaciones sin implementaciones. Todos los secretos o información confidencial deben almacenarse en [Almacén de parámetros de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) o en [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) y deben cargarse con la función. Como estos recursos son específicos de cada cuenta, es posible crear canalizaciones en varias cuentas. Las canalizaciones cargan los secretos adecuados por entorno, sin exponerlos a los desarrolladores ni requerir cambios en el código.
## Creación basada en datos bajo demanda en lugar de lotes
Muchos sistemas tradicionales están diseñados para ejecutarse periódicamente y procesar lotes de transacciones que se han acumulado con el tiempo. Por ejemplo, una aplicación bancaria puede ejecutarse cada hora para procesar las transacciones de los cajeros automáticos en los libros de contabilidad centrales. En las aplicaciones basadas en Lambda, el procesamiento personalizado debe activarse con cada evento, lo que permite al servicio escalar verticalmente la simultaneidad según sea necesario, para proporcionar un procesamiento de las transacciones casi en tiempo real.
Si bien las funciones de Lambda estándar tienen un tiempo de ejecución limitado a 15 minutos, las funciones duraderas pueden ejecutarse hasta 1 año, lo que las hace adecuadas para necesidades de procesamiento más prolongadas. Sin embargo, siempre que sea posible, debería dar preferencia al procesamiento basado en eventos por sobre el procesamiento por lotes.
Si bien puede ejecutar tareas [cron](https://en.wikipedia.org/wiki/Cron) en aplicaciones sin servidor [mediante expresiones programadas](https://docs.aws.amazon.com/eventbridge/latest/userguide/scheduled-events.html) con las reglas de Amazon EventBridge, estas deben usarse con moderación o como último recurso. En cualquier tarea programada que procese un lote, existe la posibilidad de que el volumen de transacciones crezca más allá de lo que se puede procesar dentro del límite de duración de Lambda de 15 minutos. Si las limitaciones de los sistemas externos lo obligan a usar un programador, por lo general, debe programarlo para el periodo recurrente más corto que sea razonable.
Por ejemplo, no es recomendable utilizar un proceso por lotes que active una función de Lambda para obtener una lista de nuevos objetos de Amazon S3. Esto se debe a que el servicio puede recibir más objetos nuevos entre lotes de los que se pueden procesar en una función de Lambda de 15 minutos.
![\[arquitecturas basadas en eventos figura 10\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-10.png)
En su lugar, Amazon S3 debe invocar la función Lambda cada vez que se introduzca un nuevo objeto en el bucket. Este enfoque se puede escalar significativamente más y funciona casi en tiempo real.
![\[arquitecturas basadas en eventos figura 11\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/event-driven-architectures-figure-11.png)
## Elija una opción de orquestación para flujos de trabajo complejos
Los flujos de trabajo que implican lógica de ramificación, diferentes tipos de modelos de error y lógica de reintentos suelen utilizar un orquestador para realizar un seguimiento del estado de la ejecución general. No cree orquestación ad hoc en funciones de Lambda estándar. Esto da como resultado un acoplamiento ajustado, un código de enrutamiento complejo y una falta de recuperación automática del estado.
En su lugar, utilice una de estas opciones de orquestación especialmente creadas:
+ **[Funciones duraderas de Lambda](durable-functions.md):** orquestación centrada en las aplicaciones mediante lenguajes de programación estándar con puntos de control automáticos, reintentos integrados y recuperación de la ejecución. Ideal para los desarrolladores que prefieren mantener la lógica del flujo de trabajo en el código junto con la lógica empresarial dentro de Lambda.
+ **[AWS Step Functions](with-step-functions.md):** orquestación visual de flujos de trabajo con integraciones nativas para más de 220 servicios de AWS. Ideal para coordinar varios servicios, con infraestructura que no requiere mantenimiento y diseño visual del flujo de trabajo.
Para obtener instrucciones sobre cómo elegir entre estas opciones, consulte [Funciones duraderas o Step Functions](durable-step-functions.md).
Con [Step Functions](https://aws.amazon.com/step-functions/), se utilizan máquinas de estado para administrar la orquestación. Esto extrae del código la lógica de gestión de errores, enrutamiento y ramificación y la sustituye por máquinas de estados declaradas mediante JSON. Además de hacer que los flujos de trabajo sean más robustos y observables, también puedes agregar control de versiones a los flujos de trabajo y convertir la máquina de estados en un recurso codificado que se puede agregar a un repositorio de código.
Es habitual que los flujos de trabajo más sencillos de las funciones de Lambda se tornen más complejos con el tiempo. Al utilizar una aplicación sin servidor de producción, es importante identificar cuándo ocurre esto para poder migrar esta lógica a una máquina de estado o función duradera.
## Implementación de la idempotencia
Los servicios sin servidor de AWS, incluido Lambda, son tolerantes a errores y están diseñados para gestionar los errores. Por ejemplo, si un servicio invoca una función de Lambda y se produce una interrupción del servicio, Lambda invocará la función en una zona de disponibilidad diferente. Si la función arroja un error, Lambda reintentará la invocación.
Como el mismo evento se puede recibir más de una vez, las funciones deben diseñarse de forma que sean [idempotentes](https://en.wikipedia.org/wiki/Idempotence). Esto significa que recibir el mismo evento varias veces no cambia el resultado después de la primera vez que se recibió el evento.
Para implementar la idempotencia en las funciones de Lambda, puede utilizar una tabla de DynamoDB para realizar un seguimiento de los identificadores procesados recientemente y determinar si la transacción ya se ha gestionado anteriormente. La tabla de DynamoDB suele implementar [un valor de tiempo de vida (TTL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) para hacer caducar los elementos a fin de limitar el espacio de almacenamiento utilizado.
## Uso de varias cuentas de AWS para administrar las cuotas
Muchas [cuotas de servicio](gettingstarted-limits.md) en AWS se establecen a nivel de cuenta. Esto significa que a medida que se agregan más cargas de trabajo, los límites podrían agotarse rápidamente.
Una forma eficaz de resolver este problema es utilizar varias cuentas de AWS, y dedicar cada carga de trabajo a su propia cuenta. Esto evita que las cuotas se compartan con otras cargas de trabajo o recursos ajenos a la producción.
Además, al utilizar [AWS Organizations](https://aws.amazon.com/organizations/), es posible administrar de forma centralizada la facturación, el cumplimiento y la seguridad de estas cuentas. Puede adjuntar políticas a grupos de cuentas para evitar los scripts personalizados y los procesos manuales.
Un enfoque habitual consiste en proporcionar una cuenta de AWS a cada desarrollador y, a continuación, utilizar cuentas independientes para la fase de implementación y producción de la versión beta:
![\[diseño de la aplicación (figura 3)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/application-design-figure-3.png)
Bajo este modelo, cada desarrollador cuenta con su propio conjunto de límites asignados a su cuenta, lo que garantiza que su uso no afecte el entorno de producción. Este enfoque también permite a los desarrolladores probar las funciones de Lambda de forma local en sus máquinas de desarrollo con los recursos de la nube activos de sus cuentas individuales.