You are choosing how Amazon API Gateway will authorize callers of a new API. Compare IAM (SigV4) authorization, a Cognito user pool authorizer, an HTTP API JWT authorizer, and a Lambda authorizer — what decides which one you pick?

## The question behind the question Interviewers ask this to see whether you reason from the caller's existing credential rather than from a favourite service. Every option below is a way of answering "what evidence does this caller already have, and who can check it?" ## IAM authorization (SigV4) Setting a method's authorization type to `AWS_IAM` means the caller must sign the request with AWS Signature Version 4 using AWS credentials, and API Gateway then evaluates whether that principal is allowed the `execute-api:Invoke` action on the method's ARN. **Choose it when the caller is an AWS principal**: another service in your account, an EC2 instance or Lambda function using its role, a partner account, an internal CLI. You write no authorizer code, credentials are short-lived when they come from a role, and every AWS SDK signs automatically. It also unlocks the API's **resource policy**, which lets you condition access on things an identity policy cannot express — source IP ranges, a specific VPC endpoint, an organization ID. **Do not choose it for the general public.** Handing AWS credentials to end users of a web or mobile app is the wrong shape (the exception being an identity broker that mints scoped short-lived credentials, which is a Cognito identity-pool pattern rather than something you build ad hoc). ## Cognito user pool authorizer (REST APIs) You attach an authorizer that points at a Cognito user pool. The client sends the pool-issued token in the `Authorization` header; API Gateway validates the signature and expiry against the pool before your integration runs, and exposes the token's claims to the backend as `$context.authorizer.claims`. No code, no key fetching, no verification logic in your services. The constraint is in the name: it validates tokens from **Cognito user pools only**. It also has a subtlety worth knowing — the plain configuration accepts the ID token, whereas configuring authorization scopes on the method requires an access token, because scopes live there. ## JWT authorizer (HTTP APIs) HTTP APIs ship a built-in JWT authorizer configured with two things: an **issuer** URL and one or more **audience** values. API Gateway discovers the issuer's signing keys and validates the token's signature, expiry, issuer and audience before invoking the route. You can additionally list required scopes per route, so a read route and a write route on the same API can demand different scopes. The reach is broader than Cognito's: any standards-compliant OIDC issuer works, including a Cognito user pool addressed as an issuer. The constraint is that it is an **HTTP API feature** — a REST API does not have it, and if you need REST-only features you are back to a Cognito authorizer or a Lambda authorizer. ## Lambda authorizer Your own function receives the request (a single header for a TOKEN authorizer, the full request for a REQUEST authorizer), decides, and returns an IAM policy plus a `context` map that API Gateway passes to the integration. **Choose it when nothing built-in fits**: an opaque token that must be introspected against a remote service, a legacy header scheme, mutual-TLS-derived identity, a decision combining the token with the source IP or the path, or a need to enrich the request with tenant and entitlement data that the backend should trust. It is the only option that lets you return a *dynamic* policy — allow these paths, deny those — computed per caller. **The costs are real.** It is code you write, test, patch and page on. It adds an invocation to the request path, with a cold start on the first call after idle. Its result is cached to amortise that, and the cache introduces its own behaviour you must design for. And because it is your code, a bug in it is a security hole with no vendor to blame. ## A decision order that survives follow-ups 1. Are callers AWS principals? → `AWS_IAM`, and use the resource policy for network-shaped conditions. 2. Do callers hold an OIDC-issued JWT? → HTTP API JWT authorizer if you can use an HTTP API; Cognito user pool authorizer if you are on a REST API and the issuer is a user pool. 3. Neither, or the decision needs more inputs than a token? → Lambda authorizer. 4. Public and genuinely unauthenticated? → authorization `NONE`, and put the controls elsewhere — a resource policy, WAF, and per-client limits. ## Two things to say out loud First, these are not exclusive across an API: different methods or routes can carry different authorization types, so an internal admin route can require IAM while public routes take JWTs. Second, none of them removes the need for authorization *inside* the service. The gateway decides whether the caller may reach the endpoint; whether this caller may see *this record* is an object-level check your code still owns.