When you first dive into AWS, understanding the IAM permission model can feel like the biggest hurdle. It takes time to wrap your head around concepts like least privilege and how policies work together to control access in your cloud environment.
The diagram below gives you a simplified view of the types of AWS policies. As AWS has added more types of policies and features over time, it can feel a bit overwhelming to figure out how everything fits. But don’t worry—when it comes to managing access, it all comes down to a few key ideas. AWS policies can be grouped into three main types: Organizational Policies, Identity-Based Policies, and Resource Policies. Together, these policies help you set the rules for who can access what in your AWS environment.
AWS Policy Types and the pertinent services
In this article, my goal is to explain AWS policies for less technical audiences through an analogy, your digital kingdom.
When managing a large AWS environment, keeping everything secure and organized can feel like ruling a vast kingdom. AWS policies are the rules that help you govern your digital empire. They ensure that your resources are used safely, consistently, and in line with your organization’s goals. Let’s break down these policies using the analogy of a kingdom to make them easier to understand.
Understanding AWS Policies
Organizations policies are the overarching rules that govern your AWS empire. Think of them as the constitution of your digital kingdom. These policies, attached to organizational units or individual accounts, help you create consistent security practices and resource management rules.
Imagine you’re the ruler of a kingdom with 200 regions. To keep everything running smoothly, you need a set of universal laws—like ‘No one can cut down sacred trees’, ‘Taxes must be collected every month’, or ‘All trade must pass through authorized checkpoints’. These laws apply to everyone in the kingdom, no matter where they are, ensuring that the entire kingdom operates under the same rules. In AWS, Organizational Policies work the same way. They are like these universal laws, setting rules and boundaries that apply to all or specific groups of AWS accounts. Whether it’s enforcing security practices or managing resources, these policies help keep your digital kingdom secure, compliant, and consistent..
In your kingdom, not everyone has the same responsibilities. Knights, messengers, and treasurers each have specific roles and permissions. For example, a guard might be allowed to patrol the walls but not enter the treasury, while a treasurer can access the gold vault but not the armory. In AWS, Identity-Based Policies work similarly. They define what actions a user or role can perform and which resources they can access. For instance, a developer might have permission to deploy code but not delete databases. By assigning these permissions carefully, you ensure that everyone in your digital kingdom has just the right level of access to keep things running smoothly and securely.
Now, imagine signs posted on the gates, doors, and chests in your kingdom. These signs have their own rules, like ‘Only knights with royal permission may enter’ or ‘Only the treasurer is allowed inside.’ These rules are part of the resource itself and control who can access it, even if they come from outside the kingdom (another AWS account). In AWS, Resource-Based Policies work the same way. They are attached to resources like S3 buckets or Lambda functions and define who can access them. For example, you might set a policy on an S3 bucket that says, ‘Only users from this specific AWS account can read these files.’ Resource-based policies work alongside identity-based policies to ensure your resources are protected, no matter who tries to access them.
Identity-based policies and resource-based policies work together to keep your kingdom secure, but they serve different purposes. Identity-based policies are like the badges your knights carry—they define what each user or role can do, such as accessing certain areas or performing specific tasks. On the other hand, resource-based policies are like the signs posted on doors and gates—they control who can access a specific resource, like an S3 bucket or a Lambda function, even if they come from outside your kingdom (another AWS account). While identity-based policies are typically used to grant permissions to users or groups, resource-based policies are ideal for setting rules directly on resources, ensuring consistent access control no matter who tries to access them.
Just like a well-run kingdom needs clear laws and roles, your AWS environment needs well-defined policies to stay secure and organized. Whether it’s setting universal rules with Organizational Policies, assigning roles with Identity-Based Policies, or protecting individual resources with Resource-Based Policies, AWS gives you the tools to rule your digital kingdom with confidence.
AWS Policy Evaluation: How Decisions Are Made
When it comes to accessing resources in your digital kingdom, AWS follows a set of rules to decide who gets in and who doesn’t. Here’s how it works:
-
Deny by Default: Imagine your kingdom has a strict rule: “No one is allowed anywhere unless explicitly permitted.” In AWS, this means that by default, all access to resources is denied. You have to explicitly grant permissions for anyone to enter.
-
Deny Overrides Allow: Let’s say a knight has a badge that says, “You may enter the treasury.” But the treasury door has a sign that says, “No entry for this knight.” In this case, the knight is denied access, no matter what their badge says. In AWS, if a resource-based policy denies access, it overrides any permissions granted by identity-based policies. Deny always wins.
-
Organizational Policies Are the Supreme Law: Even if a knight has permission to enter a room and the room’s policy allows it, the kingdom’s supreme laws (Organizational Policies) might still say, “No one can enter this room under any circumstances.” In AWS, Organizational Policies act as the highest authority. If they deny access, it doesn’t matter what other policies say—access is still denied.
AWS Policy Evaluation
How Policies Work Together
Imagine you have permission to enter a room. Normally, you’d be able to walk right in—unless the guards stop you. These guards can overrule your permissions and deny you access, even if you think you should be allowed inside.
For example, the guards might recognize you as a member of a highly privileged group and let you in, but your badge (your identity-based policy) might still fail to unlock the door because of a “deny” rule applied to it.
To successfully enter the room, there must be no explicit denies blocking your way. If either your badge (identity policy) or the room’s rules (resource policy) allow access, you’re good to go. But if there’s no explicit “allow” statement anywhere, the guards will automatically turn you away—this is called an implicit deny.
Summary
Managing access in AWS is like ruling a digital kingdom. AWS policies serve as the laws that keep everything secure and well-organized. They fall into three main categories:
- Organizational Policies – The kingdom’s universal laws, setting global rules across accounts.
- Identity-Based Policies – The badges your knights carry, defining what individuals or roles can do.
- Resource-Based Policies – The signs on doors and gates, controlling who can access specific resources.
These policies work together to determine access in your AWS environment. One key rule to remember: Deny always wins—if any policy explicitly denies access, it overrides all other permissions. By mastering these policy types, you can confidently manage access, ensuring security, compliance, and smooth operations in your AWS realm.