CloudFormation dynamic references: keep secrets out of templates

Use dynamic references so CloudFormation fetches a secret from AWS Secrets Manager or Systems Manager Parameter Store at deploy time, instead of putting it in the template or a parameter file. AWS recommends this over embedding credentials. Know the limits, because some resource properties and custom resources cannot use them.

The idea

A dynamic reference is a placeholder in the template that points at an external value. CloudFormation retrieves the value when it is needed during stack and change set operations and passes it to the resource. AWS's security guidance says CloudFormation never stores the actual reference value.

There are three kinds: plaintext Parameter Store values, secure strings from Parameter Store, and secrets from Secrets Manager.

Why not just use NoEcho

The NoEcho attribute on a parameter masks the value in console and API output, but the value still has to be supplied by whoever deploys, which means it exists in a pipeline variable, a parameter file or someone's clipboard. A dynamic reference moves the secret into a store with its own access control, rotation and audit trail, and your deploy role needs permission to read it.

Rules from the documentation

• Primary identifiers. Avoid putting dynamic references, or any sensitive data, in properties that form a resource's primary identifier. CloudFormation may use the plaintext value in the resource ID, which can appear in outputs and other destinations. The resource reference shows which properties make up the identifier, through the return value of Ref.
• Count limit. A template can hold up to 60 dynamic references.
• Transforms. With transforms such as AWS::Include or AWS::Serverless, the reference is passed through as a literal string and resolved when the change set runs.
• Unsupported places. Secure values cannot be used in custom resources, in AWS::CloudFormation::Init metadata, or in EC2 UserData properties.
• Trailing backslash. A reference ending in a backslash cannot be resolved and breaks stack operations.

Operating the pattern

1. Create the secret in Secrets Manager, or a secure string in Parameter Store.
2. Reference it in the template where the resource property accepts it.
3. Grant the deploy role read access to that one secret only.
4. Turn on rotation where the secret supports it, and plan for how the new value reaches running workloads.
5. Review CloudTrail for who reads the secret and when.

Better still, for database credentials, let the database service manage the secret and have the application read it at runtime, so CloudFormation never handles it.

Review checks

• No literal passwords, tokens or keys in templates or parameter files.
• No parameter named like a secret without NoEcho, and ideally no such parameter at all.
• Dynamic references only in supported properties.
• Secret access policies scoped to named secrets, not a wildcard.

A text scan of templates and parameter files is cheap and catches many mistakes before merge. Safeguard's policies and gates can hold a pull request until checks you define pass, and its compliance evidence automation can keep the review records.

Quick check

Sources

• Get values stored in other services using dynamic references (AWS CloudFormation)
• Security best practices for CloudFormation (AWS)

Last reviewed: 19 October 2026.