我创建上飞AWS短命用户和调试时为什么这些新创建的登录往往会失败，一个InvalidAccessKeyId意识到，只是增加一个小sleep解决了这个问题。等到IAM策略已应用于
外部参照How long should I wait after applying an AWS IAM policy before it is valid?重：时间一致性整个AWS
我的跟进问题上面：是有办法同步创建一致的IAM策略？或至少有一种方法知道他们准备好使用？
Amazon IAM不是为提供短期凭证而设计的。您应该为长期需求创建IAM用户，例如登录人员并登录持久应用程序。
IAM用户不应该用于应用程序登录目的。例如，如果您要创建类似Instagram的应用程序，则应该维护自己的用户数据库，或者使用Amazon Cognito进行用户验证。
那么，您如何授予用户访问AWS资源的权限？例如，如果你有一个Instagram的类似应用程序，您希望授予应用程序用户上传/下载他们的照片在Amazon S3中的能力，但要限制访问某个桶和目录？...
答案是使用AWS Security Token Service (STS)创建临时凭证。可以使用给定策略在特定时间段内创建凭证。这些凭据立即工作。例如，如果类Instragram用户登录到应用程序，则后端应用程序可以生成临时凭证，以允许用户在特定的Amazon S3存储桶内访问特定的目录一段时间（例如15分钟）。然后将这些凭据传递到移动应用程序/ Web浏览器以直接访问AWS服务。
谢谢，我会研究STS。我们使用Hashicorps Vault来管理证书，而对于其他类似db等等，这是一个非常简单的模式，只需要首先生成具有特定TTL的新用户 – salient
如果您的工作流程是“创建一个IAM资源，然后尝试使用它”，而不是“更新那么IAM资源使用它”，那么也许你可以简单地改变你的客户端代码来实现指数退避/重试达到一定数目的重试。这样，您可以无缝地重试某些失败响应，例如找不到无效的密钥或资源。 – jarmod
这些事情都不可能，但为什么你要创建短命的IAM用户？有一种处理短期凭证的机制，称为[安全令牌服务（STS）]（http://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html），它不应该要求传播/复制时间，因为令牌似乎是独立的。 –