Skip to main content

Updating & Sync

A StackSet is a living deployment: templates change, and accounts join and leave the OUs you target. This page covers editing a StackSet, keeping its targets in sync with your organization, retrying failed instances, and managing running operations.

Updating a StackSet​

Edit lets you change the StackSet's template, parameters, capability acknowledgements, target OUs, and regions.

note

Tags are set only when you create a StackSet. The Edit flow does not change tags.

warning

An update redeploys the template to every existing stack instance of the StackSet — not only the instances affected by what you changed. Before you submit, consider the full blast radius: every target account and region will run a stack update.

Reviewing Template Changes​

When you edit a StackSet whose template was uploaded, the Review step shows a Template changes panel: a line-by-line diff with +N added / −M removed counts and a Show diff toggle that colors added lines green and removed lines red — so you can confirm exactly what will roll out before you submit.

Refreshing from an S3 URL​

When a StackSet's template source is an Amazon S3 URL (see Template), the Edit screen shows the linked URL (read-only) with the option Pull the latest template from this S3 URL and redeploy if it changed, enabled by default:

  • Enabled — Prism re-reads the object at that URL and, if the content changed, redeploys the newest template to every instance.
  • Disabled — the currently deployed template is kept; only parameter, target, or region changes are applied.

Because the URL never changes, this is the update path for a GitOps workflow where a pipeline overwrites the same object in place.

Changing Targets or Regions​

Target and region changes translate into instance changes:

  • Adding OUs or regions creates new stack instances in the added targets.
  • Removing OUs or regions removes the corresponding instances. For each removal you choose whether to retain the deployed stacks (the stacks and their resources keep running in the removed accounts) or delete them (the resources are destroyed).

Keeping Targets in Sync​

New accounts that join a targeted OU are not deployed to automatically. Deployment to new accounts is always a deliberate, manual action via Sync.

Running Sync:

  1. Compares the StackSet's current instances against the accounts currently under its target OUs.
  2. Shows a preview of the differences — accounts to add and accounts to remove — before anything changes.
  3. For removals, lets you choose whether to retain or delete the deployed stacks, just like an update.
  4. For new accounts, provisions the CKPrism-StackSetExecutionRole before deploying stack instances to them.

Nothing is applied until you confirm the previewed changes.

Retrying Failed Instances​

Instances that end up in the Failed status show the failure reason in the instance table on the StackSet detail page. A single Retry failed instances action reruns the deployment for every failed instance of the StackSet at once — there is no per-instance selection. Instances that are not failed are left untouched.

note

This is separate from the per-account Retry on the StackSets list page, which reprovisions a failed execution role in a single account. Instance retry acts on deployed stack instances and always covers all failed instances together.

Operation History and Stop​

Every operation on a StackSet — create, update, sync, retry, delete — is recorded in the StackSet's operation history. Only one operation can run on a StackSet at a time.

A running operation shows a Stop action. Stopping halts the operation; instances that were already processed keep their new state, and instances that had not been reached are left as they were.

note

In-flight AWS StackSet operations (create, update, sync, and delete) re-attach after a backend restart and resume where they left off. Note that this applies to StackSet operations only — the role-provisioning fan-outs run during enable and disable are not resumable. See Restart Resilience.