I have an architecture design where I am using Cognito for user management (email, phone_number are the only attributes) and then I am using DynamoDB to also sync users so that I can make user of AppSync to query and fetch some user information.
I need some way of syncing both the DynamoDB users with Cognito users. At the moment, I have a user postConfirmation lambda trigger to run inserts into DynamoDB on new user confirmation for all of the above information BUT:
What is the ideal architecture for keeping Cognito and DynamoDB in sync?
I had the same problem. I store email, family_name and given_name in cognito as part of sign up process. Then users can change any of these fields at any time.
I couldn't find a way to track these changes as the documentation doesn't state any such lambda trigger for sync events. However, since the idToken contains the user attributes in my case, it has to update itself after user makes a change. So I tested this and found that the Pre-Token trigger is invoked any time there is a change in the user attributes so that it can regenerate a new token. That lambda contains the following payload
{
version: '1',
triggerSource: 'TokenGeneration_RefreshTokens',
region: 'XXX',
userPoolId: '',
userName: 'XXX',
callerContext: {
awsSdkVersion: 'aws-sdk-unknown-unknown',
clientId: 'XXX'
},
request: {
userAttributes: {
sub: 'XXX',
email_verified: 'false',
'cognito:user_status': 'CONFIRMED',
'cognito:email_alias': 'user1@mailinator.com',
given_name: 'Name',
family_name: 'New',
email: 'user1@mailinator.com'
},
groupConfiguration: {
groupsToOverride: [],
iamRolesToOverride: [],
preferredRole: null
}
},
response: { claimsOverrideDetails: null }
}
So I update the records in dynamodb in this lambda itself. I am not 100% sure though because the documentation doesn't say anything about this use case and pre token trigger. Give it a try and see.
I would consider not syncing these details with DynamoDb. You can query Cognito the same way as a database to find/get users. The way we do this is we use the Cognito sub (the id) for the DynamoDb userId to make it very easy to fetch data from DynamoDb for a particular user. The db table is more of a supplementary info table like you are using to keep extra user data. It's going to be a lot easier imo - then you don't need to deal with anything related to email changes.
For example - we have an admin appsync that is used for account/user. To find or otherwise mutate a user we usually use a Lambda that calls Cognito methods.