'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
Denyonrekognition:* - A deny on specific regions
- A deny using
NotActionthat 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
- Confirm the account is part of AWS Organizations.
- Check whether an SCP is attached to the account or OU.
- Search for
rekognition:*deny statements. - Inspect
NotActionpatterns that exclude Rekognition. - Review region-based deny conditions.
- 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:
errorCodepolicyEvaluationDecisionDetails
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.
AdministratorAccessinside 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.
.jpeg)

Comments
Post a Comment