Preguntas frecuentes sobre AWS Lambda

El código que ejecuta en AWS Lambda se carga como una “función de Lambda”. Cada función tiene asociada información sobre la configuración, como su nombre, descripción, punto de entrada y requisitos en cuanto a recursos. El código debe escribirse en un estilo “sin estado”, es decir, que ha de asumirse que no existe afinidad con la infraestructura informática subyacente. El acceso al sistema de archivos local, los procesos secundarios y los elementos similares no deben extenderse más allá del ciclo de vida de la solicitud. Cualquier estado persistente debe almacenarse en Amazon S3, Amazon DynamoDB, Amazon EFS o en otro servicio de almacenamiento disponible en Internet. Las funciones de Lambda pueden incluir bibliotecas, incluso las nativas.

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 configurar cada función de Lambda con su propio almacenamiento efímero entre 512 MB y 10 240 MB, en incrementos de 1 MB mediante la consola de AWS Lambda, la API de AWS Lambda o la plantilla de AWS CloudFormation durante la creación o la actualización de la función.

Sí. Todos los datos almacenados en el almacenamiento efímero se cifran en reposo con una clave administrada por AWS.

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 configurar cada función de Lambda con su propio almacenamiento efímero entre 512 MB y 10 240 MB, en incrementos de 1 MB mediante la consola de AWS Lambda, la API de AWS Lambda o la plantilla de AWS CloudFormation durante la creación o la actualización de la función.

Sí. Todos los datos almacenados en el almacenamiento efímero se cifran en reposo con una clave administrada por AWS.

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.

Mantener las funciones sin estado permite a AWS Lambda lanzar rápidamente tantas copias de la función como resulten necesarias para escalar hasta la tasa de eventos entrantes. A pesar de que el modelo de programación de AWS Lambda no tiene estado, el código puede obtener acceso a datos con estado al llamar a otros servicios web, como Amazon S3 o Amazon DynamoDB.

Sí. AWS Lambda le permite usar un lenguaje normal y las características del sistema operativo, como crear subprocesos y procesos adicionales. Los recursos asignados a la función de Lambda, entre otros, la memoria, el tiempo de ejecución, el disco y el uso de red, deben compartirse entre todos los subprocesos y procesos que esta utiliza. Puede lanzar procesos utilizando cualquier lenguaje compatible con Amazon Linux.

Lambda intenta imponer las menores restricciones posibles a las actividades normales del sistema operativo y del lenguaje, pero hay algunas actividades que están desactivadas: las conexiones de red entrantes están bloqueadas por AWS Lambda, y para las conexiones salientes, solo se admiten sockets TCP/IP y UDP/IP, y las llamadas al sistema ptrace (depuración) están bloqueadas. El tráfico a través del puerto TCP 25 también está bloqueado para evitar el spam.

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.

No tiene que escalar las funciones de Lambda – AWS Lambda se encarga de escalarlas automáticamente. Cada vez que se recibe una notificación de evento para una función, AWS Lambda encuentra rápidamente capacidad disponible en su flota informática y ejecuta el código. Dado que se trata de código sin estado, AWS Lambda puede iniciar tantas copias de la función como sean necesarias sin que se produzcan largos retrasos de implementación y configuración. No existen límites fundamentales para escalar una función. AWS Lambda asignará capacidad de manera dinámica para satisfacer la tasa de eventos entrantes.

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 clientes que ejecutan cargas de trabajo con uso intensivo de memoria o cómputo ahora pueden utilizar más memoria para sus funciones. Las funciones de memoria más grandes ayudan a que las aplicaciones con varios subprocesos se ejecuten más rápidamente, lo que las hace ideales para aplicaciones de uso intensivo de datos y cómputo, como el machine learning, los trabajos por lotes y de ETL (extracción, transformación y carga), el modelado financiero, la genómica, la informática de alto rendimiento y el procesamiento de contenidos multimedia.

