Integrating IaC into CI/CD pipelines

1. Integrating IaC into CI/CD pipelines

Welcome back! In this video, you'll add a CloudFormation deploy action to CodePipeline, see how automatic rollback handles failures, and pick between single stacks, nested stacks, and StackSets. Let's get started.

2. Code first, infrastructure later

Most teams start with code in CI/CD and infrastructure as a separate, manual job. Devs deploy Lambda updates through CodePipeline; ops resize the SQS queue through the console. The two streams drift, and the next code deploy hits an environment that no longer matches what the code expects. The fix is to wire CloudFormation into the same pipeline that ships your code.

3. CloudFormation as a pipeline action

CodePipeline ships a CloudFormation deploy action out of the box. Earlier pipeline stages produce a template artifact, and the deploy action consumes it. Action modes include CREATE_UPDATE for create-or-update, DELETE_ONLY for teardown, REPLACE_ON_FAILURE for replacing failed stacks, and the CHANGE_SET_REPLACE and CHANGE_SET_EXECUTE pair for the gated change-set workflow you saw in the first video of this chapter. You wire CloudFormation actions into the same pipeline that runs your application deploy, so infrastructure changes ride alongside code changes.

4. A typical end-to-end pipeline

A common end-to-end pipeline runs four stages. On every Git push, Source triggers the pipeline and Build has CodeBuild compile the application and generate the CloudFormation template. From there, CloudFormation creates or updates the stack so the application has the resources it needs, and finally CodeDeploy ships the new version onto that infrastructure. Each stage produces an artifact for the next, so the whole chain runs hands-off on every commit.

5. Automatic rollback on stack failure

CloudFormation tries to make every stack update succeed as a unit. If any step fails, CloudFormation rolls the stack back to its last known good state. In rare cases the rollback itself fails and the stack ends in UPDATE_ROLLBACK_FAILED, but the common pattern is the protection you rely on. The pipeline stage fails, halting later stages and triggering your failure-alert wiring.

6. Nested stacks for modular templates

Once a template grows past a few hundred lines, it starts to feel like a monolith. Nested stacks fix that. A nested stack is a stack referenced as a resource of its parent, declared with the AWS::CloudFormation::Stack type. The parent passes parameters in and reads outputs back, just like a function call. You break a 2,000-line template into reusable modules, like a networking stack and a database stack, and the parent composes them. Each module can be developed and tested in isolation.

7. StackSets for multi-account, multi-region

StackSets are the multi-account, multi-region cousin of stacks. You define a template once, then deploy it into every account and region you target in a single operation, and each target gets its own CloudFormation stack. That's how organizations roll out security baselines or shared networking across an entire AWS Organization. You manage the instances centrally, but each one runs as a regular CloudFormation stack in its target account.

8. Picking the right shape

Single stacks, nested stacks, and StackSets each fit a different scale. Reach for a single stack when the app is small and lives in one environment, simple to reason about and fast to deploy. Move to nested stacks once the template grows large enough that splitting networking, database, and application layers keeps it manageable. Choose StackSets when you need the same template across many accounts or regions, like one logging guardrail in twenty accounts. CodePipeline integrates with all three, so the choice doesn't lock you out of CI/CD.

9. Let's practice!

Let's now practice what we learned!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.