View a markdown version of this page

Prácticas recomendadas para las instancias administradas de Lambda - AWS Lambda

Prácticas recomendadas para las instancias administradas de Lambda

Configuración de los proveedores de capacidad

Separe los proveedores de capacidad por nivel de confianza. Cree diferentes proveedores de capacidad para cargas de trabajo con diferentes requisitos de seguridad. Todas las funciones asignadas al mismo proveedor de capacidad deben ser de confianza mutua, ya que los proveedores de capacidad sirven de límite de seguridad.

Utilice nombres descriptivos. Denomine los proveedores de capacidad para indicar claramente su uso previsto y su nivel de confianza (por ejemplo, production-trusted, dev-sandbox). Esto ayuda a los equipos a entender el propósito y la postura de seguridad de cada proveedor de capacidad.

Use varias zonas de disponibilidad. Especifique las subredes entre varias zonas de disponibilidad cuando cree los proveedores de capacidad. Lambda lanza tres instancias de forma predeterminada para la resiliencia de las zonas de disponibilidad, lo que garantiza una alta disponibilidad para sus funciones.

Selección del tipo de instancia

Deje que Lambda elija los tipos de instancia. De forma predeterminada, Lambda elige los mejores tipos de instancias para su carga de trabajo. Le recomendamos que deje que Lambda Managed Instances elija los tipos de instancia por usted, ya que restringir la cantidad de tipos de instancias posibles podría reducir la disponibilidad.

Especifique los tipos de instancias según los requisitos específicos. Si tiene requisitos de hardware específicos, establezca los tipos de instancias permitidos en una lista de instancias compatibles. Por ejemplo:

  • Para las aplicaciones que requieren un ancho de banda de la red elevado, seleccione varios tipos de instancias n.

  • Para entornos de pruebas o desarrollo con limitaciones de costos, elija tipos de instancias más pequeños, como m7a.large.

Función de configuración

Elija la configuración de memoria y vCPU adecuada. Seleccione configuraciones de memoria y vCPU que admitan varias ejecuciones simultáneas de su función. El tamaño mínimo de función admitido es de 2 GB y 1 vCPU.

  • Para las aplicaciones de Python, elija una proporción más alta de memoria con respecto a las vCPU (por ejemplo, 4 a 1 u 8 a 1) debido a la forma en que Python gestiona la concurrencia múltiple.

  • Para operaciones con uso intensivo de la CPU o funciones que realizan poca E/S, elija más de una vCPU

  • En el caso de las aplicaciones con un uso intensivo de E/S, como los servicios web o los trabajos por lotes, la concurrencia múltiple ofrece la mayor ventaja

Configure la máxima concurrencia de forma adecuada. Lambda elige valores predeterminados razonables para una concurrencia máxima que equilibre el consumo de recursos y el rendimiento. Ajuste esta configuración en función del uso de recursos de la función:

  • Aumente la concurrencia máxima (hasta 64 por vCPU) si las invocaciones de sus funciones utilizan muy poca CPU.

  • Reduzca la concurrencia máxima si la aplicación consume una gran cantidad de memoria y muy poca CPU.

Tenga en cuenta que los entornos de ejecución con una simultaneidad muy baja pueden experimentar limitaciones y dificultades de escalado.

Funciones de larga duración

Las funciones de las instancias administradas de AWS Lambda pueden ejecutarse hasta 90 minutos (5400 segundos) por invocación para las invocaciones asíncronas y para las invocaciones de asignación de orígenes de eventos, excepto las asignaciones de fuentes de eventos de Amazon MQ y Amazon DocumentDB, que se limitan a 15 minutos. Las invocaciones sincrónicas y la fase de inicialización de la función también están limitadas a 15 minutos. Consulte Configuración del tiempo de espera de la función de Lambda. para obtener más información sobre cómo configurar el tiempo de espera. Como la función puede ejecutarse durante más tiempo, revise las siguientes consideraciones que se aplican a los componentes que son de naturaleza efímera, como las conexiones de red y las credenciales.

Considere los tiempos de espera de las conexiones inactivas. Asegúrese de que los tiempos de espera de las conexiones inactivas en los servicios descendentes, como Amazon RDS, Amazon ElastiCache y las API externas, se adapten a la duración total de la función. Si su función enruta el tráfico a través de una puerta de enlace NAT, envíe paquetes de mantenimiento activo para evitar que las conexiones inactivas se interrumpan una vez transcurrido el tiempo de espera de 350 segundos de la puerta de enlace NAT.

Respete los valores TTL del DNS. Respete los valores TTL del DNS en el momento en que resuelva los nombres de host externos. Los SDK de AWS gestionan esto de manera automática, pero los clientes HTTP personalizados pueden almacenar en caché las resoluciones de DNS más allá de su TTL.

Actualice las credenciales temporales. Si su función adquiere credenciales o tokens temporales, compruebe que sigan siendo válidos durante toda la ejecución o actualícelos en segundo plano.

Diseñe para la idempotencia. Lambda no garantiza el procesamiento exactamente una vez. A medida que las funciones se prolongan, aumenta el período de reintentos y de entregas duplicadas. Utilice Powertools for AWS Lambda para implementar la idempotencia en operaciones como los pagos o las escrituras en bases de datos, de manera tal que produzcan el mismo resultado aunque se ejecuten más de una vez. Si se usan funciones duraderas de Lambda, los pasos tienen una semántica de ejecución de al menos una vez: el SDK de ejecución duradera omite los pasos completados durante la reproducción, pero los pasos que fallan antes del punto de control pueden volver a ejecutarse. Se pueden utilizar los nombres de ejecución como claves de idempotencia.