Se pueden configurar las funciones de AWS Lambda para que se ejecuten durante un plazo de hasta 15 minutos por ejecución. Puede establecer un tiempo de espera de cualquier valor entre 1 segundo y 15 minutos.

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í. Puede usar Compute Savings Plans para ahorrar dinero en AWS Lambda, además de Amazon EC2 y AWS Fargate. Compute Savings Plans ofrece hasta el 17 % de descuento en Duración, Simultaneidad aprovisionada y Duración (simultaneidad aprovisionada). Compute Savings Plans no ofrece descuentos en solicitudes de su factura de Lambda. Sin embargo, su compromiso con Compute Savings Plans puede aplicarse a solicitudes con tarifa normal.

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.

Los períodos de implementación pueden variar en función del tamaño del código, pero normalmente se pueden realizar llamadas a las funciones de AWS Lambda unos segundos después de cargar el código.

Sí. Puede incluir su propia copia de una biblioteca (incluido el SDK de AWS) para utilizar una versión diferente a la que AWS Lambda proporciona de forma predeterminada.

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.

Un origen de eventos es un servicio de AWS o una aplicación creada por un desarrollador que produce eventos que activan la ejecución de una función de AWS Lambda. Algunos servicios publican estos eventos en Lambda al invocar directamente la función en la nube (por ejemplo, Amazon S3). Lambda también puede sondear recursos en otros servicios que no publican eventos en Lambda. Por ejemplo, Lambda puede extraer registros de una transmisión de Amazon Kinesis o de una cola de Amazon SQS y ejecutar una función de Lambda para cada mensaje obtenido. Muchos otros servicios, como AWS CloudTrail, pueden actuar como fuentes de eventos simplemente iniciando sesión en Amazon S3 y utilizando las notificaciones de buckets de S3 para activar las funciones de AWS Lambda

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.

En la consola de AWS Lambda, puede seleccionar una función y asociarla con las notificaciones de un bucket de Amazon S3. De manera alternativa, puede usar la consola de Amazon S3 y configurar las notificaciones del bucket para enviarlas a la función de AWS Lambda. Esta misma funcionalidad también se encuentra disponible a través del SDK y la CLI de AWS.

Puede activar una función de Lambda en las actualizaciones de la tabla de DynamoDB al suscribir la función de Lambda a la transmisión de DynamoDB asociada a la tabla. Para asociar una transmisión de DynamoDB a una función de Lambda, puede usar la consola de Amazon DynamoDB, la consola de AWS Lambda o el API registerEventSource de Lambda.

En la consola de AWS Lambda, puede seleccionar una función de Lambda y asociarla con una transmisión de Amazon Kinesis que pertenezca a la misma cuenta. Esta misma funcionalidad también se encuentra disponible a través del SDK y la CLI de AWS.

Los registros de las transmisiones de Amazon Kinesis y DynamoDB enviados a la función de AWS Lambda se serializan estrictamente por fragmento. Por lo tanto, si coloca dos registros en el mismo fragmento, Lambda garantiza que la función de Lambda se invoque correctamente con el primer registro antes de invocarse con el segundo. Si se agota el tiempo de espera de la invocación, esta se limita o se produce cualquier otro error, Lambda volverá a intentar realizarla hasta que se efectúe con éxito (o el registro venza a las 24 horas) antes de pasar al siguiente registro. El orden de los registros en los distintos fragmentos no se garantiza. El procesamiento de cada fragmento se realiza de manera simultánea.

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.
 

	AWS Lambda	Amazon KDA
Ventana de saltos de tamaño constante	Sí	Sí
Ventana escalonada	No	Sí
Ventana deslizante	No	Sí
Ventana de sesión	No	Sí
Enriquecimiento	No	Sí
Tablas de referencia y entradas conjuntas	No	Sí
Flujo de entrada dividido	No	Sí
Procesamiento único	No	Sí
Tiempo máximo de la ventana	15 minutos	Sin límite
Alcance de la agregación	Partición/fragmento	Flujo
Semántica del tiempo	Tiempo del evento	Tiempo del evento, tiempo de procesamiento

