Your primary goal for deployments includes minimizing the overall time and effort required for it, while having predictability, flexibility, and visibility for each of the steps required to install and run your cloud applications. AWS CloudFormation provides an easy way to create and manage the AWS resources for your application. In addition, CloudFormation allows you to do all this in a declarative and parametrized manner while managing all of the dependencies for you.
It is important that you use CloudFormation right from the beginning even if your initial configuration is simple enough to be provisioned and managed using the console. Also ensure that all subsequent changes to your stacks flow through CloudFormation as well, in order to avoid unpredictable results. If you need to make a change from outside of CloudFormation, then you should have a process in place to make the appropriate changes in the CloudFormation template before any subsequent stack updates. Ensure you protect your stacks from accidental or inadvertent changes by strictly managing changes or updates to your templates using tag-based IAM policies. You can also create stack policies that can prevent changes to certain resources, for example, disallowing any changes to the database while changes are being made to other resources in the stack. Use comments to describe the resources and other elements in your templates. Following these practices will minimize the chance of errors during the provisioning and updating of your environments.
A typical high-level workflow using CloudFormation is shown in the following figure. The business requirements drive your application’s design and infrastructural requirements. Subsequently, these designs and infrastructural requirements are realized in your application's code and templates. CloudFormation templates are ideal for provisioning and replication of your application's technology stack.
The feedback loop helps you address your evolving business requirements, and also improves your designs and processes over time. As costs form an important input that I sent to the feedback loop, you can use the AWS Cost Explorer to obtain the costs associated with your stack (by assigning appropriate tags to your resources):
The technology stack largely consists of hardware, the OS, libraries, and your application packages and/or code. You can define one or more stacks based on your application layers and environments, that is, dev, test, staging, and production. In addition, you can also define nested stacks to address various layers or components in your architecture. CloudFormation templates that reference other templates result in nested stacks or a tree of stacks. This is typically done to drive as much reusability as possible to your deployment processes. For example, if you have several websites sharing common requirements in terms of their load balancing and autoscaling features, then you can create a template for your ELB and autoscaling groups, and reuse it across multiple stacks.
Multiple stacks are typically required not only to organize your implementation according to layers or environments but also because these layers and environments have different characteristics. These characteristics may include different life cycles associated with your AWS resources or different ownership associated with the layers in your architecture. In addition, if you have services and/or databases that are shared by multiple applications, then having a separate stack for them will help you manage these resources better.