AWS CloudFormation & Infrastructure as Code

CloudFormation makes desired infrastructure declarative and repeatable

AWS CloudFormation models AWS infrastructure in templates and provisions the described resources as stacks. Instead of manually creating related resources and trying to reproduce their settings later, a template becomes a versionable declaration of the desired environment. CloudFormation resolves dependencies between resources where it can infer them, and explicit dependencies can be expressed when creation or update order matters beyond reference relationships.

Templates can include parameters for deployment-time input, conditions for conditional resource creation or properties, mappings for lookup tables, outputs for useful values, and the resources that CloudFormation manages. Parameters make a template reusable, but they should not become an excuse to hide every architectural decision behind an unstructured set of inputs. A good template captures a coherent unit of infrastructure with predictable interfaces.

Change sets preview updates; drift detection finds out-of-band changes

A change set previews the changes CloudFormation intends to make when a stack is created or updated. This is especially important because modifying a resource property can result in no interruption, some interruption or resource replacement depending on that resource type and property. Reviewing the proposed changes gives an operator a chance to catch an unexpected replacement before executing the change set, but the preview is not a guarantee that execution will succeed under all runtime conditions.

Drift occurs when resources are changed outside CloudFormation so their actual configuration no longer matches the stack's expected configuration. Drift detection compares supported resource properties against the template-derived expected state and reports differences such as modifications or deletions. Detecting drift is therefore a governance check; resolving it requires choosing whether the actual change should be reverted or incorporated into the declared infrastructure.

• Review replacements carefully: a template change can recreate a resource rather than edit it in place.
• Change sets forecast intended stack operations; drift detection compares actual resource state with the stack's expected state.
• Out-of-band console changes weaken the value of IaC unless they are reconciled back into the managed definition.

StackSets extend a template across accounts and Regions

CloudFormation StackSets let an administrator use one template as the basis for stacks in multiple target accounts and Regions. This is a key governance primitive for repeatable infrastructure such as baseline roles, logging resources or configuration components that should exist throughout an organization. A StackSet owns stack instances in each target account/Region combination and can update those instances as the shared definition evolves.

StackSets support self-managed and service-managed permission models. With service-managed permissions and AWS Organizations integration, StackSets can target OUs and can automatically deploy to new accounts added to those targets when automatic deployment is configured. That makes StackSets complementary to Organizations policy: an SCP constrains maximum permissions, while a StackSet can actually provision standardized resources into the governed accounts.