# 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.