Preguntas frecuentes sobre AWS Lambda

Para mejorar el desempeño, AWS Lambda puede optar por mantener una instancia de la función y reutilizarla para satisfacer una solicitud posterior, en lugar de crear una copia nueva. Para obtener más información acerca de cómo Lambda reutiliza instancias de funciones, consulte la documentación. No obstante, el código no debe asumir que siempre debe proceder de este modo.

Puede configurar cada función de Lambda con su propio almacenamiento efímero entre 512 MB y 10 240 MB, en incrementos de 1 MB. El almacenamiento efímero está disponible en el directorio /tmp de cada función.

Cada función tiene acceso a 512 MB de almacenamiento sin costo adicional. Si configura sus funciones con más de 512 MB de almacenamiento efímero, se le cobrará según la cantidad de almacenamiento que configure y el tiempo de ejecución de su función, medido en incrementos de 1 ms. A modo de comparación, en la región Este de EE. UU. (Ohio), el precio del almacenamiento efímero de AWS Fargate es de 0,000111 USD por GB/hora o 0,08 USD por GB/mes. El precio por volumen de almacenamiento gp3 de Amazon EBS en la región Este de EE. UU. (Ohio) es de 0,08 USD por GB/mes. El precio del almacenamiento efímero de AWS Lambda es de 0,0000000309 USD por GB/segundo o 0,000111 USD por GB/hora y 0,08 USD por GB/mes. Para obtener más información, consulte los precios de AWS Lambda.

Puede utilizar las métricas de AWS CloudWatch Lambda Insights para monitorear su uso del almacenamiento efímero. Para obtener más información, consulte la documentación de AWS CloudWatch Lambda Insights.

Si su aplicación necesita un almacenamiento persistente y duradero, considere utilizar Amazon S3 o Amazon EFS. Si su aplicación requiere el almacenamiento de datos que necesita el código en una única invocación de función, considere usar el almacenamiento efímero de AWS Lambda como caché transitorio. Para obtener más información, consulte Elegir entre opciones de almacenamiento de datos de AWS Lambda en aplicaciones web.

Sí. Sin embargo, si su aplicación necesita almacenamiento persistente, considere utilizar Amazon EFS o Amazon S3. Cuando habilita la simultaneidad aprovisionada para la función, su código de inicialización se ejecuta durante la asignación y cada pocas horas, ya que las instancias en ejecución de la función se reciclan. Puede ver el tiempo de inicialización en los registros y rastreos después de que una instancia procesa una solicitud. Sin embargo, la inicialización se factura incluso si la instancia nunca procesa una solicitud. Este comportamiento de inicialización de simultaneidad aprovisionada puede afectar la forma en que la función interactúa con los datos que almacena en el almacenamiento efímero, incluso cuando la función no procesa solicitudes. Para obtener más información sobre la simultaneidad aprovisionada, consulte la documentación correspondiente.

Puede utilizar las métricas de AWS CloudWatch Lambda Insights para monitorear su uso del almacenamiento efímero. Para obtener más información, consulte la documentación de AWS CloudWatch Lambda Insights.

Si utiliza Node.js o Python, puede crear el código para la función con el editor de código de la consola de AWS Lambda, que permite crear y probar funciones, así como ver los resultados de las ejecuciones de funciones en un entorno sólido tipo IDE. Vaya a la consola para comenzar.

También puede comprimir el código (y cualquier biblioteca dependiente) en un archivo ZIP y cargarlo desde su entorno local mediante la consola de AWS Lambda, o bien especificar la ubicación de Amazon S3 en la que se encuentra el archivo ZIP. Las cargas no pueden tener un volumen superior a 50 MB (en formato comprimido). Puede utilizar el complemento de AWS Eclipse para diseñar e implementar funciones de Lambda en Java. Puede utilizar el complemento de Visual Studio para diseñar e implementar funciones de Lambda en C# y Node.js.

