aws-solutions / cognito-user-profiles-export-reference-architecture

A reference architecture for exporting user profiles, group details, and group memberships from an Amazon Cognito User Pool to an Amazon DynamoDB global table using AWS Step Functions and AWS Lambda.
https://aws.amazon.com/solutions/implementations/cognito-user-profiles-export-reference-architecture/
Apache License 2.0
52 stars 19 forks source link

The solution definitely is not production read (Is it a bug or feature?) #27

Closed C-h-e-r-r-y closed 11 months ago

C-h-e-r-r-y commented 1 year ago
  1. Restrictions for CSV are not handled at all. For E.g. if you have a user without phone_number_verified attribute - you will get UserNotFoundException during attaching the user to the group.
  2. Request rate management is very uneffective. CognitoTps - does not work for user export (export-users.js) it just ignored and "works" only when an exception appeared. Also, the user cycle is performed without any tsp checks. For user "import" or better say "attach users to groups" tps logic is implemented manually. Have not yet checked it but javascript has a library for automatic request rate managing.
  3. Solution uses too many resources: DynamoDb tables, SQS. You can just run lambda from the secondary region, and store all data in s3 (users, groups, user-group relations). With 30TPS hard limit for the user pool and a single thread for the user loop - this is not a problem. Why do you use DynamoDb? Just because it has a replication feature? What is the profit? The documentation said that is needed when the same logic uses this in different regions. In your application logic is different (import and export)
  4. Solution also has a very complex deployment: lambda functions are built in a loop (about 20 minutes), the build is a platform depend (due to bash scripts), and manual actions are required. A lot of custom resources with state machines (why???). Also, the solution deploys StackSet with the same resources in 2 regions with if conditions and skips some resources in the secondary region. (+20 minutes to deployment time) It is better to just use one stack for the main (export) region and a second for the import - just deploy in the needed region. Also, the solution uses Cloudformation Custom resource for constants holding - why do not use SSM here?
  5. No mention in the documentation that this is a one-time import!!! This I got from AWS support team.
C-h-e-r-r-y commented 1 year ago

to be continied

C-h-e-r-r-y commented 1 year ago
  1. Logs. No separation for debug, info, warn, etc. No log level managing. For every user I have Adding user to group and User added to group in logs. So one user +2 log statements. (And this is without logs for user to group attaching). 500k user pool -> 1000k-3000k logs statements. (Where I store my user - in the user pool or cloudwatch?). For errors I got 2022-11-23T00:13:58.989Z 985180b0-e037-4f0a-9649-ce11c30948ea ERROR UserNotFoundException: User does not exist. Yes, just message without group name and user name. With 2 doubled stack traces in logs again.
mikeols commented 11 months ago

Thank you for the thorough feedback and very sorry for the late response. You've made some good points here for us to consider. The feedback has been added to our roadmap so I will close this for now.