CloudFormation

The first three chapters described things you would create by hand: accounts and guardrails, roles and policies, keys and secrets. Doing that by clicking does not scale, cannot be reviewed, and cannot be repeated. AWS CloudFormation is AWS's own answer: you describe the resources in a template, CloudFormation creates them together as a stack, and later changes go through the same template. This chapter builds one real template (the encrypted bucket, queues and role from the last two chapters), then goes through parameters, mappings, conditions, change sets, failure and rollback, deletion policies, drift and quotas. Every template here is checked with cfn-lint, and the parts of CloudFormation that need an account are modelled or labelled.

A Template, Section by Section

The documentation's rule is short: the Resources section "is required in every CloudFormation template"; everything else is optional. The sections: Description, Metadata, Parameters (values supplied when you create or update the stack), Rules (checks on parameter combinations), Mappings ("lookup tables"), Conditions, Transform (macros, including the Serverless Application Model), Resources and Outputs (values returned for viewing or for other stacks). Each resource has a logical ID unique in the template, a type and its properties.

The template below is the running example. It builds, for one environment, the pieces AWS Intermediate/Advanced 3 argued for: a KMS key with the root statement that delegates to IAM policies and a separate administrator statement, an S3 bucket encrypted with that key (and refusing plain-HTTP requests), a work queue with a dead-letter queue, a worker role that gets exactly what it needs, and a backlog alarm that exists only in production. First the inputs:

Then the key and its alias. The key policy has no statement naming the worker role, on purpose: the role gets kms:Decrypt from its own identity policy because the root statement delegates. Naming the role in the key policy would make the key depend on the role and the role (whose policy refers to the key) depend on the key, which is a circular dependency that cfn-lint rejects (see the experiment below). DeletionPolicy and UpdateReplacePolicy are both Retain for the data stores.

The bucket, its policy and the two queues:

Run here (level 1). The whole template, linted:

Clean, with exit status 0. Everything below that is "cfn-lint says" means that exit status and those rule IDs; I observed 0 for clean, 2 for errors, 4 for warnings and 6 for both.

Parameters

Parameters are inputs you supply when you create or update a stack. From the documentation: the only required attribute is Type; Number "is validated as a number; however, when you use the parameter elsewhere ... the parameter value becomes a string"; CommaDelimitedList gives "an array of literal strings that are separated by commas" with each member "space trimmed"; List<Number> becomes a list of strings. The constraints are AllowedValues, AllowedPattern (for a String "the pattern must match the entire parameter value"), MinLength, MaxLength, MinValue, MaxValue, ConstraintDescription and Default. A parameter with no default and no value fails the stack with Parameters: [KeyName] must have values. A template may have at most 200 parameters. There are also AWS-specific types (key pair names, VPC IDs) and Systems Manager parameter types that look up the latest value in Parameter Store.

