动态创建AWS Cognito userpool与DynamoDB表的架构方案是否合理？

首先明确：动态为每个企业新建Cognito用户池、DynamoDB表的方案属于典型的「租户隔离过度设计」，仅在极强的租户隔离合规要求下才有合理性，绝大多数场景下属于不合理方案，主要问题有以下几点：

• 运维成本爆炸：AWS账户对Cognito用户池、DynamoDB表都有默认配额限制，企业数量多了之后需要不停申请提额，而且资源监控、备份、版本迭代都要处理N份资源，比如要给用户池加个自定义属性，要给几十上百个用户池挨个修改，完全不可持续
• 代码复杂度飙升：所有涉及用户鉴权、数据读写的逻辑都要动态拼接租户对应的资源ID，出错概率极高，排查问题时还要先定位租户对应的资源，排查效率极低
• 成本浪费：DynamoDB表哪怕没有请求，只要开了预置容量就会计费，小体量企业的表大部分时间处于闲置状态，完全没必要单独拆分
• 跨租户逻辑几乎无法实现：如果后续要做全局的用户统计、跨企业的业务协作，需要跨N个用户池、N套表拉数据，实现难度陡增

用户鉴权层（Cognito侧） #

全平台共用单个Cognito用户池，通过自定义属性实现租户归属：

• 给用户池新增自定义属性 custom:enterprise_id，用户注册/创建时直接写入所属企业ID，该属性可设为不可修改，保证用户唯一归属一家企业
• 如果不同企业需要自定义登录页、自定义密码策略、单独的SSO配置，可以用Cognito的用户池组（User Pool Group） 实现，每个企业对应一个用户池组，可单独配置组级别的IAM权限、登录策略，不需要单独建用户池
• 鉴权后的JWT令牌里会自动包含custom:enterprise_id和所属组信息，后端接口可以直接从令牌里取租户ID做权限校验，不需要额外查库

数据存储层（DynamoDB侧） #

全平台共用一套DynamoDB表，通过分区键实现租户隔离：

• 所有业务表都把enterprise_id作为分区键的前缀，或者直接把enterprise_id设为分区键，查询的时候必须携带enterprise_id，天然避免跨租户数据泄露
• 如果有强租户隔离要求，可以开启DynamoDB的行级安全策略（RLS），直接绑定JWT里的custom:enterprise_id，自动限制用户只能访问所属企业的数据，不需要在业务代码里写校验逻辑
• 单表的运维、扩容、索引调整都只需要处理一次，成本和复杂度指数级下降

只有满足以下所有要求的时候，才考虑按企业拆分资源：

• 行业有强制合规要求，比如金融、政务领域要求不同企业的用户数据、认证数据必须物理隔离，不能存在同一套资源里
• 企业数量非常少（一般少于20个），且都是超大客户，单独运维资源的成本可覆盖
• 未来没有跨企业的业务协作需求，完全是单租户独立运行模式

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