Ajuste las asignaciones de orígenes de eventos para un procesamiento más prolongado. Para Amazon SQS, establezca el tiempo de espera de visibilidad de la fila en al menos seis veces el tiempo de espera de la función, de modo que Lambda tenga tiempo suficiente para volver a intentar un lote si la función está limitada. Lambda lo valida al crear la asignación de orígenes de eventos, pero no impide que los cambios posteriores en la fila o en la función generen una discordancia. Para Amazon Kinesis Data Streams y Amazon DynamoDB Streams, configure el plazo máximo de procesamiento por lotes y el factor de paralelización para tener en cuenta tiempos de procesamiento más prolongados por lote y habilite la notificación de errores parciales de los lotes para que solo se vuelvan a intentar los registros con errores en lugar de todo el lote.

Scaling configuration (Escalado de configuración)

Establezca un objetivo adecuado de utilización de los recursos. De forma predeterminada, Lambda mantiene suficiente margen de maniobra para que el tráfico se duplique en 5 minutos sin limitaciones. Ajústelo en función de las características de su carga de trabajo:

  • Para cargas de trabajo muy estables o aplicaciones que no sean sensibles a las limitaciones, fije el objetivo en un nivel alto para lograr una mayor utilización y reducir los costos.

  • Para cargas de trabajo con posibles ampliaciones de tráfico, establezca los objetivos de recursos en un nivel bajo para mantener un margen de maniobra adicional.

Planifique el crecimiento del tráfico. Si el tráfico se incrementa a más del doble en cinco minutos, pueden presentarse limitaciones mientras Lambda escala verticalmente las instancias y los entornos de ejecución. Diseñe su aplicación para gestionar las posibles limitaciones durante los períodos de escalado vertical rápido.

Seguridad

Aplique el privilegio mínimo a los permisos de PassCapacityProvider. Otorgue permisos de lambda:PassCapacityProvider solo a los proveedores de capacidad necesarios. Utilice los permisos a nivel de recursos para restringir los proveedores de capacidad que los usuarios pueden asignar a las funciones.

Supervise el uso de los proveedores de capacidad. Utilice AWS CloudTrail para supervisar las asignaciones de los proveedores de capacidad y los patrones de acceso. Esto ayuda a identificar los intentos de acceso no autorizados y garantiza el cumplimiento de las políticas de seguridad.

Separe las cargas de trabajo que no son de confianza. No confíe en los contenedores para el aislamiento de seguridad entre cargas de trabajo que no sean de confianza. Utilice distintos proveedores de capacidad para separar las cargas de trabajo en las que no se confíe mutuamente.

Optimización de costos

Use las opciones de precios de EC2. Aproveche los Savings Plans y las instancias reservadas de EC2 para reducir los costos. Estas opciones de precios se aplican al cómputo de EC2 subyacente (no se descuenta la tarifa de administración del 15 %).

Optimice para cargas de trabajo estables. Las instancias administradas de Lambda son las más adecuadas para funciones de estado estable con tráfico predecible de gran volumen. Para los patrones con ampliación de tráfico, Lambda (predeterminado) podría ser más rentable.

Supervise la utilización de recursos. Realice un seguimiento de las métricas de CloudWatch para comprender la utilización de la CPU y la memoria. Ajuste la asignación de memoria de las funciones y la selección del tipo de instancia según los patrones de uso reales para optimizar los costos.

Supervisión y observabilidad

Supervise las métricas de los proveedores de capacidad. Realice un seguimiento de las métricas a nivel del proveedor de capacidad, incluidas CPUUtilization, MemoryUtilization, vCPUAvailable y MemoryAvailable para verificar que haya suficientes recursos disponibles para sus cargas de trabajo.

Supervise las métricas del entorno de ejecución. Realice un seguimiento de las métricas a nivel del entorno de ejecución, incluidas ExecutionEnvironmentConcurrency y ExecutionEnvironmentConcurrencyLimit, para comprender el comportamiento de escalado e identificar posibles limitaciones.

Configure las alarmas de CloudWatch. Cree alarmas de CloudWatch para las métricas clave a fin de identificar los problemas de forma proactiva:

  • Uso elevado de la CPU o la memoria

  • Poca capacidad disponible

  • Aproximación de los límites de concurrencia

Consideraciones específicas del lenguaje

Siga las prácticas recomendadas específicas del lenguaje. Cada lenguaje de programación gestiona la concurrencia múltiple de forma diferente. Consulte las guías específicas del lenguaje para obtener recomendaciones detalladas:

  • Java: utilice colecciones seguras para subprocesos, AtomicInteger y ThreadLocalpara el estado específico de la solicitud.

  • Node.js: utilice InvokeStore para todos los estados específicos de la solicitud y evite las variables globales.

  • Python: utilice nombres de archivo únicos en /tmp con los identificadores de solicitud y considere el aislamiento de la memoria basado en procesos.

  • Rust: utilice run_concurrent en lugar de run, con la característica concurrency-tokio habilitada. El controlador debe ser Clone + Send.

Haga pruebas para detectar problemas de seguridad y concurrencia de los subprocesos. Antes de implementarlas en producción, compruebe minuciosamente sus funciones para detectar problemas de seguridad de los subprocesos, condiciones de carrera y aislamiento de estado adecuado bajo carga simultánea.

Siguientes pasos