Updating and deleting stacks in AWS - Deep Dive

Overview - Updating and deleting stacks

What is it?

Updating and deleting stacks are ways to change or remove a group of cloud resources managed together. A stack is like a container holding resources such as servers, databases, and networks. Updating a stack changes its resources without starting from scratch. Deleting a stack removes all its resources safely and completely.

Why it matters

Without updating stacks, you would have to rebuild resources manually every time you want a change, which is slow and error-prone. Without deleting stacks, unused resources would waste money and clutter your cloud environment. These actions help keep cloud setups efficient, organized, and cost-effective.

Where it fits

Before learning this, you should understand what stacks are and how to create them. After this, you can explore advanced stack management like stack policies, drift detection, and automated deployment pipelines.

Mental Model

Core Idea

A stack is a living group of cloud resources you can safely change or remove as one unit.

Think of it like...

Think of a stack like a LEGO model you built. Updating the stack is like swapping some LEGO pieces to change the model without tearing it all down. Deleting the stack is like taking the whole model apart and putting the pieces away.

Stack Lifecycle
┌───────────────┐       Update        ┌───────────────┐
│               │───────────────────>│               │
│   Stack v1    │                    │   Stack v2    │
│ (Resources)   │                    │ (Resources)   │
└───────────────┘                    └───────────────┘
       │                                  │
       │ Delete                           │ Delete
       ▼                                  ▼
┌───────────────┐                    ┌───────────────┐
│               │                    │               │
│  No Stack     │                    │  No Stack     │
│ (Resources    │                    │ (Resources    │
│  removed)     │                    │  removed)     │
└───────────────┘                    └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is a Cloud Stack

Concept: Introduce the idea of a stack as a collection of cloud resources managed together.

A stack groups resources like servers, databases, and networks into one unit. This lets you create, update, or delete all these resources together instead of one by one. Think of it as a folder holding all parts of a project.

Result

You understand that a stack is a single unit managing multiple cloud resources.

Knowing that stacks group resources helps you manage complex cloud setups easily and consistently.

2

Foundation

Basics of Stack Creation

Concept: Explain how stacks are created from templates describing resources.

You write a template listing all resources and their settings. When you create a stack, the cloud reads this template and builds all resources automatically. This saves time and avoids mistakes from manual setup.

Result

You can create a stack that builds multiple resources from one template.

Understanding templates as blueprints is key to managing stacks efficiently.

3

Intermediate

How Stack Updates Work

🤔Before reading on: do you think updating a stack replaces all resources or only changes what’s needed? Commit to your answer.

Concept: Updating a stack changes only the resources that need to be changed based on the new template.

When you update a stack, you provide a new template or parameters. The cloud compares the new template with the current stack and changes only the resources that differ. This avoids rebuilding everything and keeps your system running smoothly.

Result

Stack updates apply changes efficiently without downtime or full rebuilds.

Knowing that updates are smart and partial prevents fear of breaking everything when changing stacks.

4

Intermediate

Safe Stack Deletion Process

🤔Before reading on: do you think deleting a stack instantly removes resources or follows a safe order? Commit to your answer.

Concept: Deleting a stack removes all resources in a safe order to avoid errors or leftover parts.

When you delete a stack, the cloud deletes resources one by one following dependencies. For example, it deletes servers before networks they use. This prevents errors and cleans up everything properly.

Result

Stack deletion removes all resources safely and completely.

Understanding deletion order helps avoid surprises like leftover resources or errors.

5

Intermediate

Handling Update Failures

🤔Before reading on: do you think stack updates always succeed or can they fail and rollback? Commit to your answer.

Concept: Stack updates can fail, and the system can roll back to the previous stable state automatically.

If an update tries to change resources but encounters errors, the cloud cancels the update and restores the stack to its last working state. This protects your system from partial or broken changes.

Result

Failed updates do not leave your stack in a broken state.

