# Building your tagging strategy As with many practices in operations, implementing a tagging strategy is *a process of iteration and improvement*. Start small with your immediate priority and grow the tagging schema as you need to. ![\[Diagram showing a graphical representation of the tagging strategy iteration and improvement cycle\]](http://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/images/tagging-strategy-cycle.png) Throughout this process, ownership is key to accountability and progress. Because tags can be used for a variety of purposes, the overall tagging strategy can be split into areas of responsibility within an organization. Tagging allows a programmatic approach to activities that depend upon the characterization of resources. The range of stakeholders that can benefit from tagging will depend on the size of the organization and operational practices. Larger organizations can benefit from clearly defining the responsibilities of the teams involved in building and implementing a tagging strategy. Some stakeholders can be responsible for identifying the needs (defining use cases) for tagging; others can be responsible for maintaining, implementing, and improving the tagging strategy. By assigning ownership, you are in a good position to implement individual aspects of the strategy. Where appropriate, this ownership can be formalized as policy and documented in a responsibility matrix (for example, RACI: Responsible, Accountable, Consulted, and Informed), or in a shared responsibility model. In smaller organizations, teams might play multiple roles in a tagging strategy, from requirements definition to implementation and enforcement. # Defining needs and use cases Start building your strategy by engaging with stakeholders who have a fundamental underlying need to consume metadata. These teams define the metadata that resources need to be tagged with to support their activities, such as reporting, automation, and data classification. They outline how the resources need to be organized and which policies they need to be mapped to. Examples of roles and functions that these stakeholders can have in organizations include: + **Finance** and **Line of Business** need to understand the value of investment by mapping it to costs to prioritize actions that need to be taken when addressing inefficiency. Understanding *cost vs value generated* helps to identify unsuccessful lines of business or product offerings. This leads to informed decisions about continuing support, adopting an alternative (for example, using a SaaS offering or managed service), or retiring an unprofitable business offering. + **Governance** and **Compliance** need to understand the categorization of data (for example, public, sensitive, or confidential), whether a specific workload is in or out of scope for audit against a specific standard or regulation, and the criticality of the service (whether the service or application is business-critical) to apply appropriate controls and oversight, such as permissions, policies, and monitoring. + **Operations** and **Development** need to understand the workload lifecycle, implemented stages of their supported products, and management of release stages (for example, Development, Test, Production split) and their associated support prioritizations and stakeholder management requirements. Duties such as Backups, Patching, Observability and Deprecation also need to be defined and understood. + **Information Security (InfoSec)** and **Security Operations (SecOps)** outline what controls must be applied and which are recommended. InfoSec normally defines the implementation of the controls, and SecOps is generally responsible for managing those controls. Depending on your use case, priorities, size of your organization, and operational practices, you might need representation from various teams within the organization, such as Finance (including Procurement), Information Security, Cloud Enablement, and Cloud Operations. You also need representation from application and process owners for functions such as patching, backup and restore, monitoring, job scheduling, and disaster recovery. These representatives help drive the definition, implementation, and measure the effectiveness of the tagging strategy. They should [https://www.youtube.com/watch?v=aFdpBqmDpzM](https://www.youtube.com/watch?v=aFdpBqmDpzM) from stakeholders and their use cases, and conduct a cross-functional workshop. In the workshop, they get a chance to share their perspectives and needs, and help drive an overall strategy. Examples of participants and their involvement in various use cases are described later in this whitepaper. The stakeholders also define and validate the keys for mandatory tags, and can recommend the scope for optional tags. For example, Finance Teams might need to relate a resource to an internal cost center, business unit, or both. Thus, they might require that certain tag keys, such as `CostCenter` and `BusinessUnit`, be made mandatory. Individual development teams might decide to use additional tags for automation purposes, such as `EnvironmentName`, `OptIn`, or `OptOut`. Key stakeholders need to agree on the tagging strategy approach, and document the answers for compliance- and governance-related questions, such as: + What use cases need to be addressed? + Who is responsible for tagging resources (implementation)? + How are tags enforced and what methods and automation will be used (proactive or reactive)? + How are tagging effectiveness and goals measured? + How often should the tagging strategy be reviewed? + Who drives improvements? How is this done? Business functions, such as Cloud Enablement, Cloud Business Office, and Cloud Platform Engineering, can then play a role of facilitators for the process of building the tagging strategy, help drive its adoption, and ensure consistency of its application by measuring progress, removing roadblocks, and reducing duplicated effort. # Defining and publishing a tagging schema Employ a consistent approach in tagging your AWS resources, both for mandatory and optional tags. A comprehensive tagging schema helps you to achieve this consistency. The following examples can help get you started: + Agree on the mandatory tag keys + Define acceptable values and tag naming conventions (upper or lower case, dashes or underscores, hierarchy, and so on) + Confirm values would not constitute personally identifiable information (PII) + Decide who can define and create new tag keys + Agree on how to add new mandatory tag values and how to manage optional tags Review the following [tagging categories](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) table, which can be used as a baseline of what you might include in your tagging schema. You still need to determine the convention you will use for the tag key and what values are permitted for each. The tagging schema is the document in which you define this for your environment. *Table 6 – Example of a definitive tagging schema* | Use Case | Tag Key | Rationale | Allowed Values (Listed or value prefix/suffix) | Used for Cost Allocation | Resource Types | Scope | Required | | --- | --- | --- | --- | --- | --- | --- | --- | | Cost Allocation | example-inc:cost-allocation:ApplicationId | Track cost vs value generated by each line of business | DataLakeX, RetailSiteX | Y | All | All | Mandatory | | Cost Allocation | example-inc:cost-allocation:BusinessUnitId | Monitor costs by business unit | Architecture, DevOps, Finance | Y | All | All | Mandatory | | Cost Allocation | example-inc:cost-allocation:CostCenter | Monitor costs by cost center | 123-\$1 | Y | All | All | Mandatory | | Cost Allocation | example-inc:cost-allocation:Owner | Which budget holder is responsible for this workload | Marketing, RetailSupport | Y | All | All | Mandatory | | Access Control | example-inc:access-control:LayerId | Identify SubComponent / Layer to grant access to resources based on the role | DB\$1Layer, Web\$1Layer, App\$1Layer | N | All | All | Optional | | Automation | example-inc:automation:EnvironmentId | Implement scheduling of test and development environments, also referred to as software development lifecycle (SDLC) stage | Prod, Dev, Test, Sandbox | N | EC2, RDS, EBS | All | Mandatory | | DevOps | example-inc:operations:Owner | Which team/squad is responsible for the creation and maintenance of the resource | Squad01 | N | All | All | Mandatory | | Disaster Recovery | example-inc:disaster-recovery:rpo | Define the recovery point objective (RPO) for a resource | 6h, 24h | N | S3, EBS | Prod | Mandatory | | Data Classification | example-inc:data:classification | Classify data for compliance and governance | Public, Private, Confidential, Restricted | N | S3, EBS | All | Mandatory | | Compliance | example-inc:compliance:framework | Identifies the compliance framework the workload is subject to | PCI-DSS, HIPAA | N | All | Prod | Mandatory | After the tagging schema is defined, manage the schema in a version-controlled repository that is made accessible to all the relevant stakeholders for easy reference and trackable updates. This approach improves efficiency and allows for agility. # AWS Organizations – Tag policies Policies in AWS Organizations allow you to apply additional types of governance to AWS accounts in your organization. A [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) is how you can express your tagging schema in JSON form so that the platform can report and optionally enforce the schema within your AWS environment. The tag policy defines the values that are acceptable for a tag key on specific resource types. This policy can be in the form of a list of values, or a prefix followed by a wildcard character (`*`). The simple prefix approach is less rigorous than a discrete list of values but requires less maintenance. The following examples show how to define a tagging policy to validate the values that are acceptable for a given key. Working from the human-friendly tabular definition of the schema, you can transcribe this information into one or more tag policies. Separate policies can be used to support delegated ownership or some policies might only apply in specific scenarios. ## ExampleInc-CostAllocation.json The following is an example of a tag policy that reports on Cost Allocation tags: ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] } } } } ``` ## ExampleInc-DisasterRecovery.json The following is an example of a tag policy that reports on Disaster Recovery tags: ``` { "tags": { "example-inc:disaster-recovery:rpo": { "tag_key": { "@@assign": "example-inc:disaster-recovery:rpo" }, "tag_value": { "@@assign": [ "6h", "24h" ] } } } } ``` In this example, the `ExampleInc-CostAllocation` tag policy is attached to the `Workloads` OU, and therefore applies to all the accounts in both the `Prod` and `Test` child OUs. Similarly, the `ExampleInc-DisasterRecovery` tag policy is attached to the `Prod` OU and therefore only applies to accounts below this OU. The [Organizing Your Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) whitepaper explores the recommended OU structures in more detail. ![\[Diagram showing the attachment of tag policies to an OU structure and the effective policy\]](http://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/images/adding-tagging-to-policies-in-ou-structure.png) Looking at the `marketing-prod` account in the diagram, both tag policies apply to this account, so we have the concept of an *effective policy*, which is the convolution of the policies of a given type that apply to an account. If you primarily manage your resources manually, then you can review the effective policy by visiting the [Resource Groups & Tag Editor:Tag policies](http://console.aws.amazon.com/resource-groups/tag-policies) in the console. If you use infrastructure as code (IaC) or scripting to manage your resources, you can use the [https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html) API call. # Implementing and enforcing tagging In this section, we’ll introduce you to the tools available for the following resource management strategies: manual, infrastructure as code (IaC), and continuous integration/continuous delivery (CI/CD). The key dimension for these approaches is an increasingly frequent rate of deployment. ## Manually managed resources These are typically workloads that fall into the [foundation or migration stages of adoption](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html). Often, these are simple largely static workloads that have been built using traditional written procedures or those migrated *as is* using tools such as AWS Application Migration Service from an on-premises environment. Migration tools, such as Migration Hub and Application Migration Service, can apply tags as part of the migration process. However, if tags were not applied during the original migration or the tagging schema has changed since then, the [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) (a feature of the AWS Management Console) allows you to search for resources using a variety of search criteria and add, modify, or delete tags in bulk. Search criteria can include resources with or without the presence of a particular tag or value. The AWS Resource Tagging API allows you to perform these functions programmatically. As these workloads are modernized, resource types such as Auto Scaling groups are introduced. These resource types allow for greater elasticity and improved resilience. The auto scaling group manages Amazon EC2 instances on your behalf, however, you might still want the EC2 instances to be tagged consistently with the manually created resources. An [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) provides the means to specify the tags that the Auto Scaling should apply to instances that it creates. When the resources of a workload are being managed manually, it can be helpful to automate the tagging of resources. There are various solutions available. One approach is to use AWS Config Rules, which can check for `required_tags` and then start a Lambda function to apply them. AWS Config Rules is described in more detail later in this whitepaper. ## Infrastructure as code (IaC) managed resources AWS CloudFormation provides a common language for provisioning all the infrastructure resources in your AWS environment. CloudFormation templates are JSON or YAML files that create AWS resources in an automated manner. When you create AWS resources using CloudFormation templates, you can use the CloudFormation Resource Tags property to apply tags to supported resource types upon creation. Managing the tags as well as the resources with IaC helps ensure consistency. When resources are created by AWS CloudFormation, the service automatically applies a set of AWS defined tags to the resources created by the AWS CloudFormation template. These are: ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` You can easily define a resource group based on the AWS CloudFormation stack. These AWS defined tags are inherited by the resources created by the stack. However, for Amazon EC2 instances within an Auto Scaling group, the [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html) needs to be set in the definition of the Auto Scaling group in your AWS CloudFormation template. Alternatively, if you are using an [EC2 Launch Template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) with the Auto Scaling group then you can define the tags in its definition. Using [EC2 Launch Templates](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html) with Auto Scaling groups or with an AWS container service is recommended. These services can help ensure consistent tagging of your Amazon EC2 instances and also support [Auto Scaling Across Multiple Instance Types & Purchase Options](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/), which can improve resilience and optimize your compute costs. [AWS CloudFormation Hooks](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) provide developers with a means of keeping key aspects of their application consistent with their organization’s standards. Hooks can be configured to provide a *warning* or *prevent deployment*. This feature is best suited to checking key configuration elements in your templates, such as whether an Auto Scaling group is configured to apply customer defined tags to all the Amazon EC2 instances it launches, or to ensure that all Amazon S3 buckets are created with the required encryption settings. In both cases, evaluation of this compliance is being pushed to the earlier in the deployment process with AWS CloudFormation hooks before deployment. AWS CloudFormation provides the capability to detect when a resource (see [Resources that support drift detection](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) provisioned from a template has been modified and resources no longer match their expected template configurations. This is known as *drift*. If you use automation to apply tags to resources managed via IaC, then you are modifying them, introducing drift. When using IaC, it's currently recommended to manage any tagging requirements as part of the IaC templates, implement AWS CloudFormation hooks, and publish AWS CloudFormation Guard rule sets that can be used by automation. ## CI/CD pipeline managed resources As the maturity of a workload increases, it’s likely that techniques such as continuous integration and continuous deployment (CI/CD) are adopted. These techniques help to reduce deployment risk by making it easier to deploy small changes more frequently with increased automation of testing. An observability strategy that detects unexpected behavior introduced by a deployment can automatically roll back the deployment with minimal user impact. As you get to the stage of deploying tens of times a day, applying tags retroactively is simply no longer practical. Everything needs to be expressed as code or configuration, version controlled, and, wherever possible, tested and evaluated before deployment into production. In the combined [develop and operations (DevOps) model](https://aws.amazon.com/devops/what-is-devops/), many of the practices address operational considerations as code and validate them early in the deployment lifecycle. Ideally, you want to push these checks as early in the process as you can (as shown with AWS CloudFormation hooks), so that you can be confident that your AWS CloudFormation template meets your policies before they leave the developer's machine. [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) provides the means to write preventative compliance rules for anything you can define with CloudFormation. The template is validated against the rules in the development environment. Clearly, this feature has a range of applications, but in this whitepaper, we will just look at some examples that would ensure the [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html) is always being used. The following is an example of a CloudFormation Guard rule: ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` In the code example, we filter the template for all resources that are of the type `AutoScalingGroup`, and then have two rules: + **`tags_asg_automation_EnvironmentId`** - Checks that a tag with this key exists, has a value within the allowed list of values, and that `PropagateAtLaunch` is set to `true` + **`tags_asg_costAllocation_CostCenter`** - Checks that a tag exists with this key, has a value that begins with the defined prefix value, and that `PropagateAtLaunch` is set to `true` ## Enforcement As described previously, **Resource Groups & Tag Editor** provides the means to identify where your resources fail to meet the tagging requirements defined in the tag policies applied to the OUs of the organization. Accessing the **Resource Groups & Tag Editor** console tool from within an Organization member account shows you the policies that apply to that account and the resource within the account that fail to meet the tag policy’s requirements. If accessed from the management account (and if **Tag policies** has *Access enabled* in services under AWS Organizations), then it is possible to view the [tag policy compliance for all the linked accounts in the organization](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). Within the Tag Policy itself, you can enable enforcement for specific resource types. In the following policy example, we’ve added enforcement such that all resources of types `ec2:instance` and `ec2:volume` are required to be compliant with the policy. There are some known limitations, such as there must be a tag on a resource for it to be evaluated by the tag policy. See [Resources that support enforcement with tag policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html) for a list. ### ExampleInc-Cost-Allocation.json The following is an example of a tag policy that reports and/or enforces Cost Allocation tags: ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config is a service that allows you to assess, audit, and evaluate the configurations of your AWS resources (see [Resource types supported by AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)). In the case of tagging, we can use it to identify resources that are lacking tags with specific keys, using the `required_tags` rule (refer to [Resource types supported by required\$1tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)). From the earlier example, we might test for the existence of the key on all Amazon EC2 instances. In cases where the key doesn’t exist, the instance will be registered as non-compliant. This AWS CloudFormation template describes an AWS Config Rule to test for the presence of the mandatory keys describe in the table, on Amazon S3 buckets, Amazon EC2 instances, and Amazon EBS volumes. ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` For environments where resources are managed manually, an AWS Config rule can be enhanced to automatically add the missing tag key to the resources using an automated remediation via an AWS Lambda function. While this works well for static workloads, it's progressively less effective as you start managing your resources via IaC and deployment pipelines. **AWS Organizations – Service control policies (SCPs)** are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization or organizational unit (OU). SCPs only affect users and roles that are managed by accounts that are part of the organization. Although they do not affect resources directly, they restrict the permissions of users and roles which includes the permissions for tagging actions. With regards to tagging, SCPs can provide additional granularity for tag enforcement in addition to what tag policies can provide. In the following example, the policy will deny `ec2:RunInstances` requests where the `example-inc:cost-allocation:CostCenter` tag is not present. The following is a deny SCP: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ It is not possible to retrieve the effective service control policy that applies to a linked account by design. Where you enforce tagging with SCPs, documentation needs to be available to developers so they can ensure their resources meet the policies that have been applied to their accounts. Providing read only access to CloudTrail events within their account can support developers in the task of debugging when their resources fail to comply. # Measuring tagging effectiveness and driving improvements After you have implemented a tagging strategy, it's important to measure its effectiveness against the target use cases. The measure of effectiveness will vary by use case. For example: + **Cost attribution** - You could measure the tagging coverage of resources based on spend using tools such as [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) or [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/). For example, you could track the *percent of tagged or untagged* resources that generate charges, particularly monitoring specific tag keys. + **Automation** - You might want to audit if the desired result has been achieved. For example, whether non-production Amazon EC2 instances are suspended outside of business hours, auditing instance start and stop times. [Resource Groups & Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) within the management account provides additional capabilities to analyze tag policy compliance for all the linked accounts in your organization. Based on the results of the measurement of your tagging effectiveness, identify if any improvements or alterations are needed in any of the steps such as use case definition, tagging schema implementation or enforcement. Make necessary changes and repeat the cycle until desired effectiveness is achieved. In the example with cost attribution, you can look at percentage improvement. Since it’s the developers and operators that need to perform the actual tagging of resources, it's critical to have them take ownership. This isn’t the only additional responsibility that teams typically assume in their journey of AWS adoption. Increased responsibility for the security and cost of developing and operating their application are also important. Organizations often use goals and targets as means of motivating the adoption of new practices, so this can also apply here.