# Authorization policies in AWS Organizations
Authorization policies in AWS Organizations enable you to centrally configure and manage access for principals and resources in your member accounts. How those policies affect the organizational units (OUs) and accounts that you apply them to depends on the type of authorization policy that you apply.
There are two different types of authorization policies in AWS Organizations: service control policies (SCPs) and resource control policies (RCPs).
**Topics**
+ [Differences between SCPs and RCPs](#understanding-scps-and-rcps)
+ [Using SCPs and RCPs](#when-to-use-scps-and-rcps)
+ [Service control policies](orgs_manage_policies_scps.md)
+ [Resource control policies](orgs_manage_policies_rcps.md)
## Differences between SCPs and RCPs
SCPs are principal-centric controls. SCPs create a permissions guardrail, or set limits, on the maximum permissions available to principals in your member accounts. You can use an SCP when you want to centrally enforce consistent access controls on principals in your organization. This can include specifying which services your IAM users and IAM roles can access, which resources they can access, or the conditions under which they can make requests (for example, from specific regions or networks).
RCPs are resource-centric controls. RCPs create a permissions guardrail, or set limits, on the maximum permissions available for resources in your member accounts. You can use an RCP when you want to centrally enforce consistent access controls across resources in your organization. This can restrict access to your resources so that they can only be accessed by identities that belong to your organization, or specifying the conditions under which identities external to your organization can access your resources.
Some controls can be applied in a similar way through SCPs and RCPs. For example, you might want to [prevent your users from uploading unencrypted objects to S3](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_s3.html#example-s3-1) which can be written as an SCP to enforce a control on the actions that your principals can take on your S3 buckets. This control can also be written as an RCP to require encryption whenever any principal uploads objects to your S3 bucket. The second option might be preferred if your bucket allows principals outside of your organization, such as third-party vendors, to upload objects to your S3 bucket. However, some controls can only be implemented in an RCP, and some controls can only be implemented in an SCP. For more information, see [General use cases for SCPs and RCPs](#scps-rcps-general-use-cases).
## Using SCPs and RCPs
SCPs and RCPs are independent controls. You can choose to enable only SCPs or RCPs, or use both policy types together. By using both SCPs and RCPs, you can create a [data perimeter](https://aws.amazon.com/identity/data-perimeters-on-aws/) around your identities and your resources.
SCPs provide an ability to control which resources your identities can access. For example, you may want to allow your identities to access resources in your AWS organization. However, you may want to prevent your identities from accessing resources outside of your organization. You can enforce this control using SCPs.
RCPs provide an ability to control which identities can access your resources. For example, you may want to allow identities in your organization to be able to access resources in your organization. However, you may want to prevent identities external to your organization from accessing your resources. You can enforce this control using RCPs. RCPs provide an ability to impact the effective permissions for principals external to your organization that are accessing your resources. SCPs can only impact the effective permissions for principals within your AWS organization.
### General use cases for SCPs and RCPs
The following table details general use cases for using an SCP and RCPs
****
| | **Impacts** |
| --- |--- |
| **Use case** | **Policy type** | **Your identities** | **External identities** | **Your Resources** | **External resources (target of the request)** |
| --- |--- |--- |--- |--- |--- |
| Restrict which services or actions your identities can use | SCP | X | | X | X |
| Restrict which resources your identities can access | SCP | X | | X | X |
| Enforce requirements on how your identities can access resources | SCP | X | | X | X |
| Restrict which identities can access your resources | RCP | X | X | X | |
| Protect sensitive resources in your organization | RCP | X | X | X | |
| Enforce requirements on how your resources can be accessed | RCP | X | X | X | |
# Service control policies (SCPs)
Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for the IAM users and IAM roles in your organization. SCPs help you to ensure your accounts stay within your organization’s access control guidelines. SCPs are available only in an organization that has [all features enabled](orgs_manage_org_support-all-features.md). SCPs aren't available if your organization has enabled only the consolidated billing features. For instructions on enabling SCPs, see [Enabling a policy type](enable-policy-type.md).
SCPs do not grant permissions to the IAM users and IAM roles in your organization. No permissions are granted by an SCP. An SCP defines a permission guardrail, or sets limits, on the actions that the IAM users and IAM roles in your organization can perform. To grant permissions, the administrator must attach policies to control access, such as identity-based policies that are attached to IAM users and IAM roles, and resource-based policies that are attached to the resources in your accounts. For more information, see [Identity-based policies and resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) in the *IAM User Guide*.
The [effective permissions](#scp-effects-on-permissions) are the logical intersection between what is allowed by the SCP and [resource control policies (RCPs)](orgs_manage_policies_rcps.md) and what is allowed by the identity-based and resource-based policies.
**SCPs don't affect users or roles in the management account**
SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization. This also means that SCPs apply to member accounts that are designated as delegated administrators.
****Topics on this page****
+ [Testing effects of SCPs](#scp-warning-testing-effect)
+ [Maximum size of SCPs](#scp-size-limit)
+ [Attaching SCPs to different levels in the organization](#scp-about-inheritance)
+ [SCP effects on permissions](#scp-effects-on-permissions)
+ [Using access data to improve SCPs](#data-from-iam)
+ [Tasks and entities not restricted by SCPs](#not-restricted-by-scp)
+ [SCP evaluation](orgs_manage_policies_scps_evaluation.md)
+ [SCP syntax](orgs_manage_policies_scps_syntax.md)
+ [Service control policy examples](orgs_manage_policies_scps_examples.md)
+ [Troubleshooting service control policies (SCPs) with AWS Organizations](org_troubleshoot_policies.md)
## Testing effects of SCPs
AWS strongly recommends that you don't attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an OU that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don't inadvertently lock users out of key services. One way to determine whether a service is used by an account is to examine the [service last accessed data in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Another way is to [use AWS CloudTrail to log service usage at the API level](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html).
**Note**
You should not remove the **FullAWSAccess** policy unless you modify or replace it with a separate policy with allowed actions, otherwise all AWS actions from member accounts will fail.
## Maximum size of SCPs
All characters in your SCP count against its [maximum size](orgs_reference_limits.md#min-max-values). The examples in this guide show the SCPs formatted with extra white space to improve their readability. However, to save space if your policy size approaches the maximum size, you can delete any white space, such as space characters and line breaks that are outside quotation marks.
**Tip**
Use the visual editor to build your SCP. It automatically removes extra white space.
## Attaching SCPs to different levels in the organization
For a detailed explanation of how SCPs work, see [SCP evaluation](orgs_manage_policies_scps_evaluation.md).
## SCP effects on permissions
SCPs are similar to AWS Identity and Access Management permission policies and use almost the same syntax. However, an SCP never grants permissions. Instead, SCPs are access controls that specify the maximum available permissions for the IAM users and IAM roles in your organization. For more information, see [Policy Evaluation Logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
+ SCPs ***affect only IAM users and roles*** that are managed by accounts that are part of the organization. SCPs don't affect resource-based policies directly. They also don't affect users or roles from accounts outside the organization. For example, consider an Amazon S3 bucket that's owned by account A in an organization. The bucket policy (a resource-based policy) grants access to users from account B outside the organization. Account A has an SCP attached. That SCP doesn't apply to those outside users in account B. The SCP applies only to users that are managed by account A in the organization.
+ An SCP restricts permissions for IAM users and roles in member accounts, including the member account's root user. Any account has only those permissions permitted by ***every*** parent above it. If a permission is blocked at any level above the account, either implicitly (by not being included in an `Allow` policy statement) or explicitly (by being included in a `Deny` policy statement), a user or role in the affected account can't use that permission, even if the account administrator attaches the `AdministratorAccess` IAM policy with \$1/\$1 permissions to the user.
+ SCPs affect only ***member*** accounts in the organization. They have no effect on users or roles in the management account. This also means that SCPs apply to member accounts that are designated as delegated administrators. For more information, see [Best practices for the management account](orgs_best-practices_mgmt-acct.md).
+ Users and roles must still be granted permissions with appropriate IAM permission policies. A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions.
+ If a user or role has an IAM permission policy that grants access to an action that is also allowed by the applicable SCPs, the user or role can perform that action.
+ If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can't perform that action.
+ SCPs affect all users and roles in attached accounts, ***including the root user***. The only exceptions are those described in [Tasks and entities not restricted by SCPs](#not-restricted-by-scp).
+ SCPs ***do not ***affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs.
+ When you disable the SCP policy type in a root, all SCPs are automatically detached from all AWS Organizations entities in that root. AWS Organizations entities include organizational units, organizations, and accounts. If you reenable SCPs in a root, that root reverts to only the default `FullAWSAccess` policy automatically attached to all entities in the root. Any attachments of SCPs to AWS Organizations entities from before SCPs were disabled are lost and aren't automatically recoverable, although you can manually reattach them.
+ If both a permissions boundary (an advanced IAM feature) and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action.
## Using access data to improve SCPs
When signed in with management account credentials, you can view [service last accessed data](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) for an AWS Organizations entity or policy in the **AWS Organizations** section of the IAM console. You can also use the AWS Command Line Interface (AWS CLI) or AWS API in IAM to retrieve service last accessed data. This data includes information about which allowed services that the IAM users and roles in an AWS Organizations account last attempted to access and when. You can use this information to identify unused permissions so that you can refine your SCPs to better adhere to the principle of [least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).
For example, you might have a [deny list SCP](orgs_manage_policies_scps_evaluation.md#how_scps_deny) that prohibits access to three AWS services. All services that aren't listed in the SCP's `Deny` statement are allowed. The service last accessed data in IAM tells you which AWS services are allowed by the SCP but are never used. With that information, you can update the SCP to deny access to services that you don't need.
For more information, see the following topics in the *IAM User Guide*:
+ [Viewing Organizations Service Last Accessed Data for Organizations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html)
+ [ Using Data to Refine Permissions for an Organizational Unit](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-example-scenarios.html#access_policies_access-advisor-reduce-permissions-orgs)
## Tasks and entities not restricted by SCPs
You ***can't*** use SCPs to restrict the following tasks:
+ Any action performed by the management account
+ Any action performed using permissions that are attached to a service-linked role
+ Register for the Enterprise support plan as the root user
+ Provide trusted signer functionality for CloudFront private content
+ Configure reverse DNS for an Amazon Lightsail email server and Amazon EC2 instance as the root user
+ Tasks on some AWS-related services:
+ Alexa Top Sites
+ Alexa Web Information Service
+ Amazon Mechanical Turk
+ Amazon Product Marketing API
# SCP evaluation
**Note**
The information in this section does ***not*** apply to management policy types, including backup policies, tag policies, chat applications policies, or AI services opt-out policies. For more information, see [Understanding management policy inheritance](orgs_manage_policies_inheritance_mgmt.md).
As you can attach multiple service control policies (SCPs) at different levels in AWS Organizations, understanding how SCPs are evaluated can help you write SCPs that yield the right outcome.
**Topics**
+ [How SCPs work with Allow](#how_scps_allow)
+ [How SCPs work with Deny](#how_scps_deny)
+ [Strategy for using SCPs](#strategy_using_scps)
## How SCPs work with Allow
For a permission to be **allowed** for a specific account, there must be an **explicit `Allow` statement** at every level from the root through each OU in the direct path to the account (including the target account itself). This is why when you enable SCPs, AWS Organizations attaches an AWS managed SCP policy named [FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) which allows all services and actions. If this policy is removed and not replaced at any level of the organization, all OUs and accounts under that level would be blocked from taking any actions.
For example, let's walk through the scenario shown in figures 1 and 2. For a permission or a service to be allowed at Account B, a SCP that allows the permission or service should be attached to Root, the Production OU, and to Account B itself.
SCP evaluation follows a deny-by-default model, meaning that any permissions not explicitly allowed in the SCPs are denied. If an allow statement is not present in the SCPs at any of the levels such as Root, Production OU or Account B, the access is denied.
![\[Example organization structure with an Allow statement attached at Root, Production OU and Account B\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_allow_1.png)
*Figure 1: Example organization structure with an `Allow` statement attached at Root, Production OU and Account B*
![\[Example organization structure with an Allow statement missing at Production OU and its impact on Account B\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_allow_2.png)
*Figure 2: Example organization structure with an `Allow` statement missing at Production OU and its impact on Account B*
## How SCPs work with Deny
For a permission to be **denied** for a specific account, **any SCP** from the root through each OU in the direct path to the account (including the target account itself) can deny that permission.
For example, let’s say there is an SCP attached to the Production OU that has an explicit `Deny` statement specified for a given service. There also happens to be another SCP attached to Root and to Account B that explicitly allows access to that same service, as shown in Figure 3. As a result, both Account A and Account B will be denied access to the service as a deny policy attached to any level in the organization is evaluated for all the OUs and member accounts underneath it.
![\[Example organization structure with a Deny statement attached at Production OU and its impact on Account B\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_deny_1.png)
*Figure 3: Example organization structure with an `Deny` statement attached at Production OU and its impact on Account B*
## Strategy for using SCPs
While writing SCPs you can make use of a combination of `Allow` and `Deny` statements to allow intended actions and services in your organization. `Deny` statements are a powerful way to implement restrictions that should be true for a broader part of your organization or OUs because when they are applied at the root or the OU-level they affect all the accounts under it.
**Tip**
You can use [service last accessed data](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) in [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) to update your SCPs to restrict access to only the AWS services that you need. For more information, see [Viewing Organizations Service Last Accessed Data for Organizations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) in the *IAM User Guide.*
AWS Organizations attaches an AWS managed SCP named [https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) to every root, OU and account when it's created. This policy allows all services and actions. You can replace **FullAWSAccess** with a policy allowing only a set of services so that new AWS services are not allowed unless they are explicitly allowed by updating SCPs. For example, if your organization wants to only allow the use of a subset of services in your environment, you can use an `Allow` statement to only allow specific services. You can choose to either replace **FullAWSAccess** at the root level or at every level. If you attach a service-specific allowlist SCP at the root, it automatically applies to all OUs and accounts beneath it—meaning a single root-level policy determines the effective service allowlist across the entire organization as shown in scenario 7. Alternatively, you can remove and replace **FullAWSAccess** at each OU and account, allowing you to implement more granular service allowlists that differ between organizational units or individual accounts.
Note: Relying solely on allow statements and the implicit deny-by-default model can lead to unintended access, because broader or overlapping Allow statements can override more restrictive ones.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"cloudwatch:*",
"organizations:*"
],
"Resource": "*"
}
]
}
```
------
A policy combining the two statements might look like the following example, which prevents member accounts from leaving the organization and allows use of desired AWS services. The organization administrator can detach the **FullAWSAccess** policy and attach this one instead.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"cloudwatch:*",
"organizations:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action":"organizations:LeaveOrganization",
"Resource": "*"
}
]
}
```
------
To demonstrate how multiple service control policies (SCPs) can be applied in an AWS Organization, consider the following organizational structure and scenarios.
### Scenario 1: Impact of Deny policies
This scenario demonstrates how deny policies at higher levels in the organization impact all accounts below. When the Sandbox OU has both "Full AWS access" and "Deny S3 access" policies, and Account B has a "Deny EC2 access" policy, the result is that Account B cannot access S3 (from the OU-level deny) and EC2 (from its account-level deny). Account A does not have S3 access (from the OU-level deny).
![\[Scenario 1: Impact of Deny policies\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_scenario_1.png)
### Scenario 2: Allow policies must exist at every level
This scenario shows how allow policies work in SCPs. For a service to be accessible, there must be an explicit allow at every level from the root down to the account. Here, as the Sandbox OU has an "Allow EC2 access" policy, which only explicitly allows EC2 service access, Account A and B will only have EC2 access.
![\[Scenario 2: Allow policies must exist at every level\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_scenario_2.png)
### Scenario 3: Impact of missing an Allow statement at the root-level
Missing an "Allow" statement at the root-level in an SCP is a critical misconfiguration that will effectively block all access to AWS services and actions for all member accounts in your organization.
![\[Scenario 3: Impact of missing an Allow statement at the root-level\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_scenario_3.png)
### Scenario 4: Layered Deny statements and resulting permissions
This scenario demonstrates a two-level deep OU structure. Both the Root and the Workloads OU have "Full AWS access", the Test OU has "Full AWS access" with "Deny EC2 access", and the Production OU has "Full AWS access". As a result, Account D has all service access except EC2 and Account E and F have all service access.
![\[Scenario 4: Layered Deny statements and resulting permissions\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_scenario_4.png)
### Scenario 5: Allow policies at the OU-level to restrict service access
This scenario shows how allow policies can be used to restrict access to specific services. The Test OU has an "Allow EC2 access" policy, which means only EC2 services are permitted for Account D. The Production OU maintains "Full AWS access", so Accounts E and F have access to all services. This demonstrates how more restrictive allow policies can be implemented at the OU-level while maintaining a broader allow at the root-level.
![\[Scenario 5: Allow policies at the OU-level to restrict service access\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_scenario_5.png)
### Scenario 6: Root-level deny affects all accounts regardless of lower-level allows
This scenario demonstrates that a deny policy at the root-level affects all accounts in the organization, regardless of allow policies at lower levels. The root has both "Full AWS access" and "Deny S3 access" policies. Even though the Test OU has an "Allow S3 access" policy, the root-level S3 deny takes precedence. Account D has no service access because the Test OU only allows S3 access, but S3 is denied at the root-level. Accounts E and F can access other services except for S3 because of the explicit deny at the root-level.
![\[Scenario 6: Root-level deny affects all accounts regardless of lower-level allows\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_scenario_6.png)
### Scenario 7: Root level custom allow policies to restrict OU-level access
This scenario demonstrates how SCPs with explicit service allow lists function when applied at root level within an AWS Organizations. At the organization root level, two custom "Service Allow" SCPs are attached that explicitly permits access to a limited set of AWS services — SCP\$11 allows IAM and Amazon EC2, SCP\$12 allows Amazon S3 and Amazon CloudWatch. At the organizational unit (OU) level, the default FullAWSAccess policy remains attached. However, due intersection behaviour, accounts A and B under these OUs can only access the services explicitly permitted by the root-level SCP. The more restrictive root policy takes precedence, effectively limiting access to only IAM, EC2, S3, and CloudWatch services, regardless of the broader permissions granted at lower organizational levels.
![\[Scenario 7: Root level custom allow policies to restrict OU-level access\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/scp_scenario_7.png)
# SCP syntax
Service control policies (SCPs) use a similar syntax to that used by AWS Identity and Access Management (IAM) permission policies and [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) (like Amazon S3 bucket policies). For more information about IAM policies and their syntax, see [Overview of IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
An SCP is a plaintext file that is structured according to the rules of [JSON](http://json.org). It uses the elements that are described in this topic.
**Note**
All characters in your SCP count against its [maximum size](orgs_reference_limits.md#min-max-values). The examples in this guide show the SCPs formatted with extra white space to improve their readability. However, to save space if your policy size approaches the maximum size, you can delete any white space, such as space characters and line breaks that are outside quotation marks.
For general information about SCPs, see [Service control policies (SCPs)](orgs_manage_policies_scps.md).
## Elements summary
The following table summarizes the policy elements that you can use in SCPs. Some policy elements are available only in SCPs that deny actions. The **Supported effects** column lists the effect type that you can use with each policy element in SCPs.
| Element | Purpose | Supported effects |
| --- | --- | --- |
| [Action](#scp-syntax-action) | Specifies AWS service and actions that the SCP allows or denies. | `Allow`, `Deny` |
| [Effect](#scp-syntax-effect) | Defines whether the SCP statement [allows](orgs_manage_policies_scps_evaluation.md#how_scps_allow) or [denies](orgs_manage_policies_scps_evaluation.md#how_scps_deny) access to the IAM users and roles in an account. | `Allow`, `Deny` |
| [Statement](#scp-syntax-statement) | Serves as the container for policy elements. You can have multiple statements in SCPs. | `Allow`, `Deny` |
| [Statement ID (Sid)](#scp-syntax-sid) | (Optional) Provides a friendly name for the statement. | `Allow`, `Deny` |
| [Version](#scp-syntax-version) | Specifies the language syntax rules to use for processing the policy. | `Allow`, `Deny` |
| [Condition](#scp-syntax-condition) | Specifies conditions for when the statement is in effect. | `Allow,``Deny` |
| [NotAction](#scp-syntax-action) | Specifies AWS service and actions that are exempt from the SCP. Used instead of the `Action` element. | `Allow,``Deny` |
| [Resource](#scp-syntax-resource) | Specifies the AWS resources that the SCP applies to. | `Allow,``Deny` |
| [NotResource](#scp-syntax-resource) | Specifies AWS resources that are exempt from the SCP. Used instead of the Resource element. | `Allow`, `Deny` |
The following sections provide more information and examples of how policy elements are used in SCPs.
**Topics**
+ [Elements summary](#scp-elements-table)
+ [`Action` and `NotAction` elements](#scp-syntax-action)
+ [`Condition` element](#scp-syntax-condition)
+ [`Effect` element](#scp-syntax-effect)
+ [`Resource`and `NotResource` element](#scp-syntax-resource)
+ [`Statement` element](#scp-syntax-statement)
+ [Statement ID (`Sid`) element](#scp-syntax-sid)
+ [`Version` element](#scp-syntax-version)
+ [Unsupported elements](#scp-syntax-unsupported)
## `Action` and `NotAction` elements
The value for the `Action` or `NotAction` element is a list (a JSON array) of strings that identify AWS services and actions that are allowed or denied by the statement.
Each string consists of the abbreviation for the service (such as "s3", "ec2", "iam", or "organizations"), in all lowercase, followed by a colon and then an action from that service. The actions and notactions are case-insensitive. Generally, they are all entered with each word starting with an uppercase letter and the rest lowercase. For example: `"s3:ListAllMyBuckets"`.
You also can use wildcard characters such as asterisk (\$1) or question mark (?) in an SCP:
+ Use an asterisk (\$1) as a wildcard to match multiple actions that share part of a name. The value `"s3:*"` means all actions in the Amazon S3 service. The value `"ec2:Describe*"` matches only the EC2 actions that begin with "Describe".
+ Use the question mark (?) wildcard to match a single character.
For a list of all the services and the actions that they support in both AWS Organizations SCPs and IAM permission policies, see [Actions, Resources, and Condition Keys for AWS Services](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actionsconditions.html) in the *IAM User Guide*.
For more information, see [IAM JSON Policy Elements: Action](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_action.html) and [IAM JSON Policy Elements: NotAction](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html) in the *IAM User Guide*.
### Example of `Action` element
The following example shows an SCP with a statement that permits account administrators to delegate describe, start, stop, and terminate permissions for EC2 instances in the account. This is an example of an [allow list](orgs_manage_policies_scps_evaluation.md#how_scps_allow), and is useful when the default `Allow *` policies are ***not*** attached so that, by default, permissions are implicitly denied. If the default `Allow *` policy is still attached to the root, OU, or account to which the following policy is attached, the policy has no effect.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs",
"ec2:DescribeSecurityGroups", "ec2:DescribeAvailabilityZones", "ec2:RunInstances",
"ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances"
],
"Resource": "*"
}
}
```
------
The following example shows how you can [deny access](orgs_manage_policies_scps_evaluation.md#how_scps_deny) to services that you don't want used in attached accounts. It assumes that the default `"Allow *"` SCPs are still attached to all OUs and the root. This example policy prevents the account administrators in attached accounts from delegating any permissions for the IAM, Amazon EC2, and Amazon RDS services. Any action from other services can be delegated as long as there isn't another attached policy that denies them.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": [ "iam:*", "ec2:*", "rds:*" ],
"Resource": "*"
}
}
```
------
### Example of `NotAction` element
The following example shows how you can use a `NotAction` element to exclude AWS services from the effect of the policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LimitActionsInRegion",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "us-west-1"
}
}
}
]
}
```
------
With this statement, affected accounts are limited to taking actions in the specified AWS Region, except when using IAM actions.
## `Condition` element
You can specify a `Condition` element in allow and deny statements in an SCP.
The following example shows how to use a condition element with an allow statement in an SCP to permit specific principals to access AWS services.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowServicesForSpecificPrincipal",
"Effect":"Allow",
"Action":[
"ec2:*",
"s3:*",
"rds:*",
"lambda:*",
"cloudformation:*",
"iam:*",
"cloudwatch:*"
],
"Resource":"*",
"Condition":{
"StringEquals":{
"aws:PrincipalArn":[
"arn:aws:iam::123456789012:role/specific-role"
]
}
}
}
]
}
```
The following example shows how to use a condition element with a deny statement in an SCP to restrict access to any operations outside the `eu-central-1` and `eu-west-1` Regions, except for actions in the specified services.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideEU",
"Effect": "Deny",
"NotAction": [
"cloudfront:*",
"iam:*",
"route53:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-central-1",
"eu-west-1"
]
}
}
}
]
}
```
------
For more information, see [IAM JSON Policy Elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
## `Effect` element
Each statement must contain one `Effect` element. The value can be either `Allow` or `Deny`. It affects any actions listed in the same statement.
For more information, see [IAM JSON Policy Elements: Effect](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_effect.html) in the *IAM User Guide*.
### `"Effect": "Allow"`
The following example shows an SCP with a statement that contains an `Effect` element with a value of `Allow` that permits account users to perform actions for the Amazon S3 service. This example is useful in an organization that uses the [allow list strategy](orgs_manage_policies_scps_evaluation.md#how_scps_allow) (where the default `FullAWSAccess` policies are all detached so that permissions are implicitly denied by default). The result is that the statement [allows](orgs_manage_policies_scps_evaluation.md#how_scps_allow) the Amazon S3 permissions for any attached accounts:
```
{
"Statement": {
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
}
```
Even though this statement uses the same `Allow` value keyword as an IAM permission policy, in an SCP it doesn't actually grant a user permission to do anything. Instead, SCPs act as filters that specify the maximum permissions for the accounts in an organization, organizational unit (OU), or account. In the preceding example, even if a user in the account had the `AdministratorAccess` managed policy attached, this SCP limits ***all*** users in affected accounts to only Amazon S3 actions.
### `"Effect": "Deny"`
In a statement where the `Effect` element has a value of `Deny`, you can also restrict access to specific resources or define conditions for when SCPs are in effect.
The following shows an example of how to use a condition key in a deny statement.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:InstanceType": "t2.micro"
}
}
}
}
```
------
This statement in an SCP sets a guardrail to prevent affected accounts (where the SCP is attached to the account itself or to the organization root or OU that contains the account), from launching Amazon EC2 instances if the Amazon EC2 instance isn't set to `t2.micro`. Even if an IAM policy that allows this action is attached to the account, the guardrail created by the SCP prevents it.
## `Resource`and `NotResource` element
In statements where the `Effect` element has a value of `Allow`, you can specify only "\$1" in the `Resource` element of an SCP. You can't specify individual resource Amazon Resource Names (ARNs).
You can use wildcard characters such as asterisk (\$1) or question mark (?) in the resource element:
+ Use an asterisk (\$1) as a wildcard to match multiple actions that share part of a name.
+ Use the question mark (?) wildcard to match a single character.
In statements where the `Effect` element has a value of `Deny`, you *can* specify individual ARNs, as shown in the following example.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAccessToAdminRole",
"Effect": "Deny",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole",
"iam:DeleteRolePermissionsBoundary",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy",
"iam:UpdateAssumeRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": [
"arn:aws:iam::*:role/role-to-deny"
]
}
]
}
```
------
This SCP restricts IAM users and roles in affected accounts from making changes to a common administrative IAM role created in all accounts in your organization.
The following example shows how to use a `NotResource` element to exclude specific Amazon Bedrock models from the effect of the policy.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"Statement1",
"Effect":"Deny",
"Action":[
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"NotResource":[
"arn:aws:bedrock:*::foundation-model/model-to-permit"
]
}
]
}
```
For more information, see [IAM JSON Policy Elements: Resource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) in the *IAM User Guide*.
## `Statement` element
An SCP consists of one or more `Statement` elements. You can have only one `Statement` keyword in a policy, but the value can be a JSON array of statements (surrounded by [ ] characters).
The following example shows a single statement that consists of single `Effect`, `Action`, and `Resource` elements.
```
"Statement": {
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
```
The following example includes two statements as an array list inside one `Statement` element. The first statement allows all actions, while the second denies any EC2 actions. The result is that an administrator in the account can delegate any permission *except* those from Amazon Elastic Compute Cloud (Amazon EC2).
```
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*"
}
]
```
For more information, see [IAM JSON Policy Elements: Statement](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_statement.html) in the *IAM User Guide*.
## Statement ID (`Sid`) element
The `Sid` is an optional identifier that you provide for the policy statement. You can assign a `Sid` value to each statement in a statement array. The following example SCP shows a sample `Sid` statement.
```
{
"Statement": {
"Sid": "AllowsAllActions",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
}
```
For more information, see [IAM JSON Policy Elements: Id](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_id.html) in the *IAM User Guide*.
## `Version` element
Every SCP must include a `Version` element with the value `"2012-10-17"`. This is the same version value as the most recent version of IAM permission policies.
For more information, see [IAM JSON Policy Elements: Version](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html) in the *IAM User Guide*.
## Unsupported elements
The following elements aren't supported in SCPs:
+ `NotPrincipal`
+ `Principal`
# Service control policy examples
The example [service control policies (SCPs)](orgs_manage_policies_scps.md) displayed in this topic are for information purposes only.
**Before using these examples**
Before you use these example SCPs in your organization, consider the following:
[Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) are meant to be used as coarse-grained guardrails, and they don't directly grant access. The administrator must still attach [identity-based or resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to IAM principals or resources in your accounts to actually grant permissions. The effective permissions are the logical intersection between the Service control policy/Resource control policy and an identity policy or the Service control policy/Resource control policy and a resource policy. You can get more details about SCP effects on permissions [here](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions).
A [Service control policy (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), when attached to an organization, organization unit or an account offers a central control over the maximum available permissions for all accounts in your organization, organization unit or an account. As an SCP can be applied at multiple levels in an organization, understanding how [SCPs are evaluated](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) can help you write SCPs that yield the right outcome.
The service control policies in this repository are shown as examples. You should not attach SCPs without thoroughly testing the impact that the policy has on accounts. Once you have a policy ready that you would like to implement, we recommend testing in a separate organization or OU that can be represent your production environment. Once tested, you should deploy changes to more specific OUs and then slowly deploy the changes to broader and broader OUs over time.
The SCP examples in this repository use a [deny list strategy](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html#strategy_using_scps), which means that you also need a [FullAWSAccess](https://console.aws.amazon.com/organizations/?#/policies/p-FullAWSAccess) policy or other policy that allows access attached to your organization entities to allow actions. You still also need to grant appropriate permissions to your principals by using identity-based or resource-based policies.
**Tip**
You can use [service last accessed data](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) in [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) to update your SCPs to restrict access to only the AWS services that you need. For more information, see [Viewing Organizations Service Last Accessed Data for Organizations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) in the *IAM User Guide.*
## GitHub repository
+ [Service control policy examples](https://github.com/aws-samples/service-control-policy-examples) - This GitHub repository contains example policies to get started or mature your usage of AWS SCPs
# Troubleshooting service control policies (SCPs) with AWS Organizations
Use the information here to help you diagnose and fix common errors found in service control policies (SCPs).
Service control policies (SCPs) in AWS Organizations are similar to IAM policies and share a common syntax. This syntax begins with the rules of [JavaScript Object Notation](http://www.json.org) (JSON). JSON describes an *object* with name and value pairs that make up the object. The [IAM policy grammar](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies-grammar.html) builds on that by defining what names and values have meaning for, and are understood by, the AWS services that use policies to grant permissions.
AWS Organizations uses a subset of the IAM syntax and grammar. For details, see [SCP syntax](orgs_manage_policies_scps_syntax.md).
**Topics**
+ [More than one policy object](#morethanonepolicyblock)
+ [More than one statement element](#morethanonestatement)
+ [Policy document exceeds maximum size](#scptoolong)
## More than one policy object
An SCP must consist of one and only one JSON object. You denote an object by placing \$1 \$1 braces around it. Although you can nest other objects within a JSON object by embedding additional \$1 \$1 braces within the outer pair, a policy can contain only one outermost pair of \$1 \$1 braces. The following example is ***incorrect*** because it contains two objects at the top level (called out in *red*):
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
```
------
You can, however, meet the intention of the preceding example with the use of correct policy grammar. Instead of including two complete policy objects, each with its own `Statement` element, you can combine the two blocks into a single `Statement` element. The `Statement` element has an array of two objects as its value, as shown in the following example:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
```
This example cannot be further compressed into a `Statement` with one element because the two elements have different effects. Generally, you can combine statements only when the `Effect` and `Resource` elements in each statement are identical.
## More than one statement element
This error might at first appear to be a variation on the error in the preceding section. However, syntactically it's a different type of error. In the following example, there is only one policy object as denoted by a single pair of \$1 \$1 braces at the top level. However, that object contains two `Statement` elements within it.
An SCP must contain only one `Statement` element, consisting of the name (`Statement`) appearing to the left of a colon, followed by its value on the right. The value of a `Statement` element must be an object, denoted by \$1 \$1 braces, containing one `Effect` element, one `Action` element, and one `Resource` element. The following example is ***incorrect*** because it contains two `Statement` elements in the policy object:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
```
------
Because a value object can be an array of multiple value objects, you can solve this problem by combining the two `Statement` elements into one element with an object array, as shown in the following example:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource":"*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
```
------
The value of the `Statement` element is an object array. The array in the example consists of two objects, each of which is a correct value for a `Statement` element. Each object in the array is separated by commas.
## Policy document exceeds maximum size
The maximum size of an SCP document is 5,120 characters. This maximum size includes all characters, including white space. To reduce the size of your SCP, you can remove all white space characters (such as spaces and line breaks) that are outside quotation marks.
**Note**
If you save the policy by using the AWS Management Console, extra white space between JSON elements and outside of quotation marks is removed and not counted. If you save the policy using an SDK operation or the AWS CLI, then the policy is saved exactly as you provided and no automatic removal of characters occurs.
# Resource control policies (RCPs)
**Note**
**Service control policies (SCPs) and resource control policies (RCPs)**
Use an SCP when you need to limit permissions of IAM principals within your organization's member accounts.
Use an RCP when you need to restrict IAM principals that are external to your organization accounts making requests to access resources within your organization’s member accounts.
For more information, see [Understanding SCPs and RCPs](orgs_manage_policies_authorization_policies.md).
Resource control policies (RCPs) are a type of organization policy that you can use to manage permissions in your organization. RCPs offer central control over the maximum available permissions for resources in your organization. RCPs help you to ensure resources in your accounts stay within your organization’s access control guidelines. RCPs are available only in an organization that has [all features enabled](orgs_manage_org_support-all-features.md). RCPs aren't available if your organization has enabled only the consolidated billing features. For instructions on enabling RCPs, see [Enabling a policy type](enable-policy-type.md).
RCPs alone are not sufficient in granting permissions to the resources in your organization. No permissions are granted by an RCP. An RCP defines a permissions guardrail, or sets limits, on the actions that identities can take on resources in your organizations. The administrator must still attach identity-based policies to IAM users or roles, or resource-based policies to resources in your accounts to actually grant permissions. For more information, see [Identity-based policies and resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) in the *IAM User Guide*.
The [effective permissions](#rcp-effects-on-permissions) are the logical intersection between what is allowed by the RCPs and [service control policies (SCPs)](orgs_manage_policies_scps.md) and what is allowed by the identity-based and resource-based policies.
**RCPs don't affect resources in the management account**
RCPs don't affect resources in the management account. They only affect resources in the member accounts within your organization. This also means that RCPs apply to member accounts that are designated as delegated administrators.
****Topics on this page****
+ [List of AWS services that support RCPs](#rcp-supported-services)
+ [Testing effects of RCPs](#rcp-warning-testing-effect)
+ [Maximum size of RCPs](#rcp-size-limit)
+ [Attaching RCPs to different levels in the organization](#rcp-about-inheritance)
+ [RCP effects on permissions](#rcp-effects-on-permissions)
+ [Resources and entities not restricted by RCPs](#actions-not-restricted-by-rcps)
+ [RCP evaluation](orgs_manage_policies_rcps_evaluation.md)
+ [RCP syntax](orgs_manage_policies_rcps_syntax.md)
+ [Resource control policy examples](orgs_manage_policies_rcps_examples.md)
## List of AWS services that support RCPs
RCPs apply to actions for the following AWS services:
+ [Amazon S3](https://docs.aws.amazon.com/s3)
+ [AWS Security Token Service](https://docs.aws.amazon.com/iam)
+ [AWS Key Management Service](https://docs.aws.amazon.com/kms)
+ [Amazon SQS](https://docs.aws.amazon.com/sqs)
+ [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager)
+ [Amazon Cognito](https://docs.aws.amazon.com/cognito)
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/cloudwatch)
+ [Amazon DynamoDB](https://docs.aws.amazon.com/dynamodb)
+ [Amazon Elastic Container Registry](https://docs.aws.amazon.com/ecr)
+ [Amazon OpenSearch Serverless](https://docs.aws.amazon.com/opensearch-service)
## Testing effects of RCPs
AWS strongly recommends that you don't attach RCPs to the root of your organization without thoroughly testing the impact that the policy has on resources in your accounts. You can begin by attaching RCPs to individual test accounts, moving them up to OUs lower in the hierarchy, and then working your way up through the organization structure as needed. One way to determine impact is to review AWS CloudTrail logs for Access Denied errors.
## Maximum size of RCPs
All characters in your RCP count against its [maximum size](orgs_reference_limits.md#min-max-values). The examples in this guide show the RCPs formatted with extra white space to improve their readability. However, to save space if your policy size approaches the maximum size, you can delete any white space, such as space characters and line breaks that are outside quotation marks.
**Tip**
Use the visual editor to build your RCP. It automatically removes extra white space.
## Attaching RCPs to different levels in the organization
You can attach RCPs directly to individual accounts, OUs, or the organization root. For a detailed explanation of how RCPs work, see [RCP evaluation](orgs_manage_policies_rcps_evaluation.md).
## RCP effects on permissions
RCPs are a type of AWS Identity and Access Management (IAM) policy. They are most closely related to [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). However, an RCP never grants permissions. Instead, RCPs are access controls that specify the maximum available permissions for resources in your organization. For more information, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
+ RCPs apply to resources for a subset of AWS services. For more information, see [List of AWS services that support RCPs](#rcp-supported-services).
+ RCPs ***affect only resources*** that are managed by accounts that are part of the organization which has attached the RCPs. They don't affect resources from accounts outside the organization. For example, consider an Amazon S3 bucket that's owned by Account A in an organization. The bucket policy (a resource-based policy) grants access to users from Account B outside the organization. Account A has an RCP attached. That RCP applies to the S3 bucket in Account A even when accessed by users from Account B. However, that RCP does not apply to resources in Account B when accessed by users in Account A.
+ An RCP restricts permissions for resources in member accounts. Any resource in an account has only those permissions permitted by ***every*** parent above it. If a permission is blocked at any level above the account, a resource in the affected account does not have that permission, even if the resource owner attaches a resource-based policy that allows full access to any user.
+ RCPs apply to the resources that are authorized as part of an operation request. These resources can be found in the “Resource type” column of the Action table in the [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html#actions_table). If a resource is specified in the "Resource type" column, then the RCPs of the calling principal account are applied. For example, `s3:GetObject` authorizes the object resource. Whenever a `GetObject` request is made, an applicable RCP will apply to determine whether the requesting principal can invoke the `GetObject` operation. An *applicable RCP* is an RCP that has been attached to an account, to an organizational unit (OU), or to the root of the organization that owns the resource being accessed.
+ RCPs affect only resources in ***member*** accounts in the organization. They have no effect on resources in the management account. This also means that RCPs apply to member accounts that are designated as delegated administrators. For more information, see [Best practices for the management account](orgs_best-practices_mgmt-acct.md).
+ When a principal makes a request to access a resource within an account that has an attached RCP (a resource with an applicable RCP), the RCP is included in the policy evaluation logic to determine whether the principal is allowed or denied access.
+ RCPs impact the effective permissions of principals trying to access resources in a member account with an applicable RCP, regardless of whether the principals belong to the same organizations or not. This includes root users. The exception is when principals are service-linked roles because RCPs do not apply to calls made by service-linked roles. Service-linked roles enable AWS services to perform necessary actions on your behalf and can't be restricted by RCPs.
+ Users and roles must still be granted permissions with appropriate IAM permission policies, including identity-based and resource-based policies. A user or role without any IAM permission policies has no access, even if an applicable RCP allows all services, all actions, and all resources.
## Resources and entities not restricted by RCPs
You ***can't*** use RCPs to restrict the following:
+ Any action on resources in the management account.
+ RCPs do not impact the effective permissions of any service-linked role. Service-linked roles are a unique type of IAM role that is linked directly to an AWS service and include all the permissions that the service requires to call other AWS services on your behalf. The permissions of service-linked roles can't be restricted by RCPs. RCPs also do not impact AWS services' ability to assume a service-linked role; that is, the service-linked role's trust policy is also not impacted by RCPs.
+ RCPs do not apply to [AWS managed keys for AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk). AWS managed keys are created, managed, and used on your behalf by an AWS service. You cannot change or manage their permissions.
+ RCPs do not impact following permissions:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)
# RCP evaluation
**Note**
The information in this section does ***not*** apply to management policy types, including backup policies, tag policies, chat applications policies, or AI services opt-out policies. For more information, see [Understanding management policy inheritance](orgs_manage_policies_inheritance_mgmt.md).
As you can attach multiple resource control policies (RCPs) at different levels in AWS Organizations, understanding how RCPs are evaluated can help you write RCPs that yield the right outcome.
## Strategy for using RCPs
The `RCPFullAWSAccess` policy is an AWS managed policy. It is automatically attached to the organization root, every OU, and every account in your organization, when you enable resource control policies (RCPs). You cannot detach this policy. This default RCP allows all principals and actions access to pass through RCP evaluation, meaning until you start creating and attaching RCPs, all your existing IAM permissions continue to operate as they did. This AWS managed policy does not grant access.
You can make use of `Deny` statements to block access to resources in your organization. For a permission to be **denied** for a resource in a specific account, **any RCP** from the root through each OU in the direct path to the account (including the target account itself) can deny that permission.
`Deny` statements are a powerful way to implement restrictions that should be true for a broader part of your organization. For example, you can attach a policy to help prevent identities external to your organization from accessing your resources root level, and that will be effective for all accounts in the organization. AWS strongly recommends that you don't attach RCPs to the root of your organization without thoroughly testing the impact that the policy has on resources in your accounts. For more information, see [Testing effects of RCPs](orgs_manage_policies_rcps.md#rcp-warning-testing-effect).
In Figure 1, there is an RCP attached to the Production OU that has an explicit `Deny` statement specified for a given service. As a result, both Account A and Account B will be denied access to the service as a deny policy attached to any level in the organization is evaluated for all the OUs and member accounts underneath it.
![\[Example organization structure with a Deny statement attached at Production OU and its impact on Account A and Account B\]](http://docs.aws.amazon.com/organizations/latest/userguide/images/rcp_deny_1.png)
*Figure 1: Example organization structure with an `Deny` statement attached at Production OU and its impact on Account A and Account B*
# RCP syntax
Resource control policies (RCPs) use a similar syntax to that used by [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based). For more information about IAM policies and their syntax, see [Overview of IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
An RCP is structured according to the rules of [JSON](http://json.org). It uses the elements that are described in this topic.
**Note**
All characters in your RCP count against its [maximum size](orgs_reference_limits.md#min-max-values). The examples in this guide show the RCPs formatted with extra white space to improve their readability. However, to save space if your policy size approaches the maximum size, you can delete any white space, such as space characters and line breaks that are outside quotation marks.
For general information about RCPs, see [Resource control policies (RCPs)](orgs_manage_policies_rcps.md).
## Elements summary
The following table summarizes the policy elements that you can use in RCPs.
**Note**
**The effect of `Allow` is only supported for the `RCPFullAWSAccess` policy**
The effect of `Allow` is only supported for the `RCPFullAWSAccess` policy. This policy is automatically attached to the organization root, every OU, and every account in your organization, when you enable resource control policies (RCPs). You cannot detach this policy. This default RCP allows all principals and actions access to pass through RCP evaluation, meaning until you start creating and attaching RCPs, all your existing IAM permissions continue to operate as they did. This does not grant access.
| Element | Purpose |
| --- | --- |
| [Version](#rcp-syntax-version) | Specifies the language syntax rules to use for processing the policy. |
| [Statement](#rcp-syntax-statement) | Serves as the container for policy elements. You can have multiple statements in RCPs. |
| [Statement ID (Sid)](#rcp-syntax-sid) | (Optional) Provides a friendly name for the statement. |
| [Effect](#rcp-syntax-effect) | Defines whether the RCP statement denies access to the resources in an account. |
| [Principal](#rcp-syntax-principal) | Specifies the principal that is allowed or denied access to resources in an account. |
| [Action](#rcp-syntax-action) | Specifies AWS service and actions that the RCP allows or denies. |
| [Resource](#rcp-syntax-resource) | Specifies the AWS resources that the RCP applies to. |
| [NotResource](#rcp-syntax-resource) | Specifies the AWS resources that are exempt from the RCP. Used instead of the `Resource` element. |
| [Condition](#rcp-syntax-condition) | Specifies conditions for when the statement is in effect. |
**Topics**
+ [Elements summary](#rcp-elements-table)
+ [`Version` element](#rcp-syntax-version)
+ [`Statement` element](#rcp-syntax-statement)
+ [Statement ID (`Sid`) element](#rcp-syntax-sid)
+ [`Effect` element](#rcp-syntax-effect)
+ [`Principal` element](#rcp-syntax-principal)
+ [`Action` element](#rcp-syntax-action)
+ [`Resource` and `NotResource` elements](#rcp-syntax-resource)
+ [`Condition` element](#rcp-syntax-condition)
+ [Unsupported elements](#rcp-syntax-unsupported)
## `Version` element
Every RCP must include a `Version` element with the value **"2012-10-17"**. This is the same version value as the most recent version of IAM permission policies.
For more information, see [IAM JSON Policy Elements: Version](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html) in the *IAM User Guide*.
## `Statement` element
An RCP consists of one or more `Statement` elements. You can have only one `Statement` keyword in a policy, but the value can be a JSON array of statements (surrounded by [ ] characters).
The following example shows a single statement that consists of single `Effect`, `Principal`, `Action`, and `Resource` elements.
```
{
"Statement": {
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutBucketPublicAccessBlock",
"Resource": "*"
}
}
```
For more information, see [IAM JSON Policy Elements: Statement](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_statement.html) in the *IAM User Guide*.
## Statement ID (`Sid`) element
The `Sid` is an optional identifier that you provide for the policy statement. You can assign a `Sid` value to each statement in a statement array. The following example RCP shows a sample `Sid` statement.
```
{
"Statement": {
"Sid": "DenyBPAConfigurations",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutBucketPublicAccessBlock",
"Resource": "*"
}
}
```
For more information, see [IAM JSON Policy Elements: Sid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_sid.html) in the *IAM User Guide*.
## `Effect` element
Each statement must contain one `Effect` element. Using the value of `Deny` in the `Effect` element, you can restrict access to specific resources or define conditions for when RCPs are in effect. For RCPs that you create, the value must be `Deny`. For more information, see [RCP evaluation](orgs_manage_policies_rcps_evaluation.md) and [IAM JSON Policy Elements: Effect](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_effect.html) in the *IAM User Guide*.
## `Principal` element
Each statement must contain the `Principal` element. You can only specify “`*`” in the `Principal` element of an RCP. Use the `Conditions` element to restrict specific principals.
For more information, see [IAM JSON Policy Elements: Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in the *IAM User Guide*.
## `Action` element
Each statement must contain the `Action` element.
The value for the `Action` element is a string or list (a JSON array) of strings that identify AWS services and actions that are allowed or denied by the statement.
Each string consists of the abbreviation for the service (such as "s3", "sqs", or "sts"), in all lowercase, followed by a colon and then an action from that service. Generally, they are all entered with each word starting with an uppercase letter and the rest lowercase. For example: `"s3:ListAllMyBuckets"`.
You also can use wildcard characters such as asterisk (\$1) or question mark (?) in an RCP:
+ Use an asterisk (\$1) as a wildcard to match multiple actions that share part of a name. The value `"s3:*"` means all actions in the Amazon S3 service. The value `"sts:Get*"` matches only the AWS STS actions that begin with "Get".
+ Use the question mark (?) wildcard to match a single character.
**Note**
**Wildcards (\$1) and question marks (?) can be used anywhere in the action name**
You cannot use "\$1" in the Action element of a customer managed RCP and have to specify the abbreviation for the service (such as "s3", "sqs", or "sts") you want to restrict access to.
For a list of the services that support RCPs, see [List of AWS services that support RCPs](orgs_manage_policies_rcps.md#rcp-supported-services). For a list of the actions an AWS service supports, see [Actions, Resources, and Condition Keys for AWS Services](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html.html) in the *Service Authorization Reference*.
For more information, see [IAM JSON Policy Elements: Action](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_action.html) in the *IAM User Guide*.
## `Resource` and `NotResource` elements
Each statement must contain the `Resource` or `NotResource` element.
You can use wildcard characters such as asterisk (\$1) or question mark (?) in the resource element:
+ Use an asterisk (\$1) as a wildcard to match multiple resources that share part of a name.
+ Use the question mark (?) wildcard to match a single character.
For more information, see [IAM JSON Policy Elements: Resource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) and see [IAM JSON Policy Elements: NotResource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html) in the *IAM User Guide*.
## `Condition` element
You can specify a `Condition` element in deny statements in an RCP.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
------
This RCP denies access to Amazon S3 operations and resources unless the request occurs over secure transport (the request was sent over TLS).
For more information, see [IAM JSON Policy Elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
## Unsupported elements
The following elements are not supported in RCPs:
+ `NotPrincipal`
+ `NotAction`
# Resource control policy examples
The example [resource control policies (RCPs)](orgs_manage_policies_rcps.md) displayed in this topic are for information purposes only.
**Before using these examples**
Before you use these example RCPs in your organization, consider the following:
[Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) are meant to be used as coarse-grained preventative controls, and they don't grant access. You must still attach [identity-based or resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to IAM principals or resources in your accounts to actually grant permissions. The effective permissions are the logical intersection between the SCP/RCP and an identity policy or the SCP/RCP and a resource policy. You can get more details about RCP effects on permissions [here](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#rcp-effects-on-permissions).
The resource control policies in this repository are shown as examples. You should not attach RCPs without thoroughly testing the impact that the policy has on resources in your accounts. Once you have a policy ready that you would like to implement, we recommend testing in a separate organization or OU that can represent your production environment. Once tested, you should deploy changes to test OUs and then progressively deploy the changes to a broader set of OUs over time.
The [RCPFullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/resource-control-policy/p-RCPFullAWSAccess) policy is automatically attached to the organization root, every OU, and every account in your organization, when you enable resource control policies (RCPs). This default RCP allows all principals and actions access to pass through RCP evaluation. You can make use of Deny statements to restrict access to resources in your organization. You still also need to grant appropriate permissions to your principals by using identity-based or resource-based policies.
A [Resource control policy (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html), when attached to an organization root, organization unit, or an account offers a central control over the maximum available permissions for resources in your organization, organization unit or an account. As an RCP can be applied at multiple levels in an organization, understanding how [RCPs are evaluated](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps_evaluation.html) can help you write RCPs that yield the expected outcome.
The example policies in this section demonstrate the implementation and use of RCPs. They're ***not*** intended to be interpreted as official AWS recommendations or best practices to be implemented exactly as shown. It is your responsibility to carefully test any policies for its suitability to solve the business requirements of your environment. Deny-based resource control policies can unintentionally limit or block your use of AWS services unless you add the necessary exceptions to the policy.
**Tip**
Before implementing RCPs, in addition to reviewing [AWS CloudTrail logs](https://aws.amazon.com/cloudtrail/), assessing [IAM Access Analyzer external access findings](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings-view.html#access-analyzer-findings-view-external) can help understand which resources are currently public or shared externally.
## GitHub repository
+ [Resource control policy examples](https://github.com/aws-samples/resource-control-policy-examples) - This GitHub repository contains example policies to get started or mature your usage of AWS RCPs