- Newest
- Most votes
- Most comments
The 10 GB limit applies to both the request payload and to the response payload. The documentation talks about Resource or Operation limit. I have no idea how it worked before. Are you sure it was larger than 10 MB?
In either case, there are two options around it:
- Use compression. This will help in some case, but may break again if the returned object is > 10 MB also after compression.
- Store the object in S3 and return a pre-signed URL to the client (it can be returned in a redirect response).
Yes, the API might have allowed response size > 10 MB previously. However, API GW made a change recently to enforce the 10MB limit which was not enforced previously for HTTP APIs. As of now, the behavior should align with quota documentation here https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#http-api-quotas Payload size 10 MB which can't be increased.
Please consider the workarounds suggested in above answer using S3 pre-signed URL.
It just goes to show the level of disdain AWS has for its clients that such a breaking change was not announced or at least not announced more clearly. In addition, the documentation is very vague: does "Payload size" apply to request, or response, or both?
This is not the first issue we've had with API Gateway and it's become obvious for us that it's not a product AWS are serious about and we'll be moving away from it very soon to avoid more unplanned disruption affecting our clients and internal users.
This definitely hurts AWS as a brand: who knows when AWS will suddenly decide to impose a limit on the size of objects on S3, or the size of an EBS volume. A cloud provider needs to be reliable, and AWS is showing it is not.
It also doesn't take away the fact that 413 is not a correct response code here. RFC 2616 clearly states for status code 413:
The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
REQUEST entity.
Relevant content
- Accepted Answerasked 17 days ago
- asked 3 months ago
- asked 9 months ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
I'm quite positive that it used to work before. We used to run file download stress tests with a script that made several requests to download different files with sizes between 20MB to 100MB and it used to work quite well.
I also don't doubt that the requests made by the script went via API Gateway since it's our only entry point. The other entry point is a private load balancer so that's ruled out.
Furthermore, I checked with users of our application and they confirmed that they were able to download files >10MB before.
I have also ruled out any issues in our application because there was no release performed recently and I was also able to replicate the issue by adding a dummy route in API gateway pointing to a random 15MB pdf file on the internet.
So I still feel it's quite possible that something probably has changed in API gateway but it's a shame we can't really know for sure.
Anyway, we were able to get around this issue by creating a public load balancer and moving this one particular API to it. Thanks for your suggestions.
Just ran into the same issue and found this post. It definitely used to work for us before for RESPONSE sizes bigger than 10MB. Now it suddenly gives a 413 error for a request that's literally 0 bytes (just a GET) but with a response that's 14699136 bytes (14MB). Using HTTP integration.
At the very least the 413 response code is simply incorrect as that's an error code about request payload size, not response payload size. I'll raise this with AWS support, but they'll probably claim (like they did for a different API Gateway issue) that it's meant to do that and that they'll pass the request on to the product team but give no guarantees about when they will implement it. AWS does not take API Gateway seriously, that much is obvious.