Puede comprimir el código (y cualquier biblioteca dependiente) en un archivo ZIP y cargarlo desde su entorno local mediante la interfaz de línea de comandos (CLI) de AWS, o bien especificar la ubicación de Amazon S3 en la que se encuentra el archivo ZIP. Las cargas no pueden tener un volumen superior a 50 MB (en formato comprimido). Consulte la Guía de introducción a Lambda para comenzar.

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 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, deberá incluir lógica en su código de la función AWS Lambda.

Puede ajustar y proteger los recursos asociados a su función de Lambda mediante la API o la consola de Lambda. Para obtener más información, consulte la documentación.

Sí, puede empaquetar cualquier código (marcos, SDK, bibliotecas, etc.) como una capa de Lambda, y administrarlo y compartirlo fácilmente a través de múltiples funciones.

AWS Lambda monitorea automáticamente sus funciones e informa las métricas en tiempo real a través de Amazon CloudWatch, como las solicitudes totales, el uso simultáneo a nivel de funciones y a nivel de cuentas, 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 la 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.

AWS Lambda se integra automáticamente con Amazon CloudWatch logs y crea un grupo de registros para cada función de Lambda y ofrece entradas básicas de registros de eventos del ciclo de vida de la aplicación, incluido el registro de los recursos consumidos cada vez que se usa esa función. Puede agregar declaraciones de registro adicionales al código con facilidad. También puede realizar llamadas a API de registro de terceros en la función de Lambda. Consulte la resolución de problemas con las funciones de Lambda para obtener más información. Se aplicarán las tarifas de los logs de Amazon CloudWatch.

En el modelo de recursos de AWS Lambda, debe elegir la cantidad de memoria que desea para su función y, posteriormente, se asignará el volumen proporcional de potencia 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 las funciones.

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 niveles de precios con descuento para la duración bajo demanda mensual de la característica que supera ciertos umbrales. Los niveles de precios están disponibles para las características que se ejecutan en arquitecturas x86 y Arm. Los niveles de precios de Lambda se aplican a la duración bajo demanda mensual agregada de sus características que se ejecutan en la misma arquitectura (x86 o Arm, respectivamente), en la misma región y dentro de la cuenta. Si utiliza la facturación unificada en AWS Organizations, los niveles de precios se aplican a la duración mensual agregada de sus características que se ejecutan en la misma arquitectura, en la misma región y en todas las cuentas de la organización. Por ejemplo, si ejecuta características x86 de Lambda en la región Este de EE. UU. (Ohio), pagará 0,0000166667 USD por cada GB/segundo durante los primeros 6 mil millones de GB/segundo por mes, 0,0000150000 USD por cada GB/segundo para los próximos 9 mil millones de GB/segundo por mes y 0,0000133334 USD por cada GB/segundo que exceda los 15 mil millones de GB/segundo por mes en esa región. El precio de las solicitudes, la simultaneidad aprovisionada y la duración de esta no se modifican. Para obtener más información, consulte los precios de AWS Lambda

Sí. El uso de Lambda que cubre el compromiso de Savings Plan por hora se factura según el descuento y la tarifa del CSP aplicables. El uso restante que no cubra el contrato se facturará según la tarifa correspondiente al nivel de la duración de la función de agregación mensual.

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

Los eventos se transfieren a una función de Lambda como un parámetro de entrada de evento. En el caso de las fuentes de eventos en las que los eventos llegan por lotes, como Amazon SQS, Amazon Kinesis y Amazon DynamoDB Streams, el parámetro de eventos puede incluir varios eventos en una sola llamada, en función del tamaño del lote que solicite. Para obtener más información sobre las notificaciones de eventos de Amazon S3, visite Configuración de notificaciones para eventos de Amazon S3. Para obtener más información sobre Amazon DynamoDB Streams, visite la Guía para desarrolladores de DynamoDB Streams. Para obtener más información sobre cómo invocar funciones de Lambda mediante Amazon SNS, consulte la Guía para desarrolladores de Amazon SNS. Para obtener más información sobre los eventos de Amazon Cognito, consulte Amazon Cognito. Para obtener más información sobre los registros de AWS CloudTrail y cómo auditar las llamadas a la API en los servicios de AWS, consulte AWS CloudTrail.

