API Gateway: Authorizers, Stages, and Throttling

Diana's first API was open to the internet. Anyone with the URL could call it. Within hours of going public, an automated scanner had hit it 40,000 times. The Lambda bill nudged up. The DynamoDB read units spiked.

This chapter is about the controls you put between your API and the internet — authorizers for who can call it, throttling for how fast, and stages for how to ship changes safely.

Authorizers

An authorizer decides whether a request is allowed before API Gateway calls your backend. Four types exist:

• IAM — caller must sign the request with AWS credentials. Common for internal AWS-to-AWS calls and CLI tools;
• Cognito User Pools — caller provides a JWT from Amazon Cognito. Common for apps that already use Cognito for sign-up and sign-in;
• Lambda authorizer (token-based) — caller sends a token (e.g., a JWT from your own auth provider), a Lambda inspects it and returns "allow" or "deny";
• Lambda authorizer (request-based) — Lambda receives headers, query strings, and path parameters, makes its own decision. For most public APIs, the choice is between Cognito (if you use it) and a Lambda authorizer (if you do not).

How a Lambda Authorizer Works

The flow:

• Client sends a request with an Authorization header containing a token;
• API Gateway invokes the authorizer Lambda with the token;
• The Lambda validates the token and returns an IAM policy document — Allow or Deny on specific resources;
• API Gateway caches the result for up to 1 hour (configurable) keyed by the token;
• If Allow, API Gateway calls your backend; if Deny, it returns 401 or 403. The caching is the trick — your authorizer does not run on every request, only the first one per token in the TTL window.

Throttling

API Gateway applies throttling at multiple levels:

• Account-level limits — default 10,000 requests/second, 5,000 burst, per account per region;

• Stage-level throttling — per stage, defaults inherited from the account;

• Method-level throttling — per HTTP method within a stage;

• Usage plans + API keys — per-client throttling. The pattern that prevented Diana's scanner story is usage plans:

• Create a usage plan with a quota (e.g., 1,000 requests/day) and rate (e.g., 10 requests/second);

• Create API keys and associate them with the usage plan;

• Require the x-api-key header on the methods;

• Distribute keys to legitimate clients. A scanner without a key gets 403 immediately, before consuming Lambda capacity.

Caching

API Gateway can cache responses at the stage level — saving Lambda invocations and database reads for identical requests. Cache size ranges from 0.5 GB to 237 GB, TTL from 0 to 3600 seconds.

The catch: cache costs money even when idle (charged per hour). And cache invalidation is by full cache flush or by header. For most APIs, the value is small unless reads dominate writes and the same parameters repeat.

Custom Domains

By default, your API lives at https://abc123.execute-api.us-east-1.amazonaws.com/prod. To use https://api.acme.com instead, you need:

• A domain you own;
• An ACM (AWS Certificate Manager) TLS certificate for that domain;
• A custom domain name in API Gateway pointing at your API and stage;
• A DNS record (CNAME or Route 53 alias) pointing your domain at the API Gateway endpoint. For REST APIs, this is an Edge-Optimized or Regional endpoint. For HTTP APIs, only Regional is supported.

Stages, Revisited

Stages are not just for separation between dev and prod. They are how you ship changes:

• Each stage holds a separate deployment of the API;
• You can deploy a new version to dev, test it, then deploy to prod;
• Canary deployments let you send a percentage of traffic to a new version of the same stage;
• Roll back instantly by re-deploying the previous version. A mature setup uses canary deployments for safer rollouts — 10% of traffic to the new version, monitor for 5 minutes, then 50%, then 100%.

CloudWatch Integration

Every API Gateway stage emits metrics: Count, Latency, 4XXError, 5XXError. You enable execution logging to send each request's details to CloudWatch Logs, and access logging for HTTP access logs.

For Diana, an alarm on 5XXError > 1% over 5 minutes was the difference between "something is broken" and "a customer told us something is broken."

For the Exam

DVA-C02 tests heavily on:

• The four authorizer types and when to use each;
• API key + usage plan pattern for throttling;
• Stage variables for environment switching;
• The difference between authorization (IAM/Cognito/Lambda) and authentication (the token validation itself).