En la consola de AWS Lambda, puede seleccionar una función de Lambda y asociarla con un tema de Amazon SNS. Esta misma funcionalidad también se encuentra disponible a través del SDK y la CLI de AWS.

Desde la consola de Amazon SES, puede configurar la regla de recepción para que Amazon SES entregue los mensajes a una función de AWS Lambda. La misma funcionalidad se encuentra disponible a través del SDK y la CLI de AWS.

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.

AWS Lambda es un servicio diseñado para procesar eventos en cuestión de milisegundos. La latencia aumentará inmediatamente después de crear o actualizar una función de Lambda, o bien si dicha función no se ha usado recientemente.

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 invocar una función de Lambda a través de HTTPS mediante la definición de una API de RESTful personalizada con Amazon API Gateway. Esto proporciona un punto de enlace para la función que puede responder a llamadas de REST, como GET, PUT y POST. Obtenga más información sobre el uso de AWS Lambda con Amazon API Gateway.

Cuando la llamada se efectúa mediante el SDK para móviles de AWS, las funciones de AWS Lambda obtienen detalles sobre el dispositivo y la aplicación que han efectuado la llamada a través del objeto "context" de manera automática.

Cuando la aplicación utiliza la identidad de Amazon Cognito, los usuarios finales se pueden autenticar con una gama de proveedores de datos de inicio de sesión públicos, como Amazon, Facebook, Google y otros servicios compatibles con OpenID Connect. A continuación, la identidad del usuario se presenta de manera automática y segura a su función de Lambda en formato de identificador de Amazon Cognito, lo que le permite acceder a los datos de usuario desde Amazon Cognito, o como clave para almacenar y recuperar datos en Amazon DynamoDB u otros servicios web.

AWS Lambda se integra con Alexa Skills Kit, una colección de API, herramientas, documentación y código de muestra de autoservicio que facilita la creación de funcionalidades (o “habilidades”) de voz para Alexa. Simplemente debe cargar el código de la función de Lambda para la nueva habilidad de Alexa que vaya a crear y AWS Lambda hará el resto, es decir, ejecutará el código en respuesta a las interacciones de voz de Alexa y administrará automáticamente los recursos de cómputo por usted. Para obtener más información, lea la documentación sobre Alexa Skills Kit.

En el caso de eventos personalizados y notificaciones de los buckets de Amazon S3, AWS Lambda tratará de ejecutar la función tres veces si se produce alguna condición de error con el código o si excede algún límite establecido para algún servicio o recurso. Para fuentes de eventos solicitados que AWS Lambda sondea en nombre del usuario, como Amazon DynamoDB Streams y Amazon Kinesis Streams, Lambda seguirá intentando la ejecución en caso de que se produzca algún error con el código del desarrollador hasta que los datos venzan. Puede monitorizar el progreso a través de las consolas de Amazon Kinesis y Amazon DynamoDB, y mediante las métricas de Amazon CloudWatch que AWS Lambda genera para su función. También puede definir alarmas de Amazon CloudWatch en función de las tasas de error o de limitación controlada de la ejecución.

Las aplicaciones basadas en Lambda (también denominadas aplicaciones sin servidor) se componen de funciones activadas por eventos. Una aplicación sin servidor típica se compone de una o más funciones activadas por eventos, como la carga de objetos a Amazon S3, notificaciones de Amazon SNS o acciones de la API. Estas funciones pueden ser independientes o utilizar otros recursos, como tablas de DynamoDB o buckets de Amazon S3. La aplicación sin servidor más básica es sencillamente una función.

