Amazon API Gateway: SAA-C03 resilience scenarios

API Gateway is a fully managed API front door: it terminates TLS, routes requests, scales automatically and integrates natively with both Lambda and HTTP/private backends, with nothing for the team to patch or capacity-plan. Why not the others: an Application Load Balancer can invoke Lambda but is a layer-7 load balancer, not an API-management layer — it has no usage plans, request validation or per-key throttling. Self-run NGINX instances reintroduce exactly the servers the requirement rules out. CloudFront is a CDN for caching and distribution; it fronts an API but does not itself provide the authorizer, throttling and validation controls the question implies. The phrase 'managed API entry point, no servers' points to API Gateway.

API Gateway throttling sets steady-state rate and burst ceilings, and usage plans tied to API keys let you cap each client individually, so one caller can no longer starve the rest — the surge is shed at the edge before it reaches compute. Why not the others: enlarging Lambda memory or maxing reserved concurrency just lets the backend absorb more of the flood at higher cost, it does not stop the abusive rate. A Dead-Letter Queue captures failed asynchronous messages; it is not attached to an API stage and does nothing to limit inbound request rate. Protecting a backend from request overload at the front door is throttling plus usage plans.

API Gateway has a built-in stage cache: enable it, set a TTL, and repeated reads are served from the cache without invoking the backend at all — fewer Lambda calls and lower latency, configured on the stage with no new components. Why not the others: ElastiCache and DAX are real caches but each is separate infrastructure the team would provision and wire in, and Lambda would still be invoked to consult them, so neither cuts invocations the way the stage cache does. Provisioned concurrency makes each Lambda start faster but still runs the function on every request. 'Cut invocations of a repeat-read API with the least new infrastructure' is the API Gateway response cache.

A Lambda authorizer runs your own code to verify a custom or third-party token and returns an allow/deny decision, while request validation checks required parameters and the body against a model — both reject bad traffic at the edge, so the backend is never invoked for an unauthorized or malformed call. Why not the others: doing it inside the function means Lambda is invoked and billed for exactly the requests you wanted to reject, defeating the requirement. IAM (SigV4) authorization suits AWS-credentialed callers, not third-party bearer tokens. WAF filters common web exploits and IP/rate patterns but is not a token authorizer and does not validate a JSON schema against a request model. Edge authorization plus validation is a Lambda authorizer plus request validation.

HTTP APIs are the newer, leaner option: lower price per request and lower latency, ideal when you only need proxy integrations and JWT/Lambda authorizers without the heavier feature set. Why not the others: REST APIs also integrate with Lambda, so 'only REST can' is false, and REST is the more expensive tier, not the cheapest — it earns its price with API keys and usage plans, request/response transformation, a built-in cache and private endpoints, none of which this team needs. A WebSocket API is for persistent two-way connections, not standard request/response. When the stem lists only basic proxy needs and stresses cost and latency, choose the HTTP API; when it demands usage plans, caching or transformation, choose REST.

API Gateway stages support canary releases: you attach a canary to a stage and route a configurable percentage of requests to the new deployment, watch the metrics, then promote it or roll back in place — no client changes. Why not the others: publishing to a separate stage means a different invoke URL, so clients would have to be told to switch, which is not a gradual same-endpoint rollout. An Application Load Balancer does not sit inside API Gateway's deployment model and cannot canary an API Gateway stage. Lambda versioning and aliases control which function code runs but do not, by themselves, split API traffic by percentage at the API layer. Percentage-based, same-endpoint rollout with instant rollback is a canary release.

Pointing API Gateway's integration straight at an SQS queue turns a synchronous overload into a buffered, asynchronous flow: the gateway enqueues each request and returns an immediate acknowledgement, and the processing service consumes the backlog steadily, so a spike is absorbed and nothing is lost — this page's sibling on SQS covers how the queue itself then decouples the consumers. Why not the others: raising throttling limits removes the very protection that keeps the surge off the fragile backend. A longer timeout leaves the request path synchronous and simply fails more slowly under load. Response caching serves repeat reads and has no role in accepting a burst of distinct writes. Absorb a write spike with no loss and an instant reply by having API Gateway enqueue to SQS.