在AWS中为基于Cognito的Web应用存储用户登录日志应选用哪种数据库？

针对你当前用Cognito做身份认证、需要记录每次登录时间、在用户个人页展示最近3次登录记录的业务场景，最适配的选择是Amazon DynamoDB，完全不需要优先考虑RDS或者S3作为存储载体。

选型核心依据 #

为什么DynamoDB是最优解 #

• 完全匹配你的业务访问模式：你所有的数据操作都是「拿到特定用户的标识，查询该用户关联的最近3条登录时间」。DynamoDB的分区键+排序键结构天生适配这类单点查询场景：将Cognito返回的用户唯一ID（也就是sub值，比用户名稳定，不会因为用户修改昵称/用户名导致数据失联）设为分区键，将登录的毫秒级时间戳设为排序键，每次写入登录记录就是新增一条独立条目；查询时直接按分区键匹配当前用户，按排序键倒序取前3条，一次请求就能返回所需数据，没有额外扫描、关联查询的开销。
• 对新手零运维压力：DynamoDB是全托管的无服务器数据库，不需要像传统数据库那样配置实例、打补丁、做性能调优、处理版本升级，控制台点几次就能完成建表。同时它的成本对你这个场景几乎可以忽略：小规模Web应用的写入量完全能被DynamoDB免费层覆盖，就算用户量上来，按请求数计费的模式也不会产生高额费用。
• 可以和现有AWS架构无缝打通：不需要自己手写接收POST请求的后端接口，直接配置Cognito的Post Authentication Lambda触发器——用户登录成功后自动触发Lambda函数，把当前用户ID、登录时间戳写入DynamoDB表，整个流程完全自动化，不需要你的前端代码额外发请求，架构更简单也更安全。

为什么另外两个选项不适合当前阶段 #

• 关于RDS：关系型数据库适合需要多表关联、复杂聚合查询、强事务要求的业务（比如订单系统、全量用户权限管理）。对你现在仅需存单个用户零散登录记录的场景，RDS属于典型的杀鸡用牛刀：就算用最小规格的RDS实例，运维成本、初始开销都远高于DynamoDB，完全没必要。
• 关于S3 Bucket：S3是对象存储，根本不适合承担低延迟的在线查询业务。如果把登录记录存在S3里，每次用户打开个人页要查最近3条登录记录，你需要先遍历存储桶里的所有文件、筛选对应用户的条目、再解析文件内容，查询延迟高、流程复杂，完全不适合这种页面实时展示的场景。

参考落地配置 #

你可以按照下面的结构设计DynamoDB表，完全能匹配你预期的存储结构：

• 分区键：UserId（存储Cognito返回的用户唯一sub值）
• 排序键：LoginTimestamp（存储登录时刻的毫秒级Unix时间戳）
• 按需附加字段：登录IP、登录设备类型等非核心信息
  查询逻辑直接设置：匹配当前用户的UserId，按LoginTimestamp倒序拉取前3条，结果直接传给前端渲染/previousactivity页面即可。

后续就算要扩展需求（比如统计用户总登录次数、登录频次），这套DynamoDB结构也完全能支撑，不需要中途换数据库。

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