本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
评估逻辑
评价期间的目的是为了确定应该允许还是拒绝授予请求。评估逻辑遵循多个基本规则：
-
在默认情况下，除了您，任何人提出使用您资源的请求均会被拒绝。
-
一个允许可以超控任何其他默认拒绝
-
一个显式拒绝可以超控任何允许
-
策略评估的顺序不重要
以下流程图和讨论更加详细地描述了如何做出决定。
| 1 |
决定开始是一个默认拒绝。 |
| 2 |
然后执行代码将评估适用于请求的所有策略（根据资源、委托人、操作和条件）。 执行代码评估策略的顺序不重要。 |
| 3 |
在所有这些策略中，执行代码将寻找一个能适用于请求的显式拒绝指令。 即使仅找到一处，执行代码也会发回“拒绝”的决定，并结束处理流程（此为“显式拒绝”；有关更多信息，请参见 显式拒绝）。 |
| 4 |
如果没有找到显式拒绝，那么执行代码将寻找适用于请求的任何“允许”指令。 如果它还是找到了一个，那么执行代码将返回一个“允许”决定，且整个过程完成（服务将继续处理该请求）。 |
| 5 |
如果没有找到允许，那么最终的决定将是“拒绝”，因为没有显式拒绝或允许，所以这将被视为是一个默认拒绝（有关更多信息，请参见默认拒绝）。 |
显式拒绝和默认拒绝的相互作用
如果策略不直接适用于请求，那么策略将产生一个默认拒绝。例如，如果用户请求使用 AmazonSNS，但该主题的政策根本没有提及该用户的 AWS 账户 政策，则该策略会导致默认拒绝。
如果一个语句中的某个条件未被满足，那么策略将产生一个默认拒绝。如果语句中的所有条件都满足，那么根据策略中的效果元素的值，策略或许会产生允许，或许会产生显式拒绝。如果一个条件未被满足，策略没有指定如何处理，那么在那种情况下默认值将产生一个默认拒绝。
例如，假设您想要阻止来自南极洲地区的请求进入。只要请求不是来自于南极洲地区，您编写的策略（称作策略 A1）将允许接受请求。下列示意图说明了该策略。
如果某人从美国发出请求，那么条件已经满足 (该请求不是来自南极洲)。因此，该请求将被允许。但是，如果某人从南极洲地区发出请求，那么条件未满足，因此策略结果将是默认拒绝。
您可通过按照下列示意图重新编写策略（称作策略 A2）将结果转变为一个显式拒绝。此时，如果请求是来自南极洲地区，那么策略将明确拒绝该请求。
如果某人从南极洲发出请求，那么条件已经满足，策略的结果将是一个显式拒绝。
默认拒绝和显式拒绝的区别很重要，因为默认拒绝可以被允许覆盖，但显式拒绝就不能。例如，假设有另一个策略，允许在 2010 年 6 月 1 日到达的请求。那么，与限制从南极洲访问的策略相结合，该策略将如何对总体结果产生影响？ 当将按日期要求设置的策略与上述策略 A1 和 A2 相结合时，我们将对比综合结果。方案 1 是将策略 A1 与策略 B 相结合，方案 2 是将策略 A2 与策略 B 相结合。以下图表和讨论显示了如果于 2010 年 6 月 1 日从南极洲区域发出请求输入时的结果。
在方案 1 中，策略 A1 将返回一个默认拒绝，如本节之前所描述的那样。Policy B 返回“允许”结果，因为该策略（依照定义）允许在 2010 年 6 月 1 日发送请求。Policy B 返回的“允许”结果将置换 Policy A1 的“默认拒绝”结果，因此，请求获得允许。
在方案 2 中，策略 A2 返回了一个显式拒绝，如本节之前所描述的那样。此外，策略 B 返回了一个允许。从策略 A2 发出的显式拒绝将超控从策略 B 发出的允许，因此该请求会被拒绝。
