Unlock the simple secret to forcing AWS CloudFormation to re-evaluate parameter properties without a full stack replacement. Learn three field-tested methods to resolve this common and frustrating DevOps challenge.

How Did I Not Know This CloudFormation Trick for Six Years?

It was 2 AM. A red alert flashed across my screen: “DATABASE_CONNECTION_FAILED”. The on-call SRE had just rotated the master password for our core `prod-db-01` RDS instance, a standard security procedure. The new password was sitting safely in SSM Parameter Store. The problem? The fleet of EC2 instances that relied on that password, launched by CloudFormation, had no idea. Their UserData script, which pulls the password on boot, had already run. We triggered a pipeline to update the stack, hoping CloudFormation would see the new SSM parameter value and trigger a rolling update. Nothing. The change set came back empty. CloudFormation, in its infinite wisdom, saw that the parameter name in the template hadn’t changed and decided there was nothing to do. We were dead in the water, and for a few panicked minutes, the only solution seemed to be tearing down the entire fleet. That’s a feeling I wouldn’t wish on my worst enemy.

The “Why”: CloudFormation’s Blind Spot

Before we dive into the fixes, you need to understand why this happens. It’s not a bug; it’s a feature of how declarative infrastructure as code works. CloudFormation determines changes by performing a “diff” on your template file, comparing the new version to the one it used for the last successful deployment.

When you use a dynamic reference like {{resolve:ssm:/prod/db/password}}, CloudFormation sees the name of the parameter, not its value. So, when the value inside Parameter Store changes, your template file doesn’t. You can run aws cloudformation update-stack a hundred times, and it will keep telling you “No changes to deploy” because, from its perspective, nothing is different.

It’s only looking at the blueprint, not the finished building. This is where we, as engineers, need to give it a little nudge.

The Fixes: From Field Splint to Surgery

Over the years, my team and I have come up with a few ways to handle this. Here are three, ranging from a quick battlefield patch to a proper, long-term solution.

Solution 1: The Quick Fix (The “Version” Dummy Parameter)

This is the classic, slightly hacky method that gets you out of a jam at 2 AM. The idea is to add a completely useless parameter to your template whose only job is to change when you need to force an update.

You add something like this to your parameters section:

Parameters:
  ForceUpdateVersion:
    Type: String
    Description: "Change this value to force an update, e.g., v1.0.1, or a timestamp."
    Default: "v1.0.0"

You don’t have to actually use this parameter anywhere in your resources. Its mere presence is enough. When you need to force the stack to re-evaluate everything (like your SSM parameter), you just change the value you pass for ForceUpdateVersion in your deployment command:

aws cloudformation update-stack --stack-name my-app-stack \
--template-body file://template.yaml \
--parameters ParameterKey=ForceUpdateVersion,ParameterValue=v1.0.1

CloudFormation sees that a parameter value has changed, generates a change set, and re-evaluates all the property values in your resources, pulling in the new secret from SSM.

Darian’s Take: This works, and it’s saved my skin more than once. But let’s be honest, it’s a code smell. It adds clutter and isn’t intuitive for new team members. Use it in an emergency, but don’t make it your standard operating procedure.

Solution 2: The Permanent Fix (Using Explicit Versioning)

This is the “right” way. Instead of letting CloudFormation pull the latest value of a parameter, you tell it exactly which version to use. Both SSM Parameter Store and Secrets Manager support versioning on your secrets.

When you update a secret, it creates a new version. To make CloudFormation aware of the change, you update your template to point to that new, specific version number.

Your dynamic reference changes from this:

UserData:
  Fn::Base64: !Sub |
    #!/bin/bash
    DB_PASSWORD={{resolve:ssm:/prod/db/password}}
    # ... rest of script

To this:

UserData:
  Fn::Base64: !Sub |
    #!/bin/bash
    DB_PASSWORD={{resolve:ssm:/prod/db/password:2}} # Note the version number at the end
    # ... rest of script

This is truly declarative. The template file itself is now the source of truth for which version of a secret is deployed. Your CI/CD pipeline becomes more robust: the process is now 1) Update secret in SSM, which creates version 3. 2) Update the template file to point to `:3`. 3) Commit and deploy. CloudFormation will always see the change.

Solution 3: The ‘Hidden Gem’ (Toggling the Description)

This is the trick that inspired this post, the one I can’t believe I missed for so long. It’s a clever middle ground between the hacky dummy parameter and the full versioning implementation.

The trick is to modify a metadata field on the parameter itself within the CloudFormation template. The Description field is perfect for this.

Let’s say your parameter looks like this:

Parameters:
  DatabasePasswordSsmPath:
    Type: 'AWS::SSM::Parameter::Value<String>'
    Default: '/prod/db/password'

To force an update, you simply add or change a description:

Parameters:
  DatabasePasswordSsmPath:
    Type: 'AWS::SSM::Parameter::Value<String>'
    Default: '/prod/db/password'
    Description: "Forcing update for Q4 password rotation." # This is a new line

CloudFormation sees this change to the parameter’s definition and triggers an update, re-resolving the value. The next time you need to do it, you can just change the description text or even remove the description field entirely. Either action constitutes a template change.

Which One Should You Use?

Here’s a quick breakdown to help you decide:

Method	Pros	Cons
1. Dummy Parameter	Simple to implement; great for emergencies.	Hacky; adds unnecessary clutter to the template.
2. Explicit Versioning	The most robust, declarative, and “correct” way. Follows IaC best practices.	Requires a more disciplined workflow (update secret, then update template).
3. Toggle Description	Cleaner than a dummy parameter; no unused code. Very low effort.	Still relies on a manual “trick” rather than a systematic process.

My final advice? For any greenfield projects or critical production systems, build your pipelines around Solution 2: Explicit Versioning. It will save you from chaos in the long run. For existing legacy stacks or one-off updates, Solution 3: Toggling the Description is a fantastic, clean trick to have in your back pocket. And for that 2 AM emergency? You have my full permission to use the dummy parameter and clean it up in the morning. We’ve all been there.

---

🤖 Frequently Asked Questions