It is important to define a strategy to tag your resources as soon as possible when establishing your cloud foundation. This enables you to find resources and environments quickly, as your overall environment expands and matures. When defining your tagging strategy, you need to determine the right tags that will help you gather all of the information you will need in your environment for the following scenarios:

Tags for workload and ownership: You can use tags to help you organize and display the resources that are owned by the same team or developer, as well as the resources that belong to the same workload across your environment. These tags can also help you identify what resources within a workload belong to a specific software development life cycle (SDLC).

Tags for cloud financial management: The ability to control how much you are spending on the cloud and what resources are incurring the costs in your environment can help you reduce your costs in the long term. The ability to create reports and view the resources associated with a specific tag also enables you to create budgets and forecast your spend based on specific tags.

Tags for regulatory scope definition and security risk management: Some of the resources in your environment may handle confidential information, personal information, or data that is subject to a specific compliance framework. Assigning tags to identify these resources allows you to ensure that the correct access controls and security mechanisms are established and working as intended.

Tags for operations and automation: When your resources are identifiable through tags, you can filter resources during your automated infrastructure activities. For example, when deploying, updating, or deleting resources within your infrastructure. Additionally, you can use tags to stop or start an entire fleet of resources according to your business needs.

Tags for operational support and disaster recovery: You can use tags to identify the kind of support a group of resources may need, and as part of your incident management process. Tags can be assigned to resources when they are isolated, or when they are on standby before deleting them or archiving them. This can help your support teams to identify the resources within a workload that need to be worked on. Tags can also be used to identify the frequency your resources need to be backed up, and where the backup copies need to go or where to restore the backups.

Tags for attribute-based access control: In addition to role-based access control (RBAC), tagging your resources enables you to define and enhance the security of your resources in the environment. When using tags for authorization (ABAC), you can further define under what conditions a resource or API can be accessed. For more information, refer to the What is ABAC for AWS? documentation.

Authorization-based access control (ABAC) is not supported for all services. For information on what services support tags, refer to the service table. In the table, locate the service and check the Authorization based on tags column. You can also select the service name for additional documentation on authorization and access control for the service.

As part of your tagging dictionary, you may define certain tags that can be used to access specific environment resources based on the tags attached to a role at a certain time. These tags can be used for a temporary escalation of privileges or for deploying changes through Infrastructure as Code (IaC) that other identities may not have access otherwise.

We recommend that you define and build a tagging dictionary where all these values are available for developers, cloud architects, and environment operators. To add, update, or remove values for each of the tags included in the tagging dictionary, you need to establishes processes where all the relevant stakeholders can provide their input when a tag becomes standard. This will ensure that all relevant stakeholders involved in the definition of the tags in your environment are aware of any changes they need to provision and deploy across their resources.

This tagging dictionary needs to be made available to builders and stakeholders, so tags can be applied consistently across the environment, and everyone is aware of requirements or errors that can be caused due to an incorrect used of tags in the environment. This includes missing tags and wrong or misspelled tag keys in your resources.

As you define your tagging strategy, a naming convention needs to be established for the different tags across your environment to ensure standardization and ability to identify resources based on their tags. The following are examples for tag key names and values:

• owner = SecOps
• cost-center = 5432
• financial-owner = Security
  

When defining a tagging dictionary, it is important to delineate between mandatory and discretionary tags.

• Mandatory tags are the set of tags that every resource should have, regardless of its purpose. These tags will enable you to identify the necessary metadata to identify the resource.
• Discretionary tags are the set of tags that must be defined as part of your tagging strategy, so they are available to be assigned to resources that need them (for example, temporary elevation of permissions, or data sensitivity).

Additionally, you need to define what resources need to tagged, and define detection and enforcement mechanisms to ensure all the required resources have the mandatory tags. When building an environment with multiple accounts, every account in the environment should have the mandatory tags that allow you to identify what the purpose of the account is for and who is responsible for the resources in that account.

Recommended mandatory tags:

Example tagging dictionary based on recommended mandatory and discretionary tags:

There are resources that always need to be tagged in your environment, because it is critical to have the identifiable information about the resources at all times. The resources in this category are meant to be persistent, and in some occasions, they act as resource containers for other resources. These resources include, but are not limited to, accounts, critical workloads, and shared infrastructure. For these resources, you should aim to tag a hundred percent of the resources, which will allow you to identify the spend, access, ownership, and permissions for the tagged resources.

