本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
使用亚马逊验证权限政策在 API 操作中存储别名
任何接受IsAuthorizedIsAuthorizedWithToken、和GetPolicyStore等policyStoreId参数的 Amazon 验证权限操作都可以接受策略存储别名来代替策略存储 ID。
重要
当您使用策略存储别名作为policyStoreId参数值时，必须包含前policy-store-alias/缀。例如，使用policy-store-alias/example-policy-store，不是example-policy-store。
在操作中使用策略存储别名
以下IsAuthorized命令使用名称为的策略存储别名example-policy-store来标识策略存储。
注意
您不能使用策略存储别名来代替DeletePolicyStore操作的policyStoreId字段。
跨使用策略存储别名 Amazon Web Services 区域
别名的最强大用途之一是在多个 Amazon Web Services 区域中运行的应用程序中。例如，您可能有一个全球应用程序，它在每个区域使用不同的策略存储。
-
在 us-east-1 中，你想使用。
PSEXAMPLEabcdefg111111 -
在 eu-west-1 中，你想使用。
PSEXAMPLEabcdefg222222
您可以在每个区域创建应用程序的不同版本，或者使用字典或 switch 语句为每个区域选择正确的策略存储。但是，在每个区域中创建具有相同策略存储别名的策略存储别名要容易得多。请记住，策略存储别名区分大小写。
然后，在代码中使用策略存储别名。当您的代码在每个区域运行时，策略存储别名将引用其在该区域中的关联策略存储。
但是，存在策略存储别名可能被删除的风险。在这种情况下，应用程序尝试使用策略存储别名将失败，您可能需要重新创建或更新策略存储别名。为了降低这种风险，在授予委托人管理您在应用程序中使用的保单存储别名的权限时要谨慎行事。
策略存储别名不是流量控制机制
策略存储库别名是策略存储库的稳定、友好的名称。它不是在策略存储区之间转移、拆分或加权授权流量的机制。如果您熟悉在资源版本之间路由流量的功能，例如 Lambda 别名，请注意策略存储别名的行为方式不同。按照设计，策略存储别名更接近 Amazon KMS 密钥别名：它为资源提供持久名称，而不是其前面的路由层。
出于这个原因，我们故意不提供UpdatePolicyStoreAlias操作。要更改策略存储别名指向的策略存储，您可以删除策略存储别名，然后创建一个名称相同且目标为不同策略存储的新策略存储别名。这不是原子操作，也不能像交通控制机制那样提供保证。
当您更改策略存储库别名解析到的策略存储库时，更改不会同时在所有地方生效：
-
更新后的映射必须从控制平面传播到评估授权请求的数据平面。映射不会即时传播。
-
由于策略存储别名解析最终是一致的，可以缓存，因此更改后会存在过渡窗口。在此窗口中，先前关联的策略存储为某些请求提供服务，而新关联的策略存储为其他请求提供服务。此窗口的长度不确定。
在此时段内，您的应用程序可以从任一策略存储区接收授权决定。由于不同的策略存储库可能包含不同的策略、实体和架构，因此同一个请求会根据哪个策略存储库为其提供服务而产生不同的决策。因此，策略存储别名不能在策略存储之间提供原子切换，也不能替代部署或流量管理策略。
不要使用别名作为切换机制
不要为了将授权流量从一个策略存储切换到另一个策略存储而构建更高级别的基础设施即代码或部署原语，以重新指向策略存储库别名。由于更改不是原子性的，因此可以在不确定的时间段内同时对两个策略存储库的请求进行授权。这可能导致授权决策不一致。要安全地切换策略存储，请参阅执行无停机策略存储更改。
执行无停机策略存储更改
由于策略存储别名不提供原子切换（参见策略存储别名不是流量控制机制），因此我们建议您通过重新指向策略存储别名来避免从一个策略存储库迁移到另一个策略存储。取而代之的是，从应用程序内部控制迁移，这样您就可以验证新的策略存储区，并在需要时立即回滚。以下方法允许您在不停机的情况下切换策略存储：
-
创建新的策略存储库并为其指定自己的策略存储别名，这样当前的策略存储库和新的策略存储库都有不同的稳定名称。例如，继续
policy-store-alias/example-policy-store指向您当前的策略存储库policy-store-alias/example-policy-store-2并为新的策略存储库创建。不要重复使用或重新指向单个策略存储别名来执行切换。 -
将您的策略、架构和任何其他配置复制到新的策略存储中，然后将其与当前策略存储并行运行。
-
向您的应用程序添加配置值或功能标志（例如，通过使用 AppConfig），以确定哪个策略存储别名对授权决策具有权威性。不要依靠更改别名本身来切换流量。
-
在影子模式下运行新的策略存储。向两个策略存储区发送相同的
IsAuthorized或IsAuthorizedWithToken请求，然后比较决策。记录并调查任何差异，直到新的保单库返回您预期的决策为止。 -
使用功能标志将授权决策逐步转移到新的策略存储别名，例如，在应用程序主机或用户群中分阶段推出。在继续操作时监控授权决策和错误率。
-
如果检测到问题，使用功能标志立即切换回原始策略存储别名。由于您的应用程序控制交换机，因此回滚是即时的，不依赖于别名传播。
-
在新策略存储库经过全面验证并为所有流量提供服务后，停用旧策略存储库及其策略存储别名。
这种模式让您的应用程序（而不是别名传播）可以控制哪个策略存储为每个请求提供服务。这种控制是使迁移安全且可逆的原因，它避免了重新指向策略存储别名所带来的过渡窗口。