Policy evaluation logic in AWS - Deep Dive

Overview - Policy evaluation logic

What is it?

Policy evaluation logic is the process AWS uses to decide if a user or service can perform an action on a resource. It checks all the rules written in policies attached to the user, group, or resource. These rules say what is allowed or denied. The system combines these rules to make a final decision.

Why it matters

Without policy evaluation logic, AWS would not know who can do what, risking security or blocking needed access. It protects resources by enforcing permissions clearly and consistently. This keeps data safe and operations smooth, preventing mistakes or attacks.

Where it fits

Before learning this, you should understand basic AWS concepts like users, roles, and policies. After this, you can learn about advanced access control, such as permission boundaries and service control policies.

Mental Model

Core Idea

AWS policy evaluation logic combines all relevant rules to decide if an action is allowed or denied on a resource.

Think of it like...

It's like a security guard checking all the passes and rules before letting someone enter a building. If any rule says no, the guard stops them.

┌───────────────┐
│User/Role/Group│
└──────┬────────┘
       │
       ▼
┌─────────────────────┐
│Collect all policies  │
│(identity + resource) │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│Evaluate each policy  │
│ - Allow or Deny      │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│Combine results:     │
│ Deny overrides Allow│
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│Final decision:      │
│ Allow or Deny       │
└─────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is a policy in AWS

Concept: Introduce the idea of policies as rules that say who can do what.

A policy is a document that lists permissions. It says which actions are allowed or denied on which resources. Policies are attached to users, groups, or roles to control access.

Result

You understand that policies are the building blocks of AWS permissions.

Knowing what a policy is helps you see how AWS controls access step-by-step.

2

Foundation

Types of policies and their roles

Concept: Explain identity-based and resource-based policies and their differences.

Identity-based policies attach to users, groups, or roles and define what they can do. Resource-based policies attach directly to resources, like S3 buckets, and define who can access them.

Result

You can identify where policies live and how they affect access.

Understanding policy types clarifies where AWS looks for permissions during evaluation.

3

Intermediate

How AWS evaluates multiple policies

🤔Before reading on: do you think AWS allows access if any policy says allow, or must all policies say allow? Commit to your answer.

Concept: Introduce the process of combining multiple policies to reach a decision.

AWS collects all policies attached to the user, group, role, and resource. It checks each policy's statements for allow or deny. If any policy explicitly denies, access is denied. Otherwise, if any policy allows, access is allowed. If no policy allows, access is denied by default.

Result

You know that deny always wins and allow only works if no deny exists.

Understanding deny overrides allow prevents security holes and unexpected access.

4

Intermediate

Effect of explicit deny vs implicit deny

🤔Before reading on: do you think missing a permission is the same as denying it? Commit to your answer.

Concept: Explain the difference between explicit deny and implicit deny in policy evaluation.

Explicit deny is when a policy statement says 'Deny' for an action. Implicit deny happens when no policy allows the action. AWS treats explicit deny as stronger and blocks access immediately. Implicit deny means no permission was found, so access is denied by default.

Result

You can distinguish between a direct block and lack of permission.

Knowing this helps you write policies that safely block unwanted access.

5

Intermediate

Role of conditions in policy evaluation

🤔Before reading on: do you think conditions can override allow or deny effects? Commit to your answer.

Concept: Introduce conditions as extra rules that must be true for a policy to apply.

Conditions add filters like time of day, IP address, or MFA status. Even if a policy says allow, conditions must be met. If conditions fail, the statement is ignored. Conditions do not override deny; deny always blocks access.

Result

You understand how conditions refine permissions dynamically.

Recognizing conditions' role helps create flexible and secure access controls.

6

Advanced

How resource-based policies interact with identity policies

🤔Before reading on: do you think resource policies can grant access even if identity policies deny it? Commit to your answer.

Concept: Explain the combined evaluation of identity and resource policies.

AWS evaluates identity-based policies first, then resource-based policies. Both must allow access for it to be granted. If either denies, access is denied. Resource policies can grant cross-account access, but cannot override explicit denies in identity policies.

Result

You see how AWS merges different policy sources for final decisions.

Understanding this prevents confusion when access is unexpectedly denied or allowed.

7

Expert

Unexpected effects of policy evaluation order and overrides

🤔Before reading on: do you think the order of policy evaluation affects the final decision? Commit to your answer.

Concept: Reveal subtle behaviors like deny precedence, policy evaluation order, and how AWS caches decisions.

AWS evaluates all policies together, not sequentially, but deny always overrides allow regardless of order. Some services cache evaluation results, causing delays in permission changes. Also, permission boundaries and service control policies add layers that can restrict permissions beyond identity and resource policies.

Result

You grasp complex interactions that can cause surprising access results.

Knowing these internals helps troubleshoot tricky permission issues and design robust security.

Under the Hood

