There are a few more things to keep in mind about SCPs:

• At the time of writing, you can only have a single root inside an organization (it's created automatically for you when you create an organization).
• For obvious reasons, the master account is not affected by any SCPs that are attached to it. You may also notice that it's technically possible to place the master account in an OU; again, it will be unaffected by any SCPs that have been attached to that OU.
• Since the master account is unaffected by SCPs, it's a good idea to leave it as empty as possible and to not create any resources in it. Use child AWS accounts instead so that you can apply fine-grained controls to them.
• SCPs are required on each OU and account but shouldn't be considered the only form of access control for your AWS accounts. Apply IAM where appropriate.
• When we're creating our policy, we have to specify a --type parameter. At the time of publishing, AWS only supports one variant of OCP: SERVICE_CONTROL_POLICY.
• As much as possible, follow the principle of least privilege. You want to give your AWS accounts access to only the services they need. This helps you mitigate damage caused by misclicks, programming errors, or compromised accounts.
• In the long run, you may find it advantageous to not assign controls at the root level. Instead, you may be better off adding all accounts to an OU and applying your controls to the OU instead.
• Your policies can take a whitelisting or blacklisting approach. In this recipe, we've used a whitelist approach, but you may prefer to allow your OUs and accounts to use all services except those you explicitly disallow. You should choose one of these approaches and stick with it, as mixing the two will cause you lots of confusion down the road.
• Unlike IAM policies, you can't specify conditions in SCP documents and Resource must be *.