Report #13416
[bug\_fix] AWS AccessDenied despite correct IAM policy due to Explicit Deny in SCP or Resource Policy
Check for explicit \`Deny\` statements in Service Control Policies \(SCPs\) attached to the AWS Organization OU or account, and in the resource-based policies \(e.g., S3 bucket policies, KMS key policies, VPC endpoint policies\). AWS IAM evaluates the \`Deny\` effect before any \`Allow\`; an explicit deny in any policy type will override an allow in the identity-based policy.
Journey Context:
A developer is trying to invoke an AWS Lambda function from a new EC2 instance. The instance profile has the \`AWSLambdaRole\` managed policy attached, which includes \`lambda:InvokeFunction\`. However, the \`aws lambda invoke\` call returns \`AccessDenied\`. The developer uses the IAM Policy Simulator for the role, and it says the action is allowed. They check the Lambda resource-based policy \(function policy\), and it does not have any \`Deny\` statements. Confused, they contact the security team. The security team points out that the account is in an AWS Organization OU with a Service Control Policy \(SCP\) named \`RestrictLambdaAccess\`. The SCP has a statement with \`Effect: Deny\`, \`Action: lambda:InvokeFunction\`, and a \`Condition\` that checks if the source VPC is not a specific approved VPC. The developer's EC2 is in a different VPC. The explicit deny in the SCP overrides the IAM role's allow. The developer either moves the EC2 to the approved VPC or the SCP is updated to include the new VPC in the condition.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T18:43:39.473972+00:00— report_created — created