Preguntas frecuentes sobre AWS Lambda

Consulte nuestra documentación para ver la lista completa de orígenes de eventos.

AWS Lambda es compatible de forma nativa con Java, Go, PowerShell, Node.js, C#, Python y el código Ruby. Además, proporciona una API de tiempo de ejecución que permite utilizar cualquier lenguaje de programación adicional para crear las funciones. Consulte nuestra documentación sobre el uso de Node.js, Python, Java, Ruby, C#, Go y PowerShell.

Cada función de AWS Lambda se pone en marcha en su propio entorno aislado, con sus propios recursos y en su vista del sistema de archivos. AWS Lambda usa las mismas técnicas que Amazon EC2 para proporcionar seguridad y separación en la infraestructura y el procesamiento. Consulte la documentación para obtener más información.

AWS Lambda almacena el código en Amazon S3 y lo cifra cuando está inactivo. AWS Lambda realiza controles de integridad adicionales mientras se usa el código. Para la información confidencial, como contraseñas de bases de datos, recomendamos que utilice el cifrado del cliente con AWS Key Management Service y almacene los valores resultantes como texto cifrado en su variable de entorno. Para descifrar los valores, tendrá que incluir lógica en su código de la función de AWS Lambda. Consulte la documentación para obtener más información.

Sí. Puede crear y modificar variables de entorno de forma sencilla desde la consola, la CLI o los SDK de AWS Lambda. Para obtener más información sobre las variables de entorno, consulte la documentación.

Para información confidencial, como contraseñas de bases de datos, recomendamos usar el cifrado en el cliente con AWS Key Management Service y almacenar los valores resultantes como texto cifrado en la variable de entorno. Para descifrar los valores, tendrá que incluir lógica en su código de la función de AWS Lambda.

Sí, puede empaquetar cualquier código (marcos, SDK, bibliotecas, etc.) como una capa de Lambda y administrarlo y compartirlo fácilmente entre varias funciones.

AWS Lambda supervisa automáticamente las funciones de Lambda en su nombre y genera informes de métricas en tiempo real a través de Amazon CloudWatch, los cuales incluyen el total de solicitudes, el uso de simultaneidad por cuenta y por función, la latencia, las tasas de error y las solicitudes limitadas. Puede consultar las estadísticas de cada una de sus funciones de Lambda mediante la consola de Amazon CloudWatch o la consola de AWS Lambda. También puede realizar llamadas a API de monitorización de terceros en la función de Lambda.
 

Consulte Resolución de problemas con métricas de CloudWatch para obtener más información. El uso de las métricas integradas de Lambda conlleva los cargos estándar de AWS Lambda.

En el modelo de recursos de AWS Lambda, debe elegir el volumen de memoria que desea para la función y, posteriormente, se asignará la capacidad proporcional de CPU y de otros recursos. Por ejemplo, si selecciona 256 MB de memoria, se asigna aproximadamente el doble de la potencia de CPU a la función de Lambda que al solicitar 128 MB de memoria y la mitad de la potencia de CPU que al seleccionar 512 MB de memoria. Para obtener más información, consulte Configuración de la memoria de una función de Lambda.

Puede configurar la memoria de 128 MB a 10 240 MB.

Los precios de AWS Lambda se basan en un modelo de pago por uso. Consulte la página de precios de AWS Lambda para obtener más detalles.

Sí. De forma predeterminada, cada función de AWS Lambda tiene una versión única y actual del código. Los clientes de la función de Lambda pueden llamar a una versión específica u obtener la implementación más reciente. Consulte nuestra documentación sobre el control de versiones de las funciones de Lambda.

AWS Lambda ofrece opciones de implementación flexibles: puede empaquetar e implementar funciones como archivos .zip que puede cargar directamente a través de la consola, la CLI o los SDK, o como imágenes de contenedor. Ambos métodos proporcionan el mismo entorno de ejecución, escalado y simplicidad operativa, lo que le brinda la flexibilidad de elegir el enfoque que mejor se adapte a su flujo de trabajo.