Knowing rollback exists builds confidence to update stacks without fear of breaking things.

6

Advanced

Using Change Sets for Updates

🤔Before reading on: do you think you can preview stack changes before applying them? Commit to your answer.

Concept: Change sets let you see what will change in a stack before actually updating it.

You create a change set by submitting a new template or parameters. The cloud shows a list of resources that will be added, changed, or removed. You review this list and only apply the update if it looks correct.

Result

You can safely preview and control stack updates.

Understanding change sets helps prevent accidental or harmful changes in production.

7

Expert

Stack Update Internals and Drift

🤔Before reading on: do you think manual changes outside stacks affect updates? Commit to your answer.

Concept: Manual changes outside the stack can cause drift, which affects updates and stack state.

If someone changes resources directly in the cloud console or API, the stack’s view becomes outdated. This is called drift. When updating, the cloud tries to reconcile drift but can fail or cause unexpected results. Detecting and fixing drift is important for reliable updates.

Result

You understand how drift impacts stack updates and why managing it matters.

Knowing about drift prevents hidden errors and ensures stack updates behave as expected.

Under the Hood

Stacks are managed by a cloud service that tracks each resource’s state and dependencies. When updating, it compares the current state with the desired state from the new template. It calculates a plan to add, modify, or delete resources in the correct order. During deletion, it follows dependency graphs to remove resources safely. Rollbacks happen by saving snapshots of the stack state before updates and restoring them if needed.

Why designed this way?

This design ensures safety, consistency, and efficiency. Managing resources as a group avoids manual errors. Dependency tracking prevents resource conflicts. Rollbacks protect against partial failures. Alternatives like manual updates were error-prone and slow, so this automated approach became standard.

Stack Management Flow
┌───────────────┐
│ New Template  │
└──────┬────────┘
       │ Compare
       ▼
┌───────────────┐
│ Change Plan   │
│ (Add/Modify/  │
│  Delete)      │
└──────┬────────┘
       │ Execute
       ▼
┌───────────────┐
│ Update Stack  │
│ Resources     │
└──────┬────────┘
       │ Success?
       ├─────────────┐
       │             │
       ▼             ▼
┌───────────────┐ ┌───────────────┐
│ Complete      │ │ Rollback to   │
│ Update        │ │ Previous State│
└───────────────┘ └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does updating a stack always replace all resources? Commit yes or no.

Common Belief: Updating a stack rebuilds all resources from scratch every time.

Reality: Updates only change resources that differ between the old and new templates, leaving unchanged resources intact.

Why it matters: Believing updates rebuild everything causes unnecessary fear of downtime and delays in applying changes.

Quick: Does deleting a stack instantly remove all resources simultaneously? Commit yes or no.

Common Belief: Deleting a stack deletes all resources at once without order.

Reality: Deletion follows a safe order respecting dependencies to avoid errors and leftover resources.

Why it matters: Ignoring deletion order can cause errors or orphaned resources, leading to wasted costs and confusion.

Quick: Can manual changes outside the stack cause problems during updates? Commit yes or no.

Common Belief: Manual changes to resources outside the stack don’t affect stack updates.

Reality: Manual changes cause drift, which can break updates or cause unexpected behavior.

Why it matters: Not managing drift risks broken stacks and failed updates in production.

Quick: Does the cloud automatically preview changes before updating stacks? Commit yes or no.

Common Belief: Stack updates happen immediately without any preview or review.

Reality: Change sets allow previewing changes before applying updates to avoid mistakes.

Why it matters: Skipping previews can cause accidental destructive changes in live environments.

Expert Zone

1

Stack updates can sometimes cause temporary resource replacement even if only minor changes are made, due to resource type limitations.

2

Deletion protection flags can prevent accidental stack deletion, adding a safety layer in production environments.

3

Nested stacks allow managing complex architectures by composing stacks inside other stacks, improving modularity and reuse.

When NOT to use

