Getting to know AWS Tagging Policies

Whether migrating to the Cloud, building a cloud native application, or working with existing cloud infrastructure, planning and organization are vital to your cloud ecosystem. Amazon Web Services (AWS) provides several mechanisms to keep your environment organized and well documented. One of the key components to a great organizational strategy has long been tagging your resources with custom keys and values that are not specific to the AWS platform. Businesses operating on AWS that have a clearly established and enforced strategy for tagging resources within their environment are poised for growth within their organization.

During the recent flurry of product releases at AWS re:Invent 2019, AWS announced the addition of a new feature called Tag Policies. These policies provide a new mechanism for governance of resource metadata and, in practice, will pair very well with the use of Service Control Policies (SCPs). We’ll take a deeper look at what you should know to get started, dive into the implementation of tag policies, and review examples. We’ll also talk about a few of those “gotchas” that are ever present in such a large ecosystem as AWS.

Expected knowledge

In order to fully understand tag policies, it’s best to start with some baseline expectations for what you should already know or be somewhat familiar with:

• Tagging Strategies are a firm prerequisite. In order to create and enforce tag policies your organization needs a strategy for identifying what data requirements are necessary for tracking and management. 
• Tag policies belong to AWS Organizations, so a solid understanding of how your organization is structured is important. You should be familiar with what organizational units and accounts are, and how they’re managed.
• Understanding Service Control Policies will support the creation, implementation, and enforcement of tag policies. There are several parallels, as well as shared responsibilities, between these two features that we’ll talk through.
• As a tangential point of reference, tag policies function similarly to—though not the same as—AWS Identity and Access Management (IAM) policies. Having a general understanding about how governance is implemented in production environments will provide a better foothold on how tag policies will be applied and enforced in your organization.

Tag Policies

As you consider where to start with tag policies, it’s best to take the same approach as recommended on every chemical cleaner on the shelf at your local store: “Test in a small isolated area first…” You should never build and implement a full policy scheme, then expect a successful outcome without first testing and educating your users. That will fail.

Let’s talk through the high-level steps for how to get started with tag policies.

Enabling tag policies

In order to successfully enable tag policies for your organization, you’ll need permissions in the root account of your organization for managing tag policies. You can find the specific IAM actions required to administer tag policies in the AWS Organizations documentation. This is useful if your security practices follow the principle of least privilege.

In the AWS console, navigate to AWS Organizations and select the Policies tab. You should be presented with a page that looks similar to the reference image below. If Tag policies is listed as Disabled, you should be able to click there to enable. You will be prompted with a confirmation screen, which you can approve. In order to utilize tag policies, your interface will need to report here that this feature has been enabled.

Creating a tag policy

Creating a tag policy is much like creating an IAM policy, yet while this is still JSON the actual syntax differs from an IAM policy. These polices consist of three primary components, which you can create through the console policy creator or by writing and validating in your text editor then transferring to the console. It’s worth noting that you can accomplish all of this through the CLI as well.

The three components for you to consider when creating a tag policy are Tag Key, allowed Tag Value(s), and Resources to enforce your tags upon. While the UI is helpful, I prefer understanding syntax and policies at the JSON level, so we’ll explore that here.

We’ll start by creating a policy that has the following requirements:

• A tag on any new EC2 Instance that has a Key of CostCenter
  • Note that CostCenter is written with Pascal Case, a variant of Camel Case which capitalizes the first character. Our naming convention is critical here, so ensure you have a standard policy.
• A known cost center as the Value, prohibiting the use of unknown cost centers
• EC2 Instances as the Resources to which this policy applies
  • Without the identification of applicable resources, tag policies are by default not enforced

{
  "tags": {
    "CostCenter": {  # Policy Key (Should match the name of your Tag Key)
      "tag_key": {
        "@@assign": "CostCenter"  # Tag key (The conventional name of your tag key)
      },
      "tag_value":
        "@@assign": [  # Tag Value(s) (One or more values that must match equality)
          "1111",
          "2222",
          "3333",
          "4444"
        ]
      },
      "enforced_for": {
        "@@assign": [  # Resources (One or more resources to which this policy applies)
          "ec2:instance"
        ]
      }
    }
  }
}

The above policy follows the requirements. It specifies a CostCenter tag key, defines the approved tag values, and applies the policy to any newly launched EC2 Instance. Instances which are already in service will not adhere to the policy upon creation/attachment.

Upon saving your policy, you can take further action on your policy from the console. The policy console should look like this:

Attaching a tag policy

Creating the policies is a great first step. For the purpose of applying and enforcing policies, they must be attached to one of: Roots, Organizational Units, or Accounts. It’s important to understand how policy inheritance works and—while we’re not going to go into depth here—you can find more information about it in the official documentation. There are two ways, via the console, to attach policies:

1. Select the policy from the Policies page (as seen above), then navigate to the right-hand side of the page that offers a detailed listing of each option for attachment.
2. Select the Accounts page, which provides a list of all accounts in the Organization, then selectively attach policies on a one-off basis.

As policies are attached, the effect is immediate. Test and implement incrementally to ensure that developmental and production resources and workflows are not affected by these policy updates.

Gotchas

As with most AWS services, there are a few items of note that can both help and hinder your progress. Below is a brief list of a few important reminders to be aware of during and after your deployment of tag policies.

1. Tag policies themselves do not restrict end users from creating resources if they fail to meet Tag Key requirements. However, failure will occur if required Tag Keys are present and Tag Values do not meet specified allowed values (if defined).
2. Any provisioned resources in your organization before a tag policy is applied will not adhere to the policy restrictions. Those resources must retroactively be tagged in compliance with your tagging strategy and policies.
3. Tag policies work very well in conjunction with Service Control Policies and can address the default behaviors listed above when defined to work in a coordinated way.
4. Not all resources are available and supported for use with tag policies. When using the console-based policy creator, you will only see resources that are supported. See the official documentation for more information.
5. Tag strategies and policies should consider edge cases. For example, the tag policy we broke down above does not account for propagating tags from a Launch Configuration or Launch Template used by an Autoscaling Group. This example may cause current and/or future issues with development of new infrastructure.

Regardless of your business size it’s never too early or too late to implement governance for how your operations function within AWS. Organization and standardization of metadata requirements for business operations is critical, and tag policies are a welcome addition that support industry standards and best practices.

We’re here to help, too! If you are interested in learning about how 1Strategy can help you optimize security, manage your resources, or control costs on AWS, we’re just an email away at info@1strategy.com.