Puede invocar una función de Lambda mediante el uso de un evento personalizado a través de la API de invocación de AWS Lambda. Solo el propietario de la función u otra cuenta de AWS a la que el propietario haya concedido permiso pueden invocar la función. Consulte la Guía para desarrolladores de Lambda para obtener más información.

AWS Lambda SnapStart puede mejorar el rendimiento de inicio de varios segundos a tan solo menos de un segundo para las aplicaciones sensibles a la latencia. SnapStart crea una instantánea del estado inicializado de la memoria (y el disco) de la función y almacena en caché esta instantánea para un acceso de baja latencia. Cuando se invoca la función posteriormente, Lambda reanuda los entornos de ejecución a partir de esta instantánea preinicializada, en lugar de inicializarlos desde cero, lo que mejora la latencia de inicio. Para lograr resiliencia, Lambda mantiene copias en caché de su instantánea y aplica automáticamente actualizaciones de software, como mejoras de tiempo de ejecución y parches de seguridad. Consulte la documentación para obtener más información.

Lambda SnapStart es una configuración simple por función que puede configurarse para funciones nuevas y existentes con la API de Lambda, la consola de administración de AWS, la interfaz de la línea de comandos de AWS (AWS CLI), el SDK de AWS, AWS Cloud Development Kit (AWS CDK), AWS CloudFormation y AWS Serverless Application Model (AWS SAM) Al configurar Lambda SnapStart, cada versión de una función que se publique a partir de entonces se beneficia de la mejora del rendimiento de inicio que ofrece Lambda SnapStart. Para obtener más información acerca de Lambda SnapStart, consulte la documentación.

Lambda SnapStart es una optimización del rendimiento que ayuda a sus funciones a lograr tiempos de inicio más rápidos al reducir la latencia variable incurrida al procesar el código de inicialización único. Aunque Lambda SnapStart reduce la latencia de inicio, funciona como una optimización de mejor esfuerzo y no garantiza la eliminación de los arranques en frío. Si su aplicación tiene requisitos estrictos de latencia y requiere tiempos de arranque de milisegundos de dos dígitos, le recomendamos que utilice la PC.

Lambda SnapStart admite varias versiones ejecutables, incluidas Java 11 (y versiones más recientes), Python 3.12 (y versiones más recientes) y .NET 8 (y versiones más recientes). Las futuras versiones de las versiones ejecutables serán compatibles una vez que se publiquen. Para conocer todos los tiempos de ejecución admitidos por Lambda, consulte la documentación sobre los tiempos de ejecución de Lambda.

Sí. Puede configurar una función de Lambda SnapStart para acceder a los recursos de una nube virtual privada (VPC). Para más información sobre cómo configurar una función con una VPC, consulte la documentación de Lambda.

Sí, se le cobrará por almacenar en caché una instantánea durante el periodo en que la versión de su función esté activa, durante un mínimo de 3 horas y por milisegundo a partir de entonces. El precio depende de la cantidad de memoria asignada a la función. También se le cobrará cada vez que Lambda reanude un entorno de ejecución mediante la restauración de la instantánea, y el precio dependerá de la cantidad de memoria que asigne a la función. Para obtener más información sobre los precios de SnapStart, consulte los Precios de AWS Lambda.

Los precios de SnapStart no se aplican a las versiones ejecutables administradas de Java compatibles, que solo pueden almacenar en caché una instantánea durante un máximo de 14 días.

La simultaneidad aprovisionada le brinda mayor control sobre el rendimiento de sus aplicaciones sin servidor. Cuando se habilita, la simultaneidad aprovisionada mantiene las funciones activadas y en el mayor estado de preparación para responder en milisegundos de dos dígitos.

Puede configurar la simultaneidad en su función a través de la consola de administración de AWS, la API de Lambda, AWS CLI y AWS CloudFormation. La forma más sencilla de beneficiarse de la simultaneidad aprovisionada es utilizar AWS Auto Scaling. Puede utilizar Auto Scaling de aplicaciones para configurar programas o hacer que Auto Scaling ajuste automáticamente el nivel de concurrencia aprovisionada en tiempo real a medida que cambia la demanda. Para obtener más información sobre la simultaneidad aprovisionada, consulte la documentación.

