在应用 AWS IAM 策略之后，需要等待多长时间才能使其有效？

我正在以编程方式添加和删除 AWS IAM 用户策略，并且从这些策略的应用程序中得到了不一致的结果。

例如，这可能会成功，也可能不会成功(我使用的是 Java1.6.6 SDK) :

从一个可以从特定存储桶读取数据的用户开始
清除用户策略(列出策略，然后为每个策略调用“ delete teUserPolicy”)
等待，直到用户没有用户策略(调用“ listUserPolicy”，直到它返回一个空集)
尝试从桶中读取(这应该会失败)

如果我在 # 3和 # 4之间放置一个断点并等待几秒钟，用户将无法从 bucket 中读取数据，这正是我所期望的。如果删除断点，用户就可以从 bucket 中读取，这是错误的。

(当我加策略然后访问资源时，这也是不一致的)

我想知道策略更改何时对组件(S3、 SQS 等)产生影响，而不仅仅是对 IAM 系统产生影响。有没有办法从这里得到收据或确认？或者也许有一定的时间等待？

是否有关于策略应用程序内部的文档？

(仅供参考，我已经复制了我的问题从 https://forums.aws.amazon.com/thread.jspa?threadID=140383&tstart=0)

46905

小开

最佳答案

The phrase "almost immediately" is used 5 times in the IAM FAQ, and is, of course, somewhat subjective.

Since AWS is a globally-distributed system, your changes have to propagate, and the system as a whole seems to be designed to favor availability and partition tolerance as opposed to immediate consistency.

I don't know whether you've considered it, but it's entirely within the bounds of possibility that you might actually, at step 4 in your flow, see a sequence of pass, fail, pass, pass, fail, fail, fail, fail... because neither a bucket nor an object in a bucket are actually a single thing in a single place, as evidenced by the mixed consistency model of different actions in S3, where new objects are immedately-consistent while overwrites and deletes are eventually consistent... so the concept of a policy having "had an effect" or not on the bucket or an object isn't an entirely meaningful concept since the application of the policy is, itself, almost certainly, a distributed event.

To confirm such an application of policies would require AWS to expose the capability of (at least indirectly) interrogating every entity that has a replicated copy of that policy to see whether it had the current version or not... which would be potentially impractical or unwieldy to say the least in a system as massive as S3, which has grown beyond a staggering 2 trillion objects, and serves peak loads in excess of 1.1 million requests per second.

Official AWS answers to this forum post provide more information:

While changes you make to IAM entities are reflected in the IAM APIs immediately, it can take noticeable time for the information to be reflected globally. In most cases, changes you make are reflected in less than a minute. Network conditions may sometimes increase the delay, and some services may cache certain non-credential information which takes time expire and be replaced.

The accompanying answer to what to do in the mean time was "try again."

We recommend a retry loop after a slight initial delay, since in most circumstances you'll see your changes reflected quite quickly. If you sleep, your code will be waiting far too long in most cases, and possibly not long enough for the rare exceptions.

We actively monitor the performance of the replication system. But like S3, we guarantee only eventual consistency, not any particular upper bound.