Introduction

This question usually starts with a reasonable goal and an imprecise assumption. You can log Cognito-backed identity information in API Gateway and CloudWatch, but API Gateway is best at logging selected claims, not dumping an entire user profile automatically.

What API Gateway Can Actually Log

When a request reaches API Gateway through a Cognito or JWT-based authorizer, user claims are attached to the request context. Access logs can reference individual values from that context, which makes them useful for correlation and auditing.

The important limitation is that logging works best when you name the exact values you want. In practice, that means fields such as sub, username, email, or a tenant identifier claim. Relying on “all user details” is usually the wrong target for two reasons:

• API Gateway access logs are formatted strings, not full identity documents.
• Logging every claim can create privacy and compliance problems.

For a REST API stage, a structured access log often looks like this:

1{
2  "requestId": "$context.requestId",
3  "ip": "$context.identity.sourceIp",
4  "route": "$context.resourcePath",
5  "status": "$context.status",
6  "userSub": "$context.authorizer.claims.sub",
7  "username": "$context.authorizer.claims.username",
8  "email": "$context.authorizer.claims.email"
9}

That format gives you traceable user context without turning CloudWatch into a copy of your identity store.

When You Need More Than Access Logs

If you truly need a larger set of Cognito details, API Gateway alone is usually not the right place to assemble them. A better pattern is:

1. let API Gateway log a small, safe subset of claims
2. pass the request to a Lambda integration
3. log any additional fields in application code after filtering sensitive data

For HTTP APIs, the Lambda event commonly exposes claims under requestContext.authorizer.jwt.claims. That makes it easy to create a deliberate, structured log entry:

1import json
2
3
4def lambda_handler(event, context):
5    claims = (
6        event.get("requestContext", {})
7        .get("authorizer", {})
8        .get("jwt", {})
9        .get("claims", {})
10    )
11
12    safe_log = {
13        "request_id": event.get("requestContext", {}).get("requestId"),
14        "subject": claims.get("sub"),
15        "username": claims.get("username"),
16        "email_verified": claims.get("email_verified"),
17        "tenant_id": claims.get("custom:tenant_id"),
18    }
19
20    print(json.dumps(safe_log))
21
22    return {
23        "statusCode": 200,
24        "body": json.dumps({"ok": True}),
25    }

This approach is better than raw access logging because the application can decide what is acceptable to persist. It also gives you one place to redact or normalize values.

Choose the Right Source of Identity Data

Another source of confusion is the difference between token claims and Cognito user attributes. The JWT already contains a set of claims, but it may not contain every user pool attribute. If you need data that is not in the token, you have two options:

• add the claim to the token through your Cognito configuration if that is appropriate
• query Cognito from trusted backend code when the extra lookup is justified

Do not query Cognito on every request just to make logs look richer. That adds latency, cost, and operational noise. Usually the stable identifier sub is enough, because you can correlate it with other systems later.

A practical production pattern is:

• access log stores request metadata plus sub
• application log stores a few business-relevant claims
• sensitive profile data stays in Cognito or a separate user service

That division keeps logs useful without turning them into a security liability.

A Safe Logging Strategy

The safest logging design is not “capture everything and filter later.” It is “capture only what operators really need.” For most teams, that means:

• request ID
• route or operation name
• status code
• source IP if your policies allow it
• 'sub or a tenant claim'
• maybe username for support workflows

Avoid logging tokens, refresh tokens, passwords, phone numbers, or custom claims that reveal billing, health, or internal authorization data. CloudWatch retention settings matter too. Even a harmless claim becomes risky if it is stored forever across multiple environments.

If you need searchable audit events, emit a dedicated application log record with stable field names. That is easier to query than a free-form string assembled in the stage log format.

Common Pitfalls

The most common pitfall is assuming API Gateway can print the full Cognito user object automatically. In practice, you normally reference individual claims, and some contexts expose only a subset depending on API type and authorizer type.

Another mistake is logging too much personally identifiable information. Just because a claim exists does not mean it belongs in CloudWatch.

A third issue is mixing REST API examples with HTTP API event shapes. Access log variables and Lambda event structures are similar in spirit but not identical. Confirm which API Gateway flavor your stage uses before copying examples.

Finally, teams often forget retention and redaction. Logging identity data without a retention policy usually creates a bigger operational problem than the original debugging need.

Summary

• API Gateway can log selected Cognito claims, but it is not a good tool for dumping every user detail.
• Use access logs for small, stable identity fields such as sub, username, and request metadata.
• Use Lambda or backend code when you need controlled, structured logging of additional claims.
• Avoid logging sensitive personal data unless there is a clear compliance-approved reason.
• Treat request tracing and identity storage as different concerns, even when both come from Cognito.