Question 18931 in Amazon Web Sevices Question posted in
The official Amazon Web Services documentation can be found here.

LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413 – Amazon Web Sevices

I have node/express + serverless backend api which I deploy to Lambda function.

When I call an api, request goes to API gateway to lambda, lambda connects to S3, reads a large bin file, parses it and generates an output in JSON object.

The response JSON object size is around 8.55 MB (I verified using postman, running node/express code locally). Size can vary as per bin file size.

When I make an api request, it fails with the following msg in cloudwatch,

LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413

I can’t/don’t want to change this pipeline : HTTP API Gateway + Lambda + S3.

What should I do to resolve the issue ?

Tags:

2

Answers


  1. 0

    the AWS lambda functions have hard limits for the sizes of the request and of the response payloads. These limits cannot be increased.

    The limits are:

    • 6MB for Synchronous requests
    • 256KB for Asynchronous requests

    You can find additional information in the official documentation here:
    https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html

    You might have different solutions:

    • use EC2, ECS/Fargate
    • use the lambda to parse and transform the bin file into the desired JSON. Then save this JSON directly in an S3 public bucket. In the lambda response, you might return the client the public URL/URI/FileName of the created JSON.

    For the last solution, if you don’t want to make the JSON file visible to whole the world, you might consider using AWS Amplify in your client or/and AWS Cognito in order to give only an authorised user access to the file that he has just created.

    Login or Signup to reply.
  2. 0

    As noted in other questions, API Gateway/Lambda has limits on on response sizes. From the discussion I read that latency is a concern additionally.

    With these two requirements Lambda are mostly out of the question, as they need some time to start up (which can be lowered with provisioned concurrency) and do only have normal network connections (whereas EC2,EKS can have enhanced networking).

    With this requirements it would be better (from AWS Point Of View) to move away from Lambda.

    Looking further we could also question the application itself:

    • Large JSON objects need to be generated on demand. Why can’t these be pre-generated asynchronously and then downloaded from S3 directly? Which would give you the best latency and speed and can be coupled with CloudFront
    • Why need the JSON be so large? Large JSONs also need to be parsed on the client side requiring more CPU. Maybe it can be split and/or compressed?
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search