Service Control Policies (SCPs) are IAM-like policies to manage permissions in AWS Organizations. SCPs restrict the actions allowed for accounts within the organization making each one of them compliant with your guidelines.
SCPs are not meant to grant permissions; you should consider them as advanced Deny/Allow list mechanisms that restrict the set of actions allowed within an organization. The only way to grant permissions to IAM Users or Roles is by attaching IAM permissions policies.
Service Control Policies can be used in a Defense in Depth strategy adding an additional layer of protection to mitigate unknown vulnerabilities on complex infrastructures. From one perspective, Organizations policies like SCPs could be considered unnecessary but according to AWS’s strategy, redundant security controls in different layers are the key to minimize attacks if a vulnerability in another layer is exploited.
At the account level, IAM Permissions + IAM Permission Boundaries overlap with SCP. You could even consider SCP unnecessary because the boundaries are already defined using IAM Permission Boundaries. But what if a user is able to perform a permission escalation exploiting a vulnerability in your policies?
Let’s assume you granted specific permissions to Billy with an IAM user. Billy can now manage multiple EC2 instances in Oregon. Billy is creating a new EC2 instance and, by exploiting a vulnerability that you haven’t noticed before, he is able to create a new Role and attach the PowerUser policy to it. Billy is violating several of AWS Organizations’ guidelines, and he is breaking the least privilege principle introducing a serious flaw, but your security controls are ineffective because they are applied to the user assigned to Billy, not to other IAM users/roles within the account. A Service Control Policy could prevent Billy from violating the guidelines and best practices. In effect, the policy acts as a redundant layer; with