In my current project I want to call a long running Lambda function from an API Gateway asynchronously. All resources are defined in a SAM template.

I tried to follow the instructions in .html and came finally up with this code:

  MyApi:
    Type: 'AWS::Serverless::Api'
    Properties:
      StageName: Prod
      DefinitionBody:
        swagger: '2.0'
        info:
          title:
            Ref: 'AWS::StackName'
        paths:
          /invoke:
            get:
              x-amazon-apigateway-integration:
                uri:
                  Fn::Sub:
                    - 'arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${LambdaArn}/invocations'
                    - LambdaArn: !GetAtt MyLambdaFunction.Arn
                httpMethod: POST
                type: aws
                responses:
                  default:
                    statusCode: 200
                requestParameters:
                  integration.request.header.X-Amz-Invocation-Type : "'Event'"
                passthroughBehavior: "when_no_match"
                contentHandling: "CONVERT_TO_TEXT"

Calling the API URL starts indeed the Lambda asynchronously but the call comes back with a HTTP 500 and a message that says "Internal server error".

Defining the API Gateway using CloudFormation code instead of SAM and using the instructions from the link above worked flawlessly, even when defining the Lambda with SAM code. (In case someone wants to see how this is done: )

So, my question is: Is it a bug, is asychronous Lambda calling intendedly not possible with SAM or did I just not find the right trick to do it?

In my current project I want to call a long running Lambda function from an API Gateway asynchronously. All resources are defined in a SAM template.

I tried to follow the instructions in https://docs.aws.amazon/apigateway/latest/developerguide/set-up-lambda-integration-async.html and came finally up with this code:

  MyApi:
    Type: 'AWS::Serverless::Api'
    Properties:
      StageName: Prod
      DefinitionBody:
        swagger: '2.0'
        info:
          title:
            Ref: 'AWS::StackName'
        paths:
          /invoke:
            get:
              x-amazon-apigateway-integration:
                uri:
                  Fn::Sub:
                    - 'arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${LambdaArn}/invocations'
                    - LambdaArn: !GetAtt MyLambdaFunction.Arn
                httpMethod: POST
                type: aws
                responses:
                  default:
                    statusCode: 200
                requestParameters:
                  integration.request.header.X-Amz-Invocation-Type : "'Event'"
                passthroughBehavior: "when_no_match"
                contentHandling: "CONVERT_TO_TEXT"

Calling the API URL starts indeed the Lambda asynchronously but the call comes back with a HTTP 500 and a message that says "Internal server error".

Defining the API Gateway using CloudFormation code instead of SAM and using the instructions from the link above worked flawlessly, even when defining the Lambda with SAM code. (In case someone wants to see how this is done: https://github/nantoka69/aws_sam_api_gateway )

So, my question is: Is it a bug, is asychronous Lambda calling intendedly not possible with SAM or did I just not find the right trick to do it?

• aws-lambda
• aws-cloudformation
• aws-api-gateway
• aws-sam

1 Answer 1

You would need to change your solution approach due API gateway 30 second timeout.
API gateway request response has a maximum timeout of 30 seconds, anything above that would receive timeour errors.

You can change your solution in multiple ways

1. Have 2 lambda's first one attached to API gateway which takes the request and calls another lambda asynchronously and return request accepted to the API gateway.

2. Have 2 lambda's first one attached to API gateway which takes the request and sends as a message on SQS which is then asynchronously processed by the other lambda

3.Instead of using REST API gateway change to use websocket and then handle it if your client is expecting processing status