AWS collects all relevant policies attached to the identity and resource. It parses each policy statement, checking the action, resource, effect (allow or deny), and conditions. It then merges these results, applying deny overrides allow. The evaluation engine uses a decision tree to quickly determine the final access decision. This process happens every time an API call is made, ensuring up-to-date enforcement.

Why designed this way?

This design balances security and flexibility. Deny overrides prevent accidental permission leaks. Combining identity and resource policies allows fine-grained control. Conditions enable dynamic rules. The system needed to be fast and scalable for millions of requests, so a clear, rule-based evaluation was chosen over complex heuristics.

┌─────────────────────────────┐
│Start API request             │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│Gather policies:             │
│ - Identity-based            │
│ - Resource-based            │
│ - Permission boundaries     │
│ - Service control policies  │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│Evaluate each statement:     │
│ Check action, resource,     │
│ effect, conditions          │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│Combine results:             │
│ Deny overrides Allow        │
│ Conditions filter applies   │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│Final decision: Allow or Deny│
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: If one policy allows an action but another denies it, does AWS allow or deny? Commit to allow or deny.

Common Belief: If any policy allows an action, AWS will allow it regardless of denies.

Reality: AWS always denies if any policy explicitly denies the action, even if others allow it.

Why it matters: Ignoring deny overrides can lead to unexpected access being blocked or security holes if deny is not used properly.

Quick: Is missing a permission the same as explicitly denying it? Commit to yes or no.

Common Belief: If a permission is missing, it is treated the same as an explicit deny.

Reality: Missing permission causes implicit deny, which is different from explicit deny that blocks access even if other policies allow.

Why it matters: Confusing these can cause over-permissive or overly restrictive access setups.

Quick: Can resource-based policies grant access even if identity policies deny it? Commit to yes or no.

Common Belief: Resource policies can override identity policy denies and grant access.

Reality: Explicit denies in identity policies always block access, regardless of resource policies.

Why it matters: Misunderstanding this can cause security risks or troubleshooting confusion.

Quick: Does the order in which AWS evaluates policies affect the final decision? Commit to yes or no.

Common Belief: The order of policy evaluation changes the access decision.

Reality: AWS evaluates all policies together; order does not affect the final deny-overrides-allow decision.

Why it matters: Believing order matters can lead to incorrect assumptions and complex, unnecessary policy changes.

Expert Zone

1

Permission boundaries act as a second layer of restriction that can limit permissions granted by identity policies, but they do not grant permissions themselves.

2

Service control policies (SCPs) in AWS Organizations can restrict permissions across accounts, overriding identity policies even if they allow access.

3

AWS caches policy evaluation results for performance, so permission changes might take a few minutes to propagate, causing temporary access inconsistencies.

When NOT to use

Policy evaluation logic is core to AWS IAM and cannot be replaced, but for very fine-grained or dynamic access control, consider using AWS Organizations SCPs, permission boundaries, or attribute-based access control (ABAC). For temporary elevated access, use session policies or AWS STS tokens instead of static policies.

Production Patterns

In production, teams use layered policies: identity-based for user roles, resource-based for cross-account access, permission boundaries for safety, and SCPs for organizational control. They monitor policy evaluation logs to audit decisions and use least privilege principles to minimize risk.

Connections

Access Control Lists (ACLs)

Similar pattern

Both ACLs and AWS policy evaluation define who can access resources, but AWS policies offer richer conditions and deny overrides.

Firewall Rule Evaluation

Similar pattern

Like firewall rules, AWS policies are evaluated with deny rules taking precedence to block unwanted traffic or actions.

Legal Contract Interpretation

Builds-on

Understanding how multiple clauses combine to form a final legal decision helps grasp how multiple policies combine to allow or deny access.

Common Pitfalls

#1 Assuming that allowing a permission in one policy is enough to grant access.

Wrong approach:

User policy: Allow s3:GetObject
Resource policy: Deny s3:GetObject

Correct approach:

User policy: Allow s3:GetObject
Resource policy: Allow s3:GetObject

Root cause:

Not realizing that explicit deny in any policy blocks access regardless of allows.

#2 Writing overly broad allow policies without conditions.

Wrong approach:

{ "Effect": "Allow", "Action": "*", "Resource": "*" }

Correct approach:

{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket/*", "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } } }

Root cause:

Ignoring the principle of least privilege and missing conditions to limit access.

#3 Expecting immediate permission changes after policy updates.

Wrong approach:

Update policy and immediately test access expecting instant effect.

Correct approach:

Update policy, then wait a few minutes for AWS to propagate changes before testing access.

Root cause:

Not knowing AWS caches policy evaluation results for performance.

Key Takeaways

AWS policy evaluation logic combines all relevant policies to decide if an action is allowed or denied.

Explicit deny always overrides any allow, ensuring strong security controls.

Conditions refine when permissions apply but cannot override explicit denies.

Both identity-based and resource-based policies must allow access for it to be granted.

Understanding this logic is essential to design secure, effective AWS permissions and troubleshoot access issues.