Cross-Account Infrastructure Deployment

Once an organisation has more than a handful of AWS accounts, the question stops being how to deploy a stack and becomes how to keep the same stack correct in fifty accounts across four Regions. There are two answers, and they differ in who initiates the deployment: the platform team pushes it, or the account team pulls it.

The infrastructure-as-code foundation

Both answers assume the infrastructure is already described in code, which buys:

• Version control over cloud infrastructure, with the same review process as application code.
• A standard, repeatable definition rather than a console procedure written in a wiki.
• A record of what was provisioned, when and by whom.
• Change management that can be reasoned about before it is applied.

The usual options are CloudFormation templates in JSON or YAML, the AWS CDK (which synthesises CloudFormation from a general-purpose language), AWS SAM for serverless workloads, Terraform, and other frameworks that ultimately emit CloudFormation. See the IaC options compared for how to choose.

CloudFormation StackSets

A StackSet extends a single template across many accounts and Regions from one place. An administrator account holds the StackSet definition; each target account holds a stack instance created from it. Updating the StackSet updates every instance.

How it is wired. The administrator account needs a StackSet administration role, and each target account needs an execution role that trusts it. With AWS Organizations, service-managed permissions remove that setup: the StackSet is targeted at organisational units and the roles are created for you, and new accounts joining an OU can be provisioned automatically.

What it is used for. Config rules that must exist everywhere; organisation-wide IAM roles and permission boundaries; logging and CloudTrail configuration; guardrail resources that compliance requires to be present in every account. Anything, in short, that account teams should not be able to opt out of.

Drift detection reports where a target account has diverged from the StackSet’s template, which matters because a StackSet’s guarantee is only as strong as the last time anyone checked.

AWS Control Tower

Control Tower sits above StackSets and automates the setup of a multi-account landing zone. It creates and organises accounts through Organizations, applies a baseline to each new account, and enforces guardrails expressed as service control policies and Config rules.

What it provides:

• A management account holding Organizations, IAM Identity Center, StackSets and Service Catalog.
• Core organisational units containing a log archive account and an audit account, so logs are aggregated outside the accounts that produce them and cross-account audit roles exist from day one.
• Account provisioning through Account Factory, which applies the baseline as part of creating the account rather than afterwards.
• Preventive and detective guardrails applied to organisational units, so a control applies to every account in the OU including ones created later.

AWS Service Catalog

Service Catalog inverts the direction. Instead of the platform team pushing infrastructure into accounts, it publishes a curated set of approved products that account teams provision for themselves.

Products are CloudFormation templates — a compliant VPC, a hardened database, a standard pipeline. Portfolios are collections of products with an access policy attached. A portfolio can be shared with specific accounts or across the whole organisation.

The point is the launch constraint: the product is provisioned using a role held by Service Catalog, so a user who has permission to launch the product does not need permission on the underlying services. A team can create a compliant RDS instance without holding rds:*.

Choosing between them

	StackSets	Service Catalog
Who initiates	Administrator	Account team
Nature	Mandatory	Optional, on demand
Model	Push	Pull
Result	Identical in every target account	Whatever teams choose to launch, from an approved set
Suits	Guardrails, logging, org-wide policy	Application infrastructure, environments, pipelines

Most organisations need both: StackSets for the baseline nobody may decline, Service Catalog for the building blocks teams assemble their own systems from.

Worked example: a self-service pipeline product

A platform team that wants every microservice to have the same delivery pipeline can:

1. Define the pipeline — source, build, test, approval, deploy — as a CloudFormation template.
2. Publish it as a Service Catalog product inside a portfolio.
3. Share the portfolio with the accounts that host microservices.
4. Let each team provision a pipeline on demand, supplying only the repository and service name as parameters.
5. Allow multiple provisioned instances per account, one per service.

Teams get a pipeline in minutes without holding CodePipeline, CodeBuild or IAM permissions, and the platform team can publish a new product version when the standard changes.

Practices

Version the products and the StackSets. A product version is what an account team pinned to; without versions, “update the standard” means “silently change what everyone is running”.

Keep infrastructure and application code together where they change together, so a change that needs both arrives as one reviewed commit. CDK constructs are a reasonable unit of reuse for the parts that are genuinely shared.

Review cross-account trust regularly. StackSet execution roles and Service Catalog launch roles are standing privilege in every target account. They deserve the same periodic review as any other production role.

Tag from the template. Cost allocation, ownership and environment tags applied by the template are the only ones that will be applied consistently.

Check compliance rather than assume it. Drift detection for StackSets, Config rules for the resources themselves, and an alarm when either reports a deviation.