每个区域的 Cognito 池与每个租户的 Cognito 池

Question

我正在阅读有关多区域架构注意事项的信息。 我们迁移到多区域架构的原因与其他人几乎相同：

1. 为不同大陆（欧盟、美国、亚洲、非洲）的客户减少延迟

2. 符合他们的数据存储需求

3. 启用区域故障转移 我们将使用 Cognito 池和 dynamo DB 进行数据存储。全局 Cognito 池似乎不是全局 DynamoDB 表。对于多租户系统SAAS系统，租户分布在不同大洲，用户池是按地域生成还是按租户生成？在此视频中，https://www.youtube.com/watch?v=kmVUbngCyOw&feature=emb_logo&ab_channel=AmazonWebServices，建议每个租户有一个池。不过我看不到它有很多好处。

4. 改为每个区域有一个用户池是个好主意吗？

5. 该视频还建议除了用户池之外还有身份池。为什么在多租户系统中会出现这种情况？

6. 如果我要确保数据驻留在与 dynamodb 中的租户相同的区域，应该如何处理？以及应该如何使用双活架构

7. 我们还需要为所有租户托管应用程序 URL，例如 tenant1.companydomain.com。最好的方法是什么？

Answer 1

这个问题太大了，但无论如何。

1. Reducing Latency

除非您经常调用 Cognito API，否则身份验证确实是这里的主要关注点，但如果您使用的是长寿命刷新令牌，则它们不应该一直进行身份验证，所以这不会是一个大问题。但是更大的问题是，如果您只使用一个池，您将不得不考虑有时需要在同一区域中进行一些 Cognito 集成，例如 API 网关上的 Cognito Authorizer。但是您可以编写自己的Lambda Authorizer 来解决这个问题。

2. Being in compliance with their data storage needs

这可能会迫使您参与用户池决策，尽管您始终可以选择将您的身份和详细信息保存在单独的存储中，利用用户池中的Lambda Triggers 来同步数据。

3. regional failover

关于您关于要使用多少个用户池的问题，我不明白这一点。如果您在每个区域都使用一个，那么如果您想添加自己的故障转移功能，则需要在另一个区域复制它。如果您只有 1 个用户池，则只需要复制 1 个。我从未听说有人将用户池复制到另一个区域，这与您在 2. 中想要的内容相冲突。如果您也使用过集成，则不能默认使用另一个用户池，而必须默认使用网站的全新实例，而不仅仅是用户池。您还必须创建自己的触发器来为您执行此操作。

Should the user pool be generated per region or per tenant?

老实说，这本身就是一个大问题，我们构建了一个多租户 SAAS 平台，老实说，我可以说每个租户的用户池将是一场噩梦。 1 个用户池是最简单的（例如使用 API GW 集成，您不能选择多用户池）。您可以为每个租户使用一个应用客户端，并为该租户自定义登录，并为每个租户提供自己的子域。

4. Is it instead a good idea to have a user pool per region instead?

可能还有其他更有意义的问题？我是否希望用户在不同区域具有相同的身份？我是否希望用户能够在区域之外使用更多内容？等等考虑具有此功能的不同网站。比如亚马逊你有全球身份，你可以切换你正在访问的商店，你需要指定要求。

5. The video

很抱歉不去看视频，但您可以让身份池从令牌中选择权限（即 Cognito 中该用户的组权限）。这涵盖了 99% 的用例从那里开始。

6. if I was to ensure data residency...

开箱即用，这就是云的样子，除非您指定全局资源，一切都是每个区域的，因此您什么也不做。您不能同时拥有数据驻留和区域故障转移。