Prácticas recomendadas para trabajar con funciones AWS Lambda

Reutilice el entorno de ejecución para mejorar el rendimiento de la función. Inicialice los clientes de SDK y las conexiones de base de datos fuera del controlador de funciones y almacene localmente en caché los recursos estáticos en el directorio /tmp. Las invocaciones posteriores procesadas por la misma instancia de su función pueden reutilizar estos recursos. Esto ahorra costes al reducir el tiempo de ejecución de la función.

Para evitar posibles filtraciones de datos entre las invocaciones, no utilice el entorno de ejecución para almacenar datos de usuario, eventos u otra información con implicaciones de seguridad. Si su función se basa en un estado mutable que no se puede almacenar en la memoria dentro del controlador, considere crear una función independiente o versiones independientes de una función para cada usuario.

Utilice una directiva keep-alive para mantener conexiones persistentes. Lambda purga las conexiones inactivas a lo largo del tiempo. Si intenta reutilizar una conexión inactiva al invocar una función, se producirá un error de conexión. Para mantener la conexión persistente, use la directiva keep-alive asociada al tiempo de ejecución. Para ver un ejemplo, consulte Reutilización de conexiones con Keep-Alive en Node.js.

Utilice variables de entorno para pasar parámetros operativos a su función. Por ejemplo, si está escribiendo en un bucket de Amazon S3, en lugar de codificar de forma rígida el nombre del bucket, configúrelo como una variable de entorno.

Evite utilizar invocaciones recursivas en la función de Lambda, en las que la función se invoca a sí misma o inicia un proceso que puede volver a invocarla. Esto podría producir un volumen no intencionado de invocaciones de la función y costos elevados. Si observa un volumen imprevisto de invocaciones, establezca la simultaneidad reservada de funciones en 0 inmediatamente para limitar todas las invocaciones de la función mientras actualiza el código.

No utilice API no documentadas y no públicas en el código de la función de Lambda. Para tiempos de ejecución administrados de AWS Lambda, Lambda aplica periódicamente actualizaciones funcionales y de seguridad a las API internas de Lambda. Estas actualizaciones de las API internas pueden ser incompatibles con versiones anteriores, lo que conlleva consecuencias no deseadas, como errores de invocación si su función depende de estas API no públicas. Consulte la referencia de la API para obtener una lista de las API disponibles públicamente.

Escriba el código idempotente. Escribir el código idempotente para las funciones garantiza que los eventos duplicados se gestionen de la misma manera. El código debe validar y gestionar correctamente los eventos duplicados. Para obtener más información, consulte ¿Cómo puedo hacer que mi función de Lambda sea idempotente?.

Prácticas recomendadas de codificación para las funciones de Lambda en Node.js

Prácticas recomendadas de codificación para las funciones de Lambda en Typescript

Prácticas recomendadas de codificación para las funciones de Lambda en Python

Prácticas recomendadas de codificación para las funciones de Lambda en Ruby

Prácticas recomendadas de codificación para las funciones de Lambda

Prácticas recomendadas de codificación para las funciones de Lambda en Go

Prácticas recomendadas de codificación para las funciones de Lambda en C#

Prácticas recomendadas de codificación para las funciones de Lambda en Rust

La prueba de desempeño de la función de Lambda es una parte crucial a la hora de garantizar la elección de la configuración de memoria óptima. Cualquier aumento del tamaño de la memoria causa un aumento equivalente de la CPU disponible para la función. El uso de la memoria de la función se determina por invocación y puede visualizarse en Amazon CloudWatch. En cada invocación se genera una entrada REPORT:, tal como se muestra a continuación:

REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3	Duration: 12.34 ms	Billed Duration: 100 ms Memory Size: 128 MB	Max Memory Used: 18 MB

Analice el campo Max Memory Used: para determinar si la función necesita más memoria o si ha aprovisionado en exceso el tamaño de la memoria para la función.

Para encontrar la configuración de memoria adecuada para sus funciones, recomendamos utilizar el proyecto AWS Lambda Power Tuning de código abierto. Para obtener más información, consulte AWS LambdaAjuste de energía en GitHub.

Para optimizar el rendimiento de las funciones, también recomendamos implementar bibliotecas que puedan aprovechar Advanced Vector Extensions 2 (AVX2). Esto le permite procesar cargas de trabajo exigentes, incluyendo inferencias de machine learning, procesamiento de medios, computación de alto rendimiento (HPC), simulaciones científicas y modelado financiero. Para obtener más información, consulte Creación de funciones de AWS Lambda más rápidas con AVX2.

Realice una prueba de carga de la función de Lambda para determinar un valor de tiempo de espera óptimo. Es importante analizar cuánto tiempo se ejecuta la función para determinar más fácilmente los posibles problemas con un servicio de dependencias que puedan aumentar la concurrencia de la función más allá de lo esperado. Esto es especialmente importante cuando la función de Lambda realiza llamadas de red a recursos que pueden no gestionar el escalado de Lambda. Para obtener más información sobre las pruebas de carga de la aplicación, consulte Pruebas de carga distribuidas en AWS.

Utilice los permisos más restrictivos al establecer las políticas de IAM. Conozca los recursos y las operaciones que la función de Lambda necesita, y limite el rol de ejecución a estos permisos. Para obtener más información, consulte Administrar permisos en AWS Lambda.

Familiarícese con los Cuotas de Lambda. A menudo, el tamaño de carga, los descriptores de archivo y el espacio de /tmp se pasan por alto a la hora de determinar los límites de recursos del tiempo de ejecución.

