AWS Cognito同一邮箱多账户处理咨询：无需合并账户

你的DynamoDB映射方案是否冗余？ #

不冗余，这个方案在避免Cognito账户合并的场景下是完全合理且轻量化的选择。

Cognito的sub字段是每个身份的唯一标识，本地注册和第三方社交登录必然生成不同的sub，而邮箱只是用户属性，Cognito默认不会自动关联同邮箱的不同身份。你的映射方案通过DynamoDB存储providerSub到originalSub的关联关系，仅消耗2个RCU就能完成数据关联，成本极低，同时保留了不同身份的独立性，避免了账户合并带来的复杂度（比如用户属性冲突、会话中断等问题）。

如果后续需要支持多登录方式关联同一个主账户，这种映射结构还可以扩展为一对多的关联（比如一个主sub对应多个第三方sub），灵活性很高。

无需合并Cognito账户的官方最佳实践 #

1. 利用Cognito前置触发器+自定义属性 #

在用户池配置Pre Sign-up触发器，当新用户（无论本地还是社交）注册时，触发器检查用户池中是否存在同邮箱的已验证用户。如果存在，将现有用户的sub写入新用户的自定义属性（例如custom:linked_sub）。

后续用户登录时，直接从该自定义属性获取关联的主账户sub，无需额外查询DynamoDB。这种方式的优势是逻辑内聚在Cognito生态中，减少外部依赖，但需要确保触发器有足够权限读取用户池数据，且要处理邮箱未验证的情况（避免误关联未验证的邮箱）。

2. 使用Cognito身份池（Identity Pool）统一身份 #

如果你的应用已经在使用Cognito身份池，可以将不同登录方式的身份关联到同一个Identity ID。身份池默认会尝试关联同邮箱的已验证身份，只需配置：

• 开启身份池的联合身份支持
• 确保各身份提供者（比如Google、本地用户池）的邮箱属性映射正确
• 要求用户验证邮箱（避免同邮箱未验证用户的误关联）

这种方式下，DynamoDB可以直接用USER#{identityId}作为主键，实现不同登录方式下的数据统一，无需额外映射表。

3. 以邮箱作为DynamoDB主键（需谨慎） #

如果业务场景允许，可以将DynamoDB的主键改为USER#{email}，同时在Cognito用户池中配置邮箱唯一约束。这种方式直接跳过sub的差异，以邮箱作为用户的全局标识。

但需要注意风险：

• 用户更换邮箱时，需要同步更新DynamoDB的主键（或添加旧邮箱到新邮箱的映射）
• 若邮箱被回收并重新注册，可能导致数据归属错误，需配合严格的邮箱验证和账户回收机制

内容的提问来源于stack exchange，提问作者L_Cleo