Synchronous AWS Lambda & Amazon API Gateway limits and what to do about them
Tags: aws, serverless, lambda, apigw
Published: 2022-04-10 15:27:20

---
title: Synchronous AWS Lambda & Amazon API Gateway limits and what to do about them
published: true
description: Combining these two services is very popular in the AWS serverless world, yet some of the service limits might feel off-putting. What can we do about them?
tags: aws, serverless, lambda, apigw
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bwb45dkyz3t2dwrdqelh.jpeg
---
In the era of AWS serverless computing, there are two services that, one would argue, are used together very frequently – the [AWS Lambda](https://aws.amazon.com/lambda/) and [Amazon API Gateway](https://aws.amazon.com/api-gateway/).

Combining these two services allows developers to create APIs that serve millions of customers daily, scaling elastically depending on the workload. It is not all sunshine and rainbows, though.

In your AWS serverless journey, you will, at some point, end up faced with inbound payload size limits, most likely when interacting with AWS Lambda and Amazon API Gateway.

In this article, I will lay out different alternatives you might want to consider when you end up in a situation where Amazon API Gateway and AWS Lambda inbound payload size limits constrain your **synchronous** workflow.

## The typical AWS Lambda Amazon API Gateway synchronous architecture

Let us examine what, I would argue, is the most typical synchronous architecture that combines the AWS Lambda and Amazon API Gateway services.

![Typical synchronous architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h29s6a650cm8hfgqbjq7.jpeg)

**There is nothing wrong with it**. I would argue that the architecture is just fine for the vast majority of use-cases, especially for creating API routes in a serverless way.

### The payload size difference problem

It is crucial to notice one critical detail – the **difference in maximum payload size of Amazon API Gateway and AWS Lambda**. This delta might be frustrating and confusing. If you send a payload bigger than 6 MB, Amazon API Gateway will happily accept it and fail when invoking the AWS Lambda.

![Payload size delta problem in Typical APIGW Lambda sync architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nh0a7nlrusjy7g1t6bcy.jpeg)

I'm not aware of any other solution to this problem than to **restrict the payload size in the user-land**. Amazon API Gateway can [validate the request via JSONSchema](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html), but, to my best knowledge, you cannot validate the size of the payload.

One might also look into [AWS WAF](https://aws.amazon.com/waf/), where request body validation is possible, but only [for payloads of size up to 8192 bytes](https://docs.aws.amazon.com/waf/latest/APIReference/API_SizeConstraintStatement.html).

### I need to process bigger payloads synchronously

If you cannot afford or do not want to re-architect your solution to be asynchronous (which would, in theory, enable you to process potentially unbound payload sizes), there is one quick-win type of change you can make that could fit your use case. I'm referring to **compressing the payload before sending it to Amazon API Gateway**.

![Compressing the payload before sending it to Amazon API Gateway](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gcpupk42j0tizmg7gmw5.jpeg)

Notice that the **Amazon API Gateway is NOT decompressing the payload**. While the service in question [has this capability](https://docs.amazonaws.cn/en_us/apigateway/latest/developerguide/api-gateway-gzip-compression-decompression.html), it is the opposite of what we want to do. If we were to decompress at the Amazon API Gateway level, the service would try to send a 15 MB payload to AWS Lambda, resulting in an error.

### I need more time to process my synchronous request

By compressing the payload in the user-land, you can, to some extent, get around the 6 MB payload size limit. What about the 30-second response timeout?

If your payload is large, you might need more time to process the request synchronously. Luckily, with some changes to our infrastructure, it is **possible** to **bump the response timeout to 15 minutes** (the AWS Lambda timeout).

#### AWS Lambda function URL

A very recent addition to the AWS Lambda-related family of features, the [AWS Lambda URL](https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html) feature might be just what you need. We **ditch Amazon API Gateway** in this architecture since it was the primary response timeout bottleneck.

![AWS Lambda URL instead of Amazon API Gateway](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j7w6dg89piw2w94pehhz.jpeg)

**Keep in mind** that ditching Amazon API Gateway could have enormous consequences depending on the use case. Amazon API Gateway is rich in features like validation, caching, usage keys/plans, etc. **By utilizing the AWS Lambda URL feature, we gain the longer synchronous request timeout but lose all the niceties of Amazon API Gateway**. Keep this in mind while reaching out for this feature.

#### AWS Lambda fronted with Application Load Balancer

Instead of using Amazon API Gateway for fronting the AWS Lambda function, we can use the [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html). Like in the case of the AWS Lambda function URL feature, you will lose many of the Amazon API Gateway features but gain a much longer response timeout.

> In some architectures, with high-enough traffic and small sizes of the requests, fronting AWS Lambda with ALB is much more cost-effective than using Amazon API Gateway. You can read more about it [in this article](https://blog.tinystacks.com/battle-of-the-serverless-api-routers-alb-vs-api-gateway-pricing).

![AWS Lambda fronted with ALB](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6v27uv1dg86iqi79jasz.jpeg)

Note about "a lot" you see for _Maximum payload size_ and _Response timeout_ for ALB. I could not find quotas referring to these variables in the AWS documentation. **If you know the limits for those, please let me know!**

## The ultimate solution

If the 6 MB payload size is not enough, even with compressed payloads, and the 15 minutes of response timeout is too short, consider **re-architecting for asynchronous communication**. In the end **waiting for responses is expensive** and reaching out for tools like AWS Lambda function URL or fronting AWS Lambda with ALB to go around the limits might be a sign that asynchronous processing would be the right fit for your use case.

AWS exposes various services to facilitate such workloads, ranging from AWS Step Functions to AWS Batch or AWS Fargate and storing data on Amazon S3. This article would be too long if I were to describe all the possible asynchronous ways to get around the 6 MB AWS Lambda payload size limit – do not worry, that article is next on my list!

Until that, I will leave you with [this great article](https://theburningmonk.com/2020/04/hit-the-6mb-lambda-payload-limit-heres-what-you-can-do/) written by [Yan Cui](https://twitter.com/theburningmonk) as a sneak-peek of what I will be covering.

## Closing words

I hope you find the approaches described in this blog post helpful. Remember that all limits have a reason, be it related to technical or hardware limitations. Some might seem off-putting, like the 6 MB AWS Lambda payload size limit. Still, I do wholeheartedly believe that some of them, most likely by accident, push your architecture more towards asynchronous communication, which in most cases is a good thing!

Consider following me on [Twitter – @wm_matuszewski](https://twitter.com/wm_matuszewski) so that you do not miss the follow-up article (and more AWS serverless-related content).

Thank you for your valuable time.