Free AWS Security Whitepaper
    Toc Consulting Logo
    comparescp-vs-iam-policies-vs-permission-boundaries
    SECURITYPublished 2025-10-01Updated 2025-12-05
    Service Control Policies (SCPs)Service Control Policies (SCPs)
    vs
    IAM PoliciesIAM Policies
    vs
    Permission BoundariesPermission Boundaries

    SCPs vs IAM Policies vs Permission Boundaries

    The three layers of AWS access control, decoded

    AWS has three distinct mechanisms to control access: Service Control Policies at the organization level, IAM policies at the account level, and Permission Boundaries at the principal level. Understanding how they intersect - and the September 2025 SCP overhaul - is critical for any multi-account architecture.

    Service Overview

    Service Control Policies (SCPs)

    Service Control Policies (SCPs)

    Organization guardrails

    Enforces guardrails across ALL accounts - no one can bypass

    TypeMaximum permission boundary for accounts
    PricingFree (included with AWS Organizations)
    IAM Policies

    IAM Policies

    Account-level permissions

    The actual permission grants - identity, resource, and session policies

    TypeGrant or deny specific permissions
    PricingFree
    Permission Boundaries

    Permission Boundaries

    Principal-level cap

    Prevents privilege escalation in delegated admin scenarios

    TypeMaximum permissions for a user or role
    PricingFree

    Side-by-Side Comparison

    $ diff --side-by-side
    CriteriaService Control Policies (SCPs)IAM PoliciesPermission Boundaries
    ScopeAll principals in member accountsSpecific users, groups, roles, or resourcesSpecific IAM user or role
    Grants Permissions?No - only restrictsYes - grants AND restrictsNo - only restricts (caps the maximum)
    Affects Management Account?NoYesYes
    Supports Deny?YesYesYes
    Supports Conditions?Yes - Deny (always), Allow (since Sept 2025)YesYes
    Max Size5,120 characters2,048–10,240 (inline, varies) / 6,144 (managed)6,144 characters
    Attached ToOU or accountUser, group, role, or resourceUser or role
    Use CasePrevent regions, services, or actions org-wideGrant least-privilege access to do the jobLet devs create roles without full admin risk

    When to Use What

    $ cat DECISION_GUIDE.md
    IFYou want to prevent anyone from disabling CloudTrail or GuardDuty
    THENSCP
    WHYSCPs are organization-wide guardrails that no IAM policy in member accounts can override. Even account administrators cannot bypass them.
    IFYou want to give a developer read access to S3 and write access to DynamoDB
    THENIAM Policy
    WHYIAM policies are the only mechanism that actually grants permissions. SCPs and boundaries only restrict.
    IFYou want to let a team lead create IAM roles but not grant themselves admin
    THENPermission Boundary
    WHYAttach a boundary to the team lead. Any roles they create are capped by the boundary - even if they attach AdministratorAccess to the new role.
    IFYou want to restrict all accounts to specific AWS regions
    THENSCP
    WHYA single SCP with a region condition applies to every principal in every member account. No per-account configuration needed.
    IFYou want to prevent a specific Lambda function from accessing KMS
    THENIAM Policy (Deny)
    WHYUse an explicit Deny in the Lambda execution role or a resource-based policy on the KMS key. SCPs are too broad for single-resource restrictions.

    Security Insights

    September 2025: SCPs got a massive upgrade

    SCPs now support full IAM policy language - conditions in Allow statements, individual resource ARNs in Deny, wildcards in action strings, and the NotResource element. This was previously the biggest limitation of SCPs.

    Effective permissions = SCP ∩ IAM Policy ∩ Permission Boundary

    A request is only allowed if ALL three layers allow it. Think of SCPs and boundaries as ceilings - they do not grant access, they limit it. The IAM policy is the only one that says "yes."

    SCPs do NOT affect the management account

    This is a critical security gap. The management account is exempt from SCPs. Never run workloads in the management account - use it only for organization management.

    Permission Boundaries prevent privilege escalation

    Without boundaries, anyone with iam:CreateRole can create a new role with AdministratorAccess and assume it. Boundaries cap the permissions of any newly created role.

    Key Takeaways

    $ cat SUMMARY.md
    1.SCPs restrict, IAM policies grant, boundaries cap - they serve different purposes
    2.Effective permission = intersection of all three layers (all must allow)
    3.September 2025 SCP update added full IAM language support (conditions, resource ARNs, NotResource)
    4.SCPs do NOT affect the management account - never run workloads there
    5.Use boundaries when delegating IAM administration to prevent escalation
    IAMOrganizationsAccess ControlMulti-Account

    Need Architecture Guidance?

    These comparisons are a starting point. Every architecture is different. Contact us for tailored AWS security assessments and architectural guidance.

    All ComparisonsGet in Touch