La simultaneidad aprovisionada agrega una dimensión de precios (de “simultaneidad aprovisionada”) para mantener las funciones inicializadas. Cuando está habilitada, paga por la cantidad de simultaneidad que configura y por el periodo por el que lo hace. Cuando su función se ejecuta mientras la simultaneidad aprovisionada está habilitada, también paga por las solicitudes y por la duración de la ejecución. Para obtener más información sobre los precios de la simultaneidad aprovisionada, consulte Precios de AWS Lambda.

Lambda@Edge le permite procesar código en ubicaciones de AWS en todo el mundo sin aprovisionar ni administrar servidores, respondiendo a los usuarios finales con la menor latencia de red posible. Simplemente tiene que cargar el código Node.js o Python en AWS Lambda y configurar la función para que se active como respuesta a solicitudes de Amazon CloudFront (es decir, cuando se reciba la solicitud de un lector, cuando una solicitud se reenvíe o se reciba del origen y antes de responder al usuario final). Después, el código estará listo para ejecutarse en ubicaciones de AWS a nivel global cuando se reciba una solicitud de contenido y ajustará la escala en función del volumen de solicitudes de CloudFront a nivel global. Para obtener más información al respecto, consulte nuestra documentación.

Para usar Lambda@Edge, basta con cargar su código en AWS Lambda y asociar una versión de función para que se active como respuesta a solicitudes de Amazon CloudFront. El código debe atenerse a los límites de servicio de Lambda@Edge. Actualmente, Lambda@Edge admite Node.js y Python para la invocación global por parte de eventos de CloudFront. Para obtener más información al respecto, consulte nuestra documentación.

Lambda@Edge está optimizado para casos de uso en los que la latencia es un factor importante, ya que los lectores finales están distribuidos globalmente. Toda la información que necesita para tomar una decisión debe estar disponible en el borde de CloudFront, dentro de la función y la solicitud. Esto significa que los casos de uso en los que se busca tomar decisiones sobre cómo ofrecer contenido según las características del usuario (p. ej., ubicación, dispositivo del cliente, etc.) ahora pueden procesarse y ofrecerse cerca de los usuarios sin necesidad de enrutarlos de vuelta a un servidor centralizado.

Puede asociar funciones de Lambda existentes con eventos de CloudFront para la invocación global si la función cumple los límites y requisitos de servicio de Lambda@Edge. Aquí puede obtener más información sobre cómo actualizar las propiedades de su función.

No. AWS Lambda es un servicio diseñado para poner en marcha numerosas instancias de las funciones simultáneamente. Sin embargo, AWS Lambda tiene un límite de regulación de seguridad predeterminado para el número de procesamientos simultáneos por cuenta y por región (consulte esta página para obtener información sobre los límites predeterminados de regulación de seguridad). También puede controlar el número máximo de procesamientos simultáneos para las funciones individuales de AWS Lambda. De este modo, puede reservar un subconjunto del límite de simultaneidad de la cuenta para las funciones críticas o limitar las tasas de tráfico a los recursos de distribución.

Si desea enviar una solicitud para aumentar el límite de procesamientos simultáneos, puede utilizar las Service Quotas para solicitar un aumento del límite.

Si excede la limitación, las funciones de AWS Lambda invocadas de manera sincrónica mostrarán un error de limitación (código de error 429). Las funciones de Lambda invocadas de manera asíncrona pueden absorber picos de tráfico razonables durante unos 15-30 minutos, tras los cuales se rechazarán los eventos entrantes por motivos de limitación. En el caso de que la función de Lambda se invoque como respuesta a eventos de Amazon S3, Amazon S3 podrían retenerse los eventos rechazados por AWS Lambda durante 24 horas para volver a intentar enviarlos. Los eventos de Amazon Kinesis Streams y Amazon DynamoDB Streams intentan reenviarse hasta que la función de Lambda tiene éxito o los datos vencen. Amazon Kinesis y Amazon DynamoDB Streams retienen los datos durante 24 horas.