Avoid updating stacks directly in production without testing; use change sets and staging environments instead. For very dynamic or short-lived resources, consider infrastructure as code tools with immutable deployments rather than stack updates. When deleting stacks, be cautious if resources are shared outside the stack; manual cleanup might be safer.

Production Patterns

Teams use automated pipelines to create change sets, review them, and apply updates during maintenance windows. Deletion protection is enabled on critical stacks. Drift detection runs regularly to catch manual changes early. Nested stacks break large systems into manageable parts, improving collaboration and reducing errors.

Connections

Version Control Systems

Both manage changes over time with safe updates and rollbacks.

Understanding stack updates as version control for infrastructure helps grasp the importance of change tracking and rollback.

Database Transactions

Stack updates and deletions behave like transactions that commit or rollback changes atomically.

Seeing stack operations as transactions clarifies why partial failures must revert to keep systems consistent.

Project Management

Managing stacks is like managing projects with phases: planning (templates), execution (updates), and closure (deletion).

Relating stacks to project phases helps understand the lifecycle and importance of careful planning and review.

Common Pitfalls

#1 Trying to update a stack by manually changing resources outside the stack.

Wrong approach:

Manually modify a server’s settings in the cloud console without updating the stack template.

Correct approach:

Update the stack template and apply a stack update to change the server settings.

Root cause:

Misunderstanding that stacks track resource state only through templates, so manual changes cause drift and confusion.

#2 Deleting a stack without checking for dependencies or deletion protection.

Wrong approach:

Run delete-stack command on a critical stack without disabling deletion protection or verifying dependencies.

Correct approach:

First disable deletion protection if enabled and ensure no dependent resources will break, then delete the stack.

Root cause:

Ignoring safety features and dependencies leads to accidental data loss or service outages.

#3 Applying stack updates without reviewing change sets.

Wrong approach:

Directly update stack with new template without creating or reviewing a change set.

Correct approach:

Create a change set, review the planned changes carefully, then execute the update if safe.

Root cause:

Skipping review steps increases risk of unintended destructive changes.

Key Takeaways

Stacks group cloud resources so you can manage them as one unit for easier updates and deletions.

Updating stacks changes only what’s needed, avoiding full rebuilds and reducing downtime.

Deleting stacks removes all resources safely by respecting dependencies and order.

Change sets let you preview updates before applying, preventing accidental mistakes.

Manual changes outside stacks cause drift, which can break updates and must be managed carefully.

Practice

1. What is the primary purpose of the update-stack command in AWS CloudFormation?

easy

A. To create a new stack from a template

B. To safely change existing cloud resources managed by a stack

C. To delete all resources created by a stack

D. To list all stacks in your AWS account

Solution

1. Step 1: Understand the role of update-stack

   The update-stack command is used to modify resources that are already managed by an existing CloudFormation stack.

2. Step 2: Differentiate from other commands

   Unlike delete-stack which removes resources, update-stack changes them safely without deleting the stack.

3. Final Answer:

   To safely change existing cloud resources managed by a stack -> Option B

4. Quick Check:

   update-stack = change resources safely [OK]

Hint: Update-stack changes resources; delete-stack removes them [OK]

Common Mistakes:

• Confusing update-stack with delete-stack
• Thinking update-stack creates new stacks
• Assuming update-stack lists stacks

2. Which AWS CLI command syntax correctly deletes a stack named MyAppStack?

easy

A. aws cloudformation delete-stack --stack-name MyAppStack

B. aws cloudformation update-stack --stack-name MyAppStack

C. aws cloudformation remove-stack --name MyAppStack

D. aws cloudformation destroy-stack --stack MyAppStack

Solution

1. Step 1: Identify the correct delete command

   The correct AWS CLI command to delete a stack is delete-stack with the parameter --stack-name.

2. Step 2: Verify syntax correctness

   aws cloudformation delete-stack --stack-name MyAppStack uses the exact syntax: aws cloudformation delete-stack --stack-name MyAppStack, which is valid and deployable.