AWS Lambda permite realizar agregaciones basadas en el tiempo (como recuento, máximo, suma, promedio, etc.) en periodos breves de hasta 15 minutos para sus datos en Amazon Kinesis o Amazon DynamoDB Streams en una sola partición lógica. Esto ofrece la posibilidad de configurar fácilmente análisis sencillos para la aplicación basada en eventos sin aumentar la complejidad a nivel de arquitectura, ya que la lógica empresarial y de análisis se pueden ubicar en la misma función. Lambda permite realizar agregaciones en una ventana de saltos de tamaño constante de 15 minutos como máximo, según la marca temporal del evento. Amazon Kinesis Data Analytics permite crear aplicaciones de análisis más complejas que admiten opciones de procesamiento flexibles y una sólida tolerancia a errores con procesamiento único sin duplicados y análisis que se pueden realizar en una secuencia de datos completa en múltiples particiones lógicas. Con KDA, puede analizar datos en varios tipos de ventanas de agregación (ventana de saltos de tamaño constante, ventana escalonada, ventana deslizante, ventana de sesión) mediante el uso del tiempo del evento o el tiempo de procesamiento.
 

En primer lugar, configure la alarma para que envíe notificaciones de Amazon SNS. A continuación, en la consola de AWS Lambda, seleccione una función de Lambda y asóciela con ese tema de Amazon SNS. Consulte la Amazon CloudWatch Developer Guide para obtener más información sobre la configuración de alarmas de Amazon CloudWatch.

En la consola de AWS Lambda, seleccione la función que desee que se active cuando se sincronice cualquier conjunto de datos asociado con un grupo de identidades de Amazon Cognito. Esta misma funcionalidad también se encuentra disponible a través del SDK y la CLI de AWS. Visite la página de Amazon Cognito para obtener más información acerca de cómo utilizar Amazon Cognito para compartir y sincronizar datos en los dispositivos de un usuario.

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.

Cargue el código que desea que AWS Lambda ejecute y, a continuación, invóquelo desde la aplicación móvil mediante el SDK de AWS Lambda incluido en el SDK para móviles de AWS. Puede efectuar llamadas directas (síncronas) para recuperar o comprobar los datos en tiempo real, así como llamadas asíncronas. También puede definir una API personalizada mediante Amazon API Gateway e invocar las funciones de Lambda a través de cualquier cliente compatible con REST. Para obtener más información sobre el SDK para móviles de AWS, visite la página del AWS Mobile SDK. Para obtener más información sobre Amazon API Gateway, visite la página de Amazon API Gateway.

Puede elegir a partir de una colección de aplicaciones sin servidor publicadas por desarrolladores, compañías y socios de la comunidad de AWS con el servicio Repositorio de aplicaciones sin servidor de AWS. Una vez que haya encontrado una aplicación, puede configurarla e implementarla directamente desde la consola de Lambda.

Puede automatizar el proceso de lanzamiento de la aplicación sin servidor con AWS CodePipeline y AWS CodeDeploy. CodePipeline es un servicio de entrega continua que permite modelar, visualizar y automatizar los pasos necesarios para lanzar la aplicación sin servidor. CodeDeploy ofrece un motor de automatización de implementaciones para las aplicaciones basadas en Lambda. CodeDeploy le permite organizar implementaciones de acuerdo con metodologías de prácticas recomendadas, como las implementaciones lineales y de valor controlado. Además, lo ayuda a definir las medidas necesarias para verificar que el código implementado recientemente sea seguro, estable y esté listo para implementarse plenamente en producción.
 

Para obtener más información sobre CI/CD sin servidor, consulte nuestra documentación.

