RequestEntityTooLargeException: Request must be smaller than 6291456 bytes for the InvokeFunction operation

What it means

Lambda caps how much data can cross the invocation boundary in either direction, and the two limits are far apart. A synchronous invocation may carry 6 MB in and 6 MB out. An asynchronous one may carry 256 KB. Both are hard service limits: they are not adjustable quotas, and no support request will move them.

The gap between the two is where most surprises live. The same payload that works perfectly through a synchronous call fails immediately when the same function is invoked from EventBridge, SNS, or with InvocationType=Event — a twenty-fourfold reduction in headroom that arrives with a change that looks purely architectural. Moving a call from synchronous to asynchronous is normally a scaling improvement, and this is the one way it can silently break.

Direction is worth reading carefully, because it changes where to look. A request that is too large never reaches your function: there is no START line, no logging of yours, nothing in the log group for that attempt at all, and the error surfaces at whatever tried to invoke you. A response that is too large means the handler ran to completion — the query ran, the rows were assembled, the work was paid for — and only then was the result rejected. That second shape is particularly frustrating because the invocation shows every sign of success right up until it fails.

The limits also have a habit of being reached long after the code is written. An endpoint returning every order for a customer is comfortable at a hundred orders and fine at a thousand. Somewhere past that it crosses six megabytes, and the failure lands on the largest, most valuable customers first. That is why pagination or a claim-check pointer is the durable answer rather than trimming fields to buy headroom — the size of the response should not depend on how much data exists behind it.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

The byte count in the message tells you which limit you hit. 6291456 is 6 MiB, the synchronous invocation limit, and it applies to the request going in and the response coming back. 262144 is 256 KiB, the asynchronous limit, which is far smaller and catches people who moved a working synchronous call to an event-driven one.

Direction matters and the wording distinguishes it. A message about the request means the event was too big to deliver and your code never ran, so there will be no START line for it at all. A message about the response payload means your handler ran, did the work, and the return value could not be delivered — which appears after all of your own logging.

Causes, most likely first

Fixes

js// Instead of returning the whole export in the response:
const key = `exports/${crypto.randomUUID()}.json`;
await s3.send(new PutObjectCommand({
  Bucket: process.env.EXPORT_BUCKET,
  Key: key,
  Body: JSON.stringify(rows)
}));

return {
  statusCode: 200,
  body: JSON.stringify({
    key,
    url: await getSignedUrl(s3, new GetObjectCommand({
      Bucket: process.env.EXPORT_BUCKET, Key: key
    }), { expiresIn: 900 }),
    count: rows.length
  })
};

jsconst PAGE = 100;

const result = await doc.send(new QueryCommand({
  TableName: "orders",
  KeyConditionExpression: "customerId = :c",
  ExpressionAttributeValues: { ":c": customerId },
  Limit: PAGE,
  ExclusiveStartKey: event.queryStringParameters?.cursor
    ? JSON.parse(Buffer.from(event.queryStringParameters.cursor, "base64").toString())
    : undefined
}));

return {
  items: result.Items,
  cursor: result.LastEvaluatedKey
    ? Buffer.from(JSON.stringify(result.LastEvaluatedKey)).toString("base64")
    : null
};

jsexport const handler = awslambda.streamifyResponse(
  async (event, responseStream) => {
    for await (const chunk of rows()) {
      responseStream.write(JSON.stringify(chunk) + "\n");
    }
    responseStream.end();
  }
);

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Lambda quotas
• AWS Lambda Developer Guide — Configuring a Lambda function to stream responses