Managing Infrastructure with AWS CloudFormation

Welcome back. Your budget alerts are in place; now you can use them while practising a complete infrastructure lifecycle. In this lesson, you will create a small AWS CloudFormation stack, inspect what it deployed, update it through a change set, and delete it. The lab uses one empty S3 bucket rather than an EC2 instance, so you can concentrate on CloudFormation without leaving a running server behind.

CloudFormation is useful well beyond this lab. When you later build VPCs and multi-tier workloads, a template lets you describe the intended infrastructure and repeat a deployment. For SAA-C03, the important distinction is that writing or reviewing a template does not provision resources: CloudFormation acts when you create a stack or execute an update.

---

Understand what CloudFormation owns

A template is a YAML or JSON description of resources. A stack is a deployment of that template in an AWS account and Region. The template gives each resource a logical ID; once deployed, CloudFormation also records the physical resource it created. In this lab, LabBucket will be the logical ID, while its physical ID will be the generated S3 bucket name.

The short demonstration below shows the lifecycle in the console. Watch for the separation between creating a change set—which previews an update—and executing it—which applies the update. Do not copy the video's infrastructure: its EC2, EBS, and security-group configuration differs from this lower-cost lab.

AWS’s Creating your first stack explains the template sections and the event history you will use. Read the conceptual passages rather than following its EC2 web-server deployment; that example requires different resources and may incur different charges.

---

Create a small stack

Before deploying, check that your budget is still active and choose the Region where you want this lab to run. Keep the same Region throughout the lab: CloudFormation stacks are regional, even though S3 bucket names must be globally unique. Use an identity with permission to operate CloudFormation and create and delete an S3 bucket.

Save the following as bucket-lifecycle.yaml on your computer:

AWSTemplateFormatVersion: '2010-09-09'
Description: Small CloudFormation lifecycle lab

Parameters:
  LabStage:
    Type: String
    Default: initial
    AllowedValues:
      - initial
      - reviewed

Resources:
  LabBucket:
    Type: AWS::S3::Bucket
    Properties:
      Tags:
        - Key: LabStage
          Value: !Ref LabStage

Outputs:
  BucketName:
    Description: Generated physical name of the lab bucket
    Value: !Ref LabBucket

There is only one resource. Because the template supplies no BucketName property, CloudFormation generates a unique name rather than asking you to invent one. The LabStage parameter supplies the bucket’s tag value, and !Ref LabBucket makes its physical name visible as a stack output. You do not need to upload objects or make the bucket public.

In the CloudFormation console, create the deployment:

1. Choose Create stack → With new resources (standard). Select an existing template, upload bucket-lifecycle.yaml, and continue.
2. Name the stack BucketLifecycleLab. Leave LabStage at initial.
3. Leave termination protection off for this disposable lab; otherwise, it will prevent stack deletion. Review the configuration and submit.
4. Open the stack’s Events tab until its status is CREATE_COMPLETE. Then inspect Resources and Outputs. Record the bucket’s physical name from the BucketName output and confirm that the resource’s physical ID matches it.

CloudFormation reports progress for both the bucket and the stack. If creation fails, use the earliest relevant CREATE_FAILED resource event and its Status reason to diagnose the problem; the final stack status alone rarely explains enough. A failed creation commonly rolls back, but you should still inspect the result.

An empty bucket avoids ongoing object-storage usage, but “small lab” does not mean a promise of zero cost: requests or other account activity may be chargeable. Do not leave the stack simply because the bucket is empty.

---

Preview and apply an update

You could edit the template and upload a new version. Here, the template already exposes the desired change as a parameter, so you can practise an update without editing the file. Change LabStage from initial to reviewed. The proposed infrastructure change is a bucket tag update, not a second bucket.

Select BucketLifecycleLab and create a change set for the current stack (the control may appear under Stack actions or the Change sets tab). Choose Use existing template. On the parameter screen, change LabStage to reviewed; if the console offers Use existing value, clear it for this parameter. Continue, name the change set if prompted, and submit it.

When its status is ready for review, examine the proposed changes before executing. You should see a Modify action for LabBucket, not the addition of another bucket. Inspect any replacement indication: for this tag-only update, you expect the existing bucket to remain in place. A change set previews CloudFormation’s planned resource operations; it is not a full guarantee that an update cannot fail or disrupt an application.

If the change set matches the intended tag update, choose Execute. Wait for UPDATE_COMPLETE. Check the bucket’s tag in the S3 console and compare the stack’s BucketName output or resource physical ID with the value you recorded earlier. It should be the same bucket, now tagged reviewed. If the change set shows no changes, return to the parameter selection and check whether the old value was retained.

This distinction matters when an update is less harmless than a tag change. Some resource properties can be modified in place; others require CloudFormation to replace a resource. In AWS’s update guide, “Availability and impact considerations” explains why you must assess an update’s effect rather than assuming every change is in place.

---

Delete the stack—and verify cleanup

A stack is also a boundary for cleanup: deleting it tells CloudFormation to delete the resources it manages, subject to resource behavior and any deletion policies. This template specifies no retention policy, so its bucket is intended to be deleted with the stack. Keep it empty; an S3 bucket containing objects can prevent ordinary stack deletion.

AWS’s first-stack guide describes how to monitor deletion. Its later, separate instructions for deleting a template-storage bucket apply to its particular walkthrough, not to a bucket you need to create separately for this lab.

Select only BucketLifecycleLab, choose Delete, and confirm. Watch Events for deletion progress. A completed deletion may remove the stack from the active-stack list; use the stack-status filter or deleted-stack view if you need to inspect its final status. Then search for the recorded bucket name in S3 to confirm it is gone. If you see DELETE_FAILED, read the failing resource’s status reason, correct the cause—for example, objects placed in the bucket—and retry rather than assuming cleanup happened.

Finally, check your budget and billing view again, allowing for reporting delay. CloudFormation deletion addresses resources in this stack; it does not remove unrelated resources you created manually.

---

Key takeaways

You deployed a template as a stack, used Events, Resources, and Outputs to inspect it, previewed a parameter-driven update with a change set, executed that update, and verified deletion. Remember the operational boundary: a change set is a review opportunity, while executing it changes real infrastructure; deleting a stack requires checking the final resource outcomes.

In the next lesson, you will distinguish CloudTrail, AWS Config, and CloudWatch. The stack events you used here provide useful deployment progress, but those services answer broader questions about API activity, configuration history, and operational health.