Para comenzar, visite la consola de AWS Lambda y descargue uno de nuestros proyectos. El archivo que descargue contendrá un archivo de AWS SAM file (que define los recursos de AWS de la aplicación) y un archivo .ZIP (que incluye el código de la función). A continuación, puede usar los comandos de AWS CloudFormation para empaquetar e implementar la aplicación sin servidor que acaba de descargar. Para obtener más detalles, consulte nuestra documentación.

Puede utilizar AWS Step Functions para coordinar una serie de funciones de AWS Lambda en un orden específico. Puede invocar numerosas funciones de Lambda de manera secuencial, pasando la salida de una a otra, y/o simultáneamente, y Step Functions mantendrá el estado durante las ejecuciones.

Puede habilitar la función Lambda para el rastreo con AWS X-Ray. Para ello, debe añadir permisos de X-Ray al rol de ejecución de la función de Lambda y cambiar el “modo de rastreo” de la función a “activo”. Cuando X-Ray está habilitado para la función Lambda, AWS Lambda emitirá información de rastreo a X-Ray con respecto a la sobrecarga del servicio Lambda incurrida al invocar la función. Esto le proporcionará información sobre la sobrecarga del servicio Lambda, el tiempo de inicialización de la función y el tiempo de ejecución de la función. Además, puede incluir el SDK de X-Ray en el paquete de implementación Lambda para crear sus propios segmentos de rastreo, anotar los rastreos o ver segmentos de rastreo para llamadas descendentes realizadas desde su función Lambda. Los SDK de X-Ray están actualmente disponibles para Node.js y Java. Consulte la sección sobre Resolución de problemas de aplicaciones basadas en Lambda para obtener más información. Se aplicarán las tarifas de AWS X-Ray.

Sí. Puede crear aplicaciones sin servidor altamente escalables y seguras basadas en Lambda que se conectan a bases de datos relacionales mediante el Amazon RDS Proxy, un proxy de base de datos con alta disponibilidad que administra miles de conexiones simultáneas a bases de datos relacionales. Actualmente, el proxy de RDS admite las bases de datos Aurora y MySQL. Puede comenzar a utilizar el proxy de RDS a través de la consola de Amazon RDS o la consola de AWS Lambda. Las aplicaciones sin servidor que utilizan grupos de conexiones completamente administrados del proxy de RDS se facturarán según los precios del proxy de RDS.

La especificación es de código abierto bajo Apache 2.0, con lo que es posible para usted y otras personas adoptar e incorporar AWS SAM a herramientas de creación, implementación, monitoreo y administración con una licencia que admite el uso comercial. Aquí puede acceder al repositorio de AWS SAM en GitHub.

Hay tres diferencias principales entre las funciones creadas con archivos ZIP y con imágenes de contenedor:

1. Las funciones creadas con archivos ZIP tienen un tamaño máximo de paquete de código de 250 MB descomprimido, mientras que las creadas con imágenes de contenedor tienen un tamaño máximo de 10 GB. 
2. Lambda utiliza Amazon ECR como almacenamiento de código subyacente para funciones definidas como imágenes de contenedor, por lo que es posible que una función no se pueda invocar cuando la imagen subyacente se elimina de ECR. 
3. A las funciones ZIP se les aplican parches automáticamente para obtener las últimas correcciones de errores y seguridad en tiempo de ejecución. Las funciones definidas como imágenes de contenedores son inmutables y los clientes son responsables de los componentes empaquetados en su función. Los clientes pueden aprovechar las imágenes base que AWS proporciona y actualiza periódicamente para la seguridad y la corrección de errores, con los parches más recientes disponibles.

No hay ningún cargo adicional por empaquetar e implementar funciones como imágenes de contenedor en AWS Lambda. Cuando invoca su función implementada como una imagen de contenedor, paga el precio habitual por las solicitudes y la duración de la ejecución. Para obtener más información, consulte Precios de AWS Lambda. Se le cobrará por almacenar las imágenes de contenedor en Amazon ECR a los precios estándar de ECR. Para obtener más información, consulte Precios de Amazon ECR.

