This whitepaper is for historical reference only. Some content might be outdated and some links might not be available. # Tagging capability Tagging capability Tagging is the act of assigning metadata to the different resources in your AWS environment for a variety of purposes, such as Attribute Based Access Control (ABAC), Cloud Financial Management, and automation (such as patching for select* tagged* instances). Tagging can also be used to create new resource constructs for visibility or control (such as grouping together resources that make up a micro-service, application, or workload). Tagging is fundamental to providing enterprise-level visibility and control. **Stakeholders:** + Central IT (Primary) + Finance + Security + Software Engineering **Personas: ** + **Cloud Team** - the team(s) who make cloud available to customers. + **Security Team** - the members of the cloud team responsible for security in AWS. + **Finance Team** - the members of the finance team responsible for reporting, allocating, and forecasting cloud costs. + **Customer** - entity within the company that consumes the logs stored within the log storage. **Supporting capabilities:** [Identity Management and Access Control capability](identity-management-access-control-capability.md) **Scenarios:** + **CF23 - S1: Tag definition and assignment** + **CF23 - S2: Tag compliance** + **CF23 - S3: Tag usage** Topics + [Overview](tagging-overview.md) + [Choosing tags for your environment](choosing-tags.md) + [Tagging standards](tagging-standards.md) # Overview Overview Tagging enables you to assign metadata to the different resources in your environment. As metadata, tags allow you to assign additional labels to these resources for you to identify them according you your business needs. We recommend you define a tagging strategy for your environment, this will allow you to confidently and efficiently identify resources across your environment and teams. It is important to define a strategy to tag your resources as soon as possible when establishing your Cloud Foundation on AWS, this will enable 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 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 lifecycle (SDLC). ## Tags for cloud financial management Tags for cloud financial management Being able 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. Being able to create reports and view the resources associated with a specific tag will also enable you to create budgets and forecast your spend based on specific tags. ## Tags for regulatory scope definition and security risk management Tags for regulatory scope definition and security risk management 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 operations and automation 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 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 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. You can limit access to certain resources for roles in different environments, and you can also use tags to grant a temporary elevated access to certain resources. For more information, refer to the [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) documentation. Authorization-based access control (ABAC) is not supported for all services. For information on what services support tags refer to, the [service table](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). 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. # Choosing tags for your environment Choosing tags for your environment Across the different kind of tags, you have to define for your environment, you need to decide what tags will be the **mandatory tags** or **discretionary tags**. 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. **Note** When building your tag strategy personally identifiable information (PII) should not be used to label your resources, as tags are not encrypted and are visible across your environment. Codify these values, so you can identify owners internally. **Mandatory tags** are the set of tags that every resource should have, regardless of purpose. These tags will enable you to identify the necessary metadata to identify the resource. The list of recommended **mandatory tags** includes: + **Owner**- This tag indicates who is the owner and main user of the resource, this can be a team or an individual. **Note** The Owner is not always the user who created the resource. + **Business Unit** - This tag identifies the business unit the resource belongs to. + **SDLC Stage** - This tag indicates if the resources are being used for Production or for non-Production. (For example, development, test, or sandbox.) + **Cost Center** - This tag specifies the budget or account that will be used to pay for the spend associated with the tag. + **Financial Owner** - This tag identifies who is responsible for the costs associated with the resource tagged with a specific tag. **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). The list of recommended **discretionary tags** includes: + **Workload ID/Name** - This tag indicates if the resource belongs to a specific workload. The value can be the workload ID or name. + **Compliance Requirement** - This tag identifies the resources that are subject to a specific compliance framework (for example, PCI-DSS or HIPAA). + **Environment version** - This tag indicates the version of the environment, in case the same workload has more than one environment associated. + **Workload tier** - This tag indicates the type of workload the resources belong to. Some workload types examples are confidential, internal, or critical. + **Backup** - This tag indicates if the resource needs to be backed up based on the type of workload and the data that it manages. + **SLA level** - This tag indicates SLA requirements. + **Lifespan** - This tag indicates the lifetime of the resources of the workload. If exceeded, these resources should be reviewed, replaced, or isolated. # Tagging standards Tagging standards As you define your tagging strategy, a naming convention needs to be established for the different tags across your environment ensuring a standard, and making it easier for the tagged resources to be identified. Tags enable you to identify resources, and having no more than 50 tags per resource will allow you to keep your tag strategy manageable in your environment. The following are examples for tag key names and values: ``` example-key:owner = SecOps ``` ``` example-key:cost-center = 5432 ``` ``` example-key:financial-owner = Security ``` ## Resources that need to be tagged Resources that need to be tagged 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. These resources should 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. ## Enforcing tagging Enforcing tagging Because of the importance of tagging and the level of complexity, it’s recommended to automate the tagging process when possible. This will reduce the human error that can be introduced when tagging critical resources, and will minimize the number of resources that are not identifiable due to the lack of tags. When possible, creating tag policies in your organization can help you ensure that the tags assigned to resources have the correct value assigned. Additionally, automation needs to be established in the environment to discover resources with missing tags or resources that are not compliant with the established tagging strategy. Once the resources have been identified, a report including these resources on the environment needs to be sent to the relevant stakeholders, to evaluate and make a decision to remediate the situation, if needed. Based on the results of this report, if a situation where persistent resources that are identified as non-compliant or have missing tags is given, it should be remediated immediately, by assigning a default pre-defined tag value defined as part of your tagging strategy, or if pre-defined tag doesn’t exist deleting the non-compliant resources. As part of your tagging strategy, it is important to implement preventative controls that ensure that disallow resource to be created without the appropriated tags on critical resources. For more information, refer to [Establish preventive controls across your environment](establish-preventive-controls-across-your-environment.md). ## Build a tagging dictionary Build a tagging dictionary As part of your tagging dictionary, you should define certain tags that can be used to access specific environments 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 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. In order 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 inputs, 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. Including missing tags and wrong or misspelled tag keys in your resources. ## Defining tags for Attribute-based access control Define tags for Attribute-based access control As part of your tagging dictionary, you should define certain tags that can be used to access specific environments 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 that other identities may not have access otherwise.