Cloud Rule Inheritance and Exemption
Even though cloud rules can be applied to OUs, they only affect accounts attached to projects. In the case of cloud rules, OUs help you manage multiple projects by enabling access management at a high level. When a cloud rule is attached to an OU, it is inherited by all of that OU's descendant OUs and projects. This creates a single point where you can easily manage the cloud rule, and it will be added/updated for all descendant accounts.
Where Can You Apply Cloud Rules?
Cloud rules can be applied on any OU or project in your organization. Applying a cloud rule to an OU is a good way to ensure all accounts in a particular part of your organization receive the rule through inheritance.
For information about applying cloud rules to OUs, see Managing Cloud Rules on Resources.
How are Cloud Rules Inherited?
Cloud rules applied to a parent OU are inherited by all descendant OUs and projects.
A single resource can receive the same cloud rule from multiple sources. Cloud rules can be applied locally, inherited from a parent, applied by a cloud access role, or applied by an enforcement.
To see which cloud rules are applied to an OU or project, navigate to that resource's details page and select the Cloud Management tab. Here, you can see if the rule was applied locally, through inheritance, or by an enforcement.
How do Exemptions Work for Cloud Rules?
Cloud rule exemptions can happen in a few different places, which changes how they behave.
- Exempted at an OU. All resources are blocked from being inherited by descendant accounts.
- Exempted on a project. All resources are blocked from being inherited by attached accounts.
- Exempted on a cloud access role. Only the IAM policies attached to the cloud rule are blocked. All other cloud rule components are still applied (webhooks, CloudFormation templates, AMIs, SCPs, service catalog portfolios, etc.).
A single resource can receive the same cloud rule from multiple sources. If a resource receives the same cloud rule from multiple sources, it must be individually exempted from each source to fully remove the cloud rule from the resource.
Exemptions are only visible on the resource they are applied on. Because the exemption prevents the cloud rule from being inherited, descendant resources have no knowledge of the rule and will not show that they are exempt from it on their details page. To reapply a cloud rule, you must do so on the same resource you created the exemption.
To see which cloud rules are affecting an OU or project, navigate to that resource's details page and select the Cloud Management tab. Here, you can see the origin of the rule and whether it is applied or exempted. However, this list only shows exemptions that are applied directly to this resource. Cloud rules exempted on a parent OU will not show on descendant OUs or projects.
Cloud rules applied by enforcements cannot be exempted.
For information about requesting an exemption, see Requesting Cloud Rule Exemptions.
How do Cloud Rules Affect Cloud Access Roles?
Cloud access roles can carry cloud rules with them, applying the rules to descendant OUs and projects. When a cloud access role is applied to an OU, it picks up all locally applied and inherited cloud rules on that OU. As a cloud access role is inherited down the organization, it does not pick up more cloud rules. Cloud access roles only become associated with cloud rules that are applied to the same OU as they are.
To see which cloud rules are being carried by a cloud access role, navigate to the cloud access role's details page. Here, you can see which rules the cloud access role is carrying and whether they are applied locally or through inheritance.
Inherited cloud access roles are not affected by local cloud rules. It is possible that a cloud rule can be applied to an OU, but not the cloud access role on that same OU. This means that an admin cloud access role applied at the top OU level will not be affected by more granular, restrictive cloud rules further down the structure, ensuring they have full access rights to projects no matter how many OUs they pass through.
For example, if you have a financial team that needs access to the AWS Billing Console for all the AWS accounts in an organization, you can create a finance cloud access role on your top-level OU. You only have to create the cloud access role once, and the team has the same access across all AWS accounts.