8.2 Multi-Account & Multi-Region Resource Sharing
Key Takeaways
- AWS CloudFormation StackSets extends CloudFormation templates to orchestrate multi-account, multi-Region infrastructure deployments in a single coordinated operation.
- Service-managed permissions integrate with AWS Organizations for automatic deployment and cleanup across Organizational Units without manual roles, whereas self-managed permissions utilize custom administration and execution IAM roles across standalone accounts.
- Operational deployment preferences—Maximum Concurrent Accounts, Failure Tolerance, and Sequential versus Parallel Region concurrency—govern rollout blast radiuses and automate failure aborts.
- AWS Resource Access Manager (AWS RAM) securely shares centralized AWS resources—including VPC subnets, Transit Gateways, Route 53 Resolver rules, and Aurora DB clusters—across accounts without provisioning duplicate infrastructure.
- In a shared VPC architecture, participant accounts can launch compute and data resources in owner-managed subnets, but participants cannot view, modify, or delete resources owned by other accounts, and cannot directly attach external security groups.
8.2 Multi-Account & Multi-Region Resource Sharing
CloudOps Blueprint Focus: Managing multi-account infrastructure is a core domain of the AWS Certified CloudOps Engineer – Associate (SOA-C03) exam. You must master AWS CloudFormation StackSets architecture and permission models, configure safe deployment preferences across accounts and Regions, govern shared resources using AWS Resource Access Manager (RAM), and enforce account-level security boundaries in centralized shared VPC environments.
Multi-Account Infrastructure with CloudFormation StackSets
In enterprise multi-account environments—where distinct accounts isolate production, staging, and security workloads—deploying infrastructure stack-by-stack introduces severe overhead and configuration drift. AWS CloudFormation StackSets extends CloudFormation templates by enabling administrators to provision, update, and manage stacks across hundreds of AWS accounts and multiple Regions in a single coordinated operation.
A StackSet implementation comprises three logical layers:
- StackSet: The parent resource defining the CloudFormation template, parameters, and IAM capabilities.
- Stack Instances: Pointers to individual stacks created in specific target accounts and Regions. A stack instance maps 1:1 to a physical stack.
- Stack Operations: The actions executed across stack instances (
CREATE,UPDATE,DELETE, orDETECT_DRIFT).
StackSets Permission Models: Service-Managed vs. Self-Managed
CloudFormation StackSets supports two distinct permission models governing cross-account authorization:
| Feature | Service-Managed Permissions | Self-Managed Permissions |
|---|---|---|
| Directory Integration | Integrated natively with AWS Organizations. | Standalone AWS accounts or multi-organization setups. |
| Targeting Mechanism | Targets Organizational Units (OUs) or entire organization. | Targets explicit, comma-separated AWS Account IDs. |
| IAM Role Setup | Zero manual IAM roles required. Uses Organizations service-linked roles. | Requires manual provisioning of AWSCloudFormationStackSetAdministrationRole and AWSCloudFormationStackSetExecutionRole. |
| Automatic Deployment | Automatically deploys stacks to accounts joining targeted OUs (AutoDeployment: Enabled). | Not supported. New accounts must be manually targeted in subsequent updates. |
| Automatic Cleanup | Automatically deletes stacks when accounts leave targeted OUs (RetainStacksOnAccountRemoval: false). | Not supported. Stacks must be manually deleted prior to account removal. |
| Delegated Administration | Supports delegating StackSet management to non-root member accounts (e.g., Security or Platform account). | Not supported; StackSets must run from the primary administrator account. |
In enterprise operations, Service-Managed permissions are standard. Delegated administration allows platform teams to manage organizational baselines—such as IAM password policies, AWS Config rules, and CloudWatch log forwarders—from a platform operations account without root access to the Organizations management account.
Operational Rollout Preferences: Concurrency & Failure Tolerances
Deploying across hundreds of accounts simultaneously poses substantial operational risk. A misconfiguration or hitting a service quota could trigger widespread outages. CloudFormation StackSets provides granular rollout controls to limit blast radiuses:
- Maximum Concurrent Accounts: Sets the maximum number or percentage of target accounts where stack instances are deployed simultaneously (e.g.,
MaxConcurrentCount: 5orMaxConcurrentPercentage: 20). Limiting concurrency prevents overwhelming AWS API rate limits and controls deployment velocity. - Failure Tolerance: Specifies the number or percentage of account deployment failures permitted before the entire StackSet operation halts immediately (e.g.,
FailureToleranceCount: 2orFailureTolerancePercentage: 5). Remaining accounts remain untouched, preventing systemic failure propagation. - Region Concurrency:
- Sequential: Deploys stacks across specified Regions one at a time. If the rollout in the initial canary Region fails, the operation aborts before altering subsequent Regions.
- Parallel: Deploys to all designated Regions simultaneously, optimizing deployment speed when changes have been pre-validated.
Centralized Resource Sharing with AWS RAM
To eliminate redundant infrastructure, centralize governance, and minimize connectivity costs, AWS Resource Access Manager (AWS RAM) allows accounts to share supported AWS resources across AWS Organizations or with individual external accounts.
Key shareable resource types include:
- Amazon VPC Subnets: Foundation of centralized shared VPC architectures.
- AWS Transit Gateways (TGW): Shares transit hubs and route tables for inter-VPC connectivity.
- Route 53 Resolver Rules: Distributes internal hybrid DNS resolution rules across all VPCs.
- AWS License Manager Configurations: Centrally enforces enterprise software licensing rules.
- Amazon Aurora DB Clusters: Shares database clones across accounts for testing and analytics.
- AWS Network Firewall Rule Groups & IPAM Pools: Centralizes egress inspection and IP address allocations.
Centralized Shared VPC Architecture & Security Boundaries
In a Shared VPC model, network engineering teams decouple subnet routing and edge security from application workloads:
- The Network Owner Account creates and owns the Amazon VPC, subnets, route tables, Internet Gateways, NAT Gateways, Transit Gateway attachments, and Network Access Control Lists (NACLs).
- The Participant Accounts are application or microservice accounts granted access to specific subnets via an AWS RAM Resource Share.
Resource Permissions and Cross-Account Security Boundaries
Within a shared VPC, strict security boundaries isolate participants:
- Ownership Isolation: Participant accounts can create, view, and manage their own resources (EC2 instances, EBS volumes, RDS databases, ENIs) inside the shared subnets. However, participants cannot view, modify, or delete resources owned by other participants or the network owner account.
- Subnet & Routing Control: Participants cannot modify subnet CIDRs, route tables, or NACLs. Only the network owner retains administrative control over VPC routing.
- Security Group Governance: Security groups are account-scoped. A participant account cannot directly attach a security group owned by another account.
- Cross-Account Security Group Referencing: To permit inter-service communication, participant accounts reference peer security groups in inbound or outbound rules (e.g., Account B's database security group permits port 3306 from Account A's security group formatted as
111122223333/sg-0123456789abcdef0). Traffic routes over AWS private network links without exposing resources to the broader subnet CIDR.
StackSet Drift Detection & Remediation
Over time, manual modifications in member accounts cause configuration drift. CloudFormation StackSets provides centralized drift detection (aws cloudformation detect-stack-set-drift). This operation queries all stack instances across all target accounts and Regions, identifying out-of-band property modifications and parameter discrepancies without impacting production workloads.
An enterprise with 150 AWS accounts organized into multiple Organizational Units (OUs) within AWS Organizations needs to deploy a standardized security logging CloudFormation template to all current member accounts and ensure that any newly created account in the 'Workloads' OU automatically receives the stack deployment. Additionally, when an account is removed from the OU, its deployed stack should be automatically deleted. The CloudOps team must implement this with the least operational overhead, avoiding manual IAM cross-account role management. Which solution fulfills these requirements?
An enterprise uses AWS Resource Access Manager (AWS RAM) to implement a centralized shared VPC architecture, where the network engineering account shares private subnets with multiple application participant accounts. An application team in Account B launches Amazon EC2 instances in the shared subnet and needs to allow inbound traffic from a microservice hosted on an EC2 instance in Account C, which also runs within the same shared subnet. How must the application team configure security group rules to permit this traffic?
A CloudOps engineer is deploying an infrastructure update across 40 accounts in 3 AWS Regions using AWS CloudFormation StackSets. To minimize the risk of application downtime caused by potential template misconfigurations, the engineer must ensure that: (1) deployments to the second Region only begin after the first Region succeeds completely, (2) no more than 4 accounts in any Region are updated concurrently, and (3) the entire StackSet operation aborts immediately if more than 2 accounts fail. Which StackSet deployment configuration satisfies these constraints?