As mentioned earlier, the intention behind SCPs is similar to that of IAM permissions boundaries, that is, to limit the perimeter of what is allowed to be done at an account level, an OU level, or an organization level.
SCPs offer central control over that maximum set of permissions that accounts in an OU or across your entire organization can have. However, it is important to understand that SCPs do not grant any permission to IAM entities (users and roles) in your accounts; they can only limit what the entities are allowed to do.
You can attach multiple SCPs (up to five) at any one time to the same organization, OU, or account. SCPs add up from the root structure down to each OU until the account level. Remember how SCPs work: they limit the scope of the possible permissions entities can have at any level. Thus, to determine what account IAM entities (roles or users) are entitled to do, you must travel down the organization tree and look at the intersection of all the permissions defined by the SCPs at each level until you reach the desired account in the organization hierarchy. An SCP at a lower level cannot add permissions that were denied by an SCP at the level above.
Consider the organizational structure, with a root account and BUs, as shown in Figure 3.6:
Figure 3.6 – Example organizational structure
Now, consider that the permissions defined in the SCPs attached at each level are assigned, as illustrated in Figure 3.7, to the root structure (permissions A, B, and C), to OU BU1 (permissions C and D), and to OU Prod (permissions C, E, F, and G):
Figure 3.7: OU permissions intersection
Then, the maximum permissions allowed to IAM entities (users or roles) in your account located in the Prod OU is the intersection of all the permissions provided by the succession of SCPs from the root down to the OU to which the account belongs—that is, permission C. So, even though your account belongs to the Prod OU, which is entitled to permissions C, E, F, and G, permission C is the only one allowed as permissions E, F, and G are not allowed by the two parent levels.
How to determine an account’s maximum permissions from SCPs
If an entity belonging to your account need access to a given AWS service, access to that service must be authorized by every SCP at every organization level above the account (from the root down to the OU to which the account belongs).
In practice, SCPs are expressed in two ways, either as deny lists or as allow lists. The most common way of using SCPs is as deny lists, mostly because they are low maintenance. Whenever AWS adds a new service, if you manage SCPs as allow lists, you will need to update them to be able to use the new service. If you use SCPs as deny lists, this won’t be the case unless you want to block the new service. Deny lists are also usually shorter and, as such, fit more easily within the maximum possible size of an SCP (5,120 bytes at the time of this writing, but do check the AWS documentation for the latest value).
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