El límite máximo predeterminado de procesamientos simultáneos se aplica por cuenta. Sin embargo, también puede establecer límites para funciones individuales (consulte aquí para obtener información sobre la simultaneidad reservada).

Cada función de Lambda invocada de forma sincrónica puede escalarse a una velocidad de hasta 1000 procesamientos simultáneos cada 10 segundos. Si bien la velocidad de escalado de Lambda es adecuada para la mayoría de los casos de uso, es especialmente ideal para aquellos con picos de tráfico predecibles o impredecibles. Por ejemplo, el procesamiento de datos vinculado al SLA requeriría un escalado rápido y predecible para satisfacer la demanda de procesamiento. Del mismo modo, publicar artículos de noticias de última hora o ventas instantáneas podría generar niveles de tráfico impredecibles en un periodo de tiempo reducido. La velocidad de escalado de Lambda puede facilitar estos casos de uso sin configuraciones ni herramientas adicionales. Además, el límite de escalado de simultaneidad es un límite por función, lo que significa que cada función de su cuenta escala de forma independiente de las demás.

Si se excede la política de reintentos para invocaciones asíncronas, puede configurar una “cola de mensajes fallidos” (DLQ) en la que se colocará el evento. Si no existe ninguna DLQ, es posible que se rechace el evento. Si se excede la política de invocaciones basadas en transmisiones, los datos habrían vencido ya y por lo tanto se rechazarán.

Puede conceder permisos a su función de Lambda para acceder a otros recursos mediante un rol de IAM. AWS Lambda asume la función mientras ejecuta la función de Lambda, para que siempre tenga un control absoluto y seguro de los recursos de AWS concretos que puede utilizar. Consulte la sección Configuración de AWS Lambda para obtener más información sobre las funciones.

Al configurar un bucket de Amazon S3 para que envíe mensajes a una función de AWS Lambda, se creará una regla de política de recursos que concederá el acceso. Consulte la Guía para desarrolladores de Lambda para obtener más información sobre las políticas de recursos y los controles de acceso para las funciones de Lambda.

Los controles de acceso se administran a través del rol de la función de Lambda. El rol que se asigna a la función de Lambda también determina los recursos que AWS Lambda puede sondear en su nombre. Consulte la Guía para desarrolladores de Lambda para obtener más información.

Puede habilitar las funciones de Lambda para acceder a los recursos de su VPC especificando la subred y el grupo de seguridad como parte de la configuración de la función. Las funciones de Lambda configuradas para obtener acceso a los recursos de una VPC determinada no tendrán acceso a Internet como configuración predeterminada. Para conceder Internet a estas funciones, utilice puertas de enlace de Internet. De forma predeterminada, las funciones de Lambda se comunican con los recursos de una VPC de doble pila a través de IPv4. Puede configurar sus funciones para acceder a los recursos de una VPC de doble pila a través de IPv6. Para obtener más información sobre las funciones de Lambda configuradas con VPC, consulte Redes privadas de Lambda con VPC.

La firma de código para AWS Lambda ofrece controles de confianza e integridad que permiten verificar que solo se implemente código inalterado de desarrolladores aprobados en las funciones de Lambda. Puede utilizar AWS Signer, un servicio de firma de código completamente administrado, para firmar digitalmente artefactos de código y configurar las funciones de Lambda para verificar las firmas en el despliegue. La firma de código para AWS Lambda actualmente solo está disponible para funciones empaquetadas como archivos ZIP.

Puede crear artefactos de código firmados digitalmente mediante un Perfil de firma en la consola de AWS Signer, la API de Signer, la CLI de SAM o AWS CLI. Para obtener más información, consulte la documentación de AWS Signer.

AWS Lambda puede realizar las siguientes comprobaciones de firma durante la implementación:

• Firma alterada: esto ocurre si el artefacto de código se ha modificado desde el momento de la firma.
• Firma no coincidente: esto ocurre si el artefacto de código está firmado por un perfil de firma no aprobado.
• Firma vencida: esto ocurre si la firma ha pasado la fecha de vencimiento establecida.
• Firma revocada: esto ocurre si el propietario del perfil de firma revoca los trabajos de firma.

Para obtener más información, consulte la documentación de AWS Lambda.

Usar la firma de código para AWS Lambda no conlleva ningún costo adicional. Paga el precio estándar para AWS Lambda. Para obtener más información, consulte Precios.

Para ofrecer una experiencia de registro simplificada y mejorada de forma predeterminada, AWS Lambda ofrece controles de registro avanzados, como la capacidad de capturar registros de funciones de Lambda en formato estructurado JSON de forma nativa, controlar el filtrado por registro de los registros de funciones de Lambda sin realizar cambios en el código, y personalizar el grupo de registros de Amazon CloudWatch al que Lambda envía los registros.

Puede capturar los registros de funciones de Lambda en formato estructurado JSON sin tener que utilizar sus propias bibliotecas de registro. Los registros estructurados en JSON facilitan la búsqueda, el filtrado y el análisis de grandes volúmenes de entradas de registro. Puede controlar el filtrado a nivel de registro de los registros de funciones de Lambda sin realizar ningún cambio en el código, lo que le permite elegir el nivel de granularidad de registro requerido para las funciones de Lambda sin tener que examinar grandes volúmenes de registros al depurar y solucionar errores. También puede establecer a qué grupo de registros de Amazon CloudWatch envíe los registros Lambda, lo que facilita la agregación de registros de varias funciones de una aplicación en un solo lugar. A continuación, puede aplicar políticas de seguridad, gobernanza y retención a los registros por aplicación, en lugar de hacerlo de forma individual a cada función.

Puede especificar controles de registro avanzados para sus funciones de Lambda mediante la API de AWS Lambda, la consola de AWS Lambda, AWS CLI, AWS Serverless Application Model (AWS SAM) y AWS CloudFormation. Para obtener más información, consulte la publicación del blog de lanzamiento para ver los controles de registro avanzados o la Guía para desarrolladores de Lambda.

Sí, puede usar sus propias bibliotecas de registro para generar registros de Lambda en formato estructurado JSON. Para garantizar que las bibliotecas de registro funcionen sin inconvenientes con la capacidad de registro estructurado JSON nativa de Lambda, Lambda no codificará dos veces los registros generados por la función que ya estén codificados en JSON. También puede usar la biblioteca Powertools para AWS Lambda para capturar los registros de Lambda en formato estructurado JSON.

El uso de controles de registro avanzados en Lambda no conlleva ningún cargo adicional. Los registros de Amazon CloudWatch le seguirán cobrando por la ingesta y el almacenamiento de sus registros de Lambda. Consulte la página de precios de CloudWatch para conocer los detalles sobre los precios de registro.

CloudWatch Application Signals es una solución de supervisión del rendimiento de la aplicación (APM) que permite a los desarrolladores y operadores supervisar fácilmente el estado y el rendimiento de las aplicaciones sin servidor creadas con Lambda. Application Signals proporciona paneles estandarizados y prediseñados para las métricas críticas de las aplicaciones, los seguimientos correlacionados y las interacciones entre las funciones de Lambda y sus dependencias, todo ello sin necesidad de que los desarrolladores realicen cambios manuales en el código ni en la instrumentación.

CloudWatch Logs Live Tail es una función interactiva de análisis y secuencia de registros que proporciona visibilidad en tiempo real de los registros, lo que facilita el desarrollo y la solución de problemas de las funciones de Lambda. Esto permite a los desarrolladores probar y validar rápidamente los cambios de código o configuración en tiempo real, lo que acelera el ciclo de creación, prueba e implementación (también conocido como “bucle de desarrollo interno”) al crear aplicaciones con Lambda. La experiencia de Live Tail también permite a los operadores y a los equipos de DevOps detectar y depurar fallos y errores críticos en el código de las funciones de Lambda de manera más eficiente, lo que reduce el tiempo medio de recuperación (MTTR) al solucionar los errores de las funciones de Lambda.

