如何限制AWS Cognito服务访问？实现自定义管控与事件补充方案

针对你提到的Cognito触发器覆盖不全（比如认证失败不触发postAuthentication）、属性校验、限制属性读取这些需求，单纯依赖Cognito原生触发器确实有局限，下面是几个更靠谱的落地方案：

1. 搭建API Gateway前置代理层（最灵活的全场景覆盖） #

这是我最推荐的方案，完全能实现对所有Cognito调用的过滤和自定义处理：

• 核心思路：把所有用户端原本直接调用Cognito的请求，全部转到你自己的API Gateway上，由网关作为中间代理，先执行你的自定义逻辑，再转发请求给Cognito，最后处理Cognito的响应再返回给用户。
• 具体操作：
  • 为Cognito的核心API（比如InitiateAuth、GetUser、UpdateUserAttributes等）在API Gateway上创建对应的资源和方法。
  • 每个方法集成Lambda函数，在Lambda里：
    • 请求转发前：做属性校验（比如用户更新属性时检查格式、权限），过滤掉不允许用户修改的字段。
    • 请求转发后：捕获Cognito的响应，比如认证失败时（返回InvalidPassword等错误），直接在这里触发你的自定义操作（比如记录日志、发送告警）；对于GetUser这类返回用户属性的请求，过滤掉不允许用户查看的属性字段后再返回。
  • 安全强化：通过IAM策略配置，只允许API Gateway的执行角色有权调用Cognito API，用户端完全看不到真实的UserPoolClientId或IdentityPoolId，只能通过网关访问，比单纯隐藏ID安全得多。

2. 自定义认证流程+Lambda Authorizer（聚焦认证场景） #

如果你的核心需求围绕用户认证和权限控制，可以用Cognito的自定义认证流程：

• 把认证逻辑完全托管在自定义Lambda里，不管是认证成功还是失败，你都能在Lambda里执行任意操作（比如失败时记录详细日志、触发通知）。
• 对于用户属性的读写，不要让用户直接调用Cognito的属性API，而是通过你自己的Lambda来封装：比如用户请求读取属性时，Lambda先校验用户权限，再调用Cognito获取属性，过滤后返回；更新属性时先做格式和权限校验，再转发给Cognito。

3. 结合Pre Token Generation触发器补充场景 #

虽然你提到Cognito触发器有限，但Pre Token Generation触发器其实能覆盖不少场景：

• 它会在ID令牌和访问令牌生成前触发，你可以在这里修改令牌内容、校验用户属性状态，甚至在用户认证成功后执行一些自定义逻辑。不过它确实覆盖不到认证失败的场景，所以最好和前面的代理层方案结合使用。

需要注意的是，代理层方案虽然配置稍繁琐，但能实现100%的场景覆盖，完全满足你的所有需求，而且安全性也远高于隐藏ID的方式。

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