Terraform vs AWS CloudFormation for AWS Tags – Part 2

Terraform vs AWS CloudFormation for AWS Tags – Part 2

Once you have adopted an AWS tagging strategy, you’ll need to make sure that all your existing AWS resources and any new ones you create abide by it. Consistency is the key – if you don’t proactively enforce your AWS tagging strategy, you’ll always be playing catch up and chasing down team members to make sure they add the right tags to their resources.

While you can apply AWS tags to your resources manually using the AWS CLI or AWS Tag Editor, you’ll probably find this cumbersome and error-prone at scale. A better approach is to automatically apply AWS tags to your resources and use rules to enforce their consistent usage.

Depending on the tool you use to maintain your infrastructure on AWS, your method of proactively enforcing AWS tags on new resources may vary. In this guide, I’ll highlight two tools: Terraform and AWS CloudFormation. You’ll see how to use each to create and update AWS cost allocation tags on your resources and then enforce the proper use of specific tags for new resources. By proactively enforcing your AWS tagging strategy, you’ll minimize your time spent auditing and correcting improper AWS tags and force developers to learn best AWS tagging best practices for your environment.

Looking for Part 1? You can find it here: AWS Tags Best Practices and AWS Tagging Strategies

Looking for Part 3? You can find it here: 6 Tools to Maintain AWs Tags When You Fall Behind

Looking for practical help with AWS Tags? Learn how our Tagging Compliance feature help users implement best practices when it comes to AWS tags

Terraform for AWS Tags

The first infrastructure management tool I’ll cover is Terraform. Terraform works across a variety of cloud hosting providers to help you provision and maintain your AWS resources. With Terraform, you can define your servers, databases, and networks in code and apply your changes programmatically to your AWS account.

If you’re new to Terraform, they have a well-documented Getting Started guide and several AWS template examples on GitHub. In this section, I’ll show you some snippets from a demo Terraform project and module that is available on GitHub. You’ll learn the following in this Terraform AWS tags:

1. Tag a New AWS EC2 Instance with Terraform
2. Using Terraform to Update Existing AWS Tags
3. Enforce AWS Tags with Terraform

Using Terraform to Tag a New EC2 Instance

If you want to deploy an EC2 instance with AWS Tags using Terraform, your configuration might include something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

resource "aws_instance" "cart" {
  connection {
    type = "ssh"
    user = "ubuntu"
    host = self.public_ip
    private_key = file(var.private_key_path)
  }

  instance_type = "t2.micro"

  ami = var.aws_amis[var.aws_region]

  key_name = aws_key_pair.auth.key_name

  vpc_security_group_ids = [aws_security_group.default.id]

  subnet_id = aws_subnet.default.id

  provisioner "remote-exec" {
    inline = [
      "sudo apt-get -y update",
      "sudo apt-get -y install nginx",
      "sudo service nginx start",
    ]
  }
  tags = {
    contact = "j-mark"
    env = "dev"
    service = "cart"
  }
}

The above example includes three AWS cost allocation tags: contact, env, and service with values described as strings. When you apply this configuration, Terraform will connect to AWS and deploy an EC2 instance having the AWS tags you specified.

Terraform to Update AWS EC2 Tag

Terraform makes it easy to update already existing resources with AWS tags in reversible and consistent ways. If you’re using AWS tags to keep track of a resource’s contact (e.g.: j-mark in the above example), you’re likely to need to update the AWS tag when the team member leaves or changes roles.

To update the AWS tags on your resource, simply update the corresponding tags in your Terraform configuration. The new tags will overwrite any previous tags assigned to the resource, including tags added outside of Terraform.

For example, to change the contact cost allocation tag on the EC2 instance above, you might update the tags block above with the following:

1
2
3
4
5

tags = {
  contact = "l-duke"
  env = "dev"
  service = "cart"
}

When you apply this configuration, the AWS tags will be automatically updated in the AWS console:

If you keep your Terraform configuration files in version control – which is probably a good idea – you will be able to see how tags have changed over time. You can also review changes using the same code review process that your application code goes through to help you catch mistakes in the execution of your tagging strategy.

Using Terrafrom for AWS Tags Enforcement