Utilice las funciones duraderas de Lambda cuando desee crear lógica dentro del modelo de programación conocido de Lambda, con pruebas locales, integración de IDE y su lenguaje de programación preferido. Utilice AWS Step Functions cuando necesite un diseño visual del flujo de trabajo, visibilidad entre equipos, más de 220 integraciones de servicios nativos o una infraestructura sin mantenimiento. Muchas aplicaciones se benefician de usar ambas opciones juntas.

Las funciones duraderas de AWS Lambda son actualmente compatibles con JavaScript, TypeScript, Python y Java. Obtenga más información sobre los tiempos de ejecución compatibles.

Para consultar la disponibilidad más reciente, consulte la página Capacidades de AWS por región.

Sí. Si bien el tiempo de espera por invocación sigue siendo de 15 minutos, las funciones duraderas de Lambda pueden suspenderse y reanudarse en varias invocaciones con capacidades de espera como temporizadores, devoluciones de llamada y condiciones de sondeo. Cuando se invocan funciones duraderas de forma asíncrona, el tiempo de espera de procesamiento duradero puede extenderse hasta un año, lo que permite casos de uso como flujos de trabajo de aprobación humana, recordatorios programados y canales de procesamiento de varios días. Para las funciones bajo demanda, no hay cargos de cómputo durante la suspensión.

El tiempo de espera (hasta 1 año) rige cuánto tiempo puede estar activo un proceso. El periodo de retención (hasta 90 días) rige cuánto tiempo se conservan el historial y los datos de puntos de control después de que el proceso alcanza un estado terminal. La retención no afecta a los procesamientos en curso. Consulte Configuración de funciones duraderas.

No. En el caso de las funciones bajo demanda, cuando se utilizan las funciones de espera del SDK de procesamiento duradero, no se cobran cargos de procesamiento durante la suspensión. Para obtener más información, consulte la página de precios y la Guía para desarrolladores.

Puede encapsular cada unidad de trabajo en un paso con reintentos automáticos. Si un paso falla después de los reintentos, el código del controlador puede detectar el error y llevar a cabo pasos de compensación, como reembolsar un pago o liberar una reserva. Dado que cada paso completado queda registrado con un punto de control, incluidas las compensaciones, el trabajo completado correctamente no se repite en los reintentos. Este patrón ayuda a crear procesos de varios pasos confiables, como flujos de trabajo de gestión de pedidos o de pagos, sin necesidad de escribir lógica personalizada de reintentos y seguimiento de estado.

El estado de procesamiento se almacena en un almacén de estados interno completamente administrado. Cada operación con punto de control, como un paso o una devolución de llamada, puede almacenar hasta 256 KB de datos. Este límite se aplica a los datos devueltos por la operación. Los datos procesados dentro de una operación, como la lectura y escritura de objetos grandes de S3, no cuentan en este límite. Si una operación necesita devolver un resultado de gran tamaño, puede configurar serializadores personalizados en el SDK para descargar cargas útiles a Amazon S3 o Amazon DynamoDB y pasar solo una referencia a través del punto de control.

Las funciones duraderas de Lambda utilizan el mismo grupo de simultaneidad por cuenta que las funciones de Lambda estándar. Los espacios de simultaneidad se liberan durante las esperas, por lo que miles de procesamientos pueden esperar sin consumir simultaneidad. Más información sobre las cuotas de AWS Lambda.

Puede probar las funciones duraderas de forma local sin credenciales de AWS con el SDK de procesamiento duradero para su lenguaje de programación compatible. La CLI de AWS SAM también admite la invocación local, las devoluciones de llamada y la administración de procesamiento duradero, lo que simplifica el desarrollo y la depuración antes de la implementación. Más información sobre cómo probar funciones duraderas.