El emulador de interfaz de versión ejecutable es un proxy para la API Runtime de Lambda que permite a los clientes probar localmente la función de Lambda empaquetada como una imagen de contenedor. Es un servidor web ligero que convierte las solicitudes HTTP en eventos JSON y emula la API Runtime de Lambda. Permite probar localmente las funciones con herramientas conocidas, como cURL y la CLI de Docker (al probar funciones empaquetadas como imágenes de contenedor). También simplifica la ejecución de la aplicación en servicios informáticos adicionales. Es posible incluir el emulador de interfaz de tiempo de ejecución de Lambda en la imagen de contenedor para que acepte solicitudes HTTP de forma nativa, en lugar de los eventos JSON necesarios para la implementación en Lambda. Este componente no emula el organizador de Lambda ni las configuraciones de seguridad y autenticación. El emulador de interfaz de tiempo de ejecución es de código abierto en GitHub. Puede comenzar al descargarlo e instalarlo en su equipo local.

Los clientes pueden agregar el emulador de interfaz de tiempo de ejecución como punto de entrada a la imagen de contenedor o empaquetarlo como un contenedor de tipo sidecar para garantizar que la imagen de contenedor ahora acepte solicitudes HTTP en lugar de eventos JSON. Esto simplifica los cambios necesarios para ejecutar la imagen de contenedor en servicios informáticos adicionales. Los clientes serán responsables de garantizar que siguen todas las prácticas recomendadas de seguridad, rendimiento y simultaneidad en el entorno elegido. El RIE viene empaquetado previamente en las imágenes proporcionadas por AWS Lambda y está disponible de forma predeterminada en la CLI de AWS SAM. Los proveedores de imágenes base pueden utilizar la documentación para proporcionar la misma experiencia para las imágenes base.

Puede implementar una aplicación en contenedores en AWS Lambda si cumple los siguientes requisitos:

1. La imagen de contenedor debe implementar la API Runtime de Lambda. Hemos puesto a disposición general un conjunto de paquetes de software de código abierto, clientes de interfaz de tiempo de ejecución (RIC), que implementan la API Runtime de Lambda, lo que permite ampliar la compatibilidad de Lambda con sus imágenes base preferidas.
2. La imagen de contenedor debe poder ejecutarse en un sistema de archivos de solo lectura. Su código de función puede acceder a un almacenamiento de directorio de escritura /tmp de 512 MB. Si utiliza una imagen que requiere un directorio raíz de escritura, configúrelo para escribir en el directorio /tmp.
3. El usuario predeterminado de Lambda puede leer los archivos necesarios para la ejecución del código de la función. Lambda define un usuario de Linux predeterminado con permisos mínimos que respeta las prácticas recomendadas de seguridad. Verifique que el código de la aplicación no dependa de archivos restringidos por otros usuarios de Linux para su ejecución.
4. Es una imagen de contenedor basada en Linux.

AWS 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 garantizar la resiliencia, Lambda mantiene copias en caché de la instantánea y les aplica automáticamente actualizaciones de software, como actualizaciones de versión ejecutable y parches de seguridad.

Lambda SnapStart es una configuración sencilla de nivel de función que puede habilitarse para funciones nuevas y existentes mediante la API de Lambda, la Consola de administración de AWS, la interfaz de la línea de comandos (CLI) de AWS, AWS SDK, Cloud Development Kit (CDK) de AWS, AWS CloudFormation y el modelo de aplicaciones sin servidor (SAM) de AWS. 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 que sus funciones consigan tiempos de inicio hasta más rápidos al reducir la latencia variable en la que se incurre durante la ejecución del 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í. Puede configurar Lambda SnapStart para las funciones que se ejecutan en arquitecturas x86 y Arm.

