- Newest
- Most votes
- Most comments
Regarding TooManyRequestsException - Status Code: 400:
Seams like a "classic" Rate Limiting issue. Cognito has default quotas (TPS - Transactions Per Second) for different operations like GetUser, Authenticate, or SignUp.
- **Cause: **Your application is calling Cognito APIs faster than your account's assigned limit.
- Fix: Implement Exponential Backoff / Ensure your SDK configuration uses a retry strategy that waits progressively longer between attempts.
- You can try to request a Quota Increase: Check the "Service Quotas" dashboard in the AWS Console. If your legitimate traffic exceeds the default (e.g., 120 TPS for
GetUser), you’ll need to request an increase. - Check for "Hot Loops": Ensure your code isn't calling Cognito inside a tight loop (e.g., checking user status on every single page load instead of using a local session/cache).
InvalidParameterException: accessToken must not be null (Status 400)
This is a Logic Error in your application code rather than a scaling issue.
- **Cause: **You are calling an API (like GetUser or GlobalSignOut) and passing a null or undefined value where a valid JWT Access Token is required.
- Fix: Add a null-check before the API call.
- Verify that your token storage logic (Cookies/LocalStorage) isn't clearing the token prematurely or failing to retrieve it before the call is made.
Status 502 & 503 (Bad Gateway / Service Unavailable)
These are Server-Side Errors from AWS. While 5xx errors are usually AWS's responsibility, they often appear alongside TooManyRequests when the service is under extreme stress from your client.
- Cause: Cognito is momentarily unable to process the request, often because it's being "flooded" or experiencing a brief internal hiccup.
- Fix: These should be handled by your Retry Logic. If your SDK is configured correctly, it should automatically retry these once or twice before surfacing the error to your logs.
see:
- https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/CommonErrors.html
- https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
To truly resolve these issues, consider these architectural improvements:
1. The "Caching" Strategy
The TooManyRequestsException is frequently caused by calling GetUser on every single request to verify permissions.
- The Insight: Instead of hitting Cognito every time, use the claims already present in the JWT (ID/Access Token). If you need custom attributes that aren't in the token, cache them in a fast data store like Redis or a local application cache.
- The Goal: Reduce the "Chattiness" between your backend and Cognito.
2. Understanding Specific Quotas (TPS) Cognito differentiates between "User Pool" and "Client-side" quotas.
- The Threshold: Most applications hit the ceiling at the default 120 TPS (Transactions Per Second) for the GetUser operation.
- The Strategy: Monitor your CloudWatch metrics specifically for GetUser vs. InitiateAuth to see exactly which limit you are hitting before requesting a quota increase.
3. The "Expired Token Trap"
The InvalidParameterException (null accessToken) is a classic symptom of a failed Refresh Token flow.
- The Scenario: A user's Access Token expires. The app tries to refresh it, but the refresh fails (e.g., due to network issues or a revoked session). If the app logic doesn't catch this failure, it proceeds to call the next API with a null token, triggering the error.
- The Fix: Ensure your interceptors (like Axios interceptors) explicitly handle refresh failures by redirecting to the login page rather than passing an empty string or null to the SDK.
Implementation Checklist
1. SDK Retry Strategy
- Audit: Are you using the standard AWS SDK?
- Action: Check your maxRetries and RetryHandler configuration. Ensure Exponential Backoff is enabled so that retries don't contribute to further throttling (the "Thundering Herd" problem).
2. Service Quotas Dashboard
- Action: Navigate to AWS Service Quotas -> Amazon Cognito User Pools.
- Metric: Check how close your peak traffic is to your current limits. If you are at 80%+, request an increase immediately, as these can take a day or two to be approved.
3. Frontend/Client Logic
- Action: Audit your 401/403 error handling.
- Safety: Ensure the application triggers a clean Logout or "Session Expired" state. Avoid "Infinite Loops" where the app tries to fetch data, fails, and immediately retries with the same invalid credentials.
see also:
For the throttling (TooManyRequestsException) I suggest add exponential backoff with jitter on your Cognito API calls. Most AWS SDKs have built-in retry configs you can tune. Cache tokens and user info instead of calling Cognito on every request. If you're doing bulk operations (migrations, batch sign-ups), throttle your own request rate. You can request a quota increase via Service Quotas in the console if your legitimate traffic needs it. Key quotas to look at: UserAuthentication and UserRead operations per second: https://docs.aws.amazon.com/cognito/latest/developerguide/quotas.html
For the null access token add null checks before calling Cognito APIs that require a token. If a prior auth call failed, don't chain into the next call blindly. // Example: guard before calling GetUser if (accessToken != null) { GetUserRequest request = new GetUserRequest().withAccessToken(accessToken); cognitoClient.getUser(request); } else { log.warn("Access token is null, skipping GetUser call"); // handle gracefully — re-authenticate or return error to client }
For the SDK retry config (Java SDK v2 example): CognitoIdentityProviderClient client = CognitoIdentityProviderClient.builder() .overrideConfiguration(ClientOverrideConfiguration.builder() .retryPolicy(RetryPolicy.builder() .numRetries(5) .backoffStrategy(EqualJitterBackoffStrategy.builder() .baseDelay(Duration.ofMillis(200)) .maxBackoffTime(Duration.ofSeconds(5)) .build()) .throttlingBackoffStrategy(EqualJitterBackoffStrategy.builder() .baseDelay(Duration.ofMillis(500)) .maxBackoffTime(Duration.ofSeconds(10)) .build()) .....
The root cause is likely the throttling — fix that first and the 502/503s and null token issues should be fixed. Start with caching and local JWT validation to reduce your call volume, then add retries. Take a look at CloudWatch logs to follow the processes in detail.
Relevant content
- asked 4 months ago

If my answer helped solve your problem, I would appreciate it if you click on “accepted answer”