However, as operational complexity increases and the level of automation to manage tags becomes more demanding, you may choose to not tag certain types of resources that are ephemeral. Ephemeral resources might run within a resource container that is properly tagged to allow you to identify and trace what happened within that environment, but enforcing the tags on these types of resources may not be necessary if they do not belong to critical workloads or applications.

As you implement your tagging strategy, it is important to have a method to build, enforce, and maintain standardization within your environment. Tag policies are a type of policy that can help you standardize tag values based on defined tag keys across resources in your organization's accounts.

We consider the following tags mandatory, so we recommend using tag policies to help enforce the usage of the tag values according to our best practices. The following table is a sample that you can use to create your own tagging dictionary for the tags that are mandatory within your environment.

{ "tags": { "Owner": { "tag_key": { "@@assign": "Owner" }, "tag_value": { "@@assign": [ "SecurityLead", "SecOps", "DevTeam1" ] }, "enforced_for": { "@@assign": [ "<service>:*" ] } }, "businessUnit": { "tag_key": { "@@assign": "BusinessUnit" }, "tag_value": { "@@assign": [ "Finance", "Retail" ] }, "enforced_for": { "@@assign": [ "<service>:*" ] } }, "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "100", "200" ] }, "enforced_for": { "@@assign": [ "<service>:*" ] } } ,"FinancialOwner": { "tag_key": { "@@assign": "FinancialOwner" }, "tag_value": { "@@assign": [ "SecOps", "HR" ] }, "enforced_for": { "@@assign": [ "<service>:*" ] } } ,"costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "100", "200" ] }, "enforced_for": { "@@assign": [ "<service>:*" ] } } ,"compliance": { "tag_key": { "@@assign": "Compliance" }, "tag_value": { "@@assign": [ "NIST", "HIPAA", "GDPR" ] }, "enforced_for": { "@@assign": [ "<service>:*" ] } } }}

Note: Tag policies can be set to enforced or not enforced. Tag policies that are set to enforced prevent the instantiation of resources with non-compliant tag values. Tag policies that are not set to enforced allow the creation of the resource, but provide an organization level view of non-compliant resources. Refer to the evaluating organization-wide compliance section of the AWS Resource Groups user guide for more information on evaluating organization tag compliance.

After defining the tag policies in your environment you can use the Resource Group API to identify and correct non-compliant resources across your environment.

For resources that do not support tag policies, you can use preventive and detective controls to enforce tagging across your environment.

 "Condition": { "Null": { "aws:RequestTag/costcenter": "true" } }

In addition to the tags you define in your environment, specific services use tags to monitor and track resources created or managed through them. These tags are reserved and start with a prefix that contains aws:. Tags starting with that prefix can’t be manually created, updated, or deleted.

For a list of the different tagging limitations on AWS, review tag naming limits and requirements.

One of the benefits of an effective tagging strategy is being able to view data based on resources that are grouped by tags. You can use resource groups to organize your AWS resources. AWS Resource Groups is an AWS service that lets you manage and automate tasks on large numbers of resources at one time based.

Once resource groups are created, you can view metrics, alarms, and dashboards in Amazon CloudWatch based on your resource groups. To view resource group data in CloudWatch, refer to the Focus on metrics and alarms in a resource group section of the CloudWatch User Guide.

Tags can enable you to organize your resources across your environment to help analyze and control how much you are spending on AWS, and determine what resources are incurring costs in your environment. You can create filter views and create reports for the resources associated with a specific tag, which also enables you to create budgets and forecast your spend based on specific tags.

Cost Allocation Tags let you track your AWS costs on a detailed level. After you activate Cost Allocation Tags, AWS uses the cost allocation tags to organize your resource costs on your cost allocation report, to make it easier for you to categorize and track your AWS costs. AWS provides two types of cost allocation tags: AWS generated tags and user-defined tags.

To enable Cost Allocation Tags, activate Cost Explorer in your environment, which may take up to 24 hours if it is the first time you are visiting.

As you start creating and tagging resources, you can activate these tags as Cost Allocation Tags on the billing console, in the Cost Allocation Tags section. Once the tags are fully activated you can use the tags within Cost Explorer to create AWS Budgets or create different reports in Cost Explorer.