Sí. Si su código asume la singularidad del estado, debe evaluar la resistencia de este a las operaciones de instantánea (por ejemplo, a ser clonado y reanudado). Para obtener más información sobre las consideraciones de singularidad con Lambda SnapStart, consulte la documentación y el blogsobre la comprensión de la singularidad en las instantáneas de máquinas virtuales con Lambda SnapStart.

Sí. Puede implementar su propia lógica de software antes de crear una instantánea (generar un punto de control) y después de restaurar una instantánea con enlaces en tiempo de ejecución. Para obtener más información, consulte la documentación de Lambda SnapStart.

Sí, se le cobrará por almacenar en caché una instantánea durante el período 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 del volumen de memoria asignado 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 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 gestionadas de Java compatibles, que solo pueden almacenar en caché una instantánea durante un máximo de 14 días.

Como todas las funciones de Lambda, los cargos por duración se aplican a las funciones de SnapStart. En el caso de las funciones configuradas con SnapStart, la duración incluye el tiempo que se tarda en cargar la versión ejecutable, cualquier código que se ejecute en un enlace de versión ejecutable y el código de inicialización ejecutado cuando se crean copias de instantáneas creadas para garantizar la resiliencia.

Con Lambda SnapStart para Python y.NET, las instantáneas de las funciones permanecen activas mientras la función esté activa. En el caso de las funciones de Java, la instantánea asociada a una función publicada caduca si permanece inactiva durante más de 14 días.

Las instantáneas se cifran por defecto con claves de AWS Key Management Service (KMS) exclusivas del cliente, propiedad del servicio Lambda y administradas por este. Los clientes también pueden cifrar las instantáneas con una clave de KMS propiedad del cliente y administrada por él.

Puede configurar la simultaneidad en su función a través de la consola de administración de AWS, la API de Lambda, la CLI de AWS 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 activadas. 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.

Los lenguajes interpretados como Python, Java y Node generalmente no requieren recopilación a menos que el código haga referencia a las bibliotecas que usan componentes específicos de la arquitectura. En esos casos, tendrá que proporcionar las bibliotecas orientadas a arm64. Para obtener más detalles, consulte la página Introducción a AWS Graviton. Los lenguajes no interpretados requerirán la compilación de su código para que esté orientado a arm64. Aunque los compiladores más modernos producirán código compilado para arm64, tendrá que implementarlo en un entorno basado en arm para probarlo. Para obtener más información sobre el uso de funciones de Lambda con Graviton2, consulte la documentación.

En el momento del lanzamiento, los clientes pueden usar Python, Node.js, Java, Ruby, .Net Core, Custom Runtime (provided.al2) e imágenes OCI Base. Para obtener más información, consulte Versión ejecutable de AWS Lambda.

Cada carga de trabajo es única y le recomendamos a los clientes que prueben sus funciones para determinar la mejora en el rendimiento del precio que podrían ver. Para ello, recomendamos utilizar la herramienta AWS Lambda Power Tuning. Recomendamos comenzar con los backends web y móvil, los datos y el procesamiento de flujos cuando pruebe sus cargas de trabajo para determinar las posibles mejoras de rendimiento en el precio.

Los desarrolladores pueden conectar un sistema de archivos de EFS existente a una función de Lambda con facilidad mediante un Punto de acceso de EFS con la consola, la CLI o el SDK. Cuando se invoca la función por primera vez, el sistema de archivos se monta automáticamente y se pone a disposición del código de la función. Consulte la documentación para obtener más información.

No se aplican cargos adicionales por utilizar Amazon EFS para AWS Lambda. Los clientes pagan el precio estándar para AWS Lambda y Amazon EFS. Cuando Lambda y EFS se usan en la misma zona de disponibilidad, los clientes no pagan las transferencias de datos. Sin embargo, si usan la interconexión de VPC para el acceso entre cuentas, se les cobrarán cargos por transferencia de datos. Para obtener más información, consulte Precios.

