AWS Services
Amazon API Gateway
Understand API Gateway for managed API front doors, including REST, HTTP, WebSocket APIs, Lambda integrations, throttling, authorization, caching, and exam signals.
After this, you will understand
API Gateway makes serverless APIs feel less like loose Lambda URLs and more like managed public contracts with auth, throttling, stages, and integrations.
API Gateway creates managed API endpoints that route client requests to Lambda, HTTP services, or AWS service integrations.
Learners use API Gateway for every event flow or forget that client-facing APIs need authorization, throttling, deployment stages, and observability.
Use API Gateway as a controlled ingress layer, then choose HTTP, REST, or WebSocket APIs based on protocol and feature needs.
Think before readingWhen is API Gateway a better mental fit than EventBridge?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Managed API front doors
- REST APIs
- HTTP APIs
- WebSocket APIs
- Lambda integrations
- HTTP integrations
- Authorizers
- Throttling and quotas
- Stages
- API Gateway versus ALB and EventBridge
1. Plain-English Mental Model
Amazon API Gateway is a managed front door for APIs.
Clients send HTTP or WebSocket requests to API Gateway. API Gateway handles the API endpoint, routing, authorization integration, throttling, request and response transformation where supported, stages, monitoring, and backend integration.
The simple model is:
client -> API Gateway -> Lambda, HTTP backend, or AWS service
API Gateway is often paired with Lambda for serverless APIs, but it can also integrate with HTTP backends, VPC links, and AWS services.
The key mental model is that API Gateway is request/response ingress. It is not a general event bus. If clients call an API and expect a response, API Gateway may fit. If services emit events to be routed asynchronously, EventBridge may fit.
2. Why This Service Exists
APIs need more than backend code.
A public API needs a stable endpoint, routes, stages, authentication or authorization, throttling, monitoring, deployment control, and sometimes request transformation. Without a managed API layer, teams often build these concerns into every service.
API Gateway exists to centralize API ingress and integrate it with AWS compute and services.
For SAA-C03, API Gateway appears when questions mention serverless REST APIs, HTTP APIs, WebSocket APIs, Lambda backends, throttling API clients, usage plans, custom domains, private APIs, request authorization, or exposing AWS services through an API.
It also appears in comparisons. API Gateway is not the same as ALB. ALB load balances HTTP traffic to targets. API Gateway provides API management features and integrations. Either may be valid depending on requirements.
3. The Naive Approach And Where It Breaks
The naive serverless API exposes a Lambda function URL or direct function invocation to clients without a broader API plan.
That may be fine for simple internal uses, but it can break when you need routes, throttling, API keys, custom authorizers, stages, request validation, custom domains, or WebSocket behavior.
Another naive design puts every container service behind API Gateway even when an ALB would be simpler and cheaper for normal HTTP load balancing.
Another mistake is using API Gateway for asynchronous event fanout. If the producer does not need a synchronous response and multiple consumers should react, EventBridge or SNS/SQS may be a better fit.
API Gateway is powerful, but the question should start with API contract needs, not service popularity.
4. Core Primitives
API Gateway supports REST APIs, HTTP APIs, and WebSocket APIs. REST APIs have the broadest legacy feature set. HTTP APIs are often simpler and lower cost for common HTTP API use cases. WebSocket APIs support bidirectional persistent communication patterns.
Routes map incoming requests to integrations.
Integrations connect API Gateway to Lambda, HTTP endpoints, VPC links, or AWS service actions.
Stages represent deployed versions or environments, such as dev, test, or prod.
Authorizers integrate with IAM, Cognito, Lambda authorizers, JWT authorizers, or other supported mechanisms depending on API type.
Throttling and quotas control request rates. Usage plans and API keys are available for REST API client management patterns.
Custom domains map friendly hostnames to APIs.
5. Architecture Use Cases
Use API Gateway plus Lambda for serverless APIs:
mobile app -> API Gateway -> Lambda -> DynamoDB
Use API Gateway HTTP APIs for lower-cost, simpler HTTP API routing when the feature set is enough.
Use REST APIs when features such as usage plans, API keys, certain transformations, or mature REST API capabilities are required.
Use WebSocket APIs for real-time bidirectional communication, such as chat connections or live updates, when API Gateway's WebSocket model fits.
Use private APIs or VPC links when API Gateway needs to reach private resources.
Use custom domains with Route 53 and ACM for public API endpoints.
7. Security Model
API Gateway security starts at the API boundary.
Choose authorization based on client type: IAM for AWS principals, Cognito for user pools, Lambda authorizers for custom auth, JWT authorizers for supported token flows, or resource policies for certain access patterns.
Use throttling and quotas to protect backends from abuse or accidental overload.
Use WAF when edge or regional API protection is required.
Use TLS for custom domains. Use resource policies or private APIs to restrict network or source access where needed.
Backend permissions matter. If API Gateway invokes Lambda, the Lambda function resource policy must allow API Gateway invocation.
Do not put secrets in query strings or logs.
8. Reliability And Resilience
API Gateway is managed, but backend reliability still matters.
If Lambda fails, API Gateway can return errors. If an HTTP backend is unhealthy, API Gateway cannot magically make it healthy.
Use throttling to prevent overload. Use retries carefully on clients because retry storms can amplify failure.
Cache responses where supported and appropriate. Caching can reduce backend load for read-heavy APIs, but stale data and invalidation must be understood.
Use stages and deployments to separate changes and roll out intentionally.
Monitor 4xx and 5xx errors, latency, integration latency, throttles, and backend metrics.
9. Performance And Scaling
API Gateway scales as a managed service, but quotas and backend capacity matter.
Latency includes API Gateway overhead plus integration latency. For very latency-sensitive internal HTTP services, ALB or direct service-to-service patterns may fit better.
Use caching for expensive read APIs when response freshness permits.
Use regional or edge-optimized endpoint choices based on client geography and architecture.
For Lambda integrations, cold starts, concurrency, and function duration affect API latency.
For private integrations, VPC link and target service performance matter.
10. Cost Model
API Gateway cost depends on API type, request count, data transfer, caching, custom domains, and related services.
HTTP APIs are often cheaper than REST APIs for simple HTTP workloads, but feature differences matter.
Caching adds cost but can reduce backend load.
ALB can be more cost-effective for high-volume container or EC2 HTTP services if API management features are not needed.
Lambda, CloudWatch logs, WAF, custom domains, and data transfer are part of the full API cost.
Do not choose the richest API type by default. Choose the needed feature set.
12. SAA-C03 Exam Signals
"Expose Lambda as a REST or HTTP API" points to API Gateway.
"WebSocket API" points to API Gateway WebSocket API.
"Throttle clients or enforce quotas" points to API Gateway throttling and usage plans where supported.
"Custom authorization before invoking Lambda" points to API Gateway authorizers.
"Simple container HTTP service behind load balancer" may point to ALB instead of API Gateway.
"Asynchronous event routing" points to EventBridge or SNS/SQS, not API Gateway.
"Private API reachable from VPC" points to private API patterns and VPC endpoints depending on wording.
13. Common Exam Traps
Do not use API Gateway when the requirement is only pub/sub event fanout.
Do not choose REST API features when HTTP API is enough and cost matters, unless the needed feature is REST-only.
Do not forget Lambda invoke permissions.
Do not ignore throttling. APIs need overload protection.
Do not use API keys as strong authentication by themselves.
Do not assume API Gateway fixes backend latency.
15. Related Topics
Review AWS Lambda, Amazon EventBridge, Amazon CloudFront, and Amazon ECS And AWS Fargate.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.