# Prerequisites for using CloudFormation StackSets
StackSets extend the functionality of stacks, so you can create, update, or delete stacks across multiple accounts and Regions with a single operation.
Because StackSets perform stack operations across multiple accounts, before you can create your first StackSet you need the necessary permissions defined in your AWS accounts.
You can manage StackSets using *self-managed* or *service-managed* permissions.
+ For *self-managed* StackSets, you must create and manage IAM roles in each target account and AWS Region. For more information, see [Grant self-managed permissions](stacksets-prereqs-self-managed.md).
+ For *service-managed* StackSets, you don't need to manually create and manage IAM roles in each account; AWS handles the role creation and permissions for you. For more information, see [Activate trusted access](stacksets-orgs-activate-trusted-access.md).
**Topics**
+ [
# Prepare to perform StackSet operations in AWS Regions that are disabled by default
](stacksets-opt-in-regions.md)
+ [
# Grant self-managed permissions
](stacksets-prereqs-self-managed.md)
+ [
# Activate trusted access for StackSets with AWS Organizations
](stacksets-orgs-activate-trusted-access.md)
# Prepare to perform StackSet operations in AWS Regions that are disabled by default
AWS Regions introduced after March 20, 2019, such as Asia Pacific (Hong Kong), are disabled by default. You must enable these Regions for your account(s) before you can use them. For more information, see [Enable or disable AWS Regions in your account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) in the *AWS Account Management Reference Guide*.
To create a StackSet from a StackSet's administrator account (if using self-managed permissions) or organization's management account (if using service-managed permissions) in a Region that is disabled by default, you must first enable that Region for the administrator or management account.
For CloudFormation to successfully create or update a stack instance:
+ The target account must reside in a Region that's currently enabled for that target account.
+ The StackSet's administrator account or organization's management account must have the same Region enabled as the target account.
**Important**
Be aware that during StackSet operations, administrator and target accounts exchange metadata regarding the accounts themselves, in addition to the StackSet and StackSet instances involved.
In addition, if you disable a Region that contains an account in which StackSet instances reside, you are responsible for deleting any such instances or resources, if desired. In addition, be aware that metadata regarding the target account in the disabled Region will be retained in the administrator account.
# Grant self-managed permissions
This topic provides instructions on how to create the IAM service roles required by StackSets to deploy across accounts and AWS Regions with *self-managed* permissions. These roles are necessary to establish a trusted relationship between the account you're administering the StackSet from and the account you're deploying stack instances to. Using this permissions model, StackSets can deploy to any AWS account in which you have permissions to create an IAM role.
To use *service-managed* permissions, see [Activate trusted access](stacksets-orgs-activate-trusted-access.md) instead.
**Topics**
+ [
## Self-managed permissions overview
](#prereqs-self-managed-permissions)
+ [
## Give all users of the administrator account permissions to manage stacks in all target accounts
](#stacksets-prereqs-accountsetup)
+ [
## Set up advanced permissions options for StackSet operations
](#stacksets-prereqs-advanced-perms)
+ [
## Set up global keys to mitigate confused deputy problems
](#confused-deputy-mitigation)
## Self-managed permissions overview
Before you create a StackSet with self-managed permissions, you must have created IAM service roles in each account.
The basic steps are:
1. Determine which AWS account is the *administrator account*.
StackSets are created in this administrator account. A *target account* is the account in which you create individual stacks that belong to a StackSet.
1. Determine how you want to structure permissions for the StackSet.
The simplest (and most permissive) permissions configuration is where you give *all* users and groups in the administrator account the ability to create and update *all* the StackSets managed through that account. If you need finer-grained control, you can set up permissions to specify:
+ Which users and groups can perform StackSet operations in which target accounts.
+ Which resources users and groups can include in their StackSets.
+ Which StackSet operations specific users and groups can perform.
1. Create the necessary IAM service roles in your administrator and target accounts to define the permissions you want.
Specifically, the two required roles are:
+ **AWSCloudFormationStackSetAdministrationRole** – This role is deployed to the administrator account.
+ **AWSCloudFormationStackSetExecutionRole** – This role is deployed to all accounts where you create stack instances.
## Give all users of the administrator account permissions to manage stacks in all target accounts
This section shows you how to set up permissions to allow all users and groups of the administrator account to perform StackSet operations in all target accounts. It guides you through creating the required IAM service roles in your administrator and target accounts. Anyone in the administrator account can then create, update, or delete any stacks across any of the target accounts.
By structuring permissions in this manner, users don't pass an administration role when creating or updating a StackSet.
![\[Any user in the administrator account can then create any StackSet in target accounts after setting up a trust relationship.\]](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/images/stacksets_perms_master_target.png)
------
#### [ Administrator account ]
In the administrator account, create an IAM role named **AWSCloudFormationStackSetAdministrationRole**.
You can do this by creating a stack from the CloudFormation template available from [https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml](https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml).
**Example permissions policy**
The administration role created by the preceding template includes the following permissions policy.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole"
],
"Effect": "Allow"
}
]
}
```
**Example trust policy 1**
The preceding template also includes the following trust policy that grants the service permission to use the administration role and the permissions attached to the role.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
**Example trust policy 2**
To deploy stack instances into a target account that resides in a Region that's disabled by default, you must also include the regional service principal for that Region. Each Region that's disabled by default will have its own regional service principal.
The following example trust policy grants the service permission to use the administration role in the Asia Pacific (Hong Kong) Region (`ap-east-1`), a Region that's disabled by default.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"cloudformation.amazonaws.com",
"cloudformation.ap-east-1.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
For more information, see [Prepare to perform StackSet operations in AWS Regions that are disabled by default](stacksets-opt-in-regions.md). For a list of Region codes, see [Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints) in the *AWS General Reference Guide*.
------
#### [ Target accounts ]
In each target account, create a service role named **AWSCloudFormationStackSetExecutionRole** that trusts the administrator account. The role must have this exact name. You can do this by creating a stack from the CloudFormation template available from [https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml](https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml). When you use this template, you are prompted to provide the account ID of the administrator account with which your target account must have a trust relationship.
**Important**
Be aware that this template grants administrator access. After you use the template to create a target account execution role, you must scope the permissions in the policy statement to the types of resources that you are creating by using StackSets.
The target account service role requires permissions to perform any operations that are specified in your CloudFormation template. For example, if your template is creating an S3 bucket, then you need permissions to create new objects for S3. Your target account always needs full CloudFormation permissions, which include permissions to create, update, delete, and describe stacks.
**Example permissions policy 1**
The role created by this template enables the following policy on a target account.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
```
**Example permissions policy 2**
The following example shows a policy statement with the *minimum* permissions for StackSets to work. To create stacks in target accounts that use resources from services other than CloudFormation, you must add those service actions and resources to the **AWSCloudFormationStackSetExecutionRole** policy statement for each target account.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": "*"
}
]
}
```
**Example trust policy**
The following trust relationship is created by the template. The administrator account's ID is shown as *admin\$1account\$1id*.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole"
}
]
}
```
You can configure the trust relationship of an existing target account execution role to trust a specific role in the administrator account. If you delete the role in the administrator account, and create a new one to replace it, you must configure your target account trust relationships with the new administrator account role, represented by *admin\$1account\$1id* in the preceding example.
------
## Set up advanced permissions options for StackSet operations
If you require finer-grained control over the StackSets that users and groups are creating through a single administrator account, you can use IAM roles to specify:
+ Which users and groups can perform StackSet operations in which target accounts.
+ Which resources users and groups can include in their StackSets.
+ Which StackSet operations specific users and groups can perform.
### Control which users can perform StackSet operations in specific target accounts
Use customized administration roles to control which users and groups can perform StackSet operations in which target accounts. You might want to control which users of the administrator account can perform StackSet operations in which target accounts. To do this, you create a trust relationship between each target account and a specific customized administration role, rather than creating the **AWSCloudFormationStackSetAdministrationRole** service role in the administrator account itself. You then activate specific users and groups to use the customized administration role when performing StackSet operations in a specific target account.
For example, you can create Role A and Role B within your administrator account. You can give Role A permissions to access target account 1 through account 8. You can give Role B permissions to access target account 9 through account 16.
![\[A trust relationship between a customized administration role and target accounts that allows users to create a StackSet.\]](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/images/stacksets_perms_admin_target.png)
Setting up the necessary permissions involves defining a customized administration role, creating a service role for the target account, and granting users permission to pass the customized administration role when performing StackSet operations.
In general, here's how it works once you have the necessary permissions in place: When creating a StackSet, the user must specify a customized administration role. The user must have permission to pass the role to CloudFormation. In addition, the customized administration role must have a trust relationship with the target accounts specified for the StackSet. CloudFormation creates the StackSet and associates the customized administration role with it. When updating a StackSet, the user must explicitly specify a customized administration role, even if it's the same customized administration role used with this StackSet previously. CloudFormation uses that role to update the stack, subject to the requirements above.
------
#### [ Administrator account ]
**Example permissions policy**
For each StackSet, create a customized administration role with permissions to assume the target account execution role.
The target account execution role name must be the same in every target account. If the role name is **AWSCloudFormationStackSetExecutionRole**, StackSets uses it automatically when creating a StackSet. If you specify a custom role name, users must provide the execution role name when creating a StackSet.
Create an [IAM service role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) with a custom name and the following permissions policy. In the examples below, *custom\$1execution\$1role* refers to the execution role in the target accounts.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/custom_execution_role"
],
"Effect": "Allow"
}
]
}
```
To specify multiple accounts in a single statement, separate them with commas.
```
"Resource": [
"arn:aws:iam::target_account_id_1:role/custom_execution_role",
"arn:aws:iam::target_account_id_2:role/custom_execution_role"
]
```
You can specify all target accounts by using a wildcard (\$1) instead of an account ID.
```
"Resource": [
"arn:aws:iam::*:role/custom_execution_role"
]
```
**Example trust policy 1**
You must provide a trust policy for the service role to defines which IAM principals can assume the role.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
**Example trust policy 2**
To deploy stack instances into a target account that resides in a Region that's disabled by default, you must also include the regional service principal for that Region. Each Region that's disabled by default will have its own regional service principal.
The following example trust policy grants the service permission to use the administration role in the Asia Pacific (Hong Kong) Region (`ap-east-1`), a Region that's disabled by default.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"cloudformation.amazonaws.com",
"cloudformation.ap-east-1.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
For more information, see [Prepare to perform StackSet operations in AWS Regions that are disabled by default](stacksets-opt-in-regions.md). For a list of Region codes, see [Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints) in the *AWS General Reference Guide*.
**Example pass role policy**
You also need an IAM permissions policy for your IAM users that allows the user to pass the customized administration role when performing StackSet operations. For more information, see [Granting a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html).
In the example below, *customized\$1admin\$1role* refers to the administration role the user needs to pass.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/customized_admin_role"
}
]
}
```
------
#### [ Target accounts ]
In each target account, create a service role that trusts the customized administration role you want to use with this account.
The target account role requires permissions to perform any operations that are specified in your CloudFormation template. For example, if your template is creating an S3 bucket, then you need permissions to create new objects in S3. Your target account always needs full CloudFormation permissions, which include permissions to create, update, delete, and describe stacks.
The target account role name must be the same in every target account. If the role name is **AWSCloudFormationStackSetExecutionRole**, StackSets uses it automatically when creating a StackSet. If you specify a custom role name, users must provide the execution role name when creating a StackSet.
**Example permissions policy**
The following example shows a policy statement with the *minimum* permissions for StackSets to work. To create stacks in target accounts that use resources from services other than CloudFormation, you must add those service actions and resources to the permissions policy.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": "*"
}
]
}
```
**Example trust policy**
You must provide the following trust policy when you create the role to define the trust relationship.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/customized_admin_role"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
### Control the resources that users can include in specific StackSets
Use customized execution roles to control which stack resources users and groups can include in their StackSets. For example, you might want to set up a group that can only include Amazon S3-related resources in the StackSets they create, while another team can only include DynamoDB resources. To do this, you create a trust relationship between the customized administration role for each group and a customized execution role for each set of resources. The customized execution role defines which stack resources can be included in StackSets. The customized administration role resides in the administrator account, while the customized execution role resides in each target account in which you want to create StackSets using the defined resources. You then activate specific users and groups to use the customized administration role when performing StackSets operations.
For example you can create customized administration roles A, B, and C in the administrator account. Users and groups with permission to use Role A can create StackSets containing the stack resources specifically listed in customized execution role X, but not those in roles Y or Z, or resource not included in any execution role.
![\[A trust relationship between a custom admin role and custom execution role in target accounts, allowing users to create a StackSet.\]](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/images/stacksets_perms_admin_execution.png)
When updating a StackSet, the user must explicitly specify a customized administration role, even if it's the same customized administration role used with this StackSet previously. CloudFormation performs the update using the customized administration role specified, so long as the user has permissions to perform operations on that StackSet.
Similarly, the user can also specify a customized execution role. If they specify a customized execution role, CloudFormation uses that role to update the stack, subject to the requirements above. If the user doesn't specify a customized execution role, CloudFormation performs the update using the customized execution role previously associated with the StackSet, so long as the user has permissions to perform operations on that StackSet.
------
#### [ Administrator account ]
Create a customized administration role in your administrator account, as detailed in [Control which users can perform StackSet operations in specific target accounts](#stacksets-prereqs-multiadmin). Include a trust relationship between the customized administration role and the customized execution roles that you want it to use.
**Example permissions policy**
The following example is a permissions policy for both the **AWSCloudFormationStackSetExecutionRole** defined for the target account, in addition to a customized execution role.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt1487980684000",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole",
"arn:aws:iam::*:role/custom_execution_role"
]
}
]
}
```
------
#### [ Target accounts ]
In the target accounts in which you want to create your StackSets, create a customized execution role that grants permissions to the services and resources that you want users and groups to be able to include in the StackSets.
**Example permissions policy**
The following example provides the minimum permissions for StackSets, along with permission to create Amazon DynamoDB tables.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"dynamoDb:createTable"
],
"Resource": "*"
}
]
}
```
**Example trust policy**
You must provide the following trust policy when you create the role to define the trust relationship.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/customized_admin_role"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
### Set up permissions for specific StackSet operations
In addition, you can set up permissions for which user and groups can perform specific StackSet operations, such as creating, updating, or deleting StackSets or stack instances. For more information, see [Actions, resources, and condition keys for CloudFormation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html) in the *Service Authorization Reference*.
## Set up global keys to mitigate confused deputy problems
The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it shouldn't otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account.
We recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that CloudFormation StackSets gives another service to the resource. If you use both global condition context keys, the `aws:SourceAccount` value and the account in the `aws:SourceArn` value must use the same account ID when used in the same policy statement.
The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. If you don't know the full ARN of the resource or if you are specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcards (`*`) for the unknown portions of the ARN. For example, `arn:aws:cloudformation::123456789012:*`. Whenever possible, use `aws:SourceArn`, because it's more specific. Use `aws:SourceAccount` only when you can't determine the correct ARN or ARN pattern.
When StackSets assumes the **Administration** role in your **administrator** account, StackSets populates your **administrator** account ID and StackSets Amazon Resource Name (ARN). Therefore, you can define conditions for [global keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) `aws:SourceAccount` and `aws:SourceArn` in the trust relationships to prevent [confused deputy problems](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). The following example shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in StackSets to prevent the confused deputy problem.
------
#### [ Administrator account ]
**Example Global keys for `aws:SourceAccount` and `aws:SourceArn`**
When using StackSets, define the global keys `aws:SourceAccount` and `aws:SourceArn` in your **AWSCloudFormationStackSetAdministrationRole** trust policy to prevent confused deputy problems.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:cloudformation:*:111122223333:stackset/*"
}
}
}
]
}
```
**Example StackSets ARNs**
Specify your associated StackSets ARNs for finer control.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": [
"arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-1",
"arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-2"
]
}
}
}
]
}
```
------
# Activate trusted access for StackSets with AWS Organizations
This topic provides instructions on how to activate trusted access with AWS Organizations, which is required by StackSets to deploy across accounts and AWS Regions using *service-managed* permissions. To use *self-managed* permissions, see [Grant self-managed permissions](stacksets-prereqs-self-managed.md) instead.
Before you create a StackSet with service-managed permissions, you must first complete the following tasks:
+ [Enable all features](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) in AWS Organizations. With only consolidated billing features enabled, you can't create a StackSet with service-managed permissions.
+ Activate trusted access with AWS Organizations. This action allows CloudFormation to create a service-linked role in the management account. After trusted access is activated, when you create a StackSet with service-managed permissions, CloudFormation creates both the necessary service-linked role and a service role named `stacksets-exec-*` in the target (member) accounts.
With trusted access activated, the management account and delegated administrator accounts can create and manage service-managed StackSets for their organization.
To activate trusted access, you must be an administrator user in the management account. An *administrator user* is a user with full permissions to your AWS account. For more information, [Create an administrator user](https://docs.aws.amazon.com/accounts/latest/reference/getting-started-step4.html) in the *AWS Account Management Reference Guide*. For recommendations for protecting the security of the management account, see [Best practices for the management account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) in the *AWS Organizations User Guide*.
**To activate trusted access**
1. Sign in to AWS as an administrator of the management account and open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation).
1. From the navigation pane, choose **StackSets**. If trusted access is deactivated, a banner displays that prompts you to activate trusted access.
![\[Activate trusted access banner.\]](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/images/console-stacksets-enable-trusted-access-from-stacksets-list-new.png)
1. Choose **Activate trusted access**.
Trusted access is successfully activated when the following banner displays.
![\[Trusted access is successfully activated banner.\]](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/images/console-stackset-trusted-access-enabled-banner-new.png)
**Note**
Activate Organizations Access is the same as Enable Organizations Access, and Deactivate Organizations Access is the same as Disable Organizations Access. These terms have been updated based on marketing guidelines.
**To deactivate trusted access**
See [CloudFormation StackSets and AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) in the *AWS Organizations User Guide*.
Before you can deactivate trusted access with AWS Organizations, you must deregister all delegated administrators. For more information, see [Register a delegated administrator](stacksets-orgs-delegated-admin.md).
**Note**
For information about using API operations instead of the console to activate or deactivate trusted access, see:
[https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ActivateOrganizationsAccess.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ActivateOrganizationsAccess.html)
[https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DeactivateOrganizationsAccess.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DeactivateOrganizationsAccess.html)
[https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DescribeOrganizationsAccess.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DescribeOrganizationsAccess.html)
## Service-linked roles
The management account uses the **AWSServiceRoleForCloudFormationStackSetsOrgAdmin** service-linked role. You can modify or delete this role only if trusted access with AWS Organizations is deactivated.
Each target account uses a **AWSServiceRoleForCloudFormationStackSetsOrgMember** service-linked role. You can modify or delete this role only under two conditions: if trusted access with AWS Organizations is deactivated, or if the account is removed from the target organization or organizational unit (OU).
For more information, see [CloudFormation StackSets and AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) in the *AWS Organizations User Guide*.
# Register a delegated administrator member account
In addition to your organization's management account, member accounts with delegated administrator permissions can create and manage StackSets with service-managed permissions for the organization. StackSets with service-managed permissions are created in the management account, including StackSets created by delegated administrators. To be registered as a delegated administrator for your organization, your member account must be in the organization. For more information about joining an organization, see [Inviting an AWS account to join your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html).
Your organization can have up to five registered delegated administrators at one time. Delegated administrators can choose to deploy to all accounts in your organization or specific OUs. Trusted access with AWS Organizations must be activated before delegated administrators can deploy to accounts managed by Organizations. For more information, see [Activate trusted access for StackSets with AWS Organizations](stacksets-orgs-activate-trusted-access.md).
**Important**
Please be aware of the following:
Delegated administrators have full permissions to deploy to accounts in your organization. The management account can't limit delegated administrator permissions to deploy to specific OUs or to perform specific StackSet operations.
Make sure your delegated administrators have `organizations:ListDelegatedAdministrators` permissions to avoid any potential errors.
You can register delegated administrators for your organization in the following Regions: US East (Ohio), US East (N. Virginia), US West (N. California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), Israel (Tel Aviv), South America (São Paulo), AWS GovCloud (US-East), and AWS GovCloud (US-West).
You can register and deregister delegated administrators using the [CloudFormation console](https://console.aws.amazon.com/cloudformation/), [AWS CLI](https://aws.amazon.com/cli/), or [AWS SDKs](https://aws.amazon.com/developer/tools/).
## To register a delegated administrator (console)
1. Sign in to AWS as an administrator of the management account and open the CloudFormation console at [https://console.aws.amazon.com/cloudformation/](https://console.aws.amazon.com/cloudformation/).
1. From the navigation pane, choose **StackSets**.
1. Under **Delegated administrators**, choose **Register delegated administrator**.
1. In the **Register delegated administrator** dialog box, choose **Register delegated administrator**.
The success message indicates that the member account has successfully been registered as a delegated administrator.
## To deregister a delegated administrator (console)
1. Sign in to AWS as an administrator of the management account and open the CloudFormation console at [https://console.aws.amazon.com/](https://console.aws.amazon.com/).
1. From the navigation pane, choose **StackSets**.
1. Under **Delegated administrators**, select the account that you want to deregister, and then choose **Deregister**.
The success message indicates that the member account has successfully been deregistered as a delegated administrator.
You can register this account again at any time.
## To register a delegated administrator (AWS CLI)
1. Open the AWS CLI.
1. Run the `register-delegated-administrator` command.
```
$ aws organizations register-delegated-administrator \
--service-principal=member.org.stacksets.cloudformation.amazonaws.com \
--account-id="memberAccountId"
```
1. Run the `list-delegated-administrators` command to verify that the specified member account is successfully registered as a delegated administrator.
```
$ aws organizations list-delegated-administrators \
--service-principal=member.org.stacksets.cloudformation.amazonaws.com
```
## To deregister a delegated administrator (AWS CLI)
1. Open the AWS CLI.
1. Run the `deregister-delegated-administrator` command.
```
$ aws organizations deregister-delegated-administrator \
--service-principal=member.org.stacksets.cloudformation.amazonaws.com \
--account-id="memberAccountId"
```
1. Run the `list-delegated-administrators` command to verify that the specified member account is successfully deregistered as a delegated administrator.
```
$ aws organizations list-delegated-administrators \
--service-principal=member.org.stacksets.cloudformation.amazonaws.com
```
You can register this account again at any time.