As your environment expands on AWS, you may identify a need to reuse the same resource configurations over and over from one stack to the next across teams or projects. For instance, you may want to implement best practices across various projects by enforcing some specific guidelines in their infrastructure resource configurations, whether they are for network, storage, or compute resources. CloudFormation modules let you do just that. You can package specific resource configurations reflecting your best practices into modules and have other CloudFormation stacks reference these modules. This is quite useful for reusability as well as enforcing standards and best practices across multiple teams or projects. Moreover, it is also beneficial to improve traceability as CloudFormation will retain knowledge of which resources in a given stack come from a particular module. This approach also helps maintain current best practices over time since you register modules in the CloudFormation registry and maintain their lifecycle, which includes versioning. You also decide the AWS Regions and accounts in which each module is made available. Check out the Further Reading section at the end of this chapter if you’re interested in finding out more about how to reuse patterns at scale within your organization.
As has been emphasized many times in this book, infrastructure is code—well, at least in the cloud. So, your CloudFormation templates, modules, and all other artifacts that you use to define resources using IaC should be maintained exactly like you maintain application code. This means storing IaC code in a code repository (CodeCommit, GitHub, etc.) to properly manage its lifecycle as well as handling the rest of the lifecycle using CI/CD best practices.
Furthermore, it’s also essential to manage your stack resources through CloudFormation. Avoid, as much as possible, making changes to stack resources deployed outside of CloudFormation. After all, if you make the effort to codify your best practices and automate your AWS resources deployment using IaC, it’s not to see them spoiled with potentially harmful manual changes. If such manual changes occur, you will inevitably end up with a configuration drift between what your stack says should be deployed and what is actually deployed in your AWS environment, and reconciling the two can be quite grueling. Therefore, it is advised that you avoid making manual updates on stack resources. What is the best practice to update such resources, then? Simply use CloudFormation. First, you should make the changes in the template(s) or module(s) behind your stack and then create a change set to evaluate and verify the actual changes that will be made to your stack if you ask CloudFormation to commit those changes.
Never directly run an update to an existing CloudFormation stack—remember to use change sets. You may sometimes be surprised by the impact a template change has on your deployed stack resources. For instance, making what looks like an innocuous name change to an RDS database may lead to unrecoverable data loss if you forget to make a database backup just before rolling out the change; this is because CloudFormation will simply create a new database and tear down the old one. Once you’re happy with the changes documented in your change set, you can apply the change set to your stack, which will roll out the changes to your resources.
Use change sets…Really do
Don’t deploy CloudFormation updates directly without first using change sets, unless you’re okay with potential data losses and breaking changes to your stack resources. It’s better to be safe than sorry: remember to use change sets.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
