AWS lambda invoke no llama a otra función lambda – Node.js

Después de otorgar todos los derechos para invocar la función. Mi función Lambda no puede invocar otra función. Cada vez que tengo tiempo de espera tengo un problema de 30 seconds timeout espera de 30 seconds timeout . Parece que lambda no puede obtener otra función lambda

Mis lambdas están en la misma región, la misma política, el mismo grupo de seguridad … También las VPC son iguales en ambas lambdas. Lo único diferente ahora son las funciones lambda

Aquí están los derechos de roles

1) creó AWSLambdaExecute y AWSLambdaBasicExecutionRole

2) Creó una función lambda que se llamará Lambda_TEST

 exports.handler = function(event, context) { console.log('Lambda TEST Received event:', JSON.stringify(event, null, 2)); context.succeed(event); }; 

3) Aquí hay otra función desde donde se llama.

 var AWS = require('aws-sdk'); AWS.config.region = 'us-east-1'; var lambda = new AWS.Lambda(); exports.handler = function(event, context) { var params = { FunctionName: 'Lambda_TEST', // the lambda function we are going to invoke InvocationType: 'RequestResponse', LogType: 'Tail', Payload: '{ "name" : "Arpit" }' }; lambda.invoke(params, function(err, data) { if (err) { context.fail(err); } else { context.succeed('Lambda_TEST said '+ data.Payload); } }) }; 

Referencia tomada de: Este enlace

    Nota

    Denotaré por ejecutor la lambda que ejecuta la segunda lambda .


    ¿Por qué Timeout?

    Como el ejecutor está “bloqueado” detrás de una VPC , todas las comunicaciones de Internet están bloqueadas.

    Como resultado, las llamadas de http(s) se agotarán debido a que solicitan que el paquete nunca llegue al destino.

    Es por eso que todas las acciones realizadas por aws-sdk resultan en un tiempo de espera excedido.


    Solución simple

    Si el ejecutor no tiene que estar en una VPC , simplemente VPC , una lambda puede funcionar sin una VPC .

    La localización de la lambda en una VPC es necesaria cuando la lambda llama a recursos dentro de la VPC .

    Solución real

    De lo anterior, se deduce que cualquier recurso ubicado dentro de una VPC no puede acceder a Internet, eso no es correcto , solo se necesitan pocas configuraciones.

    1. Crea una VPC .
    2. Crea 2 subredes , deja que una sea denotada como privada y la segunda pública (estos términos se explican a continuación, sigue leyendo).
    3. Cree una puerta de enlace de Internet : es un enrutador virtual que conecta una VPC a Internet.
    4. Cree una puerta de enlace NAT : elija la subred pública y cree una nueva dirección elastic IP para ella (esta IP es local para su VPC ): este componente conectará las comunicaciones a la internet-gateway .
    5. Cree 2 tablas de enrutamiento : una llamada pública y la segunda privada .

      1. En la tabla de rutas públicas , vaya a Rutas y agregue una nueva ruta:

      Destino: 0.0.0.0/0

      Objetivo: el ID de la internet-gateway

      1. En la tabla de enrutamiento privada , vaya a Rutas y agregue una nueva ruta:

      Destino: 0.0.0.0/0

      Objetivo: la ID de la nat-gateway

      • Una subred privada es una subred que en su tabla de enrutamiento no hay una ruta a una internet-gateway .

      • Una subred pública es una subred que, en su tabla de enrutamiento, existe una ruta a una internet-gateway


    ¿Qué tenemos aquí?

    Creamos algo como esto:

    VPC con NAT e IGW

    Esto, lo que permite que los recursos en subredes privadas llamen a Internet. Puede encontrar más documentación aquí .

    He experimentado el mismo problema cuando los lambdas que están “anclados” a una VPC no pueden invocar a otros lambdas. He estado lidiando con este problema, sin usar NAT, refactorizando la estructura de mi solución.

    Digamos que tengo varias lambdas, A, B, C, D, … y me gustaría que estas Lambdas tengan acceso de consulta a una base de datos RDS. Para tener acceso a esta base de datos, necesito poner las lambdas en la misma VPC que la base de datos. Pero también me gustaría que varias lambdas entre A, B, C, D, … se invoquen mutuamente. Entonces me encuentro con el problema que describe Arpit.

    He estado lidiando con este problema al dividir cada Lambda en dos Lambdas: uno que se enfoca en el flujo del proceso (es decir, invoca a otras lambdas y es invocado por otra lambda); y el otro se centra en hacer un trabajo “real”, como consultar la base de datos. Así que ahora tengo las funciones A_flow, B_flow, C_flow, D_flow, …; y funciona A_worker, B_worker, C_worker, D_worker, … Las diversas lambdas de flujo no están “ancladas” a una VPC específica, y pueden así invocar otras lambdas. Los diversos trabajadores Lambdas están en la misma VPC que la base de datos y pueden consultar la base de datos.

    Cada flujo lambda “delega” el trabajo de interacción con DB al correspondiente trabajador lambda. Hace esta delegación realizando una invocación sincrónica del trabajador lambda. Las obreras lambdas no invocan ninguna otra lambda. (En términos del diagtwig de flujo del proceso, las lambdas del trabajador son nodos terminales.) En mi propio sistema, las invocaciones del flujo Lambdas por otros lambdas de flujo generalmente han sido asincrónicas; pero supongo que podrían ser sincrónicos si así lo desean.

    Aunque diseñé este enfoque como una solución alternativa, tiene una buena característica de separar claramente el diseño de funciones de alto nivel en (a) flujo de procesos y (b) realizar trabajos más detallados, incluida la interacción con recursos de BD.