As your infrastructure grows, a code review process likely won’t be enough to prevent improper AWS tagging. Fortunately, you can enforce AWS tag names and values using variables and custom validation rules in Terraform.

In the examples above, the tags list was hard-coded into the EC2 instance definition. A more scalable pattern would be to break your EC2 instance template into its own module and use a tags variable. You can then write a custom validation rule to check that the tags comply with your strategy.

For example, if you want to check that:

1. The user specifies at least one tag
2. The contact tag is either j-mark or l-duke
3. The env tag is set
4. The service tag is either cart or search

You might create a module with a variable specified like this:

1
2
3
4
5
6
7
8

variable "tags" {
  description = "The tags for this resource."
  validation {
    condition = length(var.tags) > 0 && contains(["j-mark", "l-duke"], var.tags.contact) && var.tags.env != null && contains(["cart", "search", "cart:search"], var.tags.service)
    error_message = "Invalid resource tags applied."

  }
}

Now when you run terraform plan with a missing or invalid tag, you’ll get an error:

1
2
3

Error: Invalid value for variable
...
Invalid resource tags applied.

Your rules can be as complex as Terraform’s Configuration Language allows, so functions like regex(), substr(), and distinct() are all available. That said, there are some caveats to this approach.

First, custom variable validation is an experimental feature in Terraform. Experimental features are subject to change, meaning that you might need to pay attention to Terraform update mores closely. To enable variable_validation, add the following to your terraform block:

1
2
3

terraform {
  experiments = [variable_validation]
}

Second, Terraform’s variable validation only happens during the terraform plan phase of your infrastructure’s lifecycle. It can’t prevent users from accidentally changing your tags directly in the AWS console, and it’s only as good as the validation rules you write. If you start using a new resource but forget to add validation rules, you might end up with lots of resources that don’t adhere to your tagging strategy.

Another option for paid Terraform Cloud customers is Sentinel, which allows you to create custom policies for your resources. I won’t cover this method here, but Terraform has created an example policy to show you how to enforce mandatory AWS tags.

Using AWS CloudFormation to Deploy AWS Tags

Similar to Terraform, AWS CloudFormation lets you provision AWS resources based on configuration files. Unlike Terraform, CloudFormation is part of Amazon’s offerings, so it won’t necessarily help you if you want to use another infrastructure provider. The approach to tagging your resources in CloudFormation is similar to that used by Terraform, but as you’ll see, the configuration format is different.

If you’re new to AWS CloudFormation, Amazon’s official walkthrough will help you get started deploying some basic templates. In this section, I’ll show you some snippets from a demo AWS CloudFormation template which is also available on GitHub. You’ll learn the following in this Terraform AWS tags section:

1. AWS CloudFormation Template to Deploy Tags
2. Using CloudFormation to Update AWS Tags
3. CloudFormation Template to Enforce AWS Tags

AWS CloudFormation to Tag a New EC2 Instance

AWS CloudFormation is designed to make it easy to create AWS resources with a single template file. Using a CloudFormation template, every resource that can be deployed with an AWS tag.

For example, to create a new EC2 instance with the same three AWS tags used in the Terraform example above, add an array of Tags to the resource’s Properties block:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

"Resources" : {
  "WebServerInstance": {  
    "Type": "AWS::EC2::Instance",
    "Metadata" : {...},
    "Properties": {
      "Tags" : [
       {
          "Key" : "contact",
          "Value" : "j-mark"
       },
       {
          "Key" : "env",
          "Value" : "dev"
       },
       {
          "Key" : "service",
          "Value" : "cart"
       }
      ],
      ...       
    }
  },
  ...         
},

Using AWS CLI, you can deploy this CloudFormation template as a new stack. This will ensure your template is valid and create the specified resources with their tags on AWS:

1

aws cloudformation create-stack --template-body file://path/to/your/template.json --stack-name=

If you have lots of similar resources in your template, you can deploy AWS tags to all the resources in the stack at once using the --tags flag with the create-stack or update-stack commands:

1
2
3
4
5

# Creating a stack with tags
aws cloudformation create-stack --template-body file://path/to/your/template.json --stack-name= --tags="Key=env,Value=dev"

# Updating a stack with tags
aws cloudformation update-stack --template-body file://path/to/your/template.json --stack-name= --tags="Key=env,Value=dev"

