2

我在自动创建用户和角色的 AWS IAM 应用程序中遇到了一种奇怪的行为。

我的操作顺序是：

  1. 发送动作CreateUser；
  2. 为这个创建的用户发送一个动作CreateAccessKey；
  3. GetUser为此创建的用户发送操作以获取帐户 ID。我需要这样做，因为我只有根密钥和秘密；
  4. 发送一个 action CreateRole，AssumeRolePolicyDocument其中 Principal 是这个创建的用户。

当我执行第 4 步时，我收到一个MalformedPolicyDocument( Invalid principal in policy: "AWS":"arn:aws:iam::123412341234:user/newuser")。

但是，如果在第 4 步之前我延迟了 15 秒，它运行没有任何问题。

有没有我不需要坚持固定延迟的工作流程，比如阅读一些 IAM 网络服务来检查用户是否准备好使用？

4

1 回答 1

3

正如我对确定性创建和标记 EC2 实例的回答中所述，AWS API 通常只需要被视为最终一致。

具体来说，我提到可以合理地假设每个 API 操作都完全由 AWS 独立操作，即它本身就是一个微服务。这解释了为什么即使在Amazon EC2之类的服务中或在您的情况下AWS Identity and Access Management (IAM)中，对导致资源状态更改的一个 API 操作的调用也不一定对其中的（所有）其他 API 操作可见立即提供该服务 - 这正是您所体验的，即即使创建的用户对于其他 IAM API 之一已经可见GetUser，但对于不同的 IAM API 操作尚不可见CreateRole。

解决此固有特征的正确工作流程是使用指数退避策略重复所需的 API 调用，直到它成功（或达到配置的超时），这在异步通信场景中无论如何都是很好的做法。几个AWS 开发工具包同时提供对重试的集成支持和指数支持，这通常是透明应用的，但如果需要，可以针对特定场景进行定制，例如，为非常高的延迟场景延长任何默认超时等。

于 2014-04-26T13:05:08.443 回答