Policy Evaluation Within AWS
- Tushar Prasad
- Apr 7, 2021
- 3 min read

The above image is a blue print of all the event that happens in the background, when you try to access a Resource. Things get pretty complicated while debugging permission issues, So one should know the order in which AWS evaluate different policies before granting access to a resource. Next time when you get that permission denied error and you have a bunch of policies to evaluate and you have no clue on where to start, you can refer this image. This will help in debugging and you can reach to your desired outcome. So lets get started.
Before Jumping into the Evaluation Order, lets first list out all the different ways (Policies) the access can be restricted inside AWS. Below is the list of policies through which one can control the access to a resource inside AWS.
Service Control Policies (SCP).
Resource Policies.
Permission Boundaries.
Session/Role Policies.
Identity Policies.
So now lets assume that we have all these different policies set. AWS evaluates the policies in the below order.
It will first check if there is an Explicit Deny. The one rule you always have to remember is Deny->Allow->Deny. At this point AWS is going to list all the policies and check if there is an Explicit Deny available in any of the policies for the Resource you are trying to access. And if there is one, Game Over (Explicit Deny Always Wins). Evaluation Stops here itself and you will get the access denied error.
If there is No Explicit Deny set, AWS now evaluates the Service Control Policies set at the Organization Level. These Policies are a ways to control your member accounts which are present inside that OU. At this point AWS Check if there is any SCP, and if they exist, Do they allow the action ? If they Don't, Evaluation stop here itself and you will get that access denied error.
But if SCP allow the access or there is no SCP set for that OU which means there is no SCP set for the Members account, then the Evaluation proceed to the next step, which is Resource Policies. Resource Policies are like Identity Policies but only major difference is they are applied directly to a Resource. Identity policy has this limitation that, they can only be applied to an AWS identity (IAM Users) while Resource policies can be applied to Anonymous Identities. They have this Special Power and as Superman Says "With Great Power Comes Great Responsibility", so one has to be extra careful while using these. At this point AWS Check if there is a Resource Policy Available for the Resource you are trying to access and if there is one and it does allow the Access, Then that's it. You will get access to the Resource and AWS will not going to care if there are other policies available or not. That's why extra care has to be taken when using Resource Policies.
But if there are no Resource Policies or Resource Policy doesn't allow the access, then AWS Checks for the Permission Boundaries. I will have a separate blog on Permission Boundaries (What, How, Why and When to use it). At this point AWS Checks if there is one applicable Permission Boundary and If Yes, does is allow the Access ? If it doesn't, that's it. Evaluation stops here and you will get the access denied Error.
But if there is no Applicable Permission Boundary or It exist and allow the access, Evaluation moves to the nest step which is Session/Role Policies. As we all know, A typical IAM role have two policies set. One is Identity Policy which basically describe who can assume that Role and the next one is Permission Policy which describe what all permission the role has inside AWS. If AWS is evaluating this step, means, an Identity is using a Role to access the Resource. At this point AWS Checks the Role's Permission Policy and If it allows the Access ? If it doesn't, that's it. Evaluation stops here and you will get the access denied Error.
But if there is no Role being Involved or the Role's Permission Policy does allow the access, Evaluation moves to the Final step which is last but not the least "Identity Policies". At this point AWS checks all the Identity policies applicable to an Identity. If there is an Explicit Allow found for the Resource that you are trying to access, then that's it. Permission will be allowed. Other wise the Same Golden Rule of Deny->Allow->Deny will get applied and as there is no explicit Allow available, the Implicit Deny will get applied and you will get the Access Denied Error.
So next time when you get that access denied error and you have a bunch of policies to evaluate and you have no clue where to start, I hope this article will help you to achieve the desired Outcome.
P.S: I have used the image from https://learn.cantrill.io. Do Check out his Courses on AWS.
Comments