Run here (level 1). To check my understanding of these rules I wrote a small resolver: it takes a template and parameter values, applies the documented rules, and shows what the template becomes. Values only AWS knows (a resource's ID or attribute) stay as placeholders. It is a model, tested below. Here it renders the template for two environments and rejects four bad parameter sets:

Production gets a longer visibility timeout, a different redrive count and an alarm and output that development does not have, all from one template. Note how each bad input fails: a value below MinValue, a value outside AllowedValues, a pattern failure (the message uses the page's wording, with the template's ConstraintDescription), and a missing value with the page's exact message.

Mappings, Conditions and Intrinsic Functions

Mappings are two-level lookup tables used with Fn::FindInMap; the template above uses one to choose queue settings by environment. Conditions are named true/false values built with Fn::Equals, Fn::And, Fn::Or, Fn::Not, and you attach them to resources and outputs (Condition: IsProd) or to property values with Fn::If. Rules from the Condition functions page:

• Fn::And and Fn::Or take "the minimum number of conditions ... is 2, and the maximum is 10".
• Inside Fn::Equals and the other condition functions you may use only Ref, Fn::FindInMap and other condition functions. (Fn::If itself accepts a longer list, including Fn::Sub and Fn::GetAtt.)
• Fn::If can return AWS::NoValue to remove a property entirely.
• "You can use intrinsic functions only in specific parts of a template": resource properties, outputs, metadata attributes and update policy attributes, and to conditionally create resources. That list does not include DeletionPolicy.

The full list of functions on the reference page: Fn::Base64, Fn::Cidr, the condition functions, Fn::FindInMap, Fn::ForEach, Fn::GetAtt, Fn::GetAZs, Fn::GetStackOutput, Fn::ImportValue, Fn::Join, Fn::Length, Fn::Select, Fn::Split, Fn::Sub, Fn::ToJsonString, Fn::Transform, Ref and rule functions. The resolver models the first group; it refuses Fn::GetAZs, Fn::Cidr, Fn::Transform, Fn::ForEach, Fn::Length and Fn::ToJsonString rather than guess.

Run here (level 1). I ran the documentation's own examples through the resolver (the parameter type examples, the EnvType condition sample for prod, dev and test, the subnet Select/Sub example, the NoValue snippet, the condition-function limits) and wrote each expected answer first:

All 33 counted cases match, and the control (one expectation flipped) reports one mismatch. One result is a finding, deliberately not counted: the Parameters page's subnet example builds an availability zone with ${AWS::Region}${AZ} where AZ is one of the page's own default values, us-west-2b. With the Region us-west-2 that resolves to us-west-2us-west-2b. The example only makes sense if the list held bare letters like b. cfn-lint did not notice (it reported only a warning about the default VPC value). I also checked the YAML trap the page warns about: an unquoted [Yes, No] is read as booleans by PyYAML and by cfn-flip's loader, so AllowedValues with Yes and No needs single quotes. Three small cases (Fn::Join, Fn::Split with Fn::Select, and the ${!Literal} escape in Fn::Sub) come from my own knowledge of those functions, not from pages I read.

Linting: What cfn-lint Catches and What It Does Not

cfn-lint checks a template against the resource schemas that CloudFormation publishes, plus rules of its own, without any AWS call. To learn what it really catches I broke app_stack.yaml in 22 specific ways (each a plain text replacement) and generated six templates that break documented quotas. A mutation that is not flagged is a gap in the tool, not in the experiment:

Read the result in three parts. Caught well: a misspelt property, a wrong type, a reference to something that does not exist, a missing required property, a bad GetAtt, a Default outside AllowedValues, an invalid DeletionPolicy, an undefined condition, a malformed S3 bucket name, an IAM Effect typo, a value above a service maximum, and the circular dependency (E3004 names the loop). Caught only as a warning (exit status 4): an unused parameter or condition, an output that refers to a conditional resource without the condition, an IAM action missing its service prefix. A pipeline that fails only on errors will let these through. Not caught at all (4 of 22): Fn::Sub inside Fn::Equals (the documentation says it is not allowed), DeletionPolicy written with !If, a FindInMap key that exists in no mapping, and a Number parameter whose Default is the word thirty. For the quotas, cfn-lint flagged 501 resources, 201 outputs and a 1,100-byte description, accepted exactly 500 resources, and did not flag 201 parameters (only an unused-parameter warning) or a 62 KB template body. Each of those is a reason to keep a second check, such as the resolver below, and a reason to test on one account before the first real deploy.

Next, the documentation's own example templates, which you would expect to be clean:

The EnvType sample and Chapter 1's SCP template are clean. The subnet example gets warnings because its default VPC value vpc-123456 is not a valid VPC ID pattern, and the page's DeletionPolicy: Retain example gets W3011: "Both 'UpdateReplacePolicy' and 'DeletionPolicy' are needed to protect resource from deletion". That second warning is why the main template sets both.

Quotas to Design Around

From the CloudFormation quotas page (read 2026-10-12):

The deploy command in the CLI needs --s3-bucket for templates "greater than 51,200 bytes". My own quota checker (below) applied those numbers to the template and to the generated ones and agrees with the experiment above, including the two cfn-lint misses (parameters and body size).

Stacks, Change Sets and Deploying

A stack is the set of resources created from one template. Updating means giving CloudFormation a changed template or new parameter values. The safe route is a change set: "Change sets allow you to preview how proposed changes to a stack might impact your running resources". The flow on the page: create the change set (nothing changes yet), view it (which resources will be added, modified or removed, with a before/after for properties), optionally create more, and execute the one you want. After an execution "CloudFormation removes all change sets that are associated with the stack". One caution stands out: "Change sets don't guarantee that CloudFormation will successfully update a stack". Pre-deployment validation catches common causes (syntax errors, name conflicts, quota limits) but "failures that occur because of runtime conditions ... might still occur during execution".

A modification "can cause the resource to be interrupted or replaced (recreated)", which is the field you read most carefully. The page's example output shows "Action": "Modify" and "Replacement": "False" with property-level details. aws cloudformation deploy wraps all of this: it "deploys the specified AWS CloudFormation template by creating and then executing a change set", and with --no-execute-changeset it stops after creating it so you can review it. Its documented options include --parameter-overrides Key=Value, --capabilities (CAPABILITY_IAM or CAPABILITY_NAMED_IAM; without it, an IAM template fails with InsufficientCapabilities), --fail-on-empty-changeset (by default an empty change set exits with status 0) and --s3-bucket. Level 2, not run here:

Which capability does a template need?

The page says: "If you have IAM resources, you can specify either capability. If you have IAM resources with custom names, you must specify CAPABILITY_NAMED_IAM." I wrote that rule as a checker (my list of name properties, since the page says only "custom names": RoleName, UserName, GroupName, InstanceProfileName, ManagedPolicyName). Its results are in section 3 of the output further down: app_stack.yaml needs CAPABILITY_IAM, adding RoleName makes it CAPABILITY_NAMED_IAM, and Chapter 1's SCP template needs neither.

An approximation of a change set, computed locally

You cannot create a change set without an account, but you can approximate the most important question: will this edit replace something? The resource schemas bundled in cfn-lint list each type's create-only properties, the ones that cannot be changed on an existing resource. My approximation renders the old and new template, lists Add, Remove and Modify with property-level differences, and calls a modification Replacement: True when a changed property is create-only, Conditional when it is conditionally create-only, and False otherwise. It is not a change set: a False can still be an interruption (the schema does not record those), and I did not read the page's definitions of True and Conditional, so those two meanings are my own.

Four lessons. (1) Changing a parameter from dev to prod adds the alarm and modifies three resources, with no replacement. (2) Adding a fixed BucketName or QueueName to an existing resource is a replacement: the properties are create-only, and naming resources is the classic way to make a harmless-looking edit destructive. (3) Renaming a logical ID is not a rename: it is a remove plus an add, and everything that referred to it changes too (here the bucket policy's Bucket is create-only, so it is replaced, and the role's policy changes). That chain is derived from the documented Add/Remove behaviour, not a quoted sentence. (4) The schema lists no create-only properties for AWS::KMS::Key; I report that and make no claim about what real CloudFormation does when a key's other properties change.

When a Deployment Fails

The "Stack failure options" page describes how a failed operation behaves. CloudFormation "identifies dependencies between resources to parallelize independent provisioning actions", and "stops at the first failure in each independent provisioning path. A failure in one path doesn't affect other provisioning paths". If you choose Preserve successfully provisioned resources (--disable-rollback, or on-failure DO_NOTHING), the successful resources stay, the failed one is left in a failed state (CREATE_FAILED), and you can Retry (for a cause such as a missing IAM permission), Update (the template was wrong) or Roll back. Without that option the default is the rollback you are used to. The CLI command rollback-stack returns a failed stack to "its last stable state" and "will delete a stack if it doesn't contain a last known stable state". With express mode, rollback is off unless you turn it back on.

Rollback triggers let CloudWatch alarms stop a deployment: you name up to 5 alarms (or composite alarms) and a monitoring time of 0 to 180 minutes after the deployment; if any goes to ALARM during the operation or that period, "CloudFormation rolls back the entire stack operation". They are not monitored while a rollback is happening, and a missing alarm makes the whole operation fail and roll back.

Run here (level 1): I extracted the dependency graph from the template (references, GetAtt, Sub variables and DependsOn), and applied the documented behaviour to it: which resources get created, which fail, and which are never attempted when one resource fails. This is a model of those sentences, not CloudFormation. Section 3 shows the capability checker and section 4 the quota checker.

Read the waves: the key must exist first, then the alias, bucket and dead-letter queue can go in parallel, and so on. When the key fails, nothing else is attempted. When the dead-letter queue fails, the key, alias, bucket and bucket policy are still created (an independent path) but the work queue, role and alarm are never attempted. When the worker role fails, everything else exists. The circular-dependency check finds the same loop as cfn-lint's E3004, which is the cross-check I trust more than either alone. The quota section agrees with the cfn-lint experiment.

Deletion and Replacement Policies

DeletionPolicy controls what happens to a resource when its stack is deleted (and when you remove the resource from the template). The documentation:

• Delete (the default): the resource is deleted. Exceptions: the default is Snapshot for AWS::RDS::DBCluster and for AWS::RDS::DBInstance without a DBClusterIdentifier. For an S3 bucket "you must delete all objects in the bucket for deletion to succeed".
• Retain: keep the resource, "continue to incur applicable charges until you delete those resources". Allowed on any resource.
• RetainExceptOnCreate: like Retain, except that a rollback of the stack operation that created the resource still deletes it (new empty resources go, in-use ones stay).
• Snapshot: for resources that support it (EBS volumes, RDS instances and clusters, ElastiCache, Redshift, DocumentDB and Neptune clusters are on the page's list), take a snapshot first; the snapshot continues to incur charges.

Two traps. The page says the policy "doesn't apply to resources whose physical instance is replaced during stack update operations", so a harmless-looking edit that forces a replacement (previous section) is not protected by DeletionPolicy alone; UpdateReplacePolicy is the other half, and cfn-lint's W3011 says to set both (I did not read the UpdateReplacePolicy page itself). And DeletionPolicy takes a plain string: the experiment above shows cfn-lint accepting !If there, which the documentation's list of places for intrinsic functions does not allow. The page also advises: if you want to change retained resources outside CloudFormation, use Retain then delete the stack, "otherwise, your resources might get out of sync with your CloudFormation template".

Drift

Drift detection compares what a template says with what exists. The page: "Performing a drift detection operation on a stack determines whether the stack has drifted from its expected template configuration, and returns detailed information about the drift status of each resource in the stack that supports drift detection". A stack "is considered to have drifted if one or more of its resources have drifted". You run detect-stack-drift, watch it with describe-stack-drift-detection-status (it "may take several minutes"; one run at a time per stack), and read the details with describe-stack-resource-drifts. The page also warns to confirm the stack's Last drift check time is earlier than the resource results, "to prevent the use of stale data". Detection reports; it does not fix anything.

Run here (level 1): I took the page's own example (a queue whose expected and actual properties are printed as JSON) and computed the property differences. The result reproduces the page's output exactly: /DelaySeconds actual 120, expected 20, and /RedrivePolicy/maxReceiveCount actual 12, expected 10. This only compares two documents; real drift detection reads the real resources. ADD and REMOVE are my extension of the comparison.

Nested Stacks, StackSets, Exports and Terraform

Nested stacks split a large template into smaller ones; the quotas page notes you can have "a nested stack hierarchy with more than 2500 total resources", but not change more than 2,500 in a single operation. StackSets deploy a stack to many accounts and Regions; their limits are in the table above, and "StackSets does not currently support creating or updating stack sets with service-managed permissions from templates that contain macros", which includes transforms. Both are level 3 here. Outputs and exports: the outputs page did not load in the tool, so I did not read it; what follows is the tool's paraphrase from general knowledge and is unverified: export names must be unique within an account and Region, and a stack whose exported output another stack imports cannot be deleted or have that export changed. Check the page before relying on either. The function list above shows Fn::ImportValue and the newer Fn::GetStackOutput.

CloudFormation or Terraform? Terraform / Infrastructure as Code covers Terraform's own plan, apply and state. I will not repeat that here, and I did not verify claims about Terraform in this session. The choice usually turns on questions you can answer yourself: does your estate span clouds or services outside AWS, who will operate the tool and hold its state, and which preview (a change set here, a plan there) your reviewers will read. AWS Intermediate/Advanced 5 adds the AWS CDK, which generates templates like this one from code.

YAML and JSON

A template can be YAML or JSON. YAML allows short-form functions (!Ref, !Sub) and is much shorter; JSON has no comments and no short forms. Run here (level 1): cfn-flip converted the main template to JSON and back.

The data is identical in both forms and after the round trip, the JSON is about 2.3 times the size, and cfn-lint gives the same answer on both (the same rule, E3002, but at a different line, so line numbers in a report refer to whichever file you gave it). The converted JSON is also larger against the 51,200-byte request limit.

Cost and Clean-Up

Nothing in this chapter created anything in AWS. If you deploy app_stack.yaml in a sandbox account, it creates a KMS key ($1 a month while it exists, from AWS Intermediate/Advanced 3), a bucket and two queues, a role and, in production, an alarm. Because the key and bucket have Retain policies, deleting the stack leaves them behind and they keep costing money until you remove them. Not run here:

A key scheduled for deletion waits 7 to 30 days (default 30) and cannot be recovered after that (AWS Intermediate/Advanced 3). Put a budget alert in place first (AWS Fundamentals 9) and use the sandbox account from AWS Intermediate/Advanced 1.

Practice