StackSets need cross-account permissions to deploy stacks into target accounts. CFN offers **two permission models**: **self-managed** (you build the IAM roles) and **service-managed** (AWS Organizations handles it). The choice has long-term governance implications, not just setup-cost. ## Self-managed permissions **You** create the IAM roles. Two roles required: | Role | Lives in | Trusted by | |------|----------|------------| | `AWSCloudFormationStackSetAdministrationRole` | Administrator account | CloudFormation service | | `AWSCloudFormationStackSetExecutionRole` | Each target account | The administrator account | The admin role assumes the execution role in each target account at deployment time. Permissions chain: ``` CFN service → admin role (in admin account) → execution role (in target account) → AWS APIs ``` **When to use**: any AWS environment without AWS Organizations, or when you need fine-grained control over which accounts can be targets. **Cost**: per-account setup (must deploy the execution role into every target account). AWS provides bootstrap CloudFormation templates that create the roles, but you have to apply them manually or via some other automation. ## Service-managed permissions CFN creates and manages the IAM service-linked roles for you. **Requires AWS Organizations with all features enabled** (consolidated-billing-only doesn't qualify). | Role | Lives in | Created by | |------|----------|------------| | `AWSServiceRoleForCloudFormationStackSetsOrgAdmin` | Management account | CFN automatically when trusted access is activated | | `AWSServiceRoleForCloudFormationStackSetsOrgMember` | Each target (member) account | CFN automatically when targeting that account | Plus a service role named `stacksets-exec-*` is created in target accounts. **When to use**: AWS Organizations is in place. This is the modern default for any multi-account AWS estate. **Major capability service-managed adds**: **automatic deployments to new accounts**. When an account joins an OU you've targeted, CFN automatically creates the stack instance. This is how landing-zone baselines stay applied as the org grows. ## Activating service-managed: trusted access One-time setup in the management account: 1. Sign in to management account 2. CloudFormation console → StackSets → Activate trusted access Behind the scenes, this: - Creates a service-linked role allowing CFN to act across the organization - Allows future StackSet deployments to provision required service-linked roles in target accounts **To deactivate**, you must first deregister all delegated administrators. There's no clean teardown of service-managed StackSets that survives org restructuring. ## Delegated administrators By default, **only the management account** can create service-managed StackSets. The management account is supposed to be minimally used (security best practice), so AWS allows delegating StackSet management to up to **5 member accounts**. A registered delegated administrator can: - Create service-managed StackSets that target the org or specific OUs - Update / delete StackSets they created - Manage delegated stacks across the org > Delegated administrators have **full permissions** to deploy to accounts in your organization. The management account can't limit delegated administrator permissions to specific OUs or operations. This is a sharp edge: registering a delegated admin is a high-trust action with no scoping. Treat it like granting org-admin rights. Registration available in **specific regions only** (the home regions, plus EU regions, plus a few APAC). Not all regions. Worth checking before architecting. ## Deciding between models | Factor | Self-managed | Service-managed | |--------|--------------|-----------------| | Setup cost | Per-account role provisioning | Single trusted-access activation | | Automatic deployment to new accounts | No | Yes (when targeting OUs) | | Requires AWS Organizations | No | **Yes (all features)** | | Targets non-org accounts | Yes | No | | Deployment from non-management accounts | Always | Only delegated admins | | Scoping admin permissions per OU | Possible via IAM in admin account | Not possible — delegated admins have full scope | ## Operational implications for banks For a bank with AWS Organizations and dozens of accounts (typical pattern), **service-managed is almost always the right choice**, with these caveats: 1. **Lock down delegated administrator registration** — it grants org-wide deploy power 2. **Use OU-targeted deployments** to scope StackSets to specific account categories (prod-OU vs nonprod-OU vs sandbox-OU) 3. **Account gates** (Lambda functions named `AWSCloudFormationStackSetAccountGate` in target accounts) provide a pre-deployment veto — see [[CFN StackSet Deployment Controls]] 4. **Document which StackSets target which OUs** — there's no built-in reverse index of "what's deployed to this account" ## Permission boundary — a common gap Neither model automatically respects **IAM permission boundaries** in target accounts. If your org uses permission boundaries to cap maximum permissions, the StackSet's execution role bypasses them by default. Some orgs add a custom execution role with a permission boundary attached — possible but requires self-managed (or post-hoc modification of the service-linked role). ## Related - [[CFN StackSets Cross-Account Cross-Region]] - [[CFN StackSet Deployment Controls]]