What is the maximum timeout for AWS API Gateway?

AWS API Gateway REST APIs have a hard limit of 29 seconds for integration timeout. HTTP APIs allow up to 30 seconds. These limits cannot be increased. For operations that take longer, use an asynchronous pattern: have the API accept the request with a 202 Accepted response containing a job ID, process the work in the background using Lambda, SQS, or Step Functions, and provide a polling endpoint where clients check the result. This pattern works within the timeout limit while supporting operations that take minutes or hours.

How should I order timeouts across multiple layers (CDN, load balancer, gateway, service)?

Configure timeouts so inner layers time out first: the backend service should have the shortest timeout, then the API gateway slightly longer, then the load balancer, then the CDN, and the client should have the longest. For example: service 40s, gateway 45s, load balancer 50s, CDN 55s, client 60s. This ensures each layer receives a proper error from the layer below rather than hitting its own timeout. Without this cascade, you get orphaned requests where the gateway times out but the backend keeps processing, wasting resources.

What is the difference between connection timeout and read timeout?

Connection timeout is how long to wait for a TCP connection to be established — this should be short (1-5 seconds) because TCP connections either establish quickly or the server is unreachable. Read timeout (also called response timeout) is how long to wait for the response after the request has been sent — this should match your endpoint's expected processing time (10-120 seconds typically). A common mistake is setting both to the same value. A 60-second connection timeout wastes time when a server is down; a 5-second read timeout kills valid requests that need more processing time.

How do I prevent orphaned requests when a gateway times out before the backend?

Orphaned requests happen when the gateway returns 504 to the client while the backend continues processing. Three approaches: (1) Timeout cascade — set backend timeout shorter than gateway timeout so the backend fails first. (2) Deadline propagation — pass a deadline header (like X-Request-Deadline) through the call chain so each service knows when to stop processing. In Go, use context.WithTimeout; in Node.js, use AbortSignal.timeout(). (3) Request cancellation — when the gateway detects a timeout, send a cancellation signal to the backend, or design backends to check if the client connection is still alive before doing expensive work.

How do I configure per-route timeouts in Kong Gateway?

Kong allows timeout configuration at the service level via the Admin API or declarative config. Set connect_timeout, write_timeout, and read_timeout in milliseconds on the service: curl -X PATCH http://localhost:8001/services/my-service --data read_timeout=120000. For per-route overrides, use plugins. You can also use the request-termination plugin to enforce hard limits on specific routes. In declarative config (kong.yml), set these under the services section. Remember that Kong's default timeout is 60 seconds (60000ms) for all three timeout types.

Managing Timeouts for APIs Behind Gateways