 | Documentation Feedback |  |
The goal at evaluation time is to decide whether a given request from someone other than you (the resource owner) should be allowed or denied. The evaluation logic follows several basic rules:
By default, all requests to use your resource coming from anyone but you are denied
The order in which the policies are evaluated is not important
An explicit deny (hard deny) overrides any allows
An allow overrides any soft denies
The following flow chart and discussion describe in more detail how the decision is made.
 |
By default, the decision starts at "deny." |
 |
The enforcement code then evaluates all the policies that are applicable to the request (based on the resource, principal, action, and conditions). The order in which the enforcement code evaluates the policies is not important. |
 |
In all those policies, the enforcement code looks for an explicit "deny" instruction that would apply to the request. If it finds even one, the enforcement point returns a decision of "deny" and the process is finished. Because there was an explicit deny, this is considered a hard deny (for more information, see Hard Deny). |
 |
If no explicit deny is found, the enforcement code looks for any explicit "allow" instructions that would apply to the request. If it finds even one, the enforcement code returns a decision of "allow" and the process is done (the service continues to process the request). |
 |
If no explicit allow is found, then the final decision is "deny." Because there was no explicit deny or allow, this is considered a soft deny (for more information, see Soft Deny). |
![[Note]](images/note.png) | Note |
|---|---|
The order of evaluation is irrelevant to the decision-making process; one explicit deny overrides any allows that might be present in the policies. |
A hard deny results from a policy that has effect=deny. A soft deny results from a policy that would logically return a deny, but can't because effect=allow in the policy. The distinction between a soft and hard deny is important because a soft deny can be overridden by an allow, but a hard deny can't. The following example illustrates this.
In this example, you create two policies:
Policy A—Based on the time of the request
Policy B—Based on the location of the request (i.e., where it comes from)
You want to allow requests that arrive on January 1, 2009, but deny requests that come from Antarctica.
To illustrate the interplay of hard and soft denials, we'll compare what happens if you write Policy B with effect=allow (Scenario 1 in the following diagram) versus effect=deny (Scenario 2).
For both Scenario 1 and Scenario 2, you create Policy A to allow requests received on 1/1/2009.
For Scenario 1, you create Policy B1 to allow requests that don't come from Antarctica.
For Scenario 2, you create Policy B2 to deny requests that come from Antarctica.
Although Policy B1 and Policy B2 look like they do the same thing, the outcomes of Scenario 1 and Scenario 2 are different when a request comes in from Antarctica on January 1, 2009. The following figure and discussion explain why.
In both scenarios, Policy A returns an allow because the policy (by definition) allows requests that come in on January 1, 2009.
In Scenario 1, Policy B1 returns a soft deny, because (by definition) the policy only allows requests if they don't come from Antarctica. This request does come from Antarctica. But, Policy B1 is only designed to return an allow when the condition is met. The condition isn't met, so the policy returns a soft deny by default.
In Scenario 2, Policy B2 returns a hard deny, because by definition the policy denies requests that come from Antarctica. The condition is met, so the result is deny (a hard deny, because effect=deny).
A policy that returns an allow overrides any other policy that returns a soft deny. But a policy that returns a hard deny always overrides any other policy that returns an allow or soft deny. So, your results vary depending on how you write Policy B.
