A DEEPER DIVE INTO AWS TAG ENFORCEMENT WITH TAGGING POLICIES

AWS has recently released updates around AWS tagging policies and we’re keeping you up to date on tagging best practices.

These new features, combined with the information in part one of our AWS tagging enforcement guide, will help you to build a cost-efficient tagging solution that can be up and running in no time at all.

Service Control Policy Paired with Tagging Policy

Tagging policies are JSON objects that can be used to enforce AWS accounts and Organizational Units within AWS Organizations to adhere to designated tagging standards.

Creating a tagging policy with the tag specified in an SCP (which blocks CloudFormation deployments) adds another level of sophistication to a holistic tag enforcement solution.

The SCP mentioned in the previous blog is great when you are trying to prevent new resources which are not following the agreed upon tagging standard. But what happens when the resources are already present, or if you want to check if CloudFormation stack changes still have compliant tagging present?

This is where AWS’s new tagging policies can be particularly useful.

From creating a simple tagging policy:

To something more complicated with accepted values:

Both of the above polices allows you to add an easy monitoring feature, in order to enforce your tagging taxonomy in AWS environments.

Having this implemented can help identify resources which are not tagged correctly prior to implementing the preventative SCP. Additionally, you can identify any one-off resources which were created without using CloudFormation.

To bring some Excel magic to the table, AWS allows the generation of non-compliant CSV reports, which can be easily downloaded and divided up so teams can go out and properly tag these resources.

The above image shows how a SCP paired with a tagging policy leads to well-structured enforcement.

CloudFormation Resource Imports

With the addition of CloudFormation resource imports, AWS has made it even easier to enforce tagging.

Best practice is to deploy all resources from CloudFormation Stacks and have the resources managed through a proper Infrastructure as Code (IaC) medium. Luckily, AWS just released a feature which allows moving already-deployed resources (manually created) to a CloudFormation stack. All an engineer needs to do is create a CloudFormation template for the deployed resources with all its proper attributes, and ‘Create a Stack with Existing Resources’ ( import resources). During the creation of the stack and importing of the resource, be sure to tag it with your required tag—and just like that, the rogue resources are both part of a stack and properly tagged.