Great question—this is such a common point of confusion because at first glance both commands look like they do the same thing: deploy CloudFormation resources. But they’re built for distinct workflows, and that "missing executable change set" mystery ties directly into how deploy operates under the hood. Let’s break this down clearly:

Core Differences & Use Cases #

Let’s start with the fundamental purpose of each command:

create-stack #

This is the low-level, purpose-built command for creating brand-new stacks only. It has one job: submit your template and parameters to CloudFormation to spin up a fresh stack. If the stack name you specify already exists, it will throw an error immediately (no automatic updates here).

Key traits:

• No built-in support for updates—only initial stack creation
• No automatic change set generation; if you want a change set, you have to create and execute it manually
• Best for scenarios where you explicitly need to create a new stack and want to fail fast if it already exists

deploy #

This is a higher-level, "one-size-fits-all" command for full stack lifecycle management. It’s designed to handle both new and existing stacks seamlessly:

• If the stack doesn’t exist: it automatically runs the equivalent of create-stack to spin it up
• If the stack does exist: it creates a change set behind the scenes, executes it automatically, and waits for the update to complete

Key traits:

• Encapsulates both creation and update workflows in a single command
• Perfect for CI/CD pipelines or scripts where you don’t want to check if a stack exists first
• Handles change sets automatically, but doesn’t leave them hanging around as "executable"

Why No Executable Change Set After Running deploy? #

You’re right that the docs say deploy uses a change set—and they’re not lying! The catch is that deploy creates the change set, executes it immediately, and then the change set is marked as completed (not executable anymore).

CloudFormation doesn’t keep executed change sets available for re-running; once they’re applied, they’re just part of the stack’s history. You can still find the change set record in the CloudFormation console under the stack’s "Change sets" tab, but it will show as "Executed" rather than "Available for execution".

If you want to review a change set before applying it, you’ll need to split the workflow into manual steps: use aws cloudformation create-change-set to generate the set, review it via the CLI or console, then run aws cloudformation execute-change-set to apply it. The deploy command skips the manual review step by automating both creation and execution.

"Priority" Between the Two Commands #

There’s no strict "priority"—it’s all about use cases:

• Use create-stack when you need strict control over initial stack creation (and want to avoid accidental updates)
• Use deploy when you want a simplified, automated workflow that works for both new and existing stacks

Quick Cheat Sheet #

• 🆕 New stack only, fail if exists: Use create-stack
• 🔄 New or existing stack, auto-update: Use deploy
• 🧐 Review changes before applying: Use create-change-set + execute-change-set

内容的提问来源于stack exchange，提问作者nixmind