Authorization: IAM, Lambda Authorizers, and Cognito
Secure API endpoints with IAM SigV4 signatures, custom Lambda authorizers, or Amazon Cognito User Pool authorizers.
Authorization: IAM, Lambda Authorizers, and Cognito is a free AWS Solutions Architect lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the AWS Solutions Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why API Authorization Matters
Without authorisation controls, any internet client could call your API Gateway endpoints and access or modify data. API Gateway provides three native authorisation mechanisms: IAM (SigV4), Lambda Authorisers, and Amazon Cognito User Pool Authorisers. Each mechanism serves different use cases: IAM for AWS service-to-service calls, Lambda authorisers for custom token or request-based auth, and Cognito for web/mobile user authentication.
IAM Authorization with SigV4
IAM authorisation requires callers to sign requests using AWS Signature Version 4 (SigV4). The caller must have AWS credentials (access key + secret key or temporary credentials from STS) and the IAM policy must allow execute-api:Invoke on the API's ARN. This is ideal for machine-to-machine (server-to-server) calls within AWS: Lambda calling another API, EC2 calling an internal API, or cross-account service access. Browser clients cannot easily use SigV4.
# IAM policy to allow invoking a specific API endpoint
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Action': 'execute-api:Invoke',
'Resource': 'arn:aws:execute-api:us-east-1:123456789012:abc123/prod/GET/orders'
}]
}Lambda Authorizers: Token-Based
A Lambda Authoriser (formerly Custom Authoriser) is a Lambda function you write that API Gateway invokes before calling the backend integration. For token-based authorisers, API Gateway extracts a token (JWT, OAuth, API key) from the Authorization header and passes it to your Lambda. Your Lambda validates the token (e.g., verifies JWT signature against a public key, calls a third-party identity provider) and returns an IAM policy document that allows or denies the request.
def lambda_handler(event, context):
token = event['authorizationToken']
# Validate token (JWT verification, introspect OAuth, etc.)
if is_valid_token(token):
return {
'principalId': 'user123',
'policyDocument': {
'Version': '2012-10-17',
'Statement': [{'Effect': 'Allow', 'Action': 'execute-api:Invoke',
'Resource': event['methodArn']}]
},
'context': {'userId': 'user123', 'role': 'admin'}
}
raise Exception('Unauthorized')Lambda Authorizers: Request-Based
For request-based Lambda authorisers, API Gateway passes the entire request context (headers, query strings, stage variables, path parameters) to your Lambda—not just a token. This is useful for authorisation that depends on multiple request attributes: IP allowlists, header combinations, or multi-factor authentication checks. Request-based authorisers are supported by both REST API and HTTP API.
Lambda Authorizer Caching
Calling a Lambda authoriser on every API request adds latency and cost. Enable authoriser result caching: cache the IAM policy returned by the authoriser for a configurable TTL (0–3600 seconds) keyed on the token value. Subsequent requests with the same token skip the Lambda invocation and use the cached policy. Set the TTL to match your token expiry time—if a token is valid for 1 hour, cache the authoriser result for the same period. Caching is available in REST API; HTTP API JWT authorisers have built-in caching.
Amazon Cognito User Pool Authorizer
Cognito User Pool Authorisers validate Cognito-issued JWTs directly in API Gateway without a Lambda function. When a user authenticates via Cognito (via the Hosted UI, SDK, or federated identity provider), Cognito issues an ID token or access token. The client includes this token in the Authorization header. API Gateway verifies the token signature and expiry against the Cognito User Pool. If valid, the request proceeds; if not, API Gateway returns 401.
aws apigateway create-authorizer \
--rest-api-id 'abc123' \
--name 'CognitoAuthorizer' \
--type COGNITO_USER_POOLS \
--provider-arns 'arn:aws:cognito-idp:us-east-1:123456789012:userpool/us-east-1_XXXXXXX' \
--identity-source 'method.request.header.Authorization'JWT Authorizer in HTTP API
HTTP API has native JWT authoriser support without Lambda. You specify the JWT issuer URL (Cognito, Auth0, Okta) and audience, and API Gateway validates JWTs automatically. This is essentially a Cognito User Pool authoriser but also works with any standards-compliant OIDC provider. The token validation (signature, expiry, audience) is done by API Gateway internally—lower latency than Lambda authorisers and no Lambda cost.
aws apigatewayv2 create-authorizer \
--api-id 'abc123' \
--authorizer-type JWT \
--name 'JWTAuthorizer' \
--identity-source '$request.header.Authorization' \
--jwt-configuration '{
"Issuer": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXXXX",
"Audience": ["your-client-id"]
}'Cognito Identity Pools vs User Pools
For API authorisation, use Cognito User Pools: they manage user authentication and issue JWTs. Cognito Identity Pools (Federated Identities) are different—they exchange third-party tokens (from User Pools, social logins, SAML) for temporary AWS credentials (via STS AssumeRoleWithWebIdentity). Identity Pools are used when your app needs to access AWS services directly (S3, DynamoDB) from the client. For API Gateway auth, User Pool JWTs are the right choice; Identity Pool credentials are for direct AWS SDK calls from the browser/mobile.
Resource Policies on API Gateway
REST APIs support resource policies—JSON policies attached to the API that control access by IP address, VPC endpoint, source account, or ARN. Use resource policies to: allow only specific IP ranges to call your API, restrict access to requests coming through a specific VPC endpoint (private API), or allow cross-account invocations. Resource policies work in addition to method-level authorisers—both must allow the request for it to succeed.
# Allow only specific IP range to call the API
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': '*',
'Action': 'execute-api:Invoke',
'Resource': 'arn:aws:execute-api:us-east-1:123456789012:abc123/*',
'Condition': {'IpAddress': {'aws:SourceIp': '203.0.113.0/24'}}
}]
}Mutual TLS Authentication
Mutual TLS (mTLS) requires both the client and the server to present certificates during the TLS handshake. API Gateway supports mTLS for REST and HTTP APIs when custom domain names are configured. Clients must present a valid certificate signed by a Certificate Authority (CA) you upload to a truststore in S3. mTLS is used in financial services, IoT device authentication, and B2B integrations where strong client identity verification is required beyond token-based auth.
Choosing the Right Authorizer Type
Authoriser selection for the SAA-C03 exam: IAM (SigV4) → AWS service-to-service calls within the same or cross accounts; Cognito User Pool → web/mobile app users authenticated via Cognito; Lambda Authoriser → custom auth logic (third-party identity providers, legacy token formats, OAuth introspection, IP + token combined); JWT Authoriser (HTTP API) → OIDC/OAuth2 tokens with any standards-compliant provider at lower cost than Lambda authorisers. No authoriser → public API.
Quick Check
Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.
Lesson Recap
In this lesson you learned: IAM (SigV4) authorisation is for service-to-service calls using AWS credentials, Cognito User Pool Authorisers validate Cognito-issued JWTs natively for web and mobile apps, and Lambda Authorisers implement custom token validation for third-party identity providers or complex authorisation logic with optional result caching. Next up we explore throttling, caching, and usage plans in API Gateway.
Frequently asked questions
Is the “Authorization: IAM, Lambda Authorizers, and Cognito” lesson free?
Yes — the full text of “Authorization: IAM, Lambda Authorizers, and Cognito” is free to read here on the web, and the AWS Solutions Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the AWS Solutions Architect course, upgrade to CoddyKit PRO.
What will I learn in “Authorization: IAM, Lambda Authorizers, and Cognito”?
Secure API endpoints with IAM SigV4 signatures, custom Lambda authorizers, or Amazon Cognito User Pool authorizers. You practise AWS Solutions Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start AWS Solutions Architect?
No prior experience is required. AWS Solutions Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Authorization: IAM, Lambda Authorizers, and Cognito” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this AWS Solutions Architect lesson?
Yes. Every AWS Solutions Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- REST API vs HTTP API vs WebSocket API
- Integrations: Lambda, HTTP, and Mock
- Authorization: IAM, Lambda Authorizers, and Cognito
- Throttling, Caching, and Usage Plans