You need to deploy the same CloudFormation infrastructure across 20 AWS accounts in 4 regions for a multi-account landing zone. How do you use StackSets to manage this at scale?
Quick Answer
Use CloudFormation StackSets with service-managed permissions (AWS Organizations integration), deploy to organizational units (OUs), configure concurrent deployment settings, use auto-deployment for new accounts, and implement proper failure tolerance and rollback thresholds.
Detailed Answer
StackSets Architecture
StackSets extend CloudFormation to deploy stacks across multiple AWS accounts and regions from a single management account. A StackSet is a template + configuration, and stack instances are the actual deployments in target accounts/regions. You manage one template; StackSets handles the fan-out. There are two permission models: self-managed (requires IAM roles in each target account) and service-managed (uses AWS Organizations, recommended for scale).
Service-Managed vs Self-Managed
Service-managed StackSets integrate with AWS Organizations, allowing you to target OUs instead of individual account IDs. When a new account is added to the OU, StackSets automatically deploys the stack instance (auto-deployment). This is essential for landing zones where new accounts must be pre-configured. Self-managed StackSets require pre-created IAM roles (AWSCloudFormationStackSetAdministrationRole in management, AWSCloudFormationStackSetExecutionRole in targets) and explicit account ID lists.
Deployment Strategy
Configure MaxConcurrentCount or MaxConcurrentPercentage to control how many accounts deploy simultaneously. Set FailureToleranceCount to define how many account failures are acceptable before the entire operation stops. For critical infrastructure, deploy to one region first (canary), verify, then deploy to remaining regions. Use StackSet parameters with account-level overrides for region-specific configuration.
Operational Challenges
Stack instances can drift independently. Use StackSets drift detection to check all instances at once. Template updates propagate to all instances, but failing instances require manual investigation. Parameter overrides per account/region add complexity. For large-scale deployments (100+ accounts), StackSets operations can take hours - plan maintenance windows accordingly.
Code Example
# Create a service-managed StackSet targeting an OU
aws cloudformation create-stack-set \
--stack-set-name security-baseline \
--template-url https://s3.amazonaws.com/cfn-templates/security-baseline.yaml \
--permission-model SERVICE_MANAGED \
--auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
--capabilities CAPABILITY_NAMED_IAM \
--parameters \
ParameterKey=GuardDutyEnabled,ParameterValue=true \
ParameterKey=CloudTrailBucketName,ParameterValue=org-cloudtrail-central \
--managed-execution Active=true
# Deploy to OUs in multiple regions
aws cloudformation create-stack-instances \
--stack-set-name security-baseline \
--deployment-targets OrganizationalUnitIds='["ou-abc123","ou-def456"]' \
--regions us-east-1 us-west-2 eu-west-1 ap-southeast-1 \
--operation-preferences \
RegionConcurrencyType=PARALLEL,\
MaxConcurrentPercentage=25,\
FailureTolerancePercentage=10
# Override parameters for specific accounts
aws cloudformation create-stack-instances \
--stack-set-name security-baseline \
--deployment-targets Accounts='["111111111111"]' \
--regions us-east-1 \
--parameter-overrides ParameterKey=GuardDutyEnabled,ParameterValue=false
# Check deployment status
aws cloudformation describe-stack-set-operation \
--stack-set-name security-baseline \
--operation-id op-1234567890 \
--query '{Status:Status,Action:Action,CreationTimestamp:CreationTimestamp}'
# List all stack instances and their status
aws cloudformation list-stack-instances \
--stack-set-name security-baseline \
--query 'Summaries[].{Account:Account,Region:Region,Status:StackInstanceStatus.DetailedStatus}' \
--output table
# Detect drift across all instances
aws cloudformation detect-stack-set-drift \
--stack-set-name security-baseline
# Template excerpt: security-baseline.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Security baseline for all accounts
Conditions:
EnableGuardDuty: !Equals [!Ref GuardDutyEnabled, 'true']
Resources:
CloudTrail:
Type: AWS::CloudTrail::Trail
Properties:
TrailName: org-trail
S3BucketName: !Ref CloudTrailBucketName
IsMultiRegionTrail: true
EnableLogFileValidation: true
IsLogging: true
GuardDutyDetector:
Type: AWS::GuardDuty::Detector
Condition: EnableGuardDuty
Properties:
Enable: true
FindingPublishingFrequency: FIFTEEN_MINUTES
ConfigRecorder:
Type: AWS::Config::ConfigurationRecorder
Properties:
RecordingGroup:
AllSupported: true
IncludeGlobalResourceTypes: true
PasswordPolicy:
Type: AWS::IAM::AccountPasswordPolicy
Properties:
MinimumPasswordLength: 14
RequireSymbols: true
RequireNumbers: true
RequireUppercaseCharacters: true
RequireLowercaseCharacters: true
MaxPasswordAge: 90
PasswordReusePrevention: 24Interview Tip
Emphasize service-managed permissions with auto-deployment - this is the modern approach for landing zones. Discuss failure tolerance settings as a production safety mechanism. Mention the canary approach: deploy to one region first, verify, then fan out.