AWS API Gateway Explained: The Doorman in Front of Your Banking Backend

Amazon API Gateway is a managed front door for your APIs. AWS runs it, you configure it. Your banking app never talks to your backend directly. It talks to a doorman, and the doorman decides who gets in.

Clients sit on the left: the mobile app, the web app, a partner's system. They call one address. Your backends sit on the right: Lambda functions, HTTP endpoints, other AWS services, or private services behind a load balancer. Clients don't need to know where any of them live.

The request journey: four steps

Take one request. A customer opens the banking app and asks for a loan balance. The app sends a GET with the customer's token attached. That request arrives at API Gateway, and four things happen in order. The video calls this a simplified view, so treat the order as a mental model, not a guaranteed internal trace.

1. Authenticate. The first question is who is calling. API Gateway can ask IAM, Amazon Cognito or a Lambda authorizer to check the token. HTTP APIs can also validate a JWT directly, with no extra code. If the check fails, the request stops here and never touches your backend. For a bank, this keeps unknown callers away from core systems.

2. Throttle. Next, API Gateway checks how much traffic this caller is sending. It uses a token bucket: a steady request rate plus a burst allowance. Go over it and the caller gets a 429 Too Many Requests. This protects your backends from floods, whether they come from a buggy client or a deliberate attack. The default account quota is 10,000 requests per second per Region, with a bucket of 5,000. Some newer Regions, including Melbourne, start lower at 2,500 and 1,250. The quota covers every API in the account and Region, so set stage or route limits to stop one noisy client using the whole bucket.

3. Route. Now the gateway decides where the request goes. The method and path pick the integration. The loan balance route goes to a Lambda function. Another route might go to an HTTP endpoint or another AWS service. The client only ever calls one address, so you can move or replace a backend without changing the app.

4. Respond. The backend's answer travels back through the gateway to the app. On the way out, the gateway can also cache the response on REST APIs, so the next identical request skips the backend. Be careful caching anything customer-specific, such as a balance.

Three API types

	REST API	HTTP API	WebSocket API
Style	Request and response	Request and response	Two-way, connection stays open
Positioning	Full toolkit	Minimal, lower price	Real-time messaging
API keys, per-client throttling	Yes	No	No
Request validation, caching	Yes	No	No
AWS WAF, private endpoints	Yes	No	Check the docs
JWT authorizer	No (use a Lambda authorizer)	Yes	No
IAM, Lambda authorizer	Yes	Yes	Yes

AWS says to choose REST if you need API keys, per-client throttling, request validation, WAF or private endpoints. Choose HTTP if you don't need those. WebSocket suits live chat or price updates. A WebSocket connection closes after 10 idle minutes or 2 hours in total, so clients need reconnect logic. AWS also recommends an authorizer on the $connect route.

Guardrails around the route

Four controls sit around that route. Authorisation decides who may call which route, because authentication only proves who the caller is. Throttling can go further on REST APIs, where usage plans and API keys set limits per client. REST APIs can also cache responses so repeat requests skip the backend. For observability, metrics and access logs go to CloudWatch, and REST APIs add execution logs and X-Ray tracing.

REST APIs can also validate requests before the backend runs. Missing parameters or a body that fails the JSON schema return a 400. The check only confirms that required parameters exist, not their type or format, so it doesn't replace validation in your service.

Takeaway

Pick the simplest type that covers your needs: HTTP API if you want it lean, REST API if you need the full toolkit, WebSocket for real-time messaging. The gateway reduces what reaches your backend, but keep authorisation checks in the service that owns the data.

More explainers at ssmone.cloud.