Puede implementar y administrar sus aplicaciones sin servidor con AWS Serverless Application Model (AWS SAM). AWS SAM es una especificación que determina las reglas de expresión de aplicaciones sin servidor en AWS. Esta especificación se corresponde con la sintaxis utilizada por AWS CloudFormation en la actualidad y es compatible de forma nativa con AWS CloudFormation como conjunto de tipos de recursos (denominados “recursos sin servidor”). Estos recursos facilitan a los clientes de AWS el uso de CloudFormation para configurar e implementar aplicaciones sin servidor con API existentes de CloudFormation.

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.

AWS Lambda ahora permite empaquetar e implementar funciones como imágenes de contenedor. Los clientes pueden aprovechar la flexibilidad y la familiaridad de las herramientas de contenedor junto con la agilidad y la simplicidad operativa de AWS Lambda para crear aplicaciones.

Puede comenzar con las imágenes base proporcionadas por AWS para Lambda o utilizar las imágenes que prefiera de la comunidad o de su empresa privada. Luego, simplemente use la CLI de Docker para crear la imagen, cárguela en Amazon ECR y luego cree la función con todas las interfaces y las herramientas conocidas de Lambda, como la consola de administración de AWS, como AWS CLI, el SDK de AWS, AWS SAM y AWS CloudFormation.

Puede implementar imágenes base de Linux de terceros (p. ej., Alpine o Debian) en Lambda además de las imágenes que proporciona Lambda. AWS Lambda admitirá todas las imágenes basadas en los siguientes formatos de manifiesto de imágenes: Docker Image Manifest V2 Schema 2 (utilizado con Docker versión 1.10 y posteriores) o especificaciones de Open Container Initiative (OCI) (versión 1.0 y posteriores). Lambda admite imágenes con un tamaño de hasta 10 GB.

AWS Lambda proporciona una variedad de imágenes base que los clientes pueden ampliar y estos también pueden usar sus imágenes preferidas basadas en Linux con un tamaño de hasta 10 GB.

Puede usar cualquier herramienta de contenedor siempre que sea compatible con uno de los siguientes formatos de manifiesto de imágenes de contenedor: Docker Image Manifest V2 Schema 2 (utilizado con Docker versión 1.10 y posteriores) o especificaciones de Open Container Initiative (OCI) (versión 1.0 y posteriores). Por ejemplo, puede usar herramientas de contenedor nativas (es decir, docker run, docker compose, Buildah y Packer) para definir las funciones como una imagen de contenedor e implementarlas en Lambda.

Todas las funciones de AWS Lambda existentes salvo las capas de Lambda y la firma de código, se pueden utilizar con funciones implementadas como imágenes de contenedor. Una vez implementada, AWS Lambda tratará la imagen como inmutable. Los clientes pueden usar capas de contenedor durante el proceso de creación para incluir dependencias.

Por ahora no. La imagen, una vez implementada en AWS Lambda, será inmutable. El servicio no aplicará parches ni actualizará la imagen. Sin embargo, AWS Lambda publicará imágenes base seleccionadas para todos los tiempos de ejecución admitidos que se basan en el entorno administrado de Lambda. A estas imágenes publicadas se les aplicarán parches y se actualizarán junto con las actualizaciones de los tiempos de ejecución administrados de AWS Lambda. Puede extraer y utilizar la imagen base más reciente de Docker Hub o Amazon ECR Public, reconstruir su imagen de contenedor e implementarla en AWS Lambda con Amazon ECR. Esto permite crear y probar las imágenes y las versiones ejecutables actualizadas antes de implementar la imagen en producción

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. AWS Lambda garantiza que los perfiles de rendimiento para las funciones empaquetadas como imágenes de contenedor sean los mismos que para las empaquetadas como archivos ZIP, incluidos los tiempos de inicio comúnmente inferiores a un segundo.

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.

La API Runtime de Lambda en el servicio Lambda en ejecución acepta eventos JSON y devuelve respuestas. El emulador de interfaz de tiempo de ejecución de Lambda permite que la función empaquetada como imagen de contenedor acepte solicitudes HTTP durante las pruebas locales con herramientas como cURL y las muestre a través de la misma interfaz localmente a la función. Permite usar el comando docker run o docker-compose up para probar localmente la aplicación de Lambda.

