Amazon DynamoDB行级授权：用户多条目存储的实现疑问

没错，你这个思路完全靠谱，这其实是DynamoDB里实现用户专属多数据存储+行级权限控制的标准玩法之一。

先给你拆解下为什么这个方案能解决你的问题：

• 你之前用到的IAM策略条件"ForAllValues:StringEquals": { "dynamodb:LeadingKeys": [ "${cognito-identity.amazonaws.com:sub}" ] }，核心作用是限制用户只能访问**分区键（Partition Key）等于自身Cognito Sub值的条目。但如果只把Sub设为唯一主键，确实只能存一条数据——这时候引入排序键（Sort Key）**就刚好能打破这个限制，让同一个用户可以拥有多条唯一的条目。

具体的实现步骤和注意事项给你梳理下：

1. 调整表结构
   把表的分区键设置为用户的Cognito Sub（比如命名为userSub，字符串类型），然后新增一个排序键（字段名可以根据业务来，比如itemId、createTime或者noteId这类）。排序键只要能保证同一个分区键下的唯一性就行——可以用UUID生成唯一ID，也可以用时间戳、业务专属标识。

2. 保留现有IAM策略
   你的IAM条件不需要做任何改动，因为dynamodb:LeadingKeys只校验分区键是否匹配用户的Sub。只要分区键是用户自己的Sub，不管排序键是什么值，用户都能访问、新增、修改属于自己的所有条目，完美满足你“仅能操作自身所有条目且可存储多个”的需求。

举个实际的例子，假设你的表是用来存用户的笔记：

• 分区键：userSub（存储用户的Cognito Sub，比如xyz-789）
• 排序键：noteId（用UUID生成，比如abc123-def456）

用户的条目就会是这样：

这时候IAM策略会确保只有xyz-789这个用户能查询、修改这两条笔记，同时用户可以继续新增不同noteId的笔记，完全不会有唯一性冲突。

最后给你几个小建议：

• 排序键的选择尽量贴合业务需求：如果需要按时间排序查询，就用时间戳；如果需要按条目ID精准查询，就用UUID；如果有业务自带的唯一标识（比如订单号），直接用那个更方便。
• 当你需要查询用户的所有条目时，只需要指定分区键为当前用户的Sub，不需要过滤排序键，就能一次性拿到该用户的所有数据。
• 如果之后需要更复杂的查询（比如按笔记标签筛选），可以再创建全局二级索引（GSI），但核心的行级授权逻辑依然靠分区键+IAM条件来保障。

放心用这个方案吧，这是业内处理此类需求的常规操作，既能严格保证数据隔离，又能满足多条目存储的需求。

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