3. Final Answer:

   aws cloudformation delete-stack --stack-name MyAppStack -> Option A

4. Quick Check:

   delete-stack + --stack-name = correct syntax [OK]

Hint: Delete stacks with 'delete-stack' and '--stack-name' [OK]

Common Mistakes:

• Using update-stack instead of delete-stack
• Wrong parameter names like --name or --stack
• Using non-existent commands like remove-stack or destroy-stack

3. Given this AWS CLI command sequence:

aws cloudformation update-stack --stack-name TestStack --template-body file://template.json
aws cloudformation describe-stacks --stack-name TestStack

What is the expected behavior after running these commands?

medium

A. The stack TestStack is updated with the new template, and its status is shown

B. The stack TestStack is deleted, and no status is returned

C. A new stack named TestStack is created, and its details are displayed

D. The command fails because update-stack cannot be followed by describe-stacks

Solution

1. Step 1: Understand update-stack effect

   The update-stack command modifies the existing stack named TestStack using the provided template.

2. Step 2: Describe-stacks shows current stack status

   The describe-stacks command retrieves details about TestStack, including its updated status.

3. Final Answer:

   The stack TestStack is updated with the new template, and its status is shown -> Option A

4. Quick Check:

   update-stack changes stack + describe-stacks shows status [OK]

Hint: Update then describe shows updated stack status [OK]

Common Mistakes:

• Thinking update-stack deletes the stack
• Assuming describe-stacks creates a new stack
• Believing update-stack and describe-stacks cannot be used sequentially

4. You run aws cloudformation update-stack --stack-name ProdStack --template-body file://newtemplate.json but get an error saying the stack is in UPDATE_IN_PROGRESS state. What should you do to fix this?

medium

A. Ignore the error and rerun update-stack multiple times

B. Run delete-stack immediately to remove the stack

C. Change the stack name and try update-stack again

D. Wait for the current update to finish before running update-stack again

Solution

1. Step 1: Understand stack states during update

   When a stack is in UPDATE_IN_PROGRESS, it means an update is already running and must complete before another update starts.

2. Step 2: Choose the correct action

   Waiting for the current update to finish avoids conflicts and errors. Deleting or renaming the stack is unnecessary and may cause data loss or confusion.

3. Final Answer:

   Wait for the current update to finish before running update-stack again -> Option D

4. Quick Check:

   UPDATE_IN_PROGRESS means wait before next update [OK]

Hint: Wait for update to finish before next update [OK]

Common Mistakes:

• Trying to delete stack during update
• Renaming stack instead of waiting
• Ignoring error and retrying immediately

5. You want to update a stack but also ensure that if the update fails, the stack rolls back to its previous state automatically. Which AWS CloudFormation option should you avoid using with update-stack to achieve this?

hard

A. --rollback-configuration

B. --no-rollback

C. --disable-rollback

D. --enable-rollback

Solution

1. Step 1: Understand rollback behavior in update-stack

   By default, CloudFormation rolls back stack updates on failure. The --disable-rollback option disables this behavior.

2. Step 2: Identify the correct option to keep rollback enabled

   To ensure rollback happens automatically on failure, you should NOT disable rollback. Therefore, do not use --disable-rollback. The default behavior is rollback enabled, so omit this option or explicitly avoid disabling rollback.

3. Step 3: Analyze options

   --rollback-configuration is for configuring alarms, --enable-rollback and --no-rollback are not valid AWS CLI options.

4. Final Answer:

   --disable-rollback disables rollback; omit it to keep rollback enabled -> Option C

5. Quick Check:

   Omit --disable-rollback to keep rollback on failure [OK]

Hint: Do not use --disable-rollback to keep rollback active [OK]

Common Mistakes:

• Using non-existent --enable-rollback option
• Confusing disable-rollback disables rollback
• Assuming rollback is off by default