Se puede utilizar el emulador para probar si el código de la función es compatible con el entorno de Lambda, se ejecuta correctamente y proporciona el resultado esperado. Por ejemplo, es posible simular eventos de prueba de diferentes fuentes de eventos. También puede utilizarlo para probar extensiones y agentes integrados en la imagen de contenedor con la API Extensions de Lambda.

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.

No. Lambda SnapStart y la PC no pueden activarse al mismo tiempo en la misma función.

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.

No. En este momento no puede habilitar Lambda SnapStart con Amazon EFS.

No. En este momento no puede habilitar Lambda SnapStart con un almacenamiento efímero (/tmp) mayor de 512 MB.

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.

La duración máxima de inicialización permitida para Lambda SnapStart coincidirá con la duración del tiempo de espera de ejecución que haya configurado para su función. El límite máximo de tiempo de espera de ejecución configurable para una función es de 15 minutos.

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, 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.

No tiene que hacer ningún cambio en el código para utilizar la simultaneidad aprovisionada. Trabaja sin problemas con todos los tiempos de ejecución y las funciones existentes. No hay cambios en el modelo de invocación y ejecución de Lambda cuando se utiliza la simultaneidad aprovisionada.

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.

La simultaneidad aprovisionada es ideal para crear aplicaciones sensibles a la latencia, como backends móviles o web, API invocadas sincrónicamente y microservicios interactivos. Puede configurar fácilmente la cantidad de simultaneidad adecuada según la demanda única de su aplicación. Puede aumentar la cantidad de simultaneidad en momentos de alta demanda y reducirla, o desactivarla por completo, cuando la demanda disminuya.

Si la simultaneidad de una función alcanza el nivel configurado, las invocaciones posteriores de la función tendrán las características de latencia y de escalado de las funciones de Lambda comunes. Puede restringir su función para que escale solo hasta el nivel configurado. Si hace esto, evita que la función exceda el nivel configurado de la simultaneidad aprovisionada. Este es un mecanismo para evitar una variabilidad no deseada en su aplicación cuando la demanda exceda la cantidad prevista.

AWS Lambda le permite ejecutar sus funciones en procesadores basados en x86 o en Arm. Los procesadores AWS Graviton2 se crean de forma personalizada por Amazon Web Services con núcleos Arm Neoverse de 64 bits para ofrecer un mayor rendimiento del precio para sus cargas de trabajo en la nube. Los clientes obtienen las mismas ventajas de AWS Lambda, al ejecutar código sin necesidad de aprovisionar o administrar servidores, el escalado automático, la alta disponibilidad y el hecho de pagar únicamente por los recursos que consume.

Las funciones de AWS Lambda con tecnología Graviton2, que utilizan una arquitectura de procesador basada en Arm diseñada por AWS, están diseñadas para ofrecer un rendimiento de precio hasta un 34 % mejor en comparación con las funciones que se ejecutan en procesadores x86, para una variedad de cargas de trabajo sin servidor, como backends web y móviles, datos y procesamiento de transmisiones. Con una latencia más baja, un rendimiento hasta un 19 % mejor, un costo un 20 % menor y la mayor eficiencia energética disponible actualmente en AWS, las funciones Graviton2 pueden alimentar aplicaciones sin servidor crítico. Los clientes pueden configurar tanto las funciones existentes como las nuevas para dirigirse al procesador Graviton2. Pueden implementar funciones que se ejecutan en Graviton2 como archivos zip o imágenes de contenedor.

Puede configurar las funciones para que se ejecuten en Graviton2 a través de la consola de administración de AWS, la API de AWS Lambda, AWS CLI y AWS CloudFormation si establece el indicador de arquitectura en “arm64” para su función.

No hay ningún cambio entre las funciones basadas en x86 y las basadas en Arm. Simplemente, cargue su código a través de la consola de administración de AWS, un archivo zip o una imagen de contenedor, y AWS Lambda ejecutará automáticamente su código cuando se active, sin necesidad de aprovisionar o administrar la infraestructura.

