AWS Identity and Access Management (IAM) is powerful, but it is also one of the most complex and frustrating aspects of cloud security. Security teams want to enforce least privilege, but AWS IAM’s additive permissions model, combined with multiple policy layers, makes it difficult to manage permissions efficiently. Developers, on the other hand, frequently encounter confusing permission errors, slowing down their work and creating friction between teams.

This complexity stems from how AWS IAM evaluates multiple policy types together, determining access based on the sum of all applicable permissions. Over time, AWS has introduced additional policy controls—IAM identity policies, service control policies (SCPs), permission boundaries, session policies, and resource control policies (RCPs). While these tools provide security and flexibility, they also introduce challenges in enforcement and troubleshooting.

Organizations need a scalable way to enforce least privilege without slowing down developers or spending excessive time managing IAM policies. 

Breaking Down AWS IAM Policy Layers

AWS Identity and Access Management (IAM) is a powerful framework that allows organizations to control access to their cloud environments. However, as cloud adoption has grown, IAM has evolved into a layered security model with multiple policy types, each designed to address different aspects of permissions management. To understand why AWS IAM can be difficult to manage, let’s break down its policy structure and how it has evolved.

AWS IAM’s Many Layers: A Timeline of Growing Complexity

AWS IAM began with identity-based policies, which granted or restricted permissions to individual IAM users, groups, and roles. As organizations expanded their cloud usage, AWS introduced additional policy types to provide greater security controls at different levels.

Each of these policy types was introduced to solve a specific problem: Restricting permissions at the organizational level (SCPs), enforcing least privilege for IAM roles (permission boundaries), or controlling access at the resource level (resource-based policies and RCPs).

Here’s how IAM policy types have evolved:

While these policies work together, understanding how they interact in AWS’s evaluation process is critical for preventing misconfigurations, reducing overprivileged identities, and maintaining security at scale.

The AWS IAM Policy Evaluation Flow: A Web of Dependencies

AWS provides an IAM Policy Evaluation Logic diagram to illustrate how policies interact when a request is made.

At a high level, when an IAM entity (like a user or role) attempts an action, AWS evaluates policies in the following order:

1. Explicit Deny Always Wins: If any policy explicitly denies an action, AWS immediately blocks the request, regardless of any allow permissions elsewhere. By contrast, an implicit deny means access is simply not granted unless a specific allow policy exists. AWS provides a deeper explanation of explicit deny vs. implicit deny in its documentation.
2. Organizations Resource Control Policies (RCPs): RCPs apply at the AWS Organization level and define maximum permissions for AWS resource types (e.g., all EC2 instances, all S3 buckets) across an organization. If an RCP does not explicitly allow an action for a resource type, it is denied, regardless of IAM identity or resource policies.
3. Organizations Service Control Policies (SCPs): SCPs apply at the AWS Organizations level and define permission limits for all IAM users, roles, and service-linked roles within an AWS account or organizational unit (OU). If an SCP does not explicitly allow an action, IAM identity policies cannot override it.
4. Resource-Based Policies: These policies are attached directly to AWS resources (e.g., an S3 bucket, KMS key, or Lambda function) and define which AWS identities (users, roles, accounts) can access that resource. Unlike SCPs and RCPs, they are evaluated after organizational policies.
5. Identity-Based Policies: Attached to IAM identities (users, groups, roles), these policies grant or deny permissions to perform actions on AWS resources. However, they cannot grant permissions restricted by SCPs, RCPs, or permission boundaries.
6. Permissions Boundaries: These define the maximum permissions an IAM identity-based policy can grant to a user or role. They do not grant permissions themselves but act as a ceiling that IAM policies cannot exceed.
7. Session Policies: These policies are passed when assuming a role or federating a user and further restrict the temporary session’s permissions. They cannot grant more permissions than the identity’s existing IAM policies, SCPs, or permission boundaries allow.

This logic means that a deny from any level will override an allow, but finding out which policy blocked access is often difficult. A developer may see a “permission denied” error without knowing whether the issue came from an SCP, an RCP, a permission boundary, or a resource policy.

The Power of SCPs & RCPs for Centralized Control

As cloud environments scale, managing IAM policies at the individual user, group, or role level becomes overwhelming. Service Control Policies (SCPs) and Resource Control Policies (RCPs) shift permissions management from a bottom-up to a top-down model, ensuring least privilege at scale without micromanaging every IAM role.

Service Control Policies (SCPs): Enforcing Global Guardrails

SCPs define what actions can never be allowed across an AWS Organization, overriding IAM policies to enforce security at scale.

Key SCP Characteristics:

• Applied at the AWS Organization level → Affect all accounts, OUs, and linked accounts.
• Restrict permissions but do not grant them → SCPs only block actions; they don’t assign access.
• Override IAM policies → If an SCP denies an action, IAM policies cannot allow it.

Example SCP Use Cases:

• Deny risky actions globally (e.g., prevent IAM role creation outside security teams).
• Block access to unauthorized AWS regions to enforce data residency.
• Require MFA for all users across an organization.

Resource Control Policies (RCPs): Locking Down AWS Resources

RCPs set permission boundaries for AWS resource types (e.g., EC2, S3, Lambda) across an organization, limiting what IAM policies can allow.

Key RCP Characteristics:

• Applied at the AWS Organization level → Affect entire AWS resource types, not individual resources.
• Restrict actions across all instances of a resource type but do not provide fine-grained per-resource control.
• Prevent IAM policies from exceeding the limits set by RCPs.
• Apply to both organizational identities and external cross-account identities.

Example RCP Use Cases:

• Prevent public S3 bucket creation across an organization.
• Limit EC2 instance creation to specific AWS accounts or OUs.
• Restrict third-party access to organization resources.

While SCPs control permissions at the identity level, RCPs enforce boundaries at the resource type level, ensuring consistent governance across AWS environments.

SCP and RCP Quick Comparison

Policy Type	Scope	What It Controls	Overrides IAM Policies?
Service Control Policies (SCPs)	AWS Organization	Defines what actions can never be allowed across accounts.	Yes
Resource Control Policies (RCPs)	AWS Resources	Blocks access at the resource level, even if IAM policies allow it.	Yes
IAM Policies	Users, Groups, Roles	Grants or restricts permissions for specific identities.	No

SCPs and RCPs provide strong security controls, but they don’t inherently enforce least privilege. They only make it possible. Least privilege isn’t a one-time fix; it’s an ongoing effort. 

How Sonrai’s Cloud Permissions Firewall Tames the Chaos

The problem is that managing IAM permissions manually is error-prone and time-consuming, making it difficult for security teams to track unused permissions, overprivileged identities, and risky third-party access. Developers frequently encounter confusing permission errors, while security teams lack visibility to diagnose issues and effectively enforce least privilege.

Sonrai’s Cloud Permissions Firewall solves these challenges with deep visibility, automated least privilege enforcement, and a shift from permission accumulation to default deny. This approach helps organizations significantly reduce security risks and operational overhead. 

Visibility for Fast, Accurate Access Control

Security teams can instantly see who has access, which permissions are actually used, and where excessive privileges create risk. This enables them to quickly diagnose permission errors, resolve access issues, and enforce least privilege with precision.

Automated Default Deny at Scale

Sonrai flips the model to default deny at the SCP and RCP level, ensuring:

• Unused permissions are automatically locked down before they become a risk.
• Zombie identities and dormant roles are quarantined, preventing privilege escalation.
• Services, regions, and third-party access are blocked unless actively needed.

Seamless Access Workflows

Sonrai enforces least privilege without disrupting workflows by integrating Just-in-Time (JIT) access and Permissions-on-Demand (POD):

• JIT removes standing privileges, ensuring no human users have permanent access to critical production environments. Instead, access is requested per session and approved via Slack, Teams, or email. Once the session ends, access is automatically revoked.
• POD enables temporary permission elevation for users with existing base access. If a cloud engineer needs elevated access to modify an EC2 instance, they request specific permissions, which are granted for a limited time before being revoked automatically.

By combining deep visibility, automated enforcement, and a default deny model, Sonrai helps security teams eliminate unnecessary access, resolve permission errors instantly, and maintain strong security, without slowing development.

Conclusion

Managing IAM permissions manually is inefficient and risky. Without automation, security teams struggle to track unused permissions, prevent privilege creep, and enforce least privilege without disrupting development.

Sonrai’s Cloud Permissions Firewall solves this challenge by automating least privilege enforcement and establishing a default deny model for permissions outside of approved guardrails. Organizations that implement Sonrai’s solution see measurable improvements in security posture and operational efficiency, including:

• 97% reduction in time spent managing least privilege.
• 74% decrease in developer access requests.
• 92% reduction in permissions attack surface.

Learn how Sonrai delivers measurable ROI for security teams.

By shifting IAM management from manual oversight to automation-assisted enforcement, security teams can maintain strong least privilege controls while keeping development workflows efficient and uninterrupted.

*** This is a Security Bloggers Network syndicated blog from Sonrai | Enterprise Cloud Security Platform authored by Adeel Nazar. Read the original post at: https://sonraisecurity.com/blog/untangle-aws-iam-policy-logic/