Elimine las funciones de Lambda que ya no utilice. Al hacerlo, las funciones no utilizadas no contarán innecesariamente para el límite de tamaño del paquete de implementación.

Si utiliza Amazon Simple Queue Service como origen de eventos, asegúrese de que el valor del tiempo de invocación que se espera para la función no sea superior al valor de Tiempo de espera de visibilidad de la cola. Esto se aplica tanto a CreateFunction como a UpdateFunctionConfiguration.

Familiarícese con las limitaciones de rendimiento ascendentes y descendentes. Si bien las funciones de Lambda se escalan sin problemas con la carga, es posible que las dependencias ascendentes y descendentes no tengan las mismas capacidades de rendimiento. Si necesita limitar cuán alto se puede escalar su función, puede configurar la simultaneidad reservada de su función.

Tolerancia de limitación incorporada. Si su función sincrónica sufre una limitación debido a que el tráfico supera la velocidad de escalado de Lambda, puede utilizar las siguientes estrategias para mejorar la tolerancia a la aceleración:

Utilice Uso de métricas de CloudWatch con Lambda y Alarmas de CloudWatch en lugar de crear o actualizar una métrica desde dentro de la función de código de Lambda. Es una forma mucho más eficaz de realizar el seguimiento del estado de las funciones de Lambda, y le permitirá identificar los problemas al comienzo del proceso de desarrollo. Por ejemplo, puede configurar una alarma en función de la duración esperada de la invocación de la función de Lambda para solucionar los cuellos de botella o las latencias atribuibles al código de la función.

Utilice la biblioteca de registro y las AWS Lambdadimensiones y métricas para detectar los errores de las aplicaciones (por ejemplo, ERR, ERROR, WARNING, etc.)

Use Detección de anomalías de costos de AWS para detectar actividad inusual en su cuenta. La detección de anomalías de costos utiliza machine learning para monitorear de forma continua el costo y el uso y, al mismo tiempo, minimizar las alertas positivas falsas. La detección de anomalías de cotso utiliza datos de AWS Cost Explorer, que tiene un retraso de hasta 24 horas. Como resultado de ello, puede tardar hasta 24 horas en detectar una anomalía después de que se produce el uso. Para comenzar a utilizar la detección de anomalías de costo, primero debe registrarse en Cost Explorer. Luego, acceda a Cost Anomaly Detection (Detección de anomalías de costos).

Pruebe con diferentes tamaños de lote y de registro para que la frecuencia de sondeo de cada origen de eventos se ajuste a la velocidad con la que la función es capaz de completar su tarea. El parámetro de BatchSize CreateEventSourceMapping controla el número máximo de registros que se pueden enviar a la función en cada invocación. A menudo, un tamaño de lote mayor puede absorber de forma más eficiente el tráfico adicional asociado a un conjunto de registros mayor, mejorando el desempeño.

De forma predeterminada, Lambda invoca su función tan pronto como los registros estén disponibles. Si el lote que Lambda lee del origen de eventos solo tiene un registro, Lambda envía solo un registro a la función. Para evitar invocar la función con un número de registros pequeño, puede indicar al origen de eventos que almacene en búfer registros durante hasta 5 minutos configurando un plazo de procesamiento por lotes. Antes de invocar la función, Lambda continúa leyendo los registros del origen de eventos hasta que haya recopilado un lote completo, venza el plazo de procesamiento por lotes o el lote alcance el límite de carga de 6 MB. Para obtener más información, consulte Comportamiento de procesamiento por lotes.

Aumente el rendimiento del procesamiento de transmisiones de Kinesis añadiendo particiones. Un flujo de Kinesis se compone de una o más particiones. La velocidad a la que Lambda puede leer los datos de Kinesis se escala linealmente con el número de particiones. Al aumentar el número de particiones, aumentará directamente el número máximo de invocaciones simultáneas a la función de Lambda, y también puede incrementarse el rendimiento del procesamiento de flujos de Kinesis. Para obtener más información acerca de la relación entre las particiones y las invocaciones de funciones, consulte Flujos de sondeo y procesamiento por lotes. Si aumenta el número de particiones de un flujo de Kinesis, asegúrese de que ha elegido una buena clave de partición (consulte Claves de partición) para los datos, de forma que los registros relacionados acaben en las mismas particiones y los datos estén bien distribuidos.

Utilice Amazon CloudWatch en IteratorAge para determinar si el flujo de Kinesis se está procesando. Por ejemplo, configure una alarma de CloudWatch con un valor máximo de 30 000 (30 segundos).

Monitoree el uso de AWS Lambda en relación con las mejores prácticas de seguridad con AWS Security Hub. Security Hub utiliza controles de seguridad para evaluar las configuraciones de los recursos y los estándares de seguridad para ayudarlo a cumplir con varios marcos de conformidad. Para obtener más información sobre el uso de Security Hub para evaluar los recursos de Lambda, consulte controles de AWS Lambda en la Guía del usuario de AWS Security Hub.

Supervise los registros de actividad de red de Lambda con Amazon GuardDuty Lambda Protection. La protección de GuardDuty Lambda le ayuda a identificar posibles amenazas de seguridad cuando invoca sus funciones de Lambda en su Cuenta de AWS. Por ejemplo, si una de sus funciones consulta una dirección IP asociada con la actividad relacionada con criptomonedas. GuardDuty supervisa los registros de la actividad de la red generados mediante la invocación de funciones de Lambda. Para obtener más información, consulte Lambda Protection en la Guía del usuario de Amazon GuardDuty.