It is a good practice to avoid including secure data such as passwords, service tokens, and API keys in your templates as they will most likely be added to some code version control. Passing them as parameter values during runtime should ideally be avoided as those values can be identified from the stack inputs. AWS CloudFormation offers integrations with services such as AWS Secrets Manager and AWS Parameter Store to securely transfer data at runtime. Without building any additional toolingor workflows, you can directly reference those parameter keys in your template and CloudFormation will inject them during stack operations. Of course, appropriate IAM permissions will have to be ensured for CloudFormation to be able to extract those values.
This integration can be used to retrieve the entire secret string or a particular value from the secret. To extract the password value of the SecureData secret stored in SecretsManager, you can use the ‘{{resolve:secretsmanager:SecureData:SecretString:password}}’ dynamic reference.
Leverage StackSets for organization-wide stack rollouts
Multi-account and multi-region environments require certain services to be enabled, or resources to be created, as soon as new accounts are vended. It is a good practice to roll out these resources with CloudFormation StackSets. StackSets extend the capabilities of stacks by providing an additional orchestration layer on top of them. You can target individual accounts or a group of accounts within an organizational unit (OU). StackSets can be a big productivity boost when you want to ensure a minimum baseline of resources in multiple regions and accounts. It helps you link a template definition to intended targets and manages all stack operations from that point onwards.
Avoid hardcoding parameter values
A rule of thumb for good template design is to not have any hardcoded parameter values. These can be passed at runtime to make a variety of configuration permutations possible. Production installations could use a different instance type than the test/dev environments. CloudFormation conditions can also be used to conditionally roll out certain resources in an environment.
Life cycle policies to protect critical resources
AWS resources that interact with your on-premises environments or maintain data and state are some examples of critical components. Losing them can result in unexpected application failures or data loss. CloudFormation offers life cycle policies that can safeguard such resources from accidental deletion. One such policy is DeletionPolicy, which marks any CloudFormation resource for retention when the stack is deleted. This avoids accidental removal and post-stack deletion as this resource is no longer managed by CloudFormation.
By default, some resources, such as AWS::RDS::DBCluster, go through a snapshot process before they are removed, but this is something you need to ensure on a per-resource basis.