Certablo
Sign inCreate account
← Knowledge Base
Networking & Deliveryservice

Amazon API Gateway

Managed front doors for REST, HTTP and WebSocket APIs: routes and methods, stages, integrations, authorization, request throttling and the feature trade-off between REST and HTTP APIs.

CLF-C02AIP-C01

Visual overview

MANAGED API FRONT DOORMatch the request, apply controls, then invoke the configured backend integration
01ClientREST · HTTP · WebSocket
→
02Route / methodMatch request + stage
→
03ControlsAuth · token bucket throttle
→
04IntegrationLambda · HTTP · AWS service
Token bucketRate = sustained refillBurstShort-term accumulated request capacity
API Gateway throttling uses rate and burst as distinct controls. The API layer and its backend each have their own permissions, limits and telemetry.
AWS SERVICE MAPManaged request path to backend compute

API Gateway matches and controls requests before invoking application logic; CloudWatch provides operational telemetry.

API GatewayRoute + control
AWS LambdaBackend integration
CloudWatchMetrics + logs
EXAM-RELEVANT MECHANICS

Technical reference

API Gateway is a request-control layer with explicit route, deployment and throttling mechanics.

API typesREST · HTTP · WebSocket

Choose from protocol and feature requirements; REST and HTTP API feature sets differ.

Request pathRoute/method → integration

A matched request is authorized/controlled before its configured backend integration is invoked.

Throttling algorithmToken bucket

Rate describes sustained token refill; burst describes short-term bucket capacity.

StageDeployment lifecycle state

A stage references an API deployment/exposure point and can carry stage-level configuration.

Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.

A managed API front door

Amazon API Gateway lets developers create, publish, maintain, monitor and secure APIs without operating the front-door server fleet themselves. An API receives client requests and maps them to integrations such as AWS Lambda functions, HTTP services or other supported backends. This separates public API concerns—routing, authorization, throttling and deployment—from the compute that actually performs business logic.

API Gateway supports REST APIs, HTTP APIs and WebSocket APIs. REST APIs expose a rich feature set and model resources with HTTP methods; HTTP APIs use routes that combine an HTTP method and path and can be a lower-cost, lower-complexity choice when the advanced REST API feature set is unnecessary. WebSocket APIs maintain bidirectional communication using WebSocket routes for connection-oriented applications.

Routes, methods, stages and integrations are different controls

A route or REST resource/method determines which request pattern is matched. The integration determines where API Gateway sends the matched request. A stage represents a logical lifecycle state or deployment exposure point and can carry stage-level configuration. Keeping these concepts separate helps explain a request path: client calls a deployed stage → API Gateway matches a route/method → authorization and request controls run → the configured integration receives the request.

Authorization choices vary by API type and can include AWS IAM, Amazon Cognito or Lambda authorizers in supported configurations. TLS protects transport to the API endpoint, while authorizers decide whether a caller is allowed to invoke the API. Backend authorization is a separate concern: the integration role or service permissions must allow API Gateway or the backend runtime to perform the downstream operation.

Throttling uses rate and burst, not only a requests-per-second number

API Gateway uses a token-bucket algorithm for request throttling. A rate limit controls the steady rate at which tokens are added to the bucket, while burst capacity allows short traffic spikes to consume accumulated tokens. When sufficient capacity is not available, API Gateway can throttle requests. This makes rate and burst distinct parameters: two APIs with the same steady rate can behave differently under short spikes depending on burst configuration and applicable service quotas.

Throttling protects backends and promotes fair use, but AWS documents throttle targets as best-effort rather than guaranteed hard ceilings. Exact account and Regional quotas can change and may be adjustable, so production capacity planning should check the current API Gateway quotas rather than memorizing one requests-per-second number. For REST APIs, usage plans and API keys can add per-client metering/throttling features that are not equivalent to authentication.

  • Rate = sustained token refill/steady request rate; burst = short-term bucket capacity.
  • API key identifies a usage-plan consumer; it should not be treated as a substitute for caller authentication.
  • REST API exposes features such as API keys, request validation and additional controls that may not be available in the same form for HTTP APIs.
  • CloudWatch metrics/logging and backend telemetry should be used to distinguish API throttling from backend latency or errors.

Key takeaways

  1. 01

    API Gateway is the managed API front door; integrations are the backends that process matched requests.

  2. 02

    REST, HTTP and WebSocket APIs serve different feature/protocol requirements.

  3. 03

    Routes/methods, stages, authorization and integrations are separate parts of the request lifecycle.

  4. 04

    API Gateway throttling uses a token-bucket model with rate and burst parameters; exact quotas should be checked in current AWS documentation.

Official AWS sources

Use these primary AWS resources for the source material behind this article and for deeper reference.