# Solución de problemas de Lambda Los temas siguientes proporcionan consejos para solucionar problemas de errores y problemas que puedan surgir al utilizar la API de Lambda, la consola o las herramientas. Si se encuentra con un problema que no aparezca en esta lista, puede utilizar el botón **Comentarios** de esta página para notificarlo. Para obtener más consejos sobre la resolución de problemas y respuestas a preguntas comunes de soporte, visite el [Centro de conocimientos de AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Para obtener más información acerca de la depuración y la resolución de problemas de las aplicaciones de Lambda, consulte [Debugging](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops) en Serverless Land. **Topics** + [Solución de problemas de configuración en Lambda](troubleshooting-configuration.md) + [Solución de problemas en las implementaciones de Lambda](troubleshooting-deployment.md) + [Solucionar problemas de invocación en Lambda](troubleshooting-invocation.md) + [Solucionar problemas de ejecución en Lambda](troubleshooting-execution.md) + [Solución de problemas de asignación de orígenes de eventos en Lambda](troubleshooting-event-source-mapping.md) + [Solucionar problemas de redes en Lambda](troubleshooting-networking.md) # Solución de problemas de configuración en Lambda Los ajustes de configuración de la función pueden influir en el rendimiento general y el comportamiento de la función de Lambda. Es posible que no causen errores de funcionamiento reales, pero pueden provocar tiempos de espera y resultados inesperados. Los siguientes temas proporcionan consejos para la solución de problemas habituales que se pueden experimentar en relación con los ajustes de configuración de la función de Lambda. **Topics** + [Configuración de memoria](#memory-config) + [Configuraciones limitadas por CPU](#cpu-bound-config) + [Tiempos de espera](#timeouts) + [Pérdida de memoria entre las invocaciones](#memory-leakage) + [Los resultados asíncronos se devuelven a una invocación posterior](#asynchronous-results) ## Configuración de memoria Puede configurar una función de Lambda para usar entre 128 MB y 10 240 MB de memoria. De forma predeterminada, a cualquier función creada en la consola se asigna la menor cantidad de memoria. Muchas funciones lambda alcanzan un rendimiento óptimo con esta configuración mínima. Sin embargo, si importa grandes bibliotecas de código o realiza tareas que requieren mucha memoria, 128 MB no son suficientes. Si las funciones se ejecutan mucho más lento de lo esperado, el primer paso es aumentar la configuración de memoria. Para funciones limitadas por memoria, esto resolverá el cuello de botella y puede mejorar el rendimiento de su función. ## Configuraciones limitadas por CPU En el caso de operaciones que requieren gran cantidad de computación, si la función experimenta un rendimiento más lento de lo esperado, es posible que se deba a que la función está vinculada a la CPU. En este caso, la capacidad computacional de la función no puede seguir el ritmo del trabajo. Aunque Lambda no permite modificar la configuración de la CPU directamente, esta se controla indirectamente a través de la configuración de la memoria. El servicio de Lambda asigna proporcionalmente más CPU virtual a medida que se asigna más memoria. Con 1,8 GB de memoria, una función de Lambda tiene asignada una vCPU completa y, por encima de este nivel, tiene acceso a más de un núcleo de vCPU. Con un tamaño de 10 240 MB, tiene 6 vCPU disponibles. En otras palabras, puede mejorar el rendimiento si aumenta la asignación de memoria, aunque la función no utilice toda la memoria. ## Tiempos de espera [Los tiempos de espera](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html) de las funciones de Lambda se pueden establecer entre 1 y 900 segundos (15 minutos). De forma predeterminada, la consola de Lambda establece este valor en 3 segundos. El valor del tiempo de espera es una válvula de seguridad que garantiza que las funciones no se ejecuten indefinidamente. Una vez alcanzado el valor de tiempo de espera, Lambda detiene la invocación de la función. Si un valor del tiempo de espera se acerca a la duración media de una función, existe un mayor riesgo de que se agote el tiempo de espera de la función inesperadamente. La duración de una función puede variar en función de la cantidad de datos transferidos y procesados y de la latencia de cualquier servicio con el que interactúe la función. Estos son algunos de los motivos más comunes de que se agote el tiempo de espera: + Al descargar datos de buckets de S3 u otros almacenes de datos, la descarga es mayor o tarda más que la media. + Una función realiza una solicitud a otro servicio, lo que aumenta el tiempo de respuesta. + Los parámetros proporcionados a una función requieren una mayor complejidad computacional en la función, lo que hace que la invocación tarde más tiempo. Al probar la aplicación, asegúrese de que las pruebas reflejen con precisión el tamaño y la cantidad de datos y de que los valores de los parámetros sean realistas. Es importante que utilice conjuntos de datos dentro de los límites razonables esperados para la carga de trabajo. Además, aplique límites superiores en la carga de trabajo siempre que resulte práctico. En este ejemplo, la aplicación podría utilizar un límite de tamaño máximo para cada tipo de archivo. A continuación, puede probar el rendimiento de la aplicación para un rango de tamaños de archivo esperados, hasta los límites máximos incluidos. ## Pérdida de memoria entre las invocaciones Las variables y los objetos globales almacenados en la fase INIT de una invocación a Lambda retienen su estado entre las invocaciones en caliente. Solo se restablecen por completo cuando el entorno de ejecución se ejecuta por primera vez (lo que también se denomina “arranque en frío”). Todas las variables almacenadas en el controlador se destruyen cuando el controlador se cierra. Se recomienda utilizar la fase INIT para configurar conexiones a bases de datos, cargar bibliotecas, crear cachés y cargar activos inmutables. Cuando utilice bibliotecas de terceros en varias invocaciones en el mismo entorno de ejecución, asegúrese de revisar su documentación para ver si se utilizan en un entorno de computación sin servidor. Algunas bibliotecas de registro y conexión a bases de datos pueden guardar los resultados de las invocaciones intermedias y otros datos. Esto hace que el uso de memoria de estas bibliotecas aumente con las siguientes invocaciones en caliente. Si este es el caso, es posible que la función de Lambda se quede sin memoria, incluso si el código personalizado dispone de las variables correctamente. Este problema afecta a las invocaciones que se producen en entornos de ejecución en caliente. Por ejemplo, el código siguiente crea una pérdida de memoria entre las invocaciones. La función de Lambda consume memoria adicional con cada invocación al aumentar el tamaño de una matriz global: ``` let a = [] exports.handler = async (event) => { a.push(Array(100000).fill(1)) } ``` Configurada con 128 MB de memoria, después de invocar esta función 1000 veces, la pestaña **Supervisión** de la función de Lambda muestra los cambios típicos en las invocaciones, la duración y el recuento de errores cuando se produce una pérdida de memoria: ![\[operaciones de depuración (figura 4)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-4.png) 1. **Invocaciones**: periódicamente se interrumpe una tasa de transacciones estable a medida que las invocaciones tardan más en completarse. Durante el estado estable, la pérdida de memoria no consume toda la memoria asignada a la función. A medida que se reduce el rendimiento, el sistema operativo busca en el almacenamiento local para dar lugar a la creciente cantidad de memoria que necesita la función, lo que se traduce en un menor número de transacciones que se realizan. 1. **Duración**: antes de que la función se quede sin memoria, finaliza las invocaciones a una velocidad constante de milisegundos de dos dígitos. A medida que se realiza la paginación, la duración se prolonga un orden de magnitud. 1. **Recuento de errores**: cuando la pérdida de memoria supera la memoria asignada, eventualmente la función produce errores debido a que la computación supera el tiempo de espera o el entorno de ejecución detiene la función. Tras el error, Lambda reinicia el entorno de ejecución, lo que explica por qué los tres gráficos muestran una vuelta al estado original. Al ampliar las métricas de CloudWatch por duración, se proporcionan más detalles sobre las estadísticas de duración mínima, máxima y media: ![\[operaciones de depuración (figura 5)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-5.png) Para encontrar los errores generados en las 1000 invocaciones, puede utilizar el lenguaje de consultas de CloudWatch Insights. La siguiente consulta excluye los registros informativos para informar solo los errores: ``` fields @timestamp, @message | sort @timestamp desc | filter @message not like 'EXTENSION' | filter @message not like 'Lambda Insights' | filter @message not like 'INFO'  | filter @message not like 'REPORT' | filter @message not like 'END' | filter @message not like 'START' ``` Cuando se ejecuta en el grupo de registros de esta función, se muestra que los errores periódicos se debieron a los tiempos de espera: ![\[operaciones de depuración (figura 6)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-6.png) ## Los resultados asíncronos se devuelven a una invocación posterior En el caso del código de función que usa patrones asíncronos, es posible que los resultados de devolución de llamada de una invocación se devuelvan en una invocación futura. En este ejemplo se usa Node.js, pero la misma lógica se puede aplicar a otros tiempos de ejecución con patrones asíncronos. La función utiliza la sintaxis de devolución de llamada tradicional de JavaScript. Se llama a una función asíncrona con un contador incremental que registra el número de invocaciones: ``` let seqId = 0 exports.handler = async (event, context) => { console.log(`Starting: sequence Id=${++seqId}`) doWork(seqId, function(id) { console.log(`Work done: sequence Id=${id}`) }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` Cuando se invoca varias veces seguidas, los resultados de las devoluciones de llamada se producen en las siguientes invocaciones: ![\[operaciones de depuración (figura 7)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-7.png) 1. El código llama a la función `doWork` y proporciona una función de devolución de llamada como último parámetro. 1. La función `doWork` tarda un tiempo en completarse antes de invocar la devolución de llamada. 1. El registro de la función indica que la invocación finaliza antes de que la función `doWork` termine de ejecutarse. Además, tras iniciar una iteración, se procesan las llamadas de iteraciones anteriores, tal y como se muestra en los registros. En JavaScript, las devoluciones de llamada asíncronas se gestionan con [un bucle de eventos.](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) Otros tiempos de ejecución utilizan diferentes mecanismos para gestionar la simultaneidad. Cuando finaliza el entorno de ejecución de la función, Lambda congela el entorno hasta la siguiente invocación. Después de que se reanude, JavaScript continúa el procesamiento del bucle de eventos, que en este caso incluye una devolución de llamada asíncrona de una invocación anterior. Sin este contexto, puede parecer que la función ejecuta código sin motivo alguno y devuelve datos arbitrarios. De hecho, en realidad es un artefacto de la forma en que interactúan la simultaneidad del tiempo de ejecución y los entornos de ejecución. Esto crea la posibilidad de que los datos privados de una invocación anterior aparezcan en una invocación posterior. Hay dos formas de prevenir y detectar este comportamiento. En primer lugar, JavaScript proporciona las [palabras clave async y await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) para simplificar el desarrollo asíncrono y también forzar la ejecución del código a esperar a que se complete una llamada asincrónica. La función anterior se puede reescribir utilizando este enfoque de la siguiente manera: ``` let seqId = 0 exports.handler = async (event) => { console.log(`Starting: sequence Id=${++seqId}`) const result = await doWork(seqId) console.log(`Work done: sequence Id=${result}`) } function doWork(id) { return new Promise(resolve => { setTimeout(() => resolve(id), 4000) }) } ``` El uso de esta sintaxis evita que el controlador se cierre antes de que finalice la función asíncrona. En este caso, si la devolución de llamada tarda más que el tiempo de espera de la función de Lambda, la función generará un error en lugar de devolver el resultado de la llamada en una invocación posterior: ![\[operaciones de depuración (figura 8)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-8.png) 1. El código llama a la función `doWork` asíncrona con la palabra clave await en el controlador. 1. La función `doWork` tarda un tiempo en completarse antes de resolver la promesa. 1. Se agota el tiempo de espera de la función porque `doWork` tarda más de lo que permite el límite de tiempo de espera y el resultado de la devolución de llamada no se devuelve en una invocación posterior. Asegúrese de que los procesos en segundo plano o las devoluciones de llamada del código se completen antes de que este finalice. Si esto no es posible en su caso de uso, puede usar un identificador para asegurarse de que la devolución de llamada pertenece a la invocación actual. Para ello, puede utilizar el *awsRequestId* proporcionado por el objeto de contexto. Al pasar este valor a la devolución de llamada asíncrona, puede comparar el valor pasado con el valor actual para detectar si la devolución de llamada se originó a partir de otra invocación: ``` let currentContext exports.handler = async (event, context) => { console.log(`Starting: request id=$\{context.awsRequestId}`) currentContext = context doWork(context.awsRequestId, function(id) { if (id != currentContext.awsRequestId) { console.info(`This callback is from another invocation.`) } }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` ![\[operaciones de depuración (figura 9)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-9.png) 1. El controlador de funciones de Lambda toma el parámetro context, que proporciona acceso a un identificador de solicitud de invocación único. 1. El `awsRequestId` se transmite a la función doWork. En la devolución de llamada, el ID se compara con el `awsRequestId` de la invocación actual. Si estos valores son diferentes, el código puede actuar en consecuencia. # Solución de problemas en las implementaciones de Lambda Al actualizar su función, Lambda implementa el cambio iniciando nuevas instancias de la función con el código o la configuración actualizados. Los errores de implementación impiden que se utilice la nueva versión y pueden deberse a problemas con el paquete de implementación, el código, los permisos o las herramientas. Cuando implementa actualizaciones en su función directamente con la API de Lambda o con un cliente como la AWS CLI, puede ver errores de Lambda directamente en la salida. Si utiliza servicios como AWS CloudFormation, AWS CodeDeploy o AWS CodePipeline, busque la respuesta de Lambda en los registros o en la secuencia de eventos del servicio. Los temas siguientes proporcionan consejos para solucionar problemas de errores y problemas que puedan surgir al utilizar la API de Lambda, la consola o las herramientas. Si se encuentra con un problema que no aparezca en esta lista, puede utilizar el botón **Comentarios** de esta página para notificarlo. Para obtener más consejos sobre la resolución de problemas y respuestas a preguntas comunes de soporte, visite el [Centro de conocimientos de AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Para obtener más información acerca de la depuración y la resolución de problemas de las aplicaciones de Lambda, consulte [Debugging](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops) en Serverless Land. **Topics** + [General: Se deniega el permiso/No se puede cargar dicho archivo](#troubleshooting-deployment-denied) + [General: se produce un error al llamar al UpdateFunctionCode](#troubleshooting-deployment-updatefunctioncode) + [Amazon S3: Código de error PermanentRedirect.](#troubleshooting-deployment-PermanentRedirect) + [General: No se puede encontrar, no se puede cargar, no se puede importar, clase no encontrada, ningún archivo o directorio](#troubleshooting-deployment-functionHandler1) + [General: controlador de método no definido](#troubleshooting-deployment-functionHandler2) + [General: se superó el límite de almacenamiento de código de Lambda](#troubleshooting-deployment-CodeStorageExceeded) + [Lambda: error de conversión de la capa](#troubleshooting-deployment-LayerConversionFailed) + [Lambda: InvalidParameterValueException o RequestEntityTooLargeException](#troubleshooting-deployment-InvalidParameterValueException1) + [Lambda: InvalidParameterValueException](#troubleshooting-deployment-InvalidParameterValueException2) + [Lambda: cuotas de simultaneidad y memoria](#troubleshooting-deployment-quotas) + [Lambda: configuración de alias para la simultaneidad aprovisionada no válida](#troubleshooting-deployment-provisioned-concurrency) ## General: Se deniega el permiso/No se puede cargar dicho archivo **Error:** *EACCES: permission denied, open '/var/task/index.js'* **Error:** *cannot load such file -- function* **Error:** *[Errno 13] Permission denied: '/var/task/function.py'* El tiempo de ejecución de Lambda necesita permiso para leer los archivos del paquete de implementación. En la notación octal de permisos de Linux, Lambda necesita 644 permisos para archivos no ejecutables (rw-r--r--) y 755 permisos (rwxr-xr-x) para directorios y archivos ejecutables. En Linux y macOS, utilice el comando `chmod` para cambiar los permisos de los archivos y directorios del paquete de implementación. Por ejemplo, para conceder a un archivo no ejecutable los permisos correctos, ejecute el siguiente comando. ``` chmod 644 ``` Para cambiar los permisos de los archivos en Windows, consulte [Set, View, Change, or Remove Permissions on an Object](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) en la documentación de Microsoft Windows. **nota** Si no concede a Lambda los permisos necesarios para acceder a los directorios del paquete de implementación, Lambda establecerá los permisos de esos directorios en 755 (rwxr-xr-x). ## General: se produce un error al llamar al UpdateFunctionCode **Error:** *An error occurred (RequestEntityTooLargeException) when calling the UpdateFunctionCode operation* Cuando carga un paquete de implementación o un archivo de capa directamente en Lambda, el tamaño del archivo ZIP está limitado a 50 MB. Para cargar un archivo más grande, almacénelo en Amazon S3 y utilice los parámetros S3Bucket y S3Key. **nota** Cuando carga un archivo directamente con la AWS CLI, el AWS SDK o de otro modo, el archivo ZIP binario se convierte a base64, que aumenta su tamaño en aproximadamente un 30 %. Para permitir esto y el tamaño de otros parámetros de la solicitud, el límite de tamaño de solicitud real que aplica Lambda es mayor. Por este motivo, el límite de 50 MB es aproximado. ## Amazon S3: Código de error PermanentRedirect. **Error**: *se produjo un error mientras GetObject. Código de error S3: PermanentRedirect. Mensaje de error S3: el bucket está en esta región: us-east-2. Utilice esta región para volver a intentar la solicitud* Cuando carga el paquete de implementación de una función desde un bucket Amazon S3, el bucket debe estar en la misma Región que la función. Este problema puede producirse cuando especifica un objeto Amazon S3 en una llamada a [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html), o utiliza el paquete y los comandos de implementación en la CLI de AWS CLI o en la CLI de AWS SAM. Cree un bucket de artefactos de implementación para cada Región donde desarrolle aplicaciones. ## General: No se puede encontrar, no se puede cargar, no se puede importar, clase no encontrada, ningún archivo o directorio **Error:** *Cannot find module 'function'* **Error:** *cannot load such file -- function* **Error:** *Unable to import module 'function'* **Error:** *Class not found: function.Handler* **Error:** *fork/exec /var/task/function: no such file or directory* **Error:** *Unable to load type 'Function.Handler' from assembly 'Function'.* El nombre del archivo o clase en la configuración del controlador de su función no coincide con su código. Consulte la siguiente sección para obtener más información. ## General: controlador de método no definido **Error:** *index.handler is undefined or not exported* **Error:** *Handler 'handler' missing on module 'function'* **Error:** *undefined method `handler' for \$1* **Error:** *No public method named handleRequest with appropriate method signature found on class function.Handler* **Error:** *Unable to find method 'handleRequest' in type 'Function.Handler' from assembly 'Function'* El nombre del método de controlador en la configuración del controlador de su función no coincide con su código. Cada motor de ejecución define una convención de nomenclatura para los controladores, como *nombredearchivo*.*nombredelmétodo*. El controlador es el método en el código de su función ejecutado por el motor de ejecución cuando se invoca la función. En algunos idiomas, Lambda proporciona una biblioteca con una interfaz que espera que un método de controlador tenga un nombre específico. Para obtener información detallada sobre la nomenclatura de controladores para cada idioma, consulte los temas siguientes. + [Creación de funciones de Lambda con Node.js](lambda-nodejs.md) + [Creación de funciones de Lambda con Python](lambda-python.md) + [Creación de funciones de Lambda con Ruby](lambda-ruby.md) + [Creación de funciones de Lambda con Java](lambda-java.md) + [Creación de funciones de Lambda con Go](lambda-golang.md) + [Creación de funciones Lambda con C\$1](lambda-csharp.md) + [Creación de funciones de Lambda con PowerShell](lambda-powershell.md) ## General: se superó el límite de almacenamiento de código de Lambda **Error:** se *superó el límite de almacenamiento de código*. Lambda almacena el código de la función en un bucket interno de S3 privado para la cuenta. A cada cuenta de AWS se asignan 75 GB de almacenamiento en cada región. El almacenamiento de código incluye el almacenamiento total utilizado tanto por las funciones como por las capas de Lambda. Si alcanza la cuota, recibirá un error de *CodeStorageExceededException* cuando intente implementar nuevas funciones. Para administrar el espacio de almacenamiento disponible, limpie las versiones antiguas de las funciones, elimine el código sin utilizar o utilice capas de Lambda. Además, se recomienda [utilizar cuentas de AWS separadas para cargas de trabajo distintas](concepts-application-design.md#multiple-accounts), a fin de facilitar la administración de las cuotas de almacenamiento. Puede ver el uso total de almacenamiento en la consola de Lambda, en el submenú **Panel**: ![\[monitoreo y observabilidad (figura 26)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/monitoring-observability-figure-26.png) ## Lambda: error de conversión de la capa **Error:** *error de conversión de la capa de Lambda. Para obtener consejos sobre cómo resolver este problema, consulte la página Solucionar problemas de implementación en Lambda en la Guía del usuario de Lambda.* Al configurar una función de Lambda con una capa, Lambda la fusiona con el código de la función. Si este proceso no se completa, Lambda devuelve este error. Si encuentra este error, siga estos pasos: + Eliminar cualquier archivo no utilizado de la capa + Eliminar cualquier enlace simbólico de la capa + Cambie el nombre de cualquier archivo que tenga el mismo nombre que un directorio en cualquiera de las capas de la función ## Lambda: InvalidParameterValueException o RequestEntityTooLargeException **Error**: *InvalidParameterValueException: Lambda no pudo configurar las variables de entorno porque las variables de entorno que ha proporcionado han excedido el límite de 4 KB. Cadena medida: \$1"A1":"uSFeY5cyPiPn7AtnX5BsM...* **Error:** *RequestEntityTooLargeException: la solicitud debe ser menor de 5120 bytes para la operación UpdateFunctionConfiguration* El tamaño máximo del objeto de variables que se almacena en la configuración de la función no debe exceder los 4096 bytes. Esto incluye nombres clave, valores, comillas, comas y corchetes. El tamaño total del cuerpo de la solicitud HTTP también es limitado. ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Runtime": "nodejs24.x", "Role": "arn:aws:iam::123456789012:role/lambda-role", "Environment": { "Variables": { "BUCKET": "amzn-s3-demo-bucket", "KEY": "file.txt" } }, ... } ``` En este ejemplo, el objeto tiene 39 caracteres y ocupa 39 bytes cuando se almacena (sin espacios en blanco) como la cadena `{"BUCKET":"amzn-s3-demo-bucket","KEY":"file.txt"}`. Los caracteres ASCII estándar en valores de variables de entorno utilizan un byte cada uno. Los caracteres ASCII y Unicode extendidos pueden usar entre 2 y 4 bytes por carácter. ## Lambda: InvalidParameterValueException **Error:** *InvalidParameterValueException: Lambda no pudo configurar las variables de entorno porque las variables de entorno que ha proporcionado contienen claves reservadas que actualmente no se admiten para su modificación.* Lambda reserva algunas claves de variables de entorno para uso interno. Por ejemplo, el motor de ejecución usa `AWS_REGION` para determinar la región actual y no se puede reemplazar. Otras variables, como `PATH`, son usadas por el tiempo de ejecución, pero se pueden extender en la configuración de su función. Para obtener una lista completa, consulte [Variables definidas de entorno de tiempo de ejecución](configuration-envvars.md#configuration-envvars-runtime). ## Lambda: cuotas de simultaneidad y memoria **Error:*** ConcurrentExecutions especificada para la función reduce UnreservedConcurrentExecution de la cuenta por debajo de su valor mínimo* **Error:*** el valor ‘MemorySize’ no cumplió con la restricción de seguridad: el miembro debe tener un valor menor o igual a 3008* Estos errores se producen cuando se supera la simultaneidad o las [cuotas](gettingstarted-limits.md) de memoria para su cuenta. Las nuevas cuentas de AWS tienen cuotas de simultaneidad y memoria reducidas. Para resolver errores relacionados a la simultaneidad, puede [solicitar un aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). No puede solicitar aumentos de cuota. + **Simultaneidad:** puede que se produzca un error si intenta crear una función mediante simultaneidad reservada o aprovisionada, o si la solicitud de simultaneidad por función ([PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)) supera la cuota de simultaneidad de su cuenta. + **Memoria:** se producen errores si la cantidad de memoria asignada a la función supera la cuota de memoria de la cuenta. ## Lambda: configuración de alias para la simultaneidad aprovisionada no válida **Error:***configuración de alias para la simultaneidad aprovisionada no válida* Este error se produce cuando se intenta actualizar el código o la configuración de una función de Lambda mientras un alias con simultaneidad aprovisionada apunta a una versión que tiene problemas. Lambda preinicializa entornos de ejecución para la simultaneidad aprovisionada y, si estos entornos no se pueden inicializar correctamente debido a errores de código, limitaciones de recursos o a una pila y un alias afectados, se produce un error en la implementación. Si encuentra este problema, siga estos pasos: 1. **Revierta el alias:** actualice de forma temporal el alias para que apunte a la versión que funcionaba anteriormente. ``` aws lambda update-alias \ --function-name \ --name \ --function-version ``` 1. **Corrija el código de inicialización de Lambda:** asegúrese de que el código de inicialización que se ejecuta fuera del controlador no tenga excepciones no detectadas e inicialice los clientes y las conexiones. 1. **Vuelva a implementar la seguridad:** implemente el código fijo y publique una nueva versión. A continuación, actualice el alias para que apunte a la versión corregida. Opcionalmente, vuelva a habilitar la [simultaneidad aprovisionada](provisioned-concurrency.md), si es necesario. Si utiliza AWS CloudFormation, actualice la definición de la pila `FunctionVersion:!GetAtt version.Version` para que el alias apunte a la versión que funciona: ``` alias: Type: AWS::Lambda::Alias Properties: FunctionName: !Ref function FunctionVersion: !GetAtt version.Version Name: BLUE ProvisionedConcurrencyConfig: ProvisionedConcurrentExecutions: 1 ``` # Solucionar problemas de invocación en Lambda Cuando invoca una función de Lambda, Lambda valida la solicitud y comprueba la capacidad de escalado antes de enviar el evento a su función o, para la invocación asíncrona, a la cola de eventos. Los errores de invocación pueden deberse a problemas con los parámetros de solicitud, la estructura de eventos, la configuración de funciones, los permisos de usuario, los permisos de recursos o los límites. Si invoca su función directamente, verá errores de invocación en la respuesta de Lambda. Si invoca la función de forma asíncrona, con una asignación de origen de eventos o a través de otro servicio, es posible que encuentre errores en los registros, una cola de mensajes fallidos o un destino de evento fallido. Las opciones de manejo de errores y el comportamiento de reintento varían en función de cómo invoque la función y del tipo de error. Para obtener una lista de los tipos de error que la operación `Invoke` puede regresar, consulte [Invocar](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). **Topics** + [Lambda: se agota el tiempo de espera de la función durante la fase Init (Sandbox.Timedout)](#troubleshooting-timeouts) + [IAM: lambda:InvokeFunction no autorizado](#troubleshooting-invocation-noauth) + [Lambda: no se encontró un arranque válido (Runtime.InvalidEntrypoint)](#troubleshooting-invocation-bootstrap) + [Lambda: no se puede realizar la operación ResourceConflictException](#troubleshooting-invocation-ResourceConflictException) + [Lambda: la función está atascada en Pendiente](#troubleshooting-invocation-pending) + [Lambda: una función utiliza toda la concurrencia](#troubleshooting-invocation-allconcurrency) + [General: no se puede invocar la función con otras cuentas o servicios](#troubleshooting-invocation-cannotinvoke) + [General: la invocación de funciones está en bucle](#troubleshooting-invocation-loop) + [Lambda: enrutamiento de alias con concurrencia aprovisionada](#troubleshooting-invocation-alias) + [Lambda: comienza en frío con concurrencia aprovisionada](#troubleshooting-invocation-coldstart) + [Lambda: el frío comienza con nuevas versiones](#troubleshooting-invocation-newversion) + [Lambda: salida inesperada de Node.js en tiempo de ejecución (Runtime.NodeJsExit)](#troubleshooting-invocation-nodejs-exit) + [EFS: la función no pudo montar el sistema de archivos EFS](#troubleshooting-invocation-efsmount) + [EFS: la función no se pudo conectar al sistema de archivos EFS](#troubleshooting-invocation-efsconnect) + [EFS: La función no pudo montar el sistema de archivos EFS debido al tiempo de espera](#troubleshooting-invocation-efstimeout) + [Lambda: Lambda detectó un proceso de E/S que estaba tomando demasiado tiempo](#troubleshooting-invocation-ioprocess) + [Contenedor: errores de CodeArtifactUserException](#troubleshooting-deployment-container-artifact) + [Contenedor: errores de InvalidEntrypoint](#troubleshooting-deployment-container-entrypoint) ## Lambda: se agota el tiempo de espera de la función durante la fase Init (Sandbox.Timedout) **Error:** *tiempo de espera de la tarea agotado tras 3,00 segundos* Cuando se agota el tiempo de espera de la fase [Init](lambda-runtime-environment.md#runtimes-lifecycle-ib), Lambda vuelve a inicializar el entorno de ejecución y vuelve a ejecutar la fase `Init` cuando llega la siguiente solicitud de invocación. Esto se denomina [inicio suprimido](lambda-runtime-environment.md#suppressed-init). Sin embargo, si la función está configurada con un [tiempo de espera](configuration-timeout.md) corto (generalmente alrededor de 3 segundos), es posible que el inicio suprimido no se complete durante el tiempo de espera asignado, lo que provocará que vuelva a agotarse el tiempo de espera de la fase `Init`. Como alternativa, el inicio suprimido se completa, pero no deja suficiente tiempo para que se complete la fase [Invoke](lambda-runtime-environment.md#runtimes-lifecycle-invoke), lo que hace que se agote el tiempo de espera de la fase `Invoke`. Para reducir los errores de tiempo de espera, utilice una de las siguientes estrategias: + **Aumento del tiempo de espera de la función**: amplíe el [tiempo de espera](configuration-timeout.md) para que las fases `Init` y `Invoke` se completen correctamente. + **Aumento de la asignación de memoria de la función**: más [memoria](configuration-memory.md) también significa una asignación de CPU más proporcional, lo que puede acelerar tanto la fase `Init` como la fase `Invoke`. + **Optimización del código de inicialización de la función**: reduzca el tiempo necesario para la inicialización para garantizar que las fases `Init` y `Invoke` se completen dentro del tiempo de espera configurado. ## IAM: lambda:InvokeFunction no autorizado **Error:** *User: arn:aws:iam::123456789012:user/developer is not authorized to perform: lambda:InvokeFunction on resource: my-function* El usuario o el rol que usted asume necesita permiso para invocar una función. Este requisito también se aplica a las funciones de Lambda y a otros recursos informáticos que invocan funciones. Agregue la política administrada de AWS **AWSLambdaRole** a su usuario o agregue una política personalizada que le permita la acción `lambda:InvokeFunction` en la función de destino. **nota** El nombre de la acción de IAM (`lambda:InvokeFunction`) hace referencia a la operación de la API de Lambda `Invoke`. Para obtener más información, consulte  [Administrar permisos en AWS Lambda](lambda-permissions.md) . ## Lambda: no se encontró un arranque válido (Runtime.InvalidEntrypoint) **Error:** *no se encontraron los arranques válidos: [/var/task/bootstrap/opt/bootstrap]* Este error suele ocurrir cuando la raíz del paquete de implementación no contiene un archivo ejecutable denominado `bootstrap`. Por ejemplo, si va a implementar una función de `provided.al2023` con un archivo .zip, el archivo de `bootstrap` debe estar en la raíz del archivo .zip, no en un directorio. ## Lambda: no se puede realizar la operación ResourceConflictException **Error:** *ResourceConflictException: la operación no se puede realizar en este momento. La función se encuentra actualmente en el siguiente estado: Pending (Pendiente* Cuando conecta una función a una nube virtual privada (VPC) en el momento de la creación, la función entra en un estado `Pending` mientras Lambda crea interfaces de redes elásticas. Durante este tiempo, no puede invocar o modificar su función. Si conecta su función a una VPC después de la creación, puede invocarla mientras la actualización esté pendiente, pero no podrá modificar su código o configuración. Para obtener más información, consulte  [Estados de función de Lambda](functions-states.md) . ## Lambda: la función está atascada en Pendiente **Error:** *una función está bloqueada en el estado `Pending` durante varios minutos.* Si una función queda atascada en el estado `Pending` durante más de seis minutos, llame a una de las siguientes operaciones de API para desbloquearla. + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) Lambda cancela la operación pendiente y pone la función en el estado `Failed`. Luego, puede intentar realizar otra actualización. ## Lambda: una función utiliza toda la concurrencia **Problema:** *Una función utiliza toda la concurrencia disponible, lo que hace que otras funciones se limiten.* Para dividir la concurrencia disponible en una cuenta de AWS de una región de AWS en grupos, utilice [concurrencia reservada](configuration-concurrency.md). La concurrencia reservada garantiza que una función siempre puede escalar a su concurrencia asignada, y que no escalará más allá de su concurrencia asignada. ## General: no se puede invocar la función con otras cuentas o servicios **Problema:** *puede invocar la función directamente, pero esta no se ejecuta cuando otro servicio o cuenta la invoca.* Puede conceder permisos a [otros servicios](lambda-services.md) y cuentas para invocar una función en la [política basada en recursos](access-control-resource-based.md) de la función. Si el usuario que invoca la función está en otra cuenta, ese usuario también necesita [permiso para invocar funciones](access-control-identity-based.md). ## General: la invocación de funciones está en bucle **Problema:** *la función se invoca continuamente en bucle.* Esto suele ocurrir cuando la función administra recursos en el mismo servicio de AWS que lo activa. Por ejemplo, es posible crear una función que almacene un objeto en un bucket de Amazon Simple Storage Service (Amazon S3) configurado con una [notificación que invoca la función de nuevo](with-s3.md). Para evitar que la función se ejecute, reduzca la [simultaneidad](lambda-concurrency.md) disponible a cero, lo que limita todas las invocaciones futuras. A continuación, identifique la ruta de acceso del código o el error de configuración que provocó la invocación recursiva. Lambda detecta y detiene de forma automática los bucles recursivos en algunos SDK y servicios de AWS. Para obtener más información, consulte [Utilice la detección de bucles recursivos de Lambda para evitar bucles infinitos](invocation-recursion.md). ## Lambda: enrutamiento de alias con concurrencia aprovisionada **Problema:** *Invocaciones de casos de superación de simultaneidad aprovisionadas durante el enrutamiento de alias.* Lambda utiliza un modelo probabilístico simple para distribuir el tráfico entre las dos versiones de funciones. En niveles de tráfico bajos, es posible que vea una gran variación entre el porcentaje configurado y el porcentaje real de tráfico en cada versión. Si su función utiliza la concurrencia aprovisionada, puede evitar [Invocaciones de casos de superación](monitoring-metrics-types.md#invocation-metrics) configurando un mayor número de instancias de simultaneidad aprovisionadas durante el tiempo en que el enrutamiento de alias está activo. ## Lambda: comienza en frío con concurrencia aprovisionada **Problema:** *Verá inicios en frío después de habilitar la concurrencia aprovisionada.* Cuando el número de ejecuciones simultáneas en una función es menor o igual que el [nivel configurado de concurrencia aprovisionada](provisioned-concurrency.md), no debería haber ningún comienzo frío. Para ayudarle a confirmar si la concurrencia aprovisionada funciona normalmente, haga lo siguiente: + [Comprobar que la concurrencia aprovisionada esté habilitada](provisioned-concurrency.md) en la versión o alias de la función. **nota** La simultaneidad aprovisionada no es compatible con la [versión no publicada de la función](configuration-versions.md) (\$1LATEST). + Asegúrese de que los desencadenadores invoquen la versión o alias de función correctos. Por ejemplo, si está utilizando Amazon API Gateway, compruebe que API Gateway invoca la versión de la función o alias con concurrencia aprovisionada, no \$1LATEST. Para confirmar que se está utilizando la concurrencia aprovisionada, puede comprobar la [métrica ProvisionedConcurrcyInvocations de Amazon CloudWatch](monitoring-concurrency.md#provisioned-concurrency-metrics). Un valor distinto de cero indica que la función está procesando invocaciones en entornos de ejecución inicializados. + Determine si la concurrencia de funciones excede el nivel configurado de concurrencia aprovisionada comprobando la [métrica ProvisionedConcurrencySpilloverInvocations de CloudWatch](monitoring-concurrency.md#provisioned-concurrency-metrics). Un valor distinto de cero indica que toda la concurrencia aprovisionada está en uso y que se ha producido alguna invocación con un inicio en frío. + Compruebe su [frecuencia de invocación](gettingstarted-limits.md#api-requests) (solicitudes por segundo). Las funciones con concurrencia aprovisionada tienen una tasa máxima de 10 solicitudes por segundo por concurrencia aprovisionada. Por ejemplo, una función configurada con 100 concurrencia aprovisionada puede manejar 1000 solicitudes por segundo. Si la tasa de invocación supera las 1000 solicitudes por segundo, pueden producirse algunos inicios en frío. ## Lambda: el frío comienza con nuevas versiones **Problema:** *Verá arranques en frío al implementar nuevas versiones de su función. * Cuando actualiza un alias de función, Lambda cambia automáticamente la concurrencia aprovisionada a la nueva versión en función de los pesos configurados en el alias. **Error**: *KMSDisabledException: Lambda no pudo descifrar las variables de entorno porque la clave KMS utilizada está deshabilitada. Compruebe la configuración de claves de KMS de la función.* Este error puede producirse si su clave AWS Key Management Service (AWS KMS) está deshabilitada o si se revoca la concesión que permite a Lambda utilizar la clave. Si falta la concesión, configure la función para utilizar una clave diferente. Luego, reasigne la clave personalizada para volver a crear la concesión. ## Lambda: salida inesperada de Node.js en tiempo de ejecución (Runtime.NodeJsExit) **Problema:** *el cliente de tiempo de ejecución de Lambda detectó un código de salida inesperado de Node.js.* Este error se produce cuando la función se cierra antes de que se hayan resuelto todas las promesas, por ejemplo, debido a un error de código. También puede ocurrir cuando Node.js detecta un punto muerto que impide que las promesas se resuelvan. Este error solo afecta a los controladores de estilo asíncrono, no a los de tipo devolución de llamada. **Tiempos de ejecución afectados**: Node.js 18 y versiones posteriores. **Para resolver este problema, siga estos pasos:** 1. Compruebe el código de la función para detectar promesas pendientes en los controladores asíncronos. 1. Asegúrese de que todas las promesas estén debidamente resueltas o rechazadas antes de que se complete la función. 1. Revise el código para ver las posibles condiciones de carrera en operaciones asíncronas. Para obtener más información sobre los códigos de salida y la finalización de procesos en Node.js, consulte la [Documentación de Node.js](https://nodejs.org/docs/latest/api/process.html#exit-codes). ## EFS: la función no pudo montar el sistema de archivos EFS **Error:** *EFSMountFailureException: la función no pudo montar el sistema de archivos de EFS con el punto de acceso arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd.* Se rechazó la solicitud de montaje en el [sistema de archivos](configuration-filesystem.md) de la función. Compruebe los permisos de la función y confirme que su sistema de archivos y su punto de acceso existen y están listos para su uso. ## EFS: la función no se pudo conectar al sistema de archivos EFS **Error:** *EFSMountConnectivityException: la función no se pudo conectar al sistema de archivos de Amazon EFS con el punto de acceso arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd. Compruebe la configuración de la red y vuelva a intentarlo.* La función no pudo establecer una conexión con el [sistema de archivos](configuration-filesystem.md) de la función con el protocolo NFS (puerto TCP 2049). Compruebe el [grupo de seguridad y la configuración de enrutamiento](https://docs.aws.amazon.com/efs/latest/ug/network-access.html) de las subredes de la VPC. Si aparecen estos errores después de actualizar los ajustes de configuración de la VPC de la función, intente desmontar y volver a montar el sistema de archivos. ## EFS: La función no pudo montar el sistema de archivos EFS debido al tiempo de espera **Error:** *EFSMountTimeoutException: la función no pudo montar el sistema de archivos EFS con el punto de acceso \$1arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd\$1 debido a que se agotó el tiempo de espera del montaje.* La función pudo conectarse al [sistema de archivos](configuration-filesystem.md) de la función, pero se agotó el tiempo de espera de la operación de montaje. Vuelva a intentarlo después en un tiempo corto y considere limitar la [concurrencia](configuration-concurrency.md) de la función para reducir la carga en el sistema de archivos. ## Lambda: Lambda detectó un proceso de E/S que estaba tomando demasiado tiempo *EFSIOException: esta instancia de función se detuvo porque Lambda detectó un proceso de E/S que estaba tardando demasiado.* Se agotó el tiempo de espera de una invocación anterior y Lambda no pudo finalizar el controlador de funciones. Este problema puede producirse cuando un sistema de archivos adjunto se queda sin créditos de ráfaga y el rendimiento previsto es insuficiente. Para aumentar el rendimiento, puede aumentar el tamaño del sistema de archivos o utilizar el rendimiento aprovisionado. ## Contenedor: errores de CodeArtifactUserException **Error:** *mensaje de error CodeArtifactUserPendingException* CodeArtifact está pendiente de optimización. La función pasa al [estado activo](functions-states.md) cuando Lambda completa la optimización. Código de respuesta de HTTP 409. **Error:** *mensaje de error CodeArtifactUserDeleteException* La eliminación de CodeArtifact está programada. Código de respuesta de HTTP 409. **Error:** *mensaje de error CodeArtifactUserFailedException* Lambda no pudo optimizar el código. Debe corregirlo y cargarlo de nuevo. Código de respuesta de HTTP 409. ## Contenedor: errores de InvalidEntrypoint **Error:***Runtime.ExitError o "errorType": "Runtime.InvalidEntrypoint"* Compruebe que la entrada a la imagen contenedor incluye la ruta absoluta como ubicación. Compruebe también que la imagen no contiene un enlace simbólico como ENTRYPOINT. **Error:** *está utilizando una plantilla CloudFormation y su contenedor ENTRYPOINT está siendo anulado con un valor nulo o vacío.* Revise el recurso [ImageConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-lambda-function-imageconfig.html) de la plantilla CloudFormation. Si declara un recurso `ImageConfig` en la plantilla, debe proporcionar valores no vacíos para las tres propiedades. # Solucionar problemas de ejecución en Lambda Cuando el tiempo de ejecución de Lambda ejecuta el código de la función, es posible que el evento se procese en una instancia de la función que ha estado procesando eventos durante algún tiempo, o que requiera que se inicialice una nueva instancia. Pueden producirse errores durante la inicialización de la función, cuando el código de controlador procesa el evento o cuando la función devuelve (o no devuelve) una respuesta. Los errores de ejecución de funciones pueden deberse a problemas con el código, la configuración de funciones, los recursos descendentes o los permisos. Si invoca su función directamente, verá errores de función en la respuesta de Lambda. Si invoca la función de forma asíncrona, con una asignación de orígenes de eventos o a través de otro servicio, es posible que encuentre errores en los registros, una cola de mensajes fallidos o un destino en caso de error. Las opciones de manejo de errores y el comportamiento de reintento varían en función de cómo invoque la función y del tipo de error. Cuando el código de función o el tiempo de ejecución de Lambda devuelven un error, el código de estado en la respuesta de Lambda es 200 OK. La presencia de un error en la respuesta se indica mediante un encabezado llamado `X-Amz-Function-Error`. Los códigos de estado de las series 400 y 500 están reservados para [errores de invocación](troubleshooting-invocation.md). **Topics** + [Lambda: depuración remota con Visual Studio Code](#troubleshooting-execution-remote-debugging) + [Lambda: la ejecución lleva demasiado tiempo](#troubleshooting-execution-toolong) + [Lambda: carga útil de evento inesperado](#troubleshooting-execution-unexpected-payload) + [Lambda: tamaños de carga útil inesperadamente grandes](#troubleshooting-execution-large-payload) + [Lambda: errores de codificación y descodificación de JSON](#troubleshooting-execution-json-encoding) + [Lambda: los registros o rastros no aparecen](#troubleshooting-execution-logstraces) + [Lambda: no aparecen todos los registros de mi función](#troubleshooting-execution-missinglogs) + [Lambda: la función regresa antes de que finalice la ejecución](#troubleshooting-execution-unfinished) + [Lambda: ejecución de una versión o alias de función no deseada](#unintended-function) + [Lambda: detección de bucles infinitos](#infinite-loops) + [General: falta de disponibilidad de servicios intermedios](#downstream-unavailability) + [AWS SDK: versiones y actualizaciones](#troubleshooting-execution-versions) + [Python: las bibliotecas se cargan de manera incorrecta](#troubleshooting-execution-libraries) + [Java: su función tarda más en procesar los eventos después de actualizar a Java 17 desde Java 11](#troubleshooting-execution-java-perf) + [Kafka: problemas de gestión de errores y reintentos de configuración](#troubleshooting-kafka-error-handling) ## Lambda: depuración remota con Visual Studio Code **Problema:** *dificultad para solucionar el problema de comportamiento complejo de una función de Lambda en el entorno real de AWS* Lambda proporciona una característica de depuración remota a través del AWS Toolkit for Visual Studio Code. Para la configuración y para obtener instrucciones generales, consulte [Depuración de forma remota de funciones de Lambda con Visual Studio Code](debugging.md). Para obtener instrucciones detalladas sobre la solución de problemas, los casos de uso avanzados y la disponibilidad regional, consulte [Depuración remota de funciones de Lambda](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) en la Guía del usuario de AWS Toolkit for Visual Studio Code. ## Lambda: la ejecución lleva demasiado tiempo **Problema:** *la ejecución de la función tarda demasiado tiempo.* Si el código tarda mucho más en ejecutarse en Lambda que en el equipo local, puede estar limitado por la memoria o la potencia de procesamiento disponibles para la función. [Configure la función con memoria adicional](configuration-memory.md) para aumentar la memoria y la CPU. ## Lambda: carga útil de evento inesperado **Problema**: *errores en la función relacionados con un formato JSON incorrecto o una validación de datos inadecuada.* Todas las funciones de Lambda reciben un evento de una carga útil como primer parámetro del controlador. La carga útil del evento es una estructura JSON que puede contener matrices y elementos anidados. Los formatos JSON incorrectos se pueden producir cuando son proporcionados por servicios ascendentes que no utilizan un proceso robusto para comprobar las estructuras JSON. Esto ocurre cuando los servicios concatenan cadenas de texto o incorporan entradas de usuario que no se han desinfectado. Con frecuencia, JSON también se serializa para pasarlo de un servicio a otro. Analice siempre las estructuras de JSON como productoras y consumidoras de JSON para asegurarse de que la estructura sea válida. Del mismo modo, si no se comprueban los rangos de valores en la carga útil del evento, se pueden producir errores. En el siguiente ejemplo, se muestra una función que procesa una retención: ``` exports.handler = async (event) => { let pct = event.taxPct let salary = event.salary // Calculate % of paycheck for taxes return (salary * pct) } ``` Esta función utiliza un salario y un tipo impositivo de la carga útil del evento para realizar el cálculo. Sin embargo, el código no comprueba si los atributos están presentes. Tampoco comprueba los tipos de datos ni garantiza los límites, por ejemplo, si el porcentaje de impuestos está entre 0 y 1. Como resultado, los valores que se encuentran fuera de estos límites producen resultados sin sentido. Un tipo incorrecto o un atributo faltante provocan un error de tiempo de ejecución. Cree pruebas para garantizar que su función gestione cargas útiles de mayor tamaño. El tamaño máximo de una carga útil de eventos Lambda es de 1 MB. Según el contenido, las cargas útiles más grandes pueden implicar que se pasen más elementos a la función o que se incrusten más datos binarios en un atributo JSON. En ambos casos, esto puede provocar un mayor procesamiento para una función de Lambda. Las cargas útiles más grandes también pueden provocar tiempos de espera. Por ejemplo, una función de Lambda procesa un registro cada 100 ms y tiene un tiempo de espera de 3 segundos. El procesamiento se realiza correctamente para entre 0 y 29 elementos de la carga útil. Sin embargo, una vez que la carga útil contenga más de 30 objetos, la función agota el tiempo de espera y genera un error. Para evitarlo, asegúrese de que los tiempos de espera estén configurados para gestionar el tiempo de procesamiento adicional correspondiente al número máximo de elementos esperado. ## Lambda: tamaños de carga útil inesperadamente grandes **Problema**: *se agota el tiempo de espera de las funciones o se producen errores debido a cargas útiles de gran tamaño.* Las cargas útiles más grandes pueden hacer que se agote el tiempo de espera y provocar errores. Recomendamos crear pruebas para garantizar que la función gestiona las cargas útiles más grandes previstas y que el tiempo de espera de la función está configurado correctamente. Además, algunas cargas útiles de eventos pueden contener punteros a otros recursos. Por ejemplo, es posible que una función de Lambda con 128 MB de memoria procese imágenes de un archivo JPG almacenado como objeto en S3. La función se desempeña según lo previsto con archivos de imagen más pequeños. Sin embargo, cuando se proporciona un archivo JPG más grande como entrada, la función de Lambda arroja un error debido a la falta de memoria. Para evitarlo, los casos de prueba deben incluir ejemplos de los límites superiores de los tamaños de datos esperados. El código también debe validar los tamaños de las cargas útiles. ## Lambda: errores de codificación y descodificación de JSON **Problema**: *excepción NoSuchKey al analizar entradas JSON.* Compruebe que procesa correctamente los atributos JSON. Por ejemplo, en el caso de los eventos generados por S3, el atributo `s3.object.key` contiene un nombre de clave de objeto codificado mediante URL. Muchas funciones procesan este atributo como texto para cargar el objeto de S3 al que se hace referencia: **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: event.Records[0].s3.object.key }).promise() ``` Este código funciona con el nombre de la clave `james.jpg`, pero arroja un error `NoSuchKey` cuando el nombre es `james beswick.jpg`. Dado que la codificación URL convierte los espacios y otros caracteres en un nombre de clave, debe asegurarse de que las funciones decodifiquen las claves antes de utilizar estos datos: **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " ")) }).promise() ``` ## Lambda: los registros o rastros no aparecen **Problema:** *los registros no aparecen en los Registros de CloudWatch.* **Problema:** *los registros de seguimiento no aparecen en AWS X-Ray.* La función necesita permiso para llamar a los Registros de CloudWatch y a X-Ray. Actualice su [rol de ejecución](lambda-intro-execution-role.md) para concederle permiso. Añada las siguientes políticas administradas para habilitar los registros y el seguimiento. + **AWSLambdaBasicExecutionRole** + **AWSXRayDaemonWriteAccess** Cuando agregue permisos a su función, actualice también su código o configuración. Esto obliga a las instancias en ejecución de su función, cuyas credenciales han expirado, a detenerse y ser sustituidas. **nota** Los registros pueden tardar de 5 a 10 minutos en aparecer después de una invocación de la función. ## Lambda: no aparecen todos los registros de mi función **Problema:** *faltan registros de funciones en Registros de CloudWatch, aunque mis permisos son correctos* Si su Cuenta de AWS alcanza los [límites de cuota de Registros de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html), CloudWatch limita el registro de funciones. Cuando esto sucede, es posible que algunos de los registros generados por sus funciones no aparezcan en los Registros de CloudWatch. Si su función genera registros a una velocidad demasiado alta para que Lambda los procese, los resultados de los registros podrían no aparecer en Registros de CloudWatch. Cuando Lambda no puede enviar registros a CloudWatch a la velocidad a la que su función los produce, Lambda elimina los registros para evitar que la ejecución de la función se ralentice. Podrá observar de manera constante los registros descartados cuando el rendimiento del registro supere los 2 MB/s para un solo flujo de registro. Si la función está configurada para usar [registros con formato JSON](monitoring-cloudwatchlogs-logformat.md), Lambda intenta enviar un evento [`logsDropped`](telemetry-schema-reference.md#platform-logsDropped) a los registros de CloudWatch cuando los descarta. Sin embargo, cuando CloudWatch limita el registro de la función, es posible que este evento no llegue a los registros de CloudWatch, por lo que no siempre verá un registro cuando Lambda los descarte. Para comprobar si su Cuenta de AWS alcanzó su límite de cuota de los Registros de CloudWatch, haga lo siguiente: 1. Abra la [consola de Service Quotas](https://console.aws.amazon.com/servicequotas). 1. En el panel de navegación, elija **Servicios de AWS**. 1. En la lista de **servicios de AWS**, busque y seleccione Registros de Amazon CloudWatch. 1. En la lista de **Service Quotas**, seleccione las cuotas `CreateLogGroup throttle limit in transactions per second`, `CreateLogStream throttle limit in transactions per second` y `PutLogEvents throttle limit in transactions per second` para ver su utilización. También puede configurar alarmas de CloudWatch para que le avisen cuando el uso de su cuenta supere el límite que especifique para estas cuotas. Consulte [Creación de una alarma de CloudWatch basada en un umbral estático](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) para aprender más. Si los límites de cuota predeterminados de Registros de CloudWatch no son suficientes para su caso, puede [solicitar un aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). ## Lambda: la función regresa antes de que finalice la ejecución **Problema: (Node.js)** *La función se devuelve antes de que el código termine de ejecutarse* Muchas bibliotecas, incluido el AWS SDK, funcionan de forma asíncrona. Cuando realiza una llamada de red o lleva a cabo otra operación que requiere esperar una respuesta, las bibliotecas devuelven un objeto denominado promesa que realiza un seguimiento del progreso de la operación en segundo plano. Para esperar a que la promesa se resuelva en una respuesta, utilice la palabra clave `await`. Esto bloquea la ejecución de su código de controlador hasta que la promesa se resuelve en un objeto que contiene la respuesta. Si no necesita usar los datos de la respuesta en el código, puede devolver la promesa directamente al tiempo de ejecución. Algunas bibliotecas no devuelven promesas, pero se pueden envolver en código que sí lo hace. Para obtener más información, consulte [Definir el controlador de las funciones de Lambda en Node.js](nodejs-handler.md). ## Lambda: ejecución de una versión o alias de función no deseada **Problema**: *no se invoca la versión o el alias de la función* Al publicar nuevas funciones de Lambda en la consola o mediante AWS SAM, la versión más reciente del código se representa con `$LATEST`. De forma predeterminada, las invocaciones que no especifican una versión o alias se dirigen automáticamente a la versión `$LATEST` del código de la función. Si utiliza versiones o alias de funciones específicos, estos son versiones publicadas inmutables de una función además de `$LATEST`. A la hora de solucionar problemas con estas funciones, primero hay que determinar si el autor de la llamada ha invocado la versión o el alias previstos. Para ello, revise los registros de las funciones. La versión de la función invocada siempre aparece en la línea de registro START: ![\[operaciones de depuración (figura 1)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-1.png) ## Lambda: detección de bucles infinitos **Problema**: *patrones de bucle infinito relacionados con las funciones de Lambda* En la función de Lambda hay dos tipos de bucles infinitos. El primero está dentro de la propia función, ocasionado por un bucle que nunca sale. La invocación solo finaliza cuando se agota el tiempo de espera de la función. Puede identificarlos si supervisa los tiempos de espera y, a continuación, corrige el comportamiento de bucle. El segundo tipo de bucle es entre las funciones de Lambda y otros recursos de AWS. Se producen cuando un evento de un recurso, como un bucket de S3, invoca una función de Lambda, que luego interactúa con el mismo recurso de origen para activar otro evento. Esto vuelve a invocar la función, lo que crea otra interacción con el mismo bucket de S3 y así sucesivamente. Estos tipos de bucles pueden proceder de distintos orígenes de eventos de AWS, incluidas las colas de Amazon SQS y las tablas de DynamoDB. Puede utilizar la [detección de bucles recursivos](invocation-recursion.md) para identificar estos patrones. ![\[operaciones de depuración (figura 2)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-2.png) Para evitar estos bucles, asegúrese de que las funciones de Lambda escriban en recursos que no sean los mismos que el recurso consumidor. Si debe volver a publicar los datos en el recurso consumidor, asegúrese de que los nuevos datos no desencadenen el mismo evento. Como alternativa, utilice el [filtrado de eventos](invocation-eventfiltering.md). Por ejemplo, aquí se proponen dos soluciones para bucles infinitos con recursos de S3 y DynamoDB: + Si vuelve a escribir en el mismo bucket de S3, utilice un prefijo o sufijo diferente del desencadenador del evento. + Si escribe elementos en la misma tabla de DynamoDB, incluya un atributo a partir del cual una función de Lambda consumidora pueda filtrar. Si Lambda encuentra el atributo, no se producirá otra invocación. ## General: falta de disponibilidad de servicios intermedios **Problema**: *los servicios intermedios de los que depende la función de Lambda no están disponibles* En el caso de las funciones de Lambda que llaman a puntos de conexión de terceros u otros recursos intermedios, asegúrese de que puedan gestionar los errores y los tiempos de espera del servicio. Estos recursos intermedios pueden tener tiempos de respuesta variables o no estar disponibles debido a interrupciones del servicio. Según la implementación, estos errores intermedios pueden aparecer como tiempos de espera de Lambda o excepciones si la respuesta de error del servicio no se gestiona dentro del código de la función. Siempre que una función dependa de un servicio intermedio, como una llamada a la API, implemente una lógica adecuada de gestión de errores y reintentos. En el caso de los servicios críticos, la función de Lambda debe publicar métricas o registros en CloudWatch. Por ejemplo, si una API de pago de terceros deja de estar disponible, la función de Lambda podrá registrar esta información. A continuación, podrá configurar alarmas de CloudWatch para enviar notificaciones relacionadas con estos errores. Dado que Lambda puede escalar rápidamente, los servicios intermedios sin servidor pueden experimentar dificultades para gestionar los picos de tráfico. Existen tres enfoques comunes para solucionar este problema: + **Almacenamiento en caché**: considere la posibilidad de almacenar en caché el resultado de los valores devueltos por servicios de terceros si no cambian con frecuencia. Puede almacenar estos valores en una variable global en la función, o en otro servicio. Por ejemplo, los resultados de una consulta de lista de productos desde una instancia de Amazon RDS podrían guardarse durante un periodo dentro de la función para evitar consultas redundantes. + **Almacenamiento en cola**: al guardar o actualizar datos, agregue una cola de Amazon SQS entre la función de Lambda y el recurso. La cola conserva los datos de forma duradera mientras el servicio intermedio procesa los mensajes. + **Proxies**: cuando se suelen utilizar conexiones de larga duración, como en el caso de las instancias de Amazon RDS, utilice una capa de proxy para agrupar y reutilizar esas conexiones. En el caso de las bases de datos relacionales, [Amazon RDS Proxy](https://github.com/aws-samples/s3-to-lambda-patterns/tree/master/docrepository) es un servicio diseñado para ayudar a mejorar la escalabilidad y la resiliencia en aplicaciones basadas en Lambda. ## AWS SDK: versiones y actualizaciones **Problema:** *El SDK de AWS incluido en el tiempo de ejecución no es la versión más reciente* **Problema:** *el AWS SDK incluido en el tiempo de ejecución se actualiza en forma automática* Los tiempos de ejecución de los lenguajes interpretados incluyen una versión del SDK de AWS. Lambda actualiza periódicamente estos tiempos de ejecución para usar la versión más reciente del SDK. Para encontrar la versión del SDK que se incluye en el tiempo de ejecución, consulte las siguientes secciones: + [Versiones del SDK incluidas en el tiempo de ejecución (Node.js)](lambda-nodejs.md#nodejs-sdk-included) + [Versiones del SDK incluidas en el tiempo de ejecución (Python)](lambda-python.md#python-sdk-included) + [Versiones del SDK incluidas en el tiempo de ejecución (Ruby)](lambda-ruby.md#ruby-sdk-included) Para utilizar una versión más reciente del AWS SDK o para bloquear las funciones a una versión específica, puede agrupar la biblioteca con el código de función o [crear una capa de Lambda](chapter-layers.md). Para obtener información detallada sobre la creación de un paquete de implementación con dependencias, consulte los temas siguientes: ------ #### [ Node.js ] [Implementar funciones Node.js de Lambda con archivos de archivo.zip](nodejs-package.md) ------ #### [ Python ] [Uso de archivos .zip para funciones de Lambda en Python](python-package.md) ------ #### [ Ruby ] [Implementar funciones de Lambda de Ruby con archivos .zip](ruby-package.md) ------ #### [ Java ] [Implementar funciones de Lambda Java con archivos de archivo .zip o JAR](java-package.md) ------ #### [ Go ] [Implementar funciones de Lambda en Go con archivos .zip](golang-package.md) ------ #### [ C\$1 ] [Crear e implementar funciones de Lambda C\$1 con archivos de archivo .zip](csharp-package.md) ------ #### [ PowerShell ] [Implementar funciones Lambda de PowerShell con archivos .zip](powershell-package.md) ------ ## Python: las bibliotecas se cargan de manera incorrecta **Problema:** (Python) *algunas bibliotecas no se cargan de manera correcta desde el paquete de implementación* Las bibliotecas con módulos de extensión escritos en C o C\$1\$1 deben compilarse en un entorno con la misma arquitectura de procesador que Lambda (Amazon Linux). Para obtener más información, consulte [Uso de archivos .zip para funciones de Lambda en Python](python-package.md). ## Java: su función tarda más en procesar los eventos después de actualizar a Java 17 desde Java 11 **Problema:** (Java) *su función tarda más en procesar los eventos después de actualizar a Java 17 desde Java 11* Ajuste el compilador con el parámetro `JAVA_TOOL_OPTIONS`. Los tiempos de ejecución de Lambda para Java 17 y versiones posteriores de Java cambian las opciones predeterminadas del compilador. El cambio mejora los tiempos de arranque en frío para las funciones de corta duración, pero el comportamiento anterior se adapta mejor a las funciones de computación intensiva y de ejecución prolongada. Establezca `JAVA_TOOL_OPTIONS` en `-XX:-TieredCompilation` para revertir al comportamiento de Java 11. Para obtener más información sobre el parámetro `JAVA_TOOL_OPTIONS`, consulte [Cómo entender la variable de entorno `JAVA_TOOL_OPTIONS`](java-customization.md#java-tool-options). ## Kafka: problemas de gestión de errores y reintentos de configuración **Problema:** *la asignación de orígenes de eventos de Kafka no puede configurar los ajustes de reintento ni los destinos en caso de error*. Las configuraciones de reintentos de Kafka y los destinos en caso de error solo están disponibles para las asignaciones orígenes de eventos con el modo aprovisionado habilitado. Asegúrese de haber configurado `MinimumPollers` en su `ProvisionedPollerConfig` antes de intentar establecer las configuraciones de reintento. Problemas frecuentes de configuración: + **Reintentos infinitos con lotes segmentados**: no se puede habilitar `BisectBatchOnFunctionError` cuando `MaximumRetryAttempts` está establecido en -1 (infinito). Establezca un límite de reintentos finito o deshabilite el lote segmentado. + **Recursión del mismo tema**: el tema de destino de Kafka en caso de error no puede coincidir con ninguno de los temas de origen. Elija un nombre de tema diferente para el tema de los mensajes fallidos. + **Formato de destino de Kafka inválido**: utilice el formato `kafka://` cuando especifique un tema de Kafka como destino en caso de error. + **Problemas de permisos de kafka:writeData:** asegúrese de que el rol de ejecución tenga permisos de `kafka-cluster:WriteData` para el tema de destino. Los problemas de excepciones de tiempo de espera, del tema que no existe o de limitación de la API de escritura pueden requerir aumentar los límites de la cuenta. # Solución de problemas de asignación de orígenes de eventos en Lambda Los problemas en Lambda que se relacionan con una [asignación de orígenes de eventos](invocation-eventsourcemapping.md) pueden ser más complejos porque implican la depuración en varios servicios. Además, el comportamiento del origen de eventos puede variar en función del origen de eventos exacto utilizado. En esta sección se enumeran los problemas más comunes relacionados con las asignaciones de orígenes de eventos y se ofrece orientación sobre cómo identificarlos y solucionarlos. **nota** En esta sección se utiliza un origen de eventos de Amazon SQS a modo de ilustración, pero los principios se aplican a otras asignaciones de orígenes de eventos que ponen en cola mensajes para funciones de Lambda. ## Identificación y administración de la limitación En Lambda, se produce una limitación cuando se alcanza el umbral de simultaneidad de la función o de la cuenta. Considere el siguiente ejemplo, en el que hay una función de Lambda que lee mensajes de una cola de Amazon SQS. Esta función de Lambda simula invocaciones de 30 segundos y tiene un tamaño de lote de 1. Esto significa que la función únicamente procesa 1 mensaje cada 30 segundos: ``` const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms)) exports.handler = async (event) => { await doWork(30000) } ``` Con un tiempo de invocación tan largo, los mensajes comienzan a llegar a la cola más rápidamente de lo que se procesan. Si la simultaneidad no reservada de la cuenta es 100, Lambda escala verticalmente hasta las 100 ejecuciones simultáneas y, a continuación, se produce la limitación. Puede ver este patrón en las métricas de CloudWatch de la función: ![\[operaciones de depuración (figura 10)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-10.png) Las métricas de CloudWatch para la función no muestran errores, pero el gráfico de **Ejecuciones simultáneas** muestra que se ha alcanzado la simultaneidad máxima de 100. Como resultado, el gráfico de **limitaciones** muestra la limitación en vigor. Puede detectar la limitación con las alarmas de CloudWatch, así como establecer una alarma cada vez que la métrica de limitación de una función sea superior a 0. Una vez identificado el problema de limitación, existen varias opciones para solucionarlo: + Solicitar un aumento de simultaneidad de AWS Support en esta región. + Identificar los problemas de rendimiento en la función para mejorar la velocidad de procesamiento y, por lo tanto, mejorar el rendimiento. + Aumente el tamaño del lote de la función, de modo que cada invocación procese más mensajes. ## Errores en la función de procesamiento Si la función de procesamiento arroja errores, Lambda devuelve los mensajes a la cola SQS. Lambda evita que la función se escale para evitar errores a escala. Las siguientes métricas de SQS en CloudWatch indican un problema con el procesamiento de colas: ![\[operaciones de depuración (figura 11)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-11.png) En concreto, aumentan tanto la antigüedad del mensaje más antiguo como la cantidad de mensajes visibles, mientras que no se elimina ningún mensaje. La cola sigue aumentando, pero los mensajes no se procesan. Las métricas de CloudWatch para la función de Lambda de procesamiento también indican que hay un problema: ![\[operaciones de depuración (figura 12)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-12.png) La métrica del **recuento de errores** es distinta de cero y va en aumento, mientras que **las ejecuciones simultáneas** se han reducido y la limitación se ha detenido. Esto muestra que Lambda ha dejado de escalar verticalmente la función debido a errores. Los registros de CloudWatch de la función proporcionan detalles sobre el tipo de error. Para resolver este problema, identifique la función causante del error y, a continuación, busque y resuelva el error. Después de corregir el error e implementar el nuevo código de la función, las métricas de CloudWatch deberían mostrar la recuperación del procesamiento: ![\[operaciones de depuración (figura 13)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/debugging-ops-figure-13.png) Aquí, la métrica de **recuento de errores** cae a cero y la métrica de **tasa de éxito** vuelve al 100 %. Lambda comienza a escalar verticalmente la función de nuevo, como aparece en el gráfico de **Ejecuciones simultáneas**. ## Identificar y gestionar la contrapresión Si un productor de eventos genera constantemente mensajes para una cola de SQS más rápido de lo que una función de Lambda puede procesarlos, se produce una contrapresión. En este caso, la supervisión de SQS debería mostrar la antigüedad del mensaje más antiguo en crecimiento lineal, junto con la cantidad aproximada de mensajes visibles. Puede detectar la contrapresión en las colas mediante las alarmas de CloudWatch. Los pasos para resolver la contrapresión dependen de la carga de trabajo. Si el objetivo principal es mejorar la capacidad de procesamiento y el rendimiento de la función de Lambda, dispone de varias opciones: + Solicite un aumento de simultaneidad de AWS Support en esta región específica. + Aumente el tamaño del lote de la función, de modo que cada invocación procese más mensajes. # Solucionar problemas de redes en Lambda De forma predeterminada, Lambda ejecuta las funciones en una nube virtual privada (VPC) interna con conectividad a los servicios de AWS e Internet. Para acceder a los recursos de red local, puede [configurar la función para que se conecte a una VPC de la cuenta](configuration-vpc.md). Cuando utiliza esta característica, administra el acceso a Internet y la conectividad de red de la función con recursos de Amazon Virtual Private Cloud (Amazon VPC). Los errores de conectividad de red pueden deberse a problemas de configuración de enrutamiento de la VPC, reglas de grupo de seguridad, permisos de rol de AWS Identity and Access Management (IAM), traducción de direcciones de red (NAT) o disponibilidad de recursos como direcciones IP o interfaces de red. En función del problema, es posible que aparezca un error específico o de tiempo de espera si una solicitud no puede alcanzar su destino. **Topics** + [VPC: La función pierde acceso a Internet o agota el tiempo de espera](#troubleshooting-networking-cfn) + [VPC: la conexión TCP o UDP falla de forma intermitente](#troubleshooting-networking-tcp-udp) + [VPC: la función necesita acceso a los Servicios de AWS sin utilizar Internet](#troubleshooting-networking-access) + [VPC: se ha alcanzado el límite de la interfaz de red elástica](#troubleshooting-networking-limit) + [EC2: interfaz de red elástica con tipo de “lambda”](#troubleshooting-networking-eni) + [DNS: no se puede conectar a los hosts con UNKNOWNHOSTEXCEPTION](#troubleshooting-networking-dns-tcp) ## VPC: La función pierde acceso a Internet o agota el tiempo de espera **Problema:** *la función de Lambda pierde el acceso a Internet después de conectarse a una VPC.* **Error:** *Error: Connect ETIMEDOUT 176.32.98.189:443* **Error:** *Error: Tiempo de espera de la tarea agotado tras 10,00 segundos* **Error:** *ReadTimeoutError: se agotó el tiempo de espera de lectura. (Tiempo de espera de lectura = 15)* Cuando conecta una función a una VPC, todas las solicitudes salientes pasan por la VPC. Para conectarse a Internet, configure la VPC para que envíe tráfico saliente desde la subred de la función a una puerta de enlace NAT en una subred pública. Para obtener más información y ejemplos de configuraciones de VPC, consulte [Habilitación del acceso a Internet para funciones de Lambda conectadas a VPC](configuration-vpc-internet.md). Si se agota el tiempo de espera de algunas de las conexiones TCP, compruebe en [VPC: la conexión TCP o UDP falla de forma intermitente](#troubleshooting-networking-tcp-udp) si la subred utiliza una lista de control de acceso a la red (NACL). De lo contrario, es probable que se deba a la fragmentación de paquetes. Las funciones de Lambda no pueden gestionar solicitudes TCP fragmentadas entrantes, ya que Lambda no admite la fragmentación de IP para TCP o ICMP. ## VPC: la conexión TCP o UDP falla de forma intermitente **nota** Este problema se aplica solo si la subred usa una [lista de control de acceso (ACL) a la red](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html#nacl-basics). Las ACL de red no son necesarias para que Lambda se conecte a las subredes. **Problema:** *Lambda pierde de forma intermitente la conexión con las subredes de la VPC, para las que ha configurado una lista de control de acceso (ACL) a la red*. Para las funciones de Lambda habilitadas para VPC, AWS crea [ENI de hiperplano](configuration-vpc.md#configuration-vpc-enis) en la cuenta del cliente y utiliza puertos efímeros del `1024` al `65535` para conectar Lambda a la VPC del cliente. Si usa ACL de red en la subred de destino, debe permitir el rango de puertos del `1024` al `65535` tanto para TCP como para UDP. No permitir este rango completo de puertos puede causar fallos de conexión intermitentes. ## VPC: la función necesita acceso a los Servicios de AWS sin utilizar Internet **Problema:** *la función de Lambda necesita acceso a los Servicios de AWS sin utilizar Internet.* Para conectar una función a los Servicios de AWS desde una subred privada sin acceso a Internet, utilice los puntos de conexión de VPC. ## VPC: se ha alcanzado el límite de la interfaz de red elástica **Error:** *ENILimitReachedException: Se alcanzó el límite de interfaz de red elástica para la VPC de la función.* Al conectar una función de Lambda a una VPC, Lambda crea una interfaz de red elástica para cada combinación de subred y grupo de seguridad adjuntos a la función. La cuota de servicio predeterminada es de 250 interfaces de red por VPC. Para solicitar un aumento de una cuota, use la [consola de Service Quotas](https://console.aws.amazon.com/servicequotas/home/services/lambda/quotas/L-9FEE3D26). ## EC2: interfaz de red elástica con tipo de “lambda” **Código de error:** *Client.OperationNotPermitted* **Mensaje de error:** *el grupo de seguridad no se puede modificar para este tipo de interfaz* Recibirá este error si intenta modificar una interfaz de red elástica (ENI) administrada por Lambda. No se incluye `ModifyNetworkInterfaceAttribute` en la API de Lambda para las operaciones de actualización en las interfaces de red elásticas creadas por Lambda. ## DNS: no se puede conectar a los hosts con UNKNOWNHOSTEXCEPTION **Mensaje de error:** *UNKNOWNHOSTEXCEPTION* Las funciones de Lambda admiten un máximo de 20 conexiones TCP simultáneas para la resolución de DNS. Es posible que la función esté agotando ese límite. Las solicitudes de DNS más comunes se llevan a cabo a través del UDP. Si la función solo establece conexiones DNS a través de UDP, es poco probable que este sea un problema. Este error suele producirse debido a una mala configuración o a una infraestructura degradada, por lo que antes de examinar en profundidad el tráfico de DNS, confirme que su infraestructura de DNS está correctamente configurada y en buen estado y que la función de Lambda haga referencia a un host especificado en el DNS. Si diagnostica que el problema está relacionado con el límite máximo de conexión TCP, tenga en cuenta que no puede solicitar un aumento de este límite. Si su función de Lambda recurre al DNS de TCP debido a las grandes cargas útiles de DNS, confirme que la solución utilice bibliotecas compatibles con EDNS. Para obtener más información acerca de EDNS, consulte el [estándar RFC 6891](https://datatracker.ietf.org/doc/html/rfc6891). Si las cargas de DNS superan constantemente los tamaños máximos de EDNS, es posible que la solución siga agotando el límite de DNS de TCP.