Puede configurar una URL de función para su función con la consola de administración de AWS, la API de AWS Lambda, la AWS CLI, AWS CloudFormation y AWS Serverless Application Model. Las URL de las funciones se pueden habilitar en la versión no autorizada $LATEST de su función o en cualquier alias de función. Para obtener más información sobre la configuración de una URL de función, consulte la documentación.

Sí. Las funciones de Lambda se pueden habilitar en una función o un alias de función. Si no se especifica ningún alias, la URL apuntará a $LATEST de forma predeterminada. Las URL de las funciones no pueden dirigirse a la versión de una función individual.

El uso de las URL de las funciones es gratuito. Paga el precio estándar para AWS Lambda. Para obtener más información, consulte los Precios de AWS Lambda.

Lambda@Edge permite ejecutar código en ubicaciones de AWS a nivel global sin aprovisionar ni administrar servidores, y responder así a los usuarios finales con la menor latencia de red. 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. Por lo tanto, los casos de uso en los que desea tomar decisiones acerca de cómo proporcionar contenido en función de las características de los usuarios (p. ej., ubicación, dispositivo del cliente, etc.) ya se pueden ejecutar y proporcionar cerca de los usuarios sin tener que dirigirlos de vuelta a un servidor centralizado.

Puede asociar funciones de Lambda existentes con eventos de CloudFront para 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.

Sus funciones se activarán automáticamente como respuesta a los siguientes eventos de Amazon CloudFront:

• Solicitud del lector: este evento tiene lugar cuando un usuario final o un dispositivo en Internet realiza una solicitud HTTP(S) a CloudFront y la solicitud llega a la ubicación de borde más cercana a ese usuario.
• Respuesta del espectador: este evento tiene lugar cuando el servidor de CloudFront situado en el borde está listo para responder al usuario final o dispositivo que realizó la solicitud.
• Solicitud del origen: este evento tiene lugar cuando el servidor de CloudFront situado en el borde todavía no tiene el objeto solicitado en su caché, y la solicitud del lector está lista para enviarse al servidor web de origen del backend (p. ej., Amazon EC2, el equilibrador de carga de aplicaciones o Amazon S3).
• Respuesta del origen: este evento tiene lugar cuando el servidor de CloudFront situado en el borde recibe una respuesta del servidor web de origen del backend.

La diferencia es que API Gateway y Lambda son servicios regionales. La utilización de Lambda@Edge y Amazon CloudFront le permite ejecutar tareas lógicas en varias ubicaciones de AWS localizadas donde se encuentran los espectadores finales.

No. AWS Lambda es un servicio diseñado para ejecutar numerosas instancias de las funciones simultáneamente. Sin embargo, AWS Lambda tiene una limitación controlada de seguridad predeterminada para el número de ejecuciones simultáneas por cuenta por región (consulte aquí para obtener información acerca de las limitaciones controladas de seguridad predeterminadas). También puede controlar el número máximo de ejecuciones simultáneas 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 ejecución simultánea, puede utilizar las Service Quotas para solicitar una solicitud de 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 de ejecución simultánea predeterminado se aplica a nivel de 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 ejecuciones simultáneas 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 a nivel de función, lo que significa que cada función de la cuenta se escala de forma independiente de las demás funciones.

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.

El usuario puede conceder permisos a su función de Lambda para que obtenga acceso a otros recursos utilizando una función 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 de 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 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 Lambda Private Networking with 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 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 tiene costo adicional. Paga el precio estándar para AWS Lambda. Para obtener más información, consulte Precios.

Para proporcionarle una experiencia de registro simplificada y mejorada de forma predeterminada, AWS Lambda ofrece controles de registro avanzados, como la capacidad de capturar de forma nativa los registros de funciones de Lambda en formato estructurado JSON, controlar el filtrado a nivel de registro de los registros de funciones de Lambda sin realizar ningún cambio 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 a nivel de 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, la CLI de AWS, el modelo de aplicaciones sin servidor (SAM) de AWS y AWS CloudFormation. Para obtener más información, visite 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 for 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 monitoreo del rendimiento de la aplicación (APM) que permite a los desarrolladores y operadores monitorear 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.

