Example CloudFormation Template

To keep things simple, let’s just provide the required Resources section and the template format version. We’ll define our S3 resource under this section. The Resources section is defined in the template below on line 3:

Next, we define a unique logical ID that will be used to reference the S3 bucket within the stack on line 4:

Let’s define the resource type that specifies what AWS resource we want to provision. The format of the resource type should be in the service-provider::service-name::resource-type form.

Since we want to create an S3 bucket, we’ll provide AWS as the service provider, S3 as the service name, and bucket as the resource type. Based on this information, the format of the resource type would be AWS::S3::Bucket, as seen on line 5 in the template below. Just this template would be able to create a valid stack with a randomly named S3 bucket provisioned within it.

Now, let’s say we also want to pre-configure some properties for the S3 bucket. We’ll need to provide the appropriate AWS-defined syntax for it in the template.

For example, we can configure the name of our S3 bucket as my-s3-bucket. The final template with the configured properties will be as follows on lines 6–7:

Now that we’ve finalized a CloudFormation template, we need to use it to provision a stack with an S3 bucket. To do so, we need to perform the following steps:

• Upload template to CloudFormation: We can either upload your template to an Amazon S3 bucket and generate the relevant S3 URL for it, or we can define the template inline in the API/SDK request to the AWS CloudFormation service.

• Create a stack with CloudFormation: CloudFormation then creates a new stack using the provided CloudFormation template after we also specify the stack name and any parameters and tags.

• Provision stack resources: Upon stack creation/modification, the S3 bucket with the name my-s3-bucket is also provisioned and ready for use.

Best practices

Here are some best practices that we can use when working with CloudFormation templates:

• Reuse CloudFormation templates: We can reuse the AWS CloudFormation template with which we have successfully deployed a stack and provisioned an infrastructure of AWS resources.

  • For example, we could’ve successfully tested stacks in development environments. We can reuse the templates of these development environments in the production environment where most of the configurations are the same, and we may only need to update the lower-cost instances to higher-cost instances.

• Avoid embedding credentials in templates: We need to avoid embedding any sensitive information in our CloudFormation template, as CloudFormation does not have any mechanism to omit, modify, or redact such information from the template once the stack is created. Instead, we need to use dynamic references to reference this sensitive data, for which we can utilize the AWS Systems Manager Parameter Store and AWS Secrets Manager services.

• Version control of the template code: We can use a version control system to track the changes and versions of a CloudFormation template. This practice makes it easier for us to easily revert back to the previous correct version in case of any failures.

• Validate templates before use: We can use the CloudFormation service to validate the template before using it to ensure there are no errors. We can also use any IDE or linter to make sure there’s a valid JSON or YAML code in our template.

• Improve portability of templates with pseudo parameters: We can increase the portability of our CloudFormation templates by using pseudo parameters, making our templates more dynamic.

  • For example, let’s say we want to reuse our template to provision the same set of resources across regions, and the one change in our template would be the specified region. We can easily utilize the AWS::Region pseudo parameter for this use case.

• Adopt parameter constraints in templates: We can set constraints on the parameters we define in our CloudFormation templates to ensure that only the allowed input values are provided during stack creation. These constraints can be either any minimum length, maximum length, allowed patterns, and allowed values that we want to set.

  • For example, we can set the t2.micro and t2.medium values as the only allowed values for a parameter that specifies the instance type for an EC2 instance we’re provisioning. This can be useful when these are also the only allowed values in the user policy, and using any other instance type would result in an error.

• Verify service quotas: Before deploying the stack, we must verify the service quotas on our AWS account for any AWS services and resources we provision with CloudFormation. This can help us avoid the stack failing because of AWS resources exceeding the allowed set quota, which can be especially infuriating when we need to deploy a large stack that takes time to both create and clean up.

  • For example, we may need to deploy 10 VPCs in a specific AWS region, but our AWS account service quota is set at 5 VPCs per region, which will cause our stack creation to fail.

In this lesson, we went over an example template to provision a S3 bucket. We also explored some of the best practices we must follow when working with CloudFormation templates.