Best practices for long-running API Gateway requests
API Gateway has a max connection of 29 seconds. A customer would like to use API Gateway for longer-running requests. What can we provide in terms of best practices to achieve this? My initial thoughts are around making the request "job based" (short lived POST, then GET polls to get job status) but that requires rearchitecting their application and adding job state.
Do we have blog posts or whitepapers to recommend best practices around this?
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
29 sec is the max timeout as of now which works for a majority of use cases. It would be better if you explain what kind of request is it that lasts more than 29 secs. Keep in mind that there might be proxies in the path whose timeout you may not be able to control.
ALB does not have such a limit. It might be a better solution in this case, without knowing anything else. But you won't benefit from rate limiting, throttling, API Keys, etc.
Separating request into POST and then GET polling is an alternative. WebSockets might be another one.
That said, this timeout may or may not be under revision. Even if it is, 29 sec is the limit right now.
Relevanter Inhalt
AWS OFFICIALAktualisiert vor einem Jahr- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
Can we petition AWS to increase the API gateway timeout limit of 29 seconds? I have been searching for days a solution using my server less architecture and its just post after post after post about people running into the same issue of needing to find a work around for this limit of 29 seconds. Having to rebuild the architecture or doing some work around using more AWS services shouldn't be a justified answer. If a user has to wait then a user has to wait, the user has no idea if they are waiting for the ALB response or the API Gateway response. Let the engineers manage the timeout/errors.