CloudFormation – Best Practices

AWS Resource Association with CloudFormation Stacks

AWS Cloudformation needs to be used extensively to create, manage and update AWS Resources within Stacksets. Each Stackset invokes a top-level CloudFormation Stack that hierarchically invokes child CloudFormation Stacks. The top-level CloudFormation stack is named based on the Stackset name:


{customer name}-{stack name}


Related child stacks are all prefixed with the name of their parent stack.

This approach associates all AWS resources that are provisioned within a Stackset to the created CloudFormation template(s) and provides a strong mechanism that signals the purpose, intent and life-cycle requirements for each of the Resources that comprise the CloudFormation stack.

CloudFormation templates can be tricky to maintain and edit by hand.  The CloudFormation template that underlies each of these stacks is generated dynamically from templates and config/variables files that are maintained within Stackset that change within the template are in many cases externalized into YAML config files that make it easy for administrators to reflect their intent for common use cases (e.g. changing network ACL ingress/egress rules).  The approach also makes it possible to use CloudFormation’s extensive capabilities to update stacks in place in running environments.

The association of resources with CloudFormation stacks also makes it straightforward to delete and re-create environments.  The ability to delete a top-level CloudFormation stack for each Stackset needs to be controlled by a common role. Only this role can delete the top-level CloudFormation stack, which in turns propagates the deletion of child stacks.  The CloudFormation service manages the orchestration of resource deletion and considers ordering and dependencies among resources within each stack.

Resource Tagging

AWS “User Tags” can be useful for utilization and cost analysis on your account. Tagging is an effective tool to help manage AWS resources at increasing scale, providing the ability to identify, classify and locate resources for management and billing purposes.  This information is most easily located in your detailed billing report.

Tagging Restrictions:

  • The following basic restrictions apply to tags:
  • Maximum number of tags per resource – 10
  • Maximum key length – 127 Unicode characters
  • Maximum value length – 255 Unicode characters
  • Tag keys and values are case sensitive
  • Tag keys must be unique per resource
  • Do not use the “aws:” prefix in your tag name or values because it is reserved for AWS use.

The tags used for this purpose should never be changed or deleted by individuals or programs other than Nucleator.  Modification of these tags will cause incorrect behavior of Nucleator.  The user tags used for this purpose are:

  • Owner – Identifier of the business-relevant principal that created/owns the asset
  • Name – A unique name of the asset
  • Linked account – Indicates the Business unit or department responsible for these assets
  • Offering – User Tag: Identifies the product, product line, development project, marketing campaign, or other other top-level business purpose for the AWS infrastructure
  • Purpose – User Tag: Identifies the (orthogonal to Offering) purposes for the infrastructure. These include types such as environment (production, demo, dev, test), business process step (orders, front-end, fulfillment), class of materials (public materials, campaign operations, crm), etc.
  • Environment – Prod, Test, Dev, Stage1, etc.
  • Customer – name of the customer this resource will focus on
  • Group – the product that will be used
  • Stackset
  • StacksetInstance

Naming Convention


CloudFormation stacks provide one way to reliably identify sets of related resources over the life-cycle of your AWS Account.

AWS EC2 Instance


{environment}-{group}-{role}-{region+availability}-{unique identifier}


When naming an AMI its a good practice to include the creation date as part of its name, and a complete description. This will minimize confusion when selecting AMI for new instances.


{environment}-{group}-{role}-{creation date (MMDDYYYY)}

Security Groups & IAM Roles



Do Not Embed Credentials in Your Templates

Rather than embedding sensitive information in your AWS CloudFormation templates, use input parameters to pass in information whenever you create or update a stack. If you do, make sure to use the NoEcho property to obfuscate the parameter value.

For example, suppose your stack creates a new database instance. When the database is created, AWS CloudFormation needs to pass a database administrator password. You can pass in a password by using an input parameter instead of embedding it in your template.

Key Benefits

Having a consistent resource naming and association with CloudFormation stacks provides the following benefits:

  • Simplified resource governance; related resources are named consistently and associated through the structure of CloudFormation stacks
  • Related resources can be easily discovered through the “Resources” tab in CloudFormation and by navigating parent/child stack relationships
  • Orchestration code for provisioning and resource dependency management is delegated to CloudFormation (important, this means you don’t have to write and maintain it)
  • Deleting and re-provisioning related sets of resources is straightforward
  • Many common changes can be made via tweaks to YAML configs that flow into generated CloudFormation templates that flow into in-place Updates to running environments
  • Consistent design rules for resource naming means the user spends less energy working out and resolving naming conflicts and name restrictions on cloud resources for various services.
  • Consistently named resources across multiple accounts makes it easier to use the filtering and search capabilities of the AWS Management Console, improves clarity-of-purpose for provisioned infrastructure, and makes ops less error-prone

Getting Started with AWS CloudFormation – Reading a Template

AWS has a vast number of services, 120+ in total, but the best way to manage those services is using AWS CloudFormation. AWS CloudFormation is used to create and manage a collection of AWS resources. This in turns allows provisioning and updating of resources. Most of all, what I think is the best solution is keeping version control. AWS CloudFormation Designer is also included, but offers a graphical tool for creating, viewing, and modifying AWS CloudFormation Templates. With the Designer you are able to drag-and-drop resources, and then edit the parameters using JSON or YAML.

Continue reading