AWS Cognito - User profile usage and update via Cognito API or sync into separate database

Question

I am starting with Cognito and a mobile application where, along with other core functionalities, user profile can be updated and the pool gets queried quite often. Therefore I am considering following options:

1. Query the pool with Cognito API directly from the app
2. Query the pool with Cognito API - probably Admin functions? - from the backend REST web service , basically wrap Cognito API to ensure the portability and no vendor lock in

OR

3. Do not use Cognito for the user profile data at all, but only for user authentication. Create a table in a MySQL database with user subs as IDs and all the other additional attributes, like their websites, photos, text / description to the profile, etc. Populate it with help of Lambda triggers offered by Cognito.

While choosing between option 1 and 2 is rather architectural and strategical decision, option 3 popped due to my uncertainty of ways to use Cognito Pools.

I came to option 3 after finding out about Service Limits of AWS Cognito . And I know these are adjustable, but starting with allowed 5 per second I am wondering if this wont become a bottleneck at some point..

Anyone who already have built a productive app with Cognito:

1. could you share your experience with Cognito Service Limits and performance for Pool API in general (not just sign in/ sign up) ?
2. Is it better to use Cognito for authentication / authorization only or for complete user management?

Thank you!

Scrophulariaceous

The default limit appears now to be 120 requests per second (rather than 5 requests per second). – Calliope

Answer 1

We have faced the same situation Nikki. I would recommend option 3. The other 2 options will cause more troubles further down the line.

• At some point, we'd like to have extra data for the user in our lambdas but these data were not part of the jwt token. We would like to have the registration date of the user. The only way to collect that was by firing one of the admin Cognito APIs - which worked fine - but when the traffic increased significantly our endpoints were failing because we were hitting the limits for the adminGetUser.
• A problem we had was that we had constantly to do data transformations from Cognito and to Cognito. Check the response of the adminGetUser and you'll realise that it's not the best response to work with.
• One more thing that I can remember is that when we'd like to add an extra field for the user data and populate it with a specific value, or if you have a requirement where you have to retrieve a list of one of your entities and join it with users because you need to display user metadata in the response. This will be an incredibly challenging task.
• A simple task where you might want to send back a user list with pagination and sorting it can be a bit challenging. You can list the users from Cognito but no sorting.

Overall, I really like Cognito's simplicity with authentication, verification emails, social logins, app clients. It's perfect for this reason but I wouldn't hold user metadata in cognito for a production ready environment - unless it's a small proof of concept.

Irby

Thanks a lot! You talked on each and every point I was wondering about. It is great to know it for sure from someone who already went through it – Scrophulariaceous

Can you elaborate a bit on the use case where you needed to use extra user data in your lambdas? – Herrington

@SandeepDixit one scenario can be this one: - you have the jwt token which is already verified and therefore you have the details of the jwt token (e.g. username, country etc) - There are things that are not part of these data (e.g. created date of the user) - if you need to retrieve these extra data, you have to use the adminGetUser. - in some cases this is acceptable, but in bigger scale it won't work because there are limitations on how many requests you can do against adminGetUser. – Irby