Una aplicación puede contener funciones que se ejecuten en ambas arquitecturas. AWS Lambda le permite cambiar la arquitectura (“x86_64” o “arm64”) de la versión actual de su función. Una vez que crea una versión específica de su función, la arquitectura no puede cambiarse.

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.

No. Cada versión de función solo puede utilizar una única imagen de contenedor.

Sí. Las capas y extensiones pueden dirigirse a arquitecturas compatibles con “x86_64” o “arm64”. La arquitectura predeterminada para las funciones y capas es “x86_64”.

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.

Las funciones de AWS Lambda con procesadores AWS Graviton2 son un 20 % más baratas que las funciones de Lambda basadas en x86. El nivel gratuito de Lambda se aplica a las funciones de AWS Lambda con arquitecturas basadas en x86 y Arm.

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.

Con Amazon Elastic File System (Amazon EFS) para AWS Lambda, los clientes pueden hacer lecturas y escrituras en grandes volúmenes de datos, además de mantenerlos, todo de manera segura, a prácticamente cualquier escala mediante el uso de un sistema de archivos NFS elástico completamente administrado cuya escala se puede ajustar bajo demanda sin necesidad de hacer aprovisionamientos ni de administrar capacidad. Anteriormente, los desarrolladores agregaban código a sus funciones para descargar datos desde S3 o bases de datos a un almacenamiento temporal local cuyo límite era de 512 MB. Con EFS para Lambda, los desarrolladores no necesitan escribir código para descargar datos y almacenarlos temporalmente con el objetivo de procesarlos.

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.

Sí. Los destinos de montaje para Amazon EFS están asociados a una subred en una VPC. Es necesario configurar la función de AWS Lambda para poder acceder a dicha VPC.

EFS para Lambda es ideal para crear aplicaciones de machine learning o cargar modelos o archivos de referencia de gran tamaño, procesar grandes volúmenes de datos o crear copias de seguridad de ellos, alojar contenido web o desarrollar sistemas de compilación internos. Los clientes también pueden usar EFS para Lambda a fin de mantener el estado entre las invocaciones en una arquitectura de microservicios con estados, en un flujo de trabajo de Step Functions, o para compartir archivos entre instancias y aplicaciones sin servidor o aplicaciones basadas en contenedores.

Sí. El cifrado de datos en tránsito usa el estándar de la industria Transport Layer Security (TLS) 1.2 para cifrar los datos que se envían entre las funciones de AWS Lambda y los sistemas de archivos de Amazon EFS.

Los clientes pueden aprovisionar Amazon EFS para cifrar datos en reposo. Los datos en reposo se cifran de manera transparente mientras se escriben, y se descifran de la misma manera mientras se leen, por lo que no tiene que modificar sus aplicaciones. AWS Key Management Service (KMS) administra las claves de cifrado, lo que elimina la necesidad de crear y mantener una infraestructura de administración de claves segura.

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.

No. Cada función de Lambda podrá acceder a un solo sistema de archivos de EFS.

Sí. Amazon EFS admite las funciones de Lambda, los contenedores de ECS y Fargate, y las instancias EC2. Puede compartir el mismo sistema de archivos y usar los puntos de acceso y la política de IAM para controlar el acceso de cada función, contenedor o instancia.  

Sí. Se puede configurar las funciones de Lambda con una URL de función, un punto de conexión HTTPS integrado que puede invocar mediante el navegador, el comando curl y cualquier cliente HTTP. Las URL de las funciones son una forma fácil de comenzar a crear funciones accesibles mediante HTTPS.

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.

Las URL de las funciones de Lambda se protegen con la autorización de IAM de forma predeterminada. Puede elegir desactivar la autorización de IAM para crear un punto de conexión público o si planea implementar una autorización personalizada como parte de la lógica empresarial de la función.

Puede invocar fácilmente la función desde el navegador web, vaya a la URL de Lambda. También puede invocarla desde el código de la aplicación cliente mediante una biblioteca HTTP o desde la línea de comandos mediante un comando curl.

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.

Los nombres de dominio personalizados no son compatibles actualmente con las URL de funciones. Para usar un dominio personalizado con la URL de la función, puede crear una distribución de Amazon CloudFront y un CNAME para asignar el dominio personalizado al nombre de la distribución de CloudFront. A continuación, asigne el nombre del dominio de la distribución de CloudFront para que se dirija a la URL de la función como origen.

Sí, las URL de la función se pueden usar para invocar una función en una VPC.

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.

AWS Lambda está diseñado para hacer uso de la replicación y la redundancia a fin de ofrecer una disponibilidad excelente al servicio y a las funciones de Lambda que opera. No hay periodos de mantenimiento ni tiempos de inactividad programados para ninguno de los dos.

Sí. Cuando actualiza una función de Lambda, habrá un periodo de tiempo, normalmente inferior a un minuto, durante el que ni la versión nueva ni la versión antigua de su función podrá abastecer las solicitudes.

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.

Cuando se produce un error, las funciones de Lambda invocadas sincrónicamente responden con una excepción. Las funciones de Lambda que se invocan de manera asíncrona intentan reenviarse 3 veces como mínimo. 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. Kinesis y DynamoDB Streams retienen datos durante un mínimo de 24 horas.

Puede configurar una cola de Amazon SQS o un tema de Amazon SNS como cola de mensajes fallidos.

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.

Los controles de acceso se pueden administrar mediante el rol de la función Lambda o una configuración de política de recursos en la cola misma. Si ambas políticas están presentes, se aplicará el más restrictivo de los dos permisos.

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.

Puede habilitar la firma de código al crear una configuración de firma de código en la consola de administración de AWS, la API de Lambda, la CLI de AWS, AWS CloudFormation y AWS SAM. La configuración de firma de código ayuda a especificar los perfiles de firma aprobados y a configurar si debe advertir o rechazar las implementaciones si fallan las comprobaciones de firma. Las configuraciones de firma de código se pueden adjuntar a funciones individuales de Lambda para habilitar la función de firma de código. Estas funciones ahora comienzan a verificar firmas en la implementación.

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.

Sí, puede habilitar la firma de código para funciones existentes al adjuntar una configuración de firma de código a la función. Puede hacerlo en la consola de AWS Lambda, la API de Lambda, la CLI de AWS, AWS CloudFormation y AWS SAM.

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.

Lambda proporciona la versión para Linux de Amazon de openjdk 1.8.

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.

Sí. Puede usar pip para instalar los paquetes de Python que necesite.

Puede crear una función Lambda de C# mediante el IDE de Visual Studio. Para ello, seleccione “Publicar en AWS Lambda” en Solution Explorer. Como alternativa, puede ejecutar directamente el comando “dotnet lambda publish” desde la CLI de dotnet, que tiene instalado el [parche de herramientas de la CLI de Lambda #], que crea un ZIP del código fuente de C# junto con todas las dependencias de NuGet, así como sus propios ensamblajes DLL publicados, y lo carga automáticamente en AWS Lambda con el parámetro de tiempo de ejecución “dotnetcore1.0”

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. 

Para implementar una función Lambda escrita en Ruby, empaque su código y gemas de Ruby como un 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.

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.

AWS Lambda se integra con AWS CloudTrail. AWS CloudTrail puede registrar y entregar al bucket de Amazon S3 logs que detallan el uso de la API por parte de su cuenta.

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.

Sí, AWS Lambda admite el conjunto de instrucciones de extensiones vectoriales avanzadas 2 (AVX2). Para obtener más información sobre cómo compilar el código de la aplicación para que este conjunto de instrucciones mejore el rendimiento, consulte la documentación para desarrolladores de AWS Lambda.