Multi-Account and Multi-Region Provisioning

Everything in the previous topic assumed one account. Real organizations run dozens, and the same template, the same transit gateway, and the same set of approved building blocks have to reach all of them without a person clicking through each one. This topic covers the three mechanisms AWS provides for that, and the boundary between them is where most of the exam questions live.

What This Topic Covers

• CloudFormation StackSets: stack sets, stack instances, and stacks, and why an instance can exist without a stack
• Self-managed versus service-managed permissions, the two named IAM roles, trusted access with AWS Organizations, and delegated administrators
• Deployment targets, OU targeting with account filters, concurrency, failure tolerance per Region, and Region deployment order
• Stack set drift detection, the statuses that need action, and the operation that reports SUCCEEDED while stacks failed
• AWS RAM: resource shares, managed permissions, invitations versus organization sharing, and which resource types can leave the organization
• Shared VPC subnets: what the owner controls, what a participant can build, cross-account security group references, and why Availability Zone IDs matter
• Service Catalog: products, portfolios, launch roles, and the five constraint types, plus shared versus copied catalogs
• AWS Control Tower: the landing zone structure, Log Archive and Audit accounts, preventive, detective, and proactive controls, Account Factory, and drift

Why It Matters

Skill 3.1.4 of the SOA-C03 exam guide names AWS RAM and CloudFormation StackSets directly, and the surrounding governance services show up throughout the security and networking domains as well. Questions here rarely ask what a service is. They describe a rollout that reached 37 of 40 accounts, a subnet a participant account cannot route out of, or a developer who needs to launch a database without database permissions, and ask for the mechanism or the fix.

The job pressure is identical. Multi-account is where small mistakes multiply: a baseline that quietly skipped the management account, a resource share that stopped working after an OU reorganization, a launch role scoped so wide that self-service became a permissions bypass. Knowing which mechanism owns which problem is what keeps a growing account structure manageable instead of becoming forty separate environments that happen to share a bill.