Using CloudFormation to Update AWS Tags

If you want to change the contact on your EC2 instance created above, simply change the Tags section of your template file and use the [update-stack](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudformation/update-stack.html) command to deploy your changes.

1
2
3
4
5
6
7

"Tags" : [
 {
    "Key" : "contact",
    "Value" : "l-duke"
 },
  ...
],

AWS CloudFormation behaves the same way that Terraform does when you update tags outside your template file. Any tags set manually will be overridden by the update-stack command, so be sure that everyone on your team deploy’s tags through CloudFormation.

CloudFormation Template to Enforce AWS Tags

AWS provides Organization Tag Policies and Config Managed Rules to help you find improperly tagged resources, but neither of these tools prevents you from creating resources with missing or invalid tags. One way to proactively enforce your tagging strategy is by using the CloudFormation linter.

cfn-lint is a command-line tool that will make sure your AWS CloudFormation template is correctly formatted. It checks the formatting of your JSON or YAML file, proper typing of your inputs, and a few hundred other best practices. While the presence of specific tags isn’t checked by default, you can write a custom rule to do so in Python.

For example, if you want to ensure that your CloudFormation web servers follow the same rules as the Terraform example above and have:

1. At least one AWS tag
2. The contact tag set to either j-mark or l-duke
3. The env tag set
4. The service tag set to cart or search

You can create a new rule called TagsRequired.py:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

from cfnlint.rules import CloudFormationLintRule
from cfnlint.rules import RuleMatch


class TagsRequired(CloudFormationLintRule):
    id = 'E9000'
    shortdesc = 'Tags are properly set'
    description = 'Check all Tag rules for WebServerInstaces'

    def match(self, cfn):
        matches = []
        approved_contacts = ['j-mark', 'l-duke']
        valid_services = ['cart', 'search']
        web_servers = [x for x in cfn.search_deep_keys('WebServerInstance') if x[0] == 'Resources']
        
        for web_server in web_servers:
            tags = web_server[-1]['Properties']['Tags']

            if not tags:
                message = "All resources must have at least one tag"
                matches.append(RuleMatch(web_server, message.format()))

            if not next((x for x in tags if x.get('Key') == 'env'), None):
                message = "All resources must have an 'env' tag"
                matches.append(RuleMatch(web_server, message.format()))

            for tag in tags:
                if tag.get('Key') == 'contact' and tag.get('Value') not in approved_contacts:
                    message = "The contact must be an approved contact"
                    matches.append(RuleMatch(web_server, message.format()))

                if tag.get('Key') == 'service' and tag.get('Value') not in valid_services:
                    message = "The service must be a valid service"
                    matches.append(RuleMatch(web_server, message.format()))

        return matches

When you run cfn-lint, include your custom rule:

1

cfn-lint template.json -a ./path/to/custom/rules

If your CloudFormation template is missing any tags, you’ll see an error:

1
2

E9000 Missing Tag contact at Resources/WebServerInstance/Properties/Tags
template.json:169:9

Using linting to validate your AWS CloudFormation rules is a great way to enforce your AWS tags proactively. If you’re storing your CloudFormation templates in version control, you can run cfn-lint using pre-commit hooks or by making it part of your continuous integration workflow.

Because these rules are written in Python, they can be as complex as you need them to be, but they have drawbacks as well. Like Terraform’s custom variable validation, linting rules won’t tell you about existing problems in resources that aren’t managed by CloudFormation, so they work best when combined with a reactive tag audit and adjustment strategy.

Conclusion

Properly tagged resources will help you predict and control your costs, but your tagging strategy can’t just be reactive. Having proactively enforced patterns will require an up-front investment, but will save you time and money in the long-run.

Once you’ve adopted a tagging strategy and proactive enforcement method, the last piece of the puzzle is catching up when you fall behind. In the final part of this guide, you’ll see how to audit and find mistagged resources to ensure your tagging strategy continues to succeed in the future.

If you’re interested in getting help with your tagging, reach out to our CTO at [email protected] to receive a free tagging compliance report.

Looking for Part 3? You can find it here: 6 Tools to Maintain AWs Tags When You Fall Behind

Need practical help? Learn how our Tagging Compliance feature help users implement best practices when it comes to AWS tags.