Puede habilitar Application Signals para su función con un solo clic en la sección “Herramientas operativas y de monitoreo” de la pestaña Configuración de la consola Lambda. Tras habilitar Application Signals, puede ver los paneles prediseñados, el mapa de servicios y mucho más, y analizar el rendimiento y el estado de sus aplicaciones sin servidor en la consola de CloudWatch. Para obtener más información, consulte la guía para desarrolladores de Lambda y la guía para desarrolladores de Application Signals. Visite la página de precios de CloudWatch para obtener más información sobre cómo se le cobra por usar Application Signals con las funciones de Lambda.

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.

Para usar Live Tail para la función de Lambda, visite la consola de Lambda y haga clic en el botón “Abrir CloudWatch Live Tail” en el editor de código. Para obtener más información, consulte la Guía para desarrolladores de Lambda. Visite la página de precios de CloudWatch para obtener más información sobre cómo se le cobra por usar Live Tail con sus funciones de Lambda.

Puede usar herramientas estándares como Mavel o Gradle para compilar la función de Lambda. Su proceso de creación debería ser idéntico al proceso de creación que utilizaría para compilar cualquier código de Java que dependa del AWS SDK. Ejecute la herramienta de compilación de Java en los archivos fuente e incluya el AWS SDK 1.9 o superior con dependencias transitivas en el classpath. Para obtener más detalles, consulte nuestra documentación.

Sí. Puede utilizar paquetes NPM, así como paquetes a medida. Obtenga más información aquí.

Sí. El entorno de pruebas integrado de Lambda le permite ejecutar scripts por lotes (“shell”), otros tiempos de ejecución de lenguajes, rutinas de utilidades y ejecutables. Obtenga más información aquí.

Sí. Todos los módulos nativos enlazados estáticamente se pueden incluir en el archivo ZIP que cargue, así como los módulos enlazados dinámicamente compilados con un rpath que apunte al directorio raíz de su función Lambda. Obtenga más información aquí.

Sí. Puede utilizar el comando child_process de Node.js para ejecutar un binario que haya incluido en la función o cualquier ejecutable de Amazon Linux que la función pueda ver. Como alternativa, existen varios paquetes NPM que envuelven los binarios de la línea de comandos, como node-ffmpeg. Obtenga más información aquí.

Para implementar una función de Lambda escrita en Node.js, comprima el código Javascript y las bibliotecas dependientes en un archivo ZIP. Puede cargar el archivo ZIP desde su entorno local, o bien, especificar la ubicación de Amazon S3 en la que se encuentra el archivo ZIP. Para obtener más detalles, consulte nuestra documentación.

Un paquete de implementación de PowerShell Lambda es un archivo de ZIP que contiene un script de PowerShell, los módulos de PowerShell requeridos para su script de PowerShell y los ensambles necesarios para alojar el núcleo de PowerShell. Entonces use el módulo de AWSLambdaPSCore que puede instalar de la Galería de PowerShell para crear su paquete de implementación de PowerShell Lambda.

Cargue su artefacto ejecutable de Go como un archivo ZIP a través de la CLI de AWS o de la consola de Lambda y seleccionar el tiempo de ejecución go1.x. Con Lambda, puede utilizar las herramientas nativas de Go para compilar y empaquetar el código. Consulte la documentación para obtener más detalles. 

Puede ver la lista de versiones compatibles aquí.

No. AWS Lambda ofrece una única versión del sistema operativo y del tiempo de ejecución del lenguaje administrado para todos los usuarios del servicio. Puede traer su propio entorno de ejecución de lenguaje común para usarlo en Lambda.

Puede usar Amazon Step Functions para coordinar varias funciones de Lambda de invocación. Puede invocar numerosas funciones de Lambda de manera secuencial, pasando la salida de una a otra, y/o simultáneamente. Para obtener más detalles, consulte nuestra documentación.