Amazon API Gateway is a fully managed service that lets you create, publish, maintain, monitor, and secure REST and WebSocket APIs at any scale. For the DVA-C02 exam, understanding API Gateway means you can build the front doors through which all your serverless applications communicate with the outside world. This chapter will give you the mental model you need to answer questions about creating APIs, configuring stages, authorising with IAM and Cognito, and enabling caching — all core topics in Domain 3.
Jump to a section
A busy restaurant kitchen with a single front counter.
A restaurant gets dozens of phone-in orders every night. Without a system, the lone server would have to scribble every order on a napkin, shout it to the chef, then hope the customer remembers to come pick it up. It's chaos. Amazon API Gateway is like installing a dedicated order-taking station right at the front door. The phone rings, the station answers, writes down the order (the API request), checks if the customer is who they say they are (like checking a membership card), then routes the order to the correct station — the grill for burgers, the fryer for chips, or the drinks fridge.
The station also caches popular orders. If a customer asks for "the usual" (a cached response), the station hands it over instantly without bothering the kitchen. The station has different windows for different groups: a pick-up window for regular customers (public API), a delivery driver window that requires a badge (IAM authentication), and a VIP window that unlocks with a special membership card (Cognito). When the kitchen changes its menu, the station updates its menu board (the API's stage variables) so customers see the latest prices. If the kitchen gets slammed, the station throttles incoming orders — it puts some callers on hold instead of letting the kitchen catch fire. This whole system lets the restaurant serve hundreds of customers without the single human server collapsing under the pressure.
Let's start by understanding what an API actually is. API stands for Application Programming Interface. Think of it as a waiter in a restaurant. You (the client) tell the waiter what you want (a burger, no onions), the waiter takes that request to the kitchen (the backend, like a Lambda function or a database), and then brings the result back to your table. Without the waiter, you would have to walk into the kitchen yourself, which is messy, unsafe, and the chef would lose it. An API is that polite, structured intermediary.
Amazon API Gateway is a managed service that handles that waiter role completely for you. 'Managed' means AWS takes care of all the underlying servers, networking, scaling, and security — you just tell it what you want your API to look like. Before cloud services, a company would have to buy a physical server, install software like Apache or Nginx to handle the API, configure security groups, set up load balancers, and then constantly monitor it to make sure it didn't crash under traffic. API Gateway replaces all of that with a few clicks in the AWS Management Console or a few lines of code.
There are three main types of APIs you can build with API Gateway: REST APIs, HTTP APIs, and WebSocket APIs. REST APIs are the most full-featured and are what the DVA-C02 exam focuses on. HTTP APIs are a lighter, cheaper alternative that works well for simpler use cases. WebSocket APIs are for two-way, real-time communication like chat apps or live sports scores. For the exam, you need to care most about REST APIs.
Here is how it works in practice. You start by defining your API's resources and methods. A 'resource' is like a folder path in the URL. For example, if you have an API for a pet store, your resources might be /pets, /pets/{petId}, and /pets/{petId}/photos. A 'method' is the HTTP verb that acts on that resource: GET (retrieve), POST (create), PUT (update), DELETE (remove), and PATCH (partial update). So a GET request to /pets might return a list of all pets, while a POST to /pets would create a new pet.
Once you have defined your resources and methods, you need to integrate them with a backend. API Gateway supports several integration types:
Lambda functions: The most common choice for serverless architectures. The API Gateway simply invokes a Lambda function, which runs your code.
HTTP endpoints: You can point the API at an existing public HTTP endpoint, like a legacy web application running on an EC2 instance.
AWS service integrations: API Gateway can directly call other AWS services, like sending a message to an SQS queue or putting an item into a DynamoDB table.
Mock integrations: You can return a sample response without hitting any backend — useful for testing.
Now, let's talk about stages. A 'stage' is like a named snapshot of your API configuration. You typically have multiple stages: dev, test, prod. Each stage has its own URL, its own settings (like throttling limits and caching), and even its own set of environment variables called 'stage variables'. This allows you to deploy your API to a test stage, validate everything, and then promote the same API to a production stage without changing the underlying code. A real-world example: imagine you have a weather API. In the dev stage, it connects to a test data source. In the prod stage, it connects to the live national weather database. Stage variables let you swap these connections without redeploying.
Securing your API is critical, and the exam loves to test three approaches. - IAM (Identity and Access Management) authorisation: You attach an IAM policy to the API Gateway resource or to a specific method. The client—for example, your Ionic mobile app, running on behalf of an IAM user—signs each request using AWS Signature Version 4. API Gateway verifies the signature against the IAM user's credentials. This is ideal for machine-to-machine communication where the client has AWS credentials. - Amazon Cognito: Cognito is a user identity platform. You create a user pool (a directory of users) and an app client. When a user logs in, Cognito returns a JSON Web Token (JWT). The client includes that token in the request header. API Gateway validates the token with Cognito before allowing the request through. This is perfect for mobile apps or web apps where humans log in with email and password. - Lambda authorisers (formerly called custom authorisers): You write a Lambda function that receives the request headers (like an API key or a JWT from a third-party provider like Google or Facebook) and returns an IAM policy that either allows or denies the request. This gives you the most flexibility.
Caching is another core feature. You can enable API caching at the stage level or for specific methods. When caching is on, API Gateway stores the response for a given request in a cache. When the exact same request comes in again, it returns the cached response immediately without bothering your backend. This dramatically reduces latency and saves costs on Lambda invocations. The 'time-to-live' (TTL) setting controls how long an item stays in the cache. You also have the ability to invalidate (clear) the cache from the client side by sending a request with the header 'Cache-Control: max-age=0'. Exam tip: remember that caching does not work for requests that require authorisation unless you explicitly configure it.
Throttling and quota management are built in. You can set a rate limit (how many requests per second) and a burst limit (how many requests can be handled in a short burst) for each method. If traffic exceeds those limits, API Gateway returns a 429 Too Many Requests error. This protects your backend from being overwhelmed. The exam often asks what happens when a request is throttled: the answer is never "the request goes to a dead letter queue" (that's for other services like SQS). The request simply fails with 429.
Finally, API Gateway supports request and response transformations using the Velocity Template Language (VTL). This lets you reshape incoming data before it reaches your backend and reshape outgoing data before it reaches your client. For example, a mobile app sends a JSON payload with a field called 'user_name', but your backend expects 'username'. You can use a mapping template to translate between them.
In summary, API Gateway is the front door for all your serverless APIs. It handles routing, authentication, throttling, caching, and versioning so you don't have to build that plumbing yourself. For DVA-C02, focus on the differences between the three auth types, the purpose of stages and stage variables, and how caching works with TTL and cache invalidation.
Create the API
In the AWS Management Console, go to API Gateway and click 'Create API'. You choose between REST API, HTTP API, or WebSocket API. For DVA-C02, start with REST API. Give it a name like 'MyFirstApi'. This step establishes the container for all your endpoints (resources and methods).
Define Resources and Methods
After creating the API, you add resources (e.g., /items) and methods (e.g., GET, POST). Each resource is like a path in the URL (https://api.com/items). Each method is an HTTP verb that acts on that path. You configure what happens when a request hits that method — usually by linking it to a Lambda function, an HTTP endpoint, or another AWS service.
Configure the Integration
For each method, you choose an integration type. For a Lambda integration, you select the Lambda function name and choose proxy or non-proxy mode. Proxy mode forwards the entire HTTP request to the Lambda function. Non-proxy mode lets you transform the request and response using mapping templates. This step defines what backend code actually runs when the API is called.
Set Up Authentication and Authorisation
You enable one of the three authorisation mechanisms (IAM, Cognito, or Lambda authoriser) on the method. For IAM, you create a resource policy or use IAM roles. For Cognito, you select a user pool and app client. For a Lambda authoriser, you write a function that returns an IAM policy. This step secures your API so only authorised clients can invoke it.
Deploy the API to a Stage
You create a new stage (name it 'v1' or 'prod'). API Gateway generates a unique invoke URL for that stage (e.g., https://abc123.execute-api.us-east-1.amazonaws.com/prod). You configure stage variables (e.g., database table name) and enable caching or throttling at the stage level. This step makes your API accessible over the internet for the first time.
Test and Monitor
Use the built-in API Gateway test console to send requests to your deployed API and verify the responses. Then set up CloudWatch monitoring to track metrics like 4XX errors, 5XX errors, and latency. Add alarms to alert you if something goes wrong. This step ensures your API works correctly and stays healthy in production.
Meet Ana. She is a developer for a company called 'QuickPix', a small startup that runs a mobile app where users share photos. QuickPix has a backend built with Lambda and DynamoDB. The founders want to launch a public API so third-party developers (like other apps that want to embed photo feeds) can access user data — but only with proper permission. Ana needs to build and secure this API using Amazon API Gateway.
Ana opens the AWS Management Console and creates a new REST API called 'QuickPix Public API'. She defines the following resources and methods:
GET /users/{userId} — returns a user's public profile.
GET /users/{userId}/photos — returns a list of that user's shared photos.
POST /photos — allows a third-party app to upload a photo on behalf of a user.
For each method, she configures an integration with a Lambda function that does the actual data work. She attaches a Lambda function called 'getUserProfile' to the GET /users/{userId} method.
Now, security. Ana decides that the public API needs to allow only authenticated third-party developers. She sets up a Cognito user pool for the developers. Each developer signs up, gets a client ID, and after login receives a JWT. Ana configures the API Gateway method 'GET /users/{userId}' to use a Cognito authoriser. When a request comes in with a JWT, API Gateway validates the token. If the token is valid, the request proceeds. If not, API Gateway returns a 401 Unauthorized response without ever invoking the Lambda function. This saves money and reduces latency.
Ana also needs to keep the internal mobile app separate. The mobile app (used by regular users, not developers) authenticates with IAM. Ana creates an IAM role that the app's backend assumes. This role has a policy that allows only the specific endpoints the app needs. For this traffic, she enables IAM authorisation on the relevant methods.
Next, Ana sets up stages. She creates a 'dev' stage for testing and a 'prod' stage for live traffic. She configures stage variables to connect the dev stage to a test DynamoDB table and the prod stage to the production table. She also sets up API keys for the third-party developers. Each developer gets a unique API key that they pass in the 'x-api-key' header. Ana creates a usage plan that limits each developer to 1000 requests per day. If a developer exceeds that limit, API Gateway returns a 429 error.
Ana enables caching on the GET /users/{userId} endpoint because the same user's profile is requested many times. She sets the cache TTL to 60 seconds. Now, when a developer requests the same user twice in one minute, the second request gets a lightning-fast response from the cache. Ana also adds a 'Cache-Control: max-age=0' header to allow developers to force a cache refresh if needed.
Finally, Ana monitors the API using CloudWatch. She sees that the /photos endpoint is getting hammered at 3 PM every day. She sets a rate limit of 200 requests per second on that method to prevent the backend from being overwhelmed. She also sets up alarm to notify her if error rates spike.
Ana deploys the API. The URL for her dev stage looks something like 'https://abcdef123.execute-api.us-east-1.amazonaws.com/dev'. The prod stage URL is 'https://abcdef123.execute-api.us-east-1.amazonaws.com/prod'. She shares the prod URL with the third-party developers. The API handles thousands of requests per hour without Ana needing to manage a single server. That is the power of API Gateway in a real business context.
The DVA-C02 exam tests Amazon API Gateway heavily. You need to be precise about the differences between authentication methods, stage behaviour, and caching mechanics. The exam will try to confuse you by mixing up features from different AWS services. Here is exactly what you need to know.
First, authorisation types are a favourite topic. You will get multiple-choice questions asking: 'Which authorisation method should you use for a mobile app where users login with email and password?' The correct answer is almost always Amazon Cognito, because Cognito is designed for human user identity. IAM is for machine-to-machine scenarios where the client has AWS credentials. Lambda authorisers are for custom or third-party tokens. A classic trap: the question describes a human login scenario but the answer options include 'IAM roles'. Do not pick IAM roles for human users — pick Cognito. Another trap: the question mentions 'API keys'. API keys are for identifying and throttling individual third-party developers (like in a usage plan), but they are not a security mechanism — they can be stolen easily. API keys alone are not considered secure authorisation for the exam.
Second, caching. You must know the default TTL is 300 seconds (5 minutes). The minimum TTL is 0 seconds (disabled) and the maximum is 3600 seconds (1 hour). You must know that cache invalidation happens by sending a 'Cache-Control: max-age=0' header. The exam will try to trick you with 'Expires' headers or 'Pragma' headers — those are from old HTTP specs. Stick with 'Cache-Control'. Also, remember that caching works per stage. You enable it in the stage settings. You can also enable caching per method, but the setting is in the stage.
Third, stages and stage variables. The exam loves to ask: 'What is the purpose of a stage?' The answer is to isolate API configurations for different environments (dev, test, prod). Stage variables are like environment variables for your API. A common exam scenario: you need to connect to a different DynamoDB table in dev vs prod. The answer is to use a stage variable in the Lambda function's environment variable mapping. The trap answer is 'use a config file in the Lambda function' — that is not how you do it in a serverless environment.
Fourth, throttling. Know the difference between rate limit (steady-state requests per second) and burst limit (how many requests can be handled in a spike). If both are exceeded, API Gateway returns a 429 status code. The exam will also test whether throttling applies per stage or per method. It applies per method in the stage, and you configure it in the stage settings.
Fifth, integration types. You must know the difference between 'Lambda proxy integration' and 'Lambda non-proxy integration'. In a proxy integration, the entire HTTP request (including headers, query parameters, and body) is passed as-is to the Lambda function. In a non-proxy integration, you use mapping templates to transform the request. Proxy is simpler and recommended. The exam will present a scenario where you need to transform the request — the answer is to use a non-proxy integration with a mapping template.
Key definitions to memorise: - 'Endpoint configuration': Edge-optimised (uses CloudFront for global clients), Regional (for clients in the same region), Private (only accessible within a VPC). - 'Usage plan': Associates API keys with throttling and quota limits. - 'API key': A string value that identifies a client. Used with usage plans. - 'Throttling limit': Maximum number of requests per second for a method. - 'Cache TTL': Number of seconds the cache holds a response before discarding it.
A common exam trap is asking about 'custom domain names'. You can set up a custom domain (like api.quickpix.com) for your API Gateway endpoint. This requires an ACM certificate (AWS Certificate Manager) in the same region. If the API is edge-optimised, the certificate must be in us-east-1. If Regional, the certificate must be in the same region as the API. The exam will try to trick you by saying the certificate can be anywhere.
Another trap: 'VPC Link'. API Gateway can connect to private resources inside a VPC (like an internal ALB) using a VPC Link. The exam will ask when to use VPC Link: when your backend is inside a VPC and not publicly accessible. If your backend is a Lambda function, you do not need a VPC Link; VPC Link is for HTTP backends running on EC2 or an ALB inside a VPC.
Finally, the exam loves to test error handling. If an integration fails (for example, the Lambda function times out), API Gateway returns a 502 Bad Gateway error. If the request is malformed, it returns 400. If authorisation fails, it returns 401 or 403 depending on the mechanism (401 for missing or expired token, 403 for a valid token that lacks permissions). Know these error codes cold.
In short, focus your DVA-C02 preparation on: auth types (IAM vs Cognito vs Lambda), caching mechanics (TTL, invalidation), stages and stage variables, throttling (rate vs burst), integration types (proxy vs non-proxy), and error codes (400, 401, 403, 429, 502).
Amazon API Gateway acts as the single front door for all your serverless APIs, handling routing, authentication, throttling, caching, and versioning automatically.
There are three main authorisation methods: IAM (for machine-to-machine with AWS credentials), Cognito (for human user login with email/password), and Lambda authorisers (for custom or third-party tokens).
API keys are for usage plans and client identification, not for security — always pair them with an authoriser for real protection.
Caching in API Gateway is controlled by a TTL (default 300 seconds) and is invalidated by sending a request with the Cache-Control: max-age=0 header.
Stages let you deploy different versions of your API (dev, test, prod) with separate URLs, stage variables, and settings like throttling and caching.
When throttling limits are exceeded, API Gateway returns a 429 Too Many Requests error — the request is not queued or retried automatically.
Edge-optimised endpoints use CloudFront for low latency globally, while Regional endpoints are for clients in the same AWS region, and Private endpoints are only accessible within a VPC.
A VPC Link connects API Gateway to private HTTP backends inside your VPC, like internal load balancers or EC2 instances.
Error codes to memorise: 400 (bad request), 401 (auth missing), 403 (auth denied), 429 (throttled), 502 (bad integration response or timeout).
These come up on the exam all the time. Here's how to tell them apart.
Cognito Authoriser
Designed for human user identity (email/password login).
Validates JWTs issued by a Cognito user pool automatically.
No custom code needed — configuration only in the API Gateway console.
Lambda Authoriser
Flexible — can validate any type of token (OAuth, SAML, custom).
Requires you to write and maintain a Lambda function.
Can return a custom IAM policy dynamically, allowing fine-grained access control.
Proxy Integration
Entire HTTP request is passed as-is to the Lambda function.
Easier to set up — no mapping templates needed.
Lambda function must parse the raw event to extract headers, body, etc.
Non-Proxy Integration
Request and response are transformed using mapping templates (VTL).
Lambda function receives already-parsed parameters.
More control over the structure of the data, but more complex to configure.
Rate Limit
The steady-state number of requests per second allowed.
Determines long-term throughput.
If exceeded over a sustained period, requests get throttled.
Burst Limit
The maximum number of requests allowed in a short burst (e.g., one second).
Allows traffic spikes as long as the average stays under the rate limit.
If exceeded even once, the excess requests are throttled with a 429.
Edge-Optimised Endpoint
Uses CloudFront content delivery network globally.
Best for clients distributed worldwide.
ACM certificate must be in us-east-1 (North Virginia).
Regional Endpoint
Serves requests from the same AWS region as the API.
Best for clients in the same region, offering lower latency for them.
ACM certificate must be in the same region as the API.
Mistake
API Gateway is only for REST APIs and cannot handle real-time data.
Correct
API Gateway also supports WebSocket APIs, which allow two-way real-time communication for use cases like chat, live data streaming, and collaborative editing.
Beginners often hear 'REST API' and assume that is all API Gateway does, ignoring WebSocket support because they have not built real-time apps yet.
Mistake
API keys alone provide strong authentication for securing an API.
Correct
API keys are for identifying and throttling clients, not for security. They are easily stolen (sent in plain text) and can be shared. For true security, you must use IAM, Cognito, or a Lambda authoriser.
The word 'key' sounds secure, like a physical key to a door. People naturally assume a secret key protects them, when in fact API keys are more like a username than a password.
Mistake
Enabling caching in API Gateway always makes your API faster, so it should be enabled on all endpoints.
Correct
Caching is only beneficial for GET requests with responses that do not change frequently. Enabling caching on POST, PUT, or DELETE requests is useless (or harmful because it caches outdated data).
The term 'caching' sounds universally positive. Beginners do not realise that caching only makes sense for idempotent read operations, not for mutating writes.
Mistake
If you set a rate limit of 100 requests per second, the 101st request in that second will be queued and processed later.
Correct
It does not queue. The 101st request receives an immediate HTTP 429 Too Many Requests error and is dropped. The client must retry, often with exponential backoff.
People are familiar with queues from real-life (like waiting in line) and assume cloud services behave the same. But throttling in API Gateway is a hard reject, not a queue.
Mistake
A single API Gateway API can only serve one domain name (e.g., api.example.com).
Correct
You can configure multiple custom domain names (e.g., api.example.com and api.example.org) to point to the same API Gateway API, each with its own certificates and base path mappings.
Most introductory tutorials show a single domain, so beginners assume it is a one-to-one relationship. They do not realise API Gateway can host many domain names on a single API.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
REST APIs offer more features like API keys, usage plans, caching, stage variables, and integration with X-Ray. HTTP APIs are simpler, cheaper, and have lower latency but do not support API keys or caching. Use REST for production applications that need fine-grained control; use HTTP for simpler, cost-sensitive projects.
Yes. API Gateway supports HTTP integrations, meaning you can point it to any public HTTP endpoint (including on-premises servers, Heroku, or Google Cloud). However, many exam questions focus on Lambda integrations as the typical serverless pattern.
You need an SSL/TLS certificate from AWS Certificate Manager (ACM) in the region matching your API. Then you create a 'Custom Domain Name' in API Gateway, associate the certificate, and create a DNS record (like a CNAME) in Amazon Route 53 pointing to the API Gateway domain name.
The Lambda authoriser function runs and returns a policy. If the function returns a 'Deny' effect, or if the function itself throws an error (e.g., it crashes), API Gateway returns a 403 Forbidden response (if the token is valid but denied) or a 401 (if the token is invalid or missing).
No. Caching is optional. By default, all requests go directly to your backend. You enable caching only when you want to reduce latency and backend load for responses that do not change frequently. Without caching, the API still works perfectly fine — it just hits the backend every time.
Yes. You can deploy the same API to multiple stages (e.g., 'v1' and 'v2'), or create separate APIs entirely. Each stage has a unique URL. You can also use base path mappings with custom domains to route requests like myapi.com/v1 to one stage and myapi.com/v2 to another.
A 401 Unauthorized means the request did not include any valid authentication credentials (e.g., no JWT token). A 403 Forbidden means the request included valid credentials, but those credentials do not have permission to perform the operation. API Gateway uses 401 for missing/expired tokens and 403 for insufficient permissions.
You've just covered Amazon API Gateway: Building and Securing REST APIs — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?