This chapter covers Amazon API Gateway, a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. For the CLF-C02 exam, API Gateway is a core service under the 'Cloud Technology Services' domain and appears in questions about serverless architectures, API management, and integration with AWS Lambda. Understanding API Gateway's features—such as throttling, caching, and authentication—is critical because the exam tests your ability to identify when to use API Gateway versus other services like ALB or CloudFront. This objective typically represents about 5-8% of the exam, so mastering it can significantly boost your score.
Jump to a section
Imagine you are a restaurant owner with a busy kitchen (your backend services). Customers (client apps) want to place orders, check reservations, or request the bill. Instead of letting customers barge into the kitchen directly—which would be chaotic, unsafe, and require the kitchen to handle every type of request—you hire a maître d'hotel (API Gateway). The maître d' stands at the front door, greets each customer, and checks their reservation (authentication). They then direct the customer to the appropriate station: the bar for drinks, the host for seating, or the cashier for payment. The maître d' also handles common tasks like taking coats (request transformation) and managing the waitlist (throttling). If too many customers arrive at once, the maître d' politely asks some to wait (rate limiting) rather than overwhelming the kitchen. The maître d' also keeps a log of all interactions (logging/monitoring) and can even combine multiple requests into one trip to the kitchen (aggregation). Importantly, the maître d' does not cook the food—they only manage the flow. This separation lets the kitchen focus on cooking (business logic) while the maître d' handles security, routing, and scaling. In AWS, API Gateway is that maître d': it sits between your clients and your backend (Lambda, EC2, or any HTTP endpoint), managing all the front-of-house concerns so your backend can be simple and scalable.
What is Amazon API Gateway and What Problem Does It Solve?
Amazon API Gateway is a fully managed service that enables developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs (Application Programming Interfaces) are the way different software applications communicate with each other. In a modern application, you often have many clients—web browsers, mobile apps, IoT devices—that need to interact with your backend services. Without a centralized API layer, each client would have to know the exact location and implementation details of each backend service. This tight coupling makes the system brittle: if you change a backend endpoint, all clients must be updated. Additionally, you would need to implement security, throttling, caching, and monitoring separately for each service, leading to duplicated effort and inconsistencies.
API Gateway solves these problems by acting as a single entry point for all client requests. It decouples the frontend from the backend, allowing backend services to evolve independently. It also handles cross-cutting concerns like authentication, rate limiting, request/response transformation, and API versioning. Because it is fully managed, you do not need to provision or manage any servers; AWS automatically scales the gateway to handle millions of concurrent requests.
How API Gateway Works — The Mechanism
At its core, API Gateway is a web service that listens on an HTTPS endpoint (you can also use WebSocket for real-time communication). When a client sends a request, API Gateway performs the following steps:
Receives the Request: The client sends an HTTPS request to the API Gateway endpoint URL, which looks something like https://api-id.execute-api.region.amazonaws.com/stage/resource. The request includes an HTTP method (GET, POST, PUT, DELETE, etc.), headers, query parameters, and a body.
2. Authentication and Authorization: API Gateway can validate the request using several mechanisms: - AWS IAM: The client signs the request using AWS Signature Version 4, and API Gateway verifies the signature with IAM. This is common for internal services. - Cognito User Pools: API Gateway can integrate with Amazon Cognito to authenticate users via JWT tokens. - Lambda Authorizer: You can write a custom Lambda function that validates the token (e.g., OAuth, SAML) and returns an IAM policy that grants or denies access. - API Keys: For usage plans, you can require an API key passed in the header.
Request Validation: API Gateway can validate the request body and parameters against a model (JSON Schema) before passing it to the backend. This prevents malformed requests from reaching your backend.
4. Integration Request: API Gateway transforms the incoming request into the format expected by the backend. This is done using mapping templates (Velocity Template Language, VTL) or, more commonly now, using request parameters and passthrough behaviors. The integration can be of several types: - Lambda: API Gateway invokes a Lambda function, passing the event object with the request data. - HTTP: API Gateway proxies the request to an HTTP endpoint (public or private VPC endpoint). - AWS Service: API Gateway can call other AWS services directly, such as DynamoDB, SQS, or Step Functions. - Mock: API Gateway returns a static response without calling a backend—useful for testing.
Backend Execution: The backend processes the request and returns a response. For Lambda, the function returns a response object; for HTTP, the endpoint returns an HTTP response.
Integration Response: API Gateway transforms the backend response into the desired format for the client. Again, mapping templates can modify the status code, headers, and body.
Caching: API Gateway can cache responses from the backend for a configurable TTL (Time to Live, default 300 seconds, min 0, max 3600). This reduces the load on your backend and improves latency for repeated requests.
Response Returned: API Gateway sends the final HTTP response to the client, including headers like x-amzn-RequestId for debugging.
Key Features and Configurations
API Types: - REST API: Traditional RESTful API with features like API keys, usage plans, and request validation. Most common for web and mobile backends. - HTTP API: A lighter, cheaper, and faster alternative to REST API. Supports OIDC and JWT authentication but lacks some features like API keys and usage plans. Introduced in 2019, it is ideal for simple Lambda proxy integrations. - WebSocket API: Maintains persistent connections for real-time two-way communication, such as chat apps or streaming data.
Stages and Deployments:
You define your API configuration in a resource tree (resources and methods). To make it callable, you must deploy the API to a stage. Stages represent environments like dev, test, prod. Each stage has its own endpoint URL and can have stage variables (like environment-specific Lambda function aliases).
You can enable canary deployments on a stage to gradually shift traffic to a new version.
Throttling and Quotas:
API Gateway provides rate limiting (requests per second) and burst limits (concurrent requests). By default, the account-level limit is 10,000 requests per second across all APIs, but you can request increases.
Usage plans allow you to set per-client throttling and quotas (daily, weekly, monthly). This is often used with API keys to monetize APIs.
Monitoring:
API Gateway integrates with Amazon CloudWatch for metrics (e.g., count, latency, 4XX/5XX errors) and logs. You can enable detailed CloudWatch Logs for each stage.
AWS X-Ray can be enabled to trace requests from the client through API Gateway to the backend, helping identify bottlenecks.
Pricing Models
API Gateway charges based on the number of API calls and the amount of data transferred. Pricing varies by region and API type: - REST API: $3.50 per million requests (for the first trillion) plus data transfer costs. Cache memory is charged hourly. - HTTP API: $1.00 per million requests (significantly cheaper). - WebSocket API: $1.00 per million messages and $0.25 per million connection minutes.
There is no upfront cost; you pay only for what you use. The free tier includes 1 million API calls per month for REST APIs for the first 12 months.
Comparison to On-Premises Alternatives
Before cloud, organizations would deploy API gateways like NGINX or Kong on their own servers. This required provisioning hardware, installing software, configuring load balancers, managing SSL certificates, and handling scaling. With API Gateway, AWS manages all of that. You define your API in a few clicks or via CloudFormation, and AWS automatically scales it. However, on-premises gateways give you full control over the software stack, which some enterprises require for compliance. API Gateway is also tightly integrated with other AWS services, making it the natural choice for serverless architectures.
When to Use API Gateway vs Alternatives
Use API Gateway when: You need a fully managed API layer with built-in authentication, throttling, caching, and monitoring. It excels in serverless applications (Lambda + API Gateway) and when you need to expose multiple backend services through a single endpoint.
Use Application Load Balancer (ALB) when: You need to route HTTP traffic to multiple targets (EC2, ECS, Lambda) at the network layer. ALB does not provide API key management, usage plans, or request transformation.
Use CloudFront when: You need content delivery and edge caching with some API routing capabilities (via Lambda@Edge). CloudFront is a CDN, not an API gateway, but can be used together with API Gateway to serve APIs from the edge.
Use AppSync when: You need a GraphQL API or real-time data synchronization for mobile apps. AppSync is purpose-built for GraphQL, while API Gateway is REST/HTTP/WebSocket.
Create a REST API
In the AWS Management Console, navigate to API Gateway and click 'Create API'. Choose 'REST API' (not HTTP or WebSocket) as the protocol. You'll be prompted to choose between 'New API' or 'Import from Swagger/OpenAPI 3'. For a new API, give it a name like 'PetStoreAPI' and optionally a description. Choose an endpoint type: 'Regional' (for clients in the same region), 'Edge-optimized' (uses CloudFront edge locations for lower latency worldwide), or 'Private' (only accessible within your VPC). For most serverless apps, Regional is fine. Click 'Create API'. Behind the scenes, AWS creates the API resource hierarchy in a 'draft' state—it's not yet accessible until you deploy it. The default endpoint type is Edge-optimized, which is important for the exam: it uses CloudFront under the hood, but you don't manage CloudFront separately.
Define Resources and Methods
After creating the API, you define the resource structure. A resource is a path segment like '/pets' or '/pets/{petId}'. Click 'Actions' > 'Create Resource'. For a path parameter, check 'Configure as proxy resource' or manually add curly braces. Then, for each resource, you define HTTP methods (GET, POST, PUT, DELETE, etc.). Click 'Actions' > 'Create Method'. Choose GET, for example, and click the checkmark. You then configure the integration type: Lambda Function, HTTP, AWS Service, Mock, or VPC Link. For a Lambda integration, select the Lambda region and function name. You can also choose 'Use Lambda Proxy Integration'—this passes the entire request as-is to Lambda, and Lambda must return a properly formatted response. Non-proxy integration allows you to use mapping templates to transform requests/responses. The default timeout for Lambda integration is 29 seconds. After setup, you can test the method using the 'Test' button in the console, which sends a sample request to your backend.
Deploy the API to a Stage
Once your API is configured, you must deploy it to make it publicly accessible. Click 'Actions' > 'Deploy API'. You are prompted to select or create a 'Deployment Stage'. Stages are like environments: 'dev', 'test', 'prod'. Each stage has its own invoke URL (e.g., https://api-id.execute-api.us-east-1.amazonaws.com/dev). You can also enable stage variables (key-value pairs) to pass environment-specific values to your integration, like a Lambda function alias or a DynamoDB table name. After deploying, you can test the live endpoint using a tool like curl or Postman. Important: Every time you update your API (add resources, change integrations), you must redeploy to a stage for changes to take effect. The exam tests that you understand the deployment step is required.
Configure Authentication and Throttling
To secure your API, you can enable authorization. For a method, go to 'Method Request' and set 'Authorization' to 'AWS_IAM' or 'Cognito' or choose a custom Lambda authorizer. For IAM, clients must sign requests with AWS credentials. For Cognito, you set up a user pool and require the client to pass a JWT token. You can also require an API key by checking 'API Key Required' and then creating a usage plan. To throttle, create a 'Usage Plan' with rate limits (e.g., 1000 requests per second) and quota (e.g., 10000 requests per day). Associate the usage plan with an API stage and issue API keys to clients. API Gateway will then enforce throttling at the client level. Without a usage plan, only account-level throttling applies. The exam often asks how to implement client-specific throttling—the answer is usage plans with API keys.
Monitor with CloudWatch and X-Ray
After deployment, you should monitor your API's health. In the API Gateway console, for a deployed stage, you can enable 'CloudWatch Logs' and 'X-Ray Tracing'. Enabling CloudWatch Logs generates detailed logs of each request, including request/response bodies and latency. You can set the log level to ERROR or INFO. X-Ray tracing provides end-to-end visibility from the client through API Gateway to your backend. This helps identify where latency is introduced. In the exam, know that you can enable both CloudWatch and X-Ray from the stage settings. Also, API Gateway emits metrics to CloudWatch automatically (Count, Latency, IntegrationLatency, 4XXError, 5XXError). You can create alarms based on these metrics. For example, if the 5XXError count exceeds a threshold, you can trigger an SNS notification.
Scenario 1: Serverless E-Commerce Backend
A startup building a mobile shopping app uses API Gateway as the single entry point for all client requests. The backend consists of several Lambda functions: one for product catalog, one for user authentication, one for order processing, and one for payment. The team creates a REST API with resources like /products, /orders, and /users. Each method integrates with a corresponding Lambda function. API Gateway handles authentication via Amazon Cognito User Pools—users log in with their email and password, and the mobile app passes the JWT token in the Authorization header. API Gateway validates the token before invoking the Lambda. The team also enables caching for the /products endpoint with a TTL of 60 seconds, reducing the load on the product Lambda and improving response times for popular items. They set up a usage plan for external third-party developers who want to access the product catalog API, issuing API keys and limiting them to 1000 requests per day. Cost is minimal: they pay per million requests, which for their early-stage app is under $10/month. A common mistake is forgetting to redeploy after changing the Lambda function's memory or timeout, causing the API to still invoke the old function. The team learned to always redeploy after any backend change.
Scenario 2: Real-Time Chat Application
A gaming company wants to provide real-time chat for players. They use API Gateway WebSocket API to maintain persistent connections. When a player opens the chat, the client establishes a WebSocket connection to the API Gateway endpoint. The $connect route triggers a Lambda function that registers the player's connection ID in a DynamoDB table. When a player sends a message, the $default route invokes a Lambda that broadcasts the message to all connected clients using the @connections API (postToConnection). The $disconnect route cleans up the connection ID. API Gateway handles the scaling of WebSocket connections automatically, supporting millions of concurrent connections. The company uses CloudWatch Logs to monitor connection counts and errors. One issue they encountered was that if the Lambda function times out (29 seconds), the WebSocket connection is closed. They adjusted the Lambda timeout to 10 seconds and added error handling. Cost is based on messages sent and connection minutes; for their 100,000 daily active users, the cost is about $50/month.
Scenario 3: Microservices Aggregation
A large enterprise has multiple legacy services running on EC2 instances behind an internal ALB. They want to expose a unified API to mobile apps. They deploy API Gateway with VPC Link (using NLB) to privately connect to the internal ALB within the VPC. API Gateway acts as a facade: the mobile app calls a single endpoint like /api/v1/user/profile, and API Gateway routes the request to the appropriate internal service. They also use request transformation to map the mobile app's JSON payload to the legacy XML format required by one of the services. This decouples the mobile team from the backend teams, allowing each to evolve independently. Cost considerations: VPC Link incurs an hourly charge plus data processing fees. They also enable caching to reduce load on the legacy services. A misconfiguration they faced: the VPC Link's security group did not allow inbound traffic from API Gateway's private IPs, causing 503 errors. They fixed it by allowing traffic from the VPC Link's subnet.
What CLF-C02 Tests on This Objective
Under 'Cloud Technology Services' (Domain 3, Objective 3.4), the exam expects you to identify the purpose and features of Amazon API Gateway. Specific topics include:
Recognizing API Gateway as the service that creates, publishes, and manages APIs.
Understanding that API Gateway can invoke Lambda functions, HTTP endpoints, or other AWS services.
Knowing the difference between REST API, HTTP API, and WebSocket API.
Identifying that API Gateway supports authentication via IAM, Cognito, Lambda authorizers, and API keys.
Understanding throttling and usage plans for rate limiting.
Knowing that API Gateway can cache responses to improve performance.
Recognizing that API Gateway integrates with CloudWatch and X-Ray for monitoring.
Common Wrong Answers and Why Candidates Choose Them
'API Gateway is used to host static websites.' This is wrong because hosting static websites is typically done with S3 + CloudFront. Candidates confuse API Gateway's ability to serve content with static hosting.
'API Gateway can only integrate with Lambda.' Wrong. API Gateway can integrate with HTTP endpoints, other AWS services, and even mock integrations. The exam may present a scenario where the backend is an EC2 instance behind an ALB; API Gateway can route to it via VPC Link.
'API Gateway is required for any serverless application.' While common, it's not required. You can invoke Lambda directly via AWS SDK or use ALB as a trigger. The exam might ask which service is best for exposing a RESTful API to the internet—API Gateway is the correct answer, but candidates might choose ALB because they think it's simpler.
'API Gateway automatically scales to unlimited requests.' It scales, but there are soft limits (default 10,000 rps) that can be increased. The exam tests that you know throttling occurs at the account level unless you set usage plans.
'HTTP API is more expensive than REST API.' Actually, HTTP API is cheaper ($1 vs $3.50 per million requests). Candidates often assume REST API is cheaper because it's older.
Specific Terms and Values on the Exam
Edge-optimized endpoint: Uses CloudFront edge locations; ideal for global clients.
Regional endpoint: Serves clients in the same region; lower latency for local clients.
Private endpoint: Only accessible within a VPC.
Usage Plan: Defines throttling (rate) and quota (number of requests) per API key.
API Key: A string value passed in the x-api-key header.
Lambda Proxy Integration: The entire request is passed to Lambda; the function must return a specific format.
Mapping Template: Used to transform request/response (VTL).
Canary Deployment: Gradually shift traffic to a new version.
$default, $connect, $disconnect: Route keys for WebSocket API.
Tricky Distinctions
API Gateway vs ALB: ALB is a Layer 7 load balancer; it does not provide API keys, usage plans, or request transformation. API Gateway is for API management, not just routing.
API Gateway vs CloudFront: CloudFront is a CDN that can serve APIs via Lambda@Edge, but it doesn't have built-in API key validation or usage plans. They are often used together.
REST API vs HTTP API: HTTP API is simpler and cheaper but lacks features like API keys and usage plans. The exam might ask which to use for a simple Lambda backend—HTTP API is correct.
Decision Rule for Multiple Choice
When you see a question about exposing an API to external clients with authentication and throttling, eliminate ALB and CloudFront first. Then decide between REST and HTTP API: if the question mentions API keys or usage plans, choose REST API. If it's a simple proxy to Lambda without those features, choose HTTP API. If it's real-time, choose WebSocket API.
Amazon API Gateway is a fully managed service for creating, publishing, and securing APIs at scale.
Three API types: REST API, HTTP API, and WebSocket API.
Supports authentication via IAM, Cognito User Pools, Lambda authorizers, and API keys.
Throttling is implemented through usage plans with rate and quota limits per API key.
Caching can be enabled per stage with configurable TTL (default 300 seconds).
Integration targets include Lambda functions, HTTP endpoints, and AWS services.
Deploying an API to a stage makes it publicly accessible; changes require redeployment.
Edge-optimized endpoints use CloudFront for global performance; regional endpoints are for local clients.
HTTP API is cheaper and simpler than REST API but lacks API keys and usage plans.
API Gateway integrates with CloudWatch for metrics and logs, and X-Ray for tracing.
These come up on the exam all the time. Here's how to tell them apart.
API Gateway REST API
Supports API keys, usage plans, and client throttling
Supports request validation with JSON Schema
Supports mapping templates (VTL) for request/response transformation
More expensive: $3.50 per million requests
Supports canary deployments and stage variables
API Gateway HTTP API
No built-in API keys or usage plans (use JWT or OIDC)
No request validation (use Lambda to validate)
No mapping templates (passthrough only)
Cheaper: $1.00 per million requests
Supports automatic deployments and JWT authorizers
Mistake
API Gateway is only for serverless applications using Lambda.
Correct
API Gateway can integrate with any HTTP endpoint, including EC2 instances, on-premises servers, and other AWS services like DynamoDB or SQS. Lambda is just one of many integration targets.
Mistake
API Gateway automatically caches all responses.
Correct
Caching is optional and must be enabled per stage. You configure the cache capacity (0.5 GB to 237 GB) and TTL (default 300 seconds). Not all responses are cached; you must set the cache key parameters.
Mistake
HTTP API is a newer version of REST API and will replace it.
Correct
HTTP API is a lighter alternative, but REST API still offers features like API keys, usage plans, and request validation that HTTP API lacks. They coexist, and you choose based on requirements.
Mistake
API Gateway can only handle HTTPS traffic.
Correct
API Gateway supports HTTPS for REST and HTTP APIs, but WebSocket API uses the wss:// protocol. It does not support plain HTTP; all traffic is encrypted in transit.
Mistake
You must use API Gateway to invoke a Lambda function from the internet.
Correct
You can invoke a Lambda function directly via the AWS SDK or CLI, but that requires AWS credentials. For public HTTP access, API Gateway or ALB are common, but you could also use Function URLs (Lambda feature) for simple use cases.
REST API offers full-featured API management including API keys, usage plans, request validation, and mapping templates. HTTP API is a lighter alternative that is cheaper and faster, supporting only JWT and OIDC authentication, and lacks API keys and usage plans. Choose REST API if you need client throttling or request transformation; choose HTTP API for simple Lambda proxy integrations where cost and performance are priorities.
API Gateway supports four authentication mechanisms: (1) AWS IAM – clients sign requests with SigV4; (2) Amazon Cognito User Pools – validate JWT tokens; (3) Lambda authorizer – custom logic to validate tokens and return an IAM policy; (4) API keys – simple key in the x-api-key header, often used with usage plans. For the exam, know that IAM is for internal services, Cognito for user pools, Lambda authorizer for custom OAuth/SAML, and API keys for third-party developer access.
A usage plan defines throttling limits (rate of requests per second) and quotas (total requests per day/week/month) for a specific API key. It allows you to enforce client-specific rate limiting and monetize your API. Without a usage plan, only account-level throttling applies (default 10,000 rps). Usage plans are associated with API stages and require API keys.
Yes, API Gateway supports WebSocket APIs for real-time, two-way communication. You define routes like $connect, $disconnect, and $default. When a client connects, the $connect route is invoked (often to store the connection ID in DynamoDB). Messages are sent via the $default route, and the backend can send messages to clients using the @connections API. WebSocket API is ideal for chat apps, live updates, and gaming.
Caching stores responses from your backend so that subsequent identical requests can be served without invoking the backend. You enable caching per stage and choose a cache capacity (0.5 GB to 237 GB) and TTL (default 300 seconds, min 0, max 3600). You can set cache key parameters (e.g., query strings, headers) to define what constitutes a unique request. Caching reduces latency and backend load, but adds cost for the cache instance.
Edge-optimized endpoints use CloudFront edge locations to improve latency for clients around the world. The API is deployed to a single region, but CloudFront caches responses at edge locations. Regional endpoints serve clients from the same region, reducing latency for local clients and avoiding CloudFront overhead. Edge-optimized is best for global audiences; Regional is best for clients in the same region as the API.
Logging is enabled per stage. In the API Gateway console, go to the stage, select the 'Logs' tab, and check 'Enable CloudWatch Logs'. You can set the log level to ERROR or INFO. You can also enable X-Ray tracing from the same tab. CloudWatch Logs captures detailed request/response data, while X-Ray provides end-to-end tracing. Note that enabling logs incurs additional CloudWatch costs.
You've just covered Amazon API Gateway — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?