本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

Lambda 函数轮换策略

对于通过 Lambda 函数进行旋转，对于数据库密钥，Secrets Manager 提供了两种轮换策略。

轮换策略：单用户

此策略在一个密钥中更新一个用户的凭证。对于 Amazon RDS Db2 实例，由于用户无法更改自己的密码，因此您必须在单独的秘密中提供管理员凭证。这是最简单的轮换策略，适用于大多数使用场景。具体而言，建议您为一次性（临时）用户或交互式用户的凭证使用此策略。

轮换密钥时，不会删除打开的数据库连接。在进行轮换时，在数据库中的密码更改后一小段时间，相应的密码才会更新。在此期间，数据库有较低的风险拒绝使用轮换凭证的调用。您可以使用适当的重试策略来降低风险。轮换后，新连接将使用新凭证。

轮换策略：交替用户

此策略在一个密钥中更新两个用户的凭证。您创建第一个用户，然后在第一次轮换期间，轮换函数将进行克隆以创建第二个用户。每次轮换密钥时，轮换函数都会交替更新其更新的用户密码。由于大多数用户无权克隆自己，因此您必须在另一个密钥中为 superuser 提供凭证。如果数据库中的克隆用户与原始用户具有的权限不同，或者涉及一次性（临时）用户或交互式用户的凭证，我们建议使用单用户轮换策略。

此策略适用于具有权限模型的数据库，其中一个角色拥有数据库表，而另一个角色具有访问数据库表的权限。其也适用于需要高可用性的应用程序。如果应用程序在轮换期间检索密钥，则该应用程序仍会获得一组有效的凭证。轮换后，user 和 user_clone 凭证均有效。在这种类型的轮换期间，应用程序获得拒绝的可能性甚至比单用户轮换获得拒绝的可能性更小。如果数据库托管在服务器场中，密码更改需要时间传播到所有服务器，则存在数据库拒绝使用新凭证的调用的风险。您可以使用适当的重试策略来降低风险。

Secrets Manager 将创建权限与原始用户相同的克隆用户。如果您在创建克隆用户后更改了原始用户的权限，则还必须更改克隆用户的权限。

例如，假设您使用某个数据库用户的凭证创建了一个密钥，则该密钥包含一个带有这些凭证的版本。

第一次轮换 – 轮换函数使用生成的密码创建克隆用户，这些凭证将成为当前的密钥版本。

第二次轮换 – 轮换函数更新原始用户的密码。

第三次轮换 – 轮换函数更新克隆用户的密码。