'AccessDeniedException' When Rekognition Fails Due to Service Control Policy (SCP) Explicit Deny

 

'AccessDeniedException' When Rekognition Fails Due to Service Control Policy (SCP) Explicit Deny

Why AdministratorAccess cannot override organization guardrails in AWS





Problem

Your application calls DetectLabels in Amazon Rekognition.

The IAM role has:

  • AdministratorAccess
  • Explicit rekognition:* permissions
  • Verified trust relationship

Yet the request fails with:

AccessDeniedException: User is not authorized to perform: rekognition:DetectLabels

IAM looks correct.
The role is admin.
Still denied.


Clarifying the Issue

If your account is part of AWS Organizations, an Organization-level Service Control Policy (SCP) may be blocking Rekognition.

An SCP operates above IAM.

It does not grant permissions.
It defines the maximum permissions allowed within an account.

If an SCP includes:

  • An explicit Deny on rekognition:*
  • A deny on specific regions
  • A deny using NotAction that excludes Rekognition

Then the request will fail — regardless of the role’s permissions.

In AWS policy evaluation logic:

📌 Explicit Deny (including SCP) overrides all Allow statements.

AdministratorAccess cannot override an SCP.


Why It Matters

This failure is especially common in:

  • Enterprise environments
  • Sandbox accounts
  • Guardrail-heavy production environments
  • Multi-account Organizations

Engineers waste hours debugging IAM roles that are functioning exactly as configured.

The real block lives above the account.

This is not a Rekognition issue.
It is an Organization guardrail issue.


Key Terms

Service Control Policy (SCP) – Organization-level policy that limits permissions for all accounts in an Organizational Unit.

Explicit Deny – A policy statement that blocks an action regardless of other allows.

Organizational Unit (OU) – Logical grouping of AWS accounts within Organizations.

Maximum Permission Boundary (SCP context) – The ceiling of allowed actions defined by the Organization.


Steps at a Glance

  1. Confirm the account is part of AWS Organizations.
  2. Check whether an SCP is attached to the account or OU.
  3. Search for rekognition:* deny statements.
  4. Inspect NotAction patterns that exclude Rekognition.
  5. Review region-based deny conditions.
  6. Validate findings in CloudTrail policy evaluation details.

Detailed Steps

Step 1: Confirm Organization Membership

Navigate to:

AWS Organizations → Accounts

If the account is under an Organizational Unit, SCPs may apply.

Standalone accounts are not affected by SCPs.


Step 2: Inspect Attached SCPs

Go to:

Organizations → Policies → Service Control Policies

Identify:

  • Policies attached directly to the account
  • Policies attached to the parent OU

SCPs cascade downward.

Important: SCPs apply to all identities within a member account — including the account’s Root user. Logging in as Root in a member account does not bypass an SCP. Only the Root user of the Organization’s Management (Payer) account is exempt from SCP restrictions.


Step 3: Search for Explicit Deny Statements

Look for patterns such as:

{
  "Effect": "Deny",
  "Action": "rekognition:*",
  "Resource": "*"
}

An explicit deny on Rekognition immediately blocks the service, regardless of IAM role permissions.


Step 4: Inspect NotAction Allowlist Models

Some Organizations use a deny-everything-except model:

{
  "Effect": "Deny",
  "NotAction": [
    "ec2:*",
    "s3:*"
  ],
  "Resource": "*"
}

If Rekognition is not included in the allowed service list, it is effectively denied.

This pattern often blocks newly introduced services.


Step 5: Review Region-Based Deny Conditions

Many Organizations restrict services to approved regions.

Example:

{
  "Effect": "Deny",
  "Action": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": [
        "us-east-1",
        "us-west-2"
      ]
    }
  }
}

If Rekognition is invoked in a non-approved region, it will fail.

Rekognition must operate in a region permitted by the SCP.


Step 6: Validate in CloudTrail

Open CloudTrail → Event History → Filter by rekognition.amazonaws.com.

Inspect the failed event and review:

  • errorCode
  • policyEvaluationDecisionDetails

If the denial originates from an SCP, CloudTrail will reflect that evaluation context.

This confirms the issue is organizational — not IAM misconfiguration.


Pro Tips

  • SCPs do not grant permissions — they only restrict them.
  • AdministratorAccess inside an account does not bypass an SCP.
  • SCPs apply to the Root user of a member account.
  • NotAction-based deny models are easy to misread and often block newly introduced services.
  • Always check OU-level SCPs, not just account-level attachments.
  • When onboarding new AWS services, confirm they are permitted at the Organization layer first.

If IAM looks correct but everything still fails, look upward.


Conclusion

AccessDeniedException in Rekognition with correct IAM permissions often signals an SCP restriction.

When operating inside AWS Organizations, the true permission boundary lives above the account.

IAM roles operate within that ceiling.

If Rekognition is not allowed at the Organization layer, no role configuration can fix it.

This is an organizational boundary issue — not a Rekognition issue.


Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.

Comments

Popular posts from this blog

The New ChatGPT Reason Feature: What It Is and Why You Should Use It

Insight: The Great Minimal OS Showdown—DietPi vs Raspberry Pi OS Lite

Raspberry Pi Connect vs. RealVNC: A Comprehensive Comparison