Ejecuciones de Lambda

Cuando Lambda ejecuta una función en su nombre, administra tanto el aprovisionamiento como la configuración de los sistemas subyacentes necesarios para ejecutar el código. Esto permite a los desarrolladores centrarse en la lógica empresarial y escribir código, no en administrar y gestionar los sistemas subyacentes.

El servicio Lambda se divide en el plano de control y el plano de datos. Cada plano tiene un propósito distinto en el servicio. El plano de control proporciona las API de administración (por ejemplo, CreateFunction,UpdateFunctionCode,PublishLayerVersion, etc.) y administra las integraciones con todos los servicios de AWS. Las comunicaciones con el plano de control de Lambda están protegidas en tránsito por TLS. Todos los datos de los clientes almacenados en el plano de control de Lambda se cifran en reposo mediante el uso de AWS KMS, que está diseñado para protegerlos de la divulgación o manipulación no autorizadas.

El plano de datos es la API Invoke de Lambda, que desencadena la invocación de funciones de Lambda. Cuando se invoca una función de Lambda, el plano de datos asigna un entorno de ejecución en un proceso de trabajo AWS Lambda (o para abreviar, un proceso de trabajo, que es un tipo de instancia de Amazon EC2) para esa versión de la función, o elige un entorno de ejecución existente que ya se ha configurado para esa versión de la función, que luego usa para completar la invocación. Para obtener más información, consulte la sección “MicroVM y procesos de trabajo de AWS Lambda” de este documento.

Entornos de ejecución de Lambda

El servicio de invocación de Lambda enruta cada invocación a un entorno de ejecución en un proceso de trabajo que puede atender la solicitud. Salvo a través del plano de datos, los clientes y otros usuarios no pueden iniciar directamente las comunicaciones de red entrantes/de entrada con un entorno de ejecución. Esto ayuda a garantizar que las comunicaciones con su entorno de ejecución se autentiquen y autoricen.

Los entornos de ejecución están reservados para una versión de la función específica y no se pueden reutilizar en otras versiones de la función, funciones o cuentas de AWS. Esto significa que una sola función que tenga dos versiones diferentes daría como resultado al menos dos entornos de ejecución únicos.

Cada entorno de ejecución solo se puede usar para una invocación simultánea a la vez, y se pueden reutilizar en múltiples invocaciones de la misma versión de la función por motivos de rendimiento. Dependiendo de varios factores (por ejemplo, velocidad de invocación, configuración de funciones, etc.), pueden existir uno o más entornos de ejecución para la versión de una función determinada. Con este enfoque, Lambda puede proporcionar aislamiento a nivel de versión de las funciones para sus clientes.

Lambda no aísla las invocaciones en el entorno de ejecución de la versión de una función. Lo que esto significa es que una invocación puede dejar un estado que podría afectar a la siguiente invocación (por ejemplo, archivos escritos en /tmp o datos en memoria). Si desea asegurarse de que una invocación no afecte a otra, Lambda recomienda crear funciones distintas adicionales. Por ejemplo, podría crear funciones distintas para operaciones de análisis complejas que son más propensas a errores y reutilizar funciones que no realizan operaciones en las que la seguridad es importante. Lambda no limita actualmente la cantidad de funciones que pueden crear los clientes. Para obtener más información sobre los límites, consulte la página Cuotas de Lambda.

Lambda supervisa y administra continuamente los entornos de ejecución, que pueden crearse o destruirse por diversos motivos, entre los que se incluyen, entre otros:

• Llega una nueva invocación y no existe un entorno de ejecución adecuado.

• Se produce una implementación de software de proceso de trabajo o tiempo de ejecución interna.

• Se publica una nueva configuración de simultaneidad aprovisionada.

• El tiempo de concesión en el entorno de ejecución, o el proceso de trabajo, se está acabando o ha superado la vida útil máxima.

• Otros procesos de reequilibrio de la carga de trabajo interna.

Los clientes pueden administrar el número de entornos de ejecución aprovisionados previamente que existen para una versión de función configurando la simultaneidad aprovisionada en su configuración de funciones. De esta manera, Lambda creará, administrará y garantizará que siempre exista la cantidad configurada de entornos de ejecución. Esto garantiza que los clientes tengan un mayor control sobre el rendimiento inicial de sus aplicaciones sin servidor a cualquier escala.

Excepto con una configuración de simultaneidad aprovisionada, los clientes no pueden controlar de manera determinista la cantidad de entornos de ejecución que Lambda crea o administra en respuesta a las invocaciones.

Rol de ejecución

Cada función de Lambda también debe configurarse con un rol de ejecución, que es un rol de IAM que asume el servicio Lambda al realizar operaciones del plano de control y el plano de datos relacionadas con la función. El servicio Lambda asume esta función para obtener credenciales de seguridad temporales que luego están disponibles como variables de entorno durante la invocación de una función. Por motivos de rendimiento, el servicio Lambda almacena en caché estas credenciales y puede reutilizarlas en diferentes entornos de ejecución que usan el mismo rol de ejecución.

Para garantizar el cumplimiento del principio de privilegios mínimos, Lambda recomienda que cada función tenga su propio rol único y que se configure con el conjunto mínimo de permisos que requiere.

El servicio Lambda también puede asumir el rol de ejecución para realizar determinadas operaciones del plano de control, como las relacionadas con la creación y configuración de interfaces de red elásticas (ENI) para funciones de VPC, el envío de registros a Amazon CloudWatch Application Insights, el envío de rastros a AWS X-Ray u otras operaciones no relacionadas con la invocación. Los clientes siempre pueden revisar y auditar estos casos de uso en los registros de auditoría que se encuentran en AWS CloudTrail.

Para obtener más información sobre este tema, consulte la página de documentación del rol de ejecución de AWS Lambda.

MicroVM y procesos de trabajo de Lambda

Lambda crea sus entornos de ejecución en una flota de instancias de Amazon EC2 denominadas procesos de trabajo AWS Lambda. Los procesos de trabajo son instancias Nitro EC2bare metal completas que Lambda lanza y administra en una cuenta de AWS aislada e independiente que no es visible para los clientes. Los procesos de trabajo tienen una o más micromáquinas virtuales (MVM) virtualizadas por hardware creadas por Firecracker. Firecracker es un monitor de máquina virtual (VMM) de código abierto que utiliza la máquina virtual basada en el kernel (KVM) de Linux para crear y administrar MVM. Está diseñado específicamente para crear y administrar contenedores multiinquilino seguros y servicios basados en funciones que proporcionan modelos operativos sin servidor. Para obtener más información sobre el modelo de seguridad de Firecracker, consulte el sitio web del proyecto Firecracker.

Como parte del modelo de responsabilidad compartida, Lambda es responsable de mantener la configuración de seguridad, los controles y el nivel de revisiones de los procesos de trabajo. El equipo de Lambda utiliza Amazon Inspector para detectar posibles problemas de seguridad conocidos, así como otros mecanismos de notificación de problemas de seguridad personalizados y listas de divulgación previa, de modo que los clientes no tengan que administrar la posición de seguridad subyacente de su entorno de ejecución.

Figura 3: Modelo de aislamiento para procesos de trabajo AWS Lambda

La concesión de los procesos de trabajo tiene una duración máxima de 14 horas. Cuando un proceso de trabajo está llegando al final de su tiempo máximo de concesión, no se le enrutan más invocaciones, las MVM se terminan correctamente y la instancia del proceso de trabajo subyacente se termina. Lambda supervisa y alerta continuamente sobre las actividades del ciclo de vida útil de su flota.

Todas las comunicaciones del plano de datos a los procesos de trabajo se cifran mediante el estándar de cifrado avanzado con Galois/Counter Mode (AES-GCM). Excepto con las operaciones del plano de datos, los clientes no pueden interactuar directamente con un proceso de trabajo, ya que está alojado en una Amazon VPC aislada en red administrada por Lambda en las cuentas de servicio de Lambda.

Cuando un proceso de trabajo tiene que crear un nuevo entorno de ejecución, se le da autorización durante un tiempo limitado para acceder a los artefactos de funciones del cliente. Estos artefactos están optimizados específicamente para el entorno de ejecución y los procesos de trabajo de Lambda. El código de función que se carga con el formato ZIP se optimiza una vez y, a continuación, se almacena en un formato cifrado con una clave administrada por AWS y AES-GCM.

También se optimizan las funciones que se cargan en Lambda con el formato de imagen de contenedor. La imagen del contenedor se descarga primero de su fuente original, se optimiza en fragmentos distintos y, a continuación, se almacena como fragmentos cifrados mediante un método de cifrado convergente autenticado que utiliza una combinación de AES-CTR, AES-GCM y SHA-256 MAC. El método de cifrado convergente permite a Lambda deduplicar de forma segura fragmentos cifrados. Todas las claves necesarias para descifrar los datos del cliente están protegidas mediante una AWS KMS clave maestra del cliente (CMK) administrada por el cliente. El uso de CMK por parte del servicio Lambda está disponible para los clientes en los registros de AWS CloudTrail para fines de seguimiento y auditoría.