Introduction- AWS Tagging Rules

There are certain requirements to define the AWS tagging rules and one must follow them.

This topic describes commonly used  tagging, categories and strategies to help you implement a consistent and effective tagging strategy. The following sections assume basic knowledge of AWS resources, tagging, detailed billing, and AWS Identity and Access Management (IAM).

Each tag has two parts:

• A tag key (for example, CostCenter, Environment, or Project). Remember that tag keys are case sensitive.
• A tag value (for example, 111122223333 or Production). Like tag keys, tag values are also case sensitive.

Tags would be used to categorize resources by purpose, owner, environment, or other criteria. Please add, change, or remove tags one resource at a time from each resource’s service console, service API, or the AWS CLI.

• Each resource can have a maximum of 50 tags.
• For each resource, each tag key must be unique, and each tag key can have only one value.
• The maximum tag key length is 128 Unicode characters in UTF-8.
• The maximum tag value length is 256 Unicode characters in UTF-8.
• Allowed characters are letters, numbers, spaces representable in UTF-8, and the following characters: . : + = @ _ / – (hyphen). Amazon EC2 resources allow any characters.
• Tag keys and values are case sensitive. As a best practice, decide on a strategy for capitalizing tags, and consistently implement that strategy across all resource types. For example, decide whether to use Costcenter, costcenter, or CostCenter, and use the same convention for all tags. Avoid using similar tags with inconsistent case treatment.
• The aws prefix is prohibited for tags; it’s reserved for AWS use. You can’t edit or delete tag keys or values with this prefix. Tags with this prefix do not count against your tags per resource quota.

This article summarizes AWS Tagging Rules and that includes:

• Types of tags
• Best practices
• Naming Constructs
• Mandatory Type of tags

Types of Tags

Below is the account structure we are planning to adopt

• Tags for AWS console organization and Resource groups
• Tags for cost allocation example cost center, business unit or project
• Tags for automation
• Tags for operational support – Backup, Restore, Patching, Ticket creation in ITSM
• Tags for access control
• Tags for security risk Management

AWS Tagging Rules- Best Practices

You should follow the below practices in using the tags

• Inform each team and stakeholders about the right tags so that they can use them and check periodically for the same in reports.
• Use tags consistently
• Tag owners should be identified to enable use and tracking of tags
• Tags for cost
  1. Tagging decisions are reversible, giving you the flexibility to edit or change as needed in the future. However, there is one exception—cost allocation tags—which are included in AWS monthly cost allocation reports. The data for these reports is based on AWS services utilization and captured monthly. As a result, when you introduce a new cost allocation tag it takes effect starting from that point in time. The new tag will not apply to past cost allocation reports
  2. Adopt a standardized approach uses the naming convention as listed in the document below for resource specific tags
• Tag everything
• Constrain tag values: Tags are not useful if they contain missing or invalid data values. If tag values are set by automation, then automation code can be reviewed, tested, and enhanced to ensure that valid tag values are used. When tags are entered manually, there is the opportunity for human error. Reduce this by using AWS Service Catalog
• Propagate tags and then tag values across related resources
• If tags are used in access control limit, users have the ability to modify tag values in order to gain access
• Use AWS Configuration to create rules to check resources for required tags as it will continuously monitor your resources against those rules 
• Impact analysis, approval, and implementation for requests to add, change, or deprecate tags application of existing tagging requirements as new AWS services are adopted by monitoring and remediation of missing or incorrect tags

• Use each key only once for each resource. If you attempt to use the same key twice on the same resource, then your request will be rejected.
• You cannot tag a resource at the same time you create it. Tagging requires a separate action after the resource is created.
• You cannot backdate the application of a tag.
• Maximum number of tags per resource: 10
• The more tags you have, the better your AWS visibility.
• Standardize your tagging format to prevent duplications, mix-ups, and inconsistencies.
• Don’t use tags to store confidential data such as your personal information. Because tags are used across many services on AWS, the information could be accidentally shared
• Automation tools, such as CloudFormation templates can help you tag resources proactively, especially as you scale.
• Get notified automatically when tags are incorrect or missing.
• Designate a tag owner – the individual who owns a specific tag and can demonstrate its value to the organization.

AWS Tagging Rules- Naming Constructs

The following basic restrictions apply to tags.

Mandatory Types of Tags

“Environment” Tag

The “environment” tag refers to the hierarchical stages an application deployment migrates through.

Tag Name

The tag name MUST be written as “environment”.

Possible Value

• The tag value for environment MUST be one of [“Production”, “UAT”, “Test” or “Development”].
• If you have an environment that is not one of the values listed, you MUST select a value that most closely relates.  Note: the “Name” tag convention MAY allow more flexibility for this.
• The tag value SHOULD be in agreement with the scope of the account you are in.

Rationale

•  Useful for Business Owner to understand their spending by environment and possibly see opportunities for cost savings.
• Operations – Monitoring (among other things) is driven directly by the environment.

“Application” Tag

• The “application” tag refers to the application context of the resource.

 Tag Name

• The tag name MUST be “application”.

Possible Values

• The tag value for the application must be the same name as the application name in AWS

Rationale

• Billing – Since most groups manage more than one application, it is useful to be able to differentiate and spend on a per-application basis.
• Operations – By matching the nomenclature in this tag to the list of Applications then this tag can be used for Incident Management purposes and routing any requests to the specific application owner
• Security – As with Operations, this tag could be used to escalate Security incidents to the appropriate party.

“Costcenter” Tag

• The “costcenter” tag refers to the identifier used to manage billing for a resource.

Tag Name

• The tag name MUST be “cost center”.

Possible Values

• Different cost center code values then which can be defined specific to each client

Rationale

• Billing – Enables AWS Billing to divide up a single account among multiple costcenter codes.

“Name” Tag

• The “Name” tag is used by Amazon to display a default name in the AWS console for many resource types.

Tag Name

• The tag name MUST be “Name”. Note the uppercase “N”, as distinct from other Tag Names in this document.

Possible Values

• The Name value is arbitrary but SHOULD be standardized across organizations.
• Refer to AWS Naming conventions and then name should be same or similar specific to the AWS Account, Application or env name
• See the Appendix section for naming restrictions specific to your cloud vendor.

Rationale

• Operations – If this tag is not populated, then AWS consoles will not display a name for assets, making them difficult to manage at a glance.

“Platform” Tag

The “platform” tag is then primarily used for operational purposes to distinguish between the major operating system types (Linux and Windows) for better visibility within configuration management.

Tag Name

• The tag name MUST be “platform” (lowercase).

Possible Values

• Tag values must be lowercase.
• “linux” for Linux based instances (Amazon Linux, CentOS, RHEL, Ubuntu, etc…).
• “windows” for Windows based instances.

Rationale

• To allow greater visibility to the configuration management system for inventory grouping purposes.
• Allow better filtering of operating system types within other data gathering tools.

Optional Tags: AWS tagging rules

Assume that all tags and values are case sensitive, particularly for arbitrary values.

“Subproduct” Tag

• The “subproduct” is OPTIONAL and refers to specify a sub classification of your product.

Tag Name

• The tag name MUST be “subproduct”.

Possible Values

• Component of product or application (implied hierarchical relationship with product).
• Then see the Appendix section for naming restrictions specific to your cloud vendor.

Rationale

• Billing – If the “product” tag is insufficiently granular for managing IT spend inside a single group, then  this tag can also be used.

Authorization to Create/Edit Tags

• Tags are sensitive and should only be created/updated by those with the appropriate level of permission. Then this can be accomplished with an execution model which is not yet standardized at the time of this writing.
• Incorrectly tagged assets can impact both billing and uptime of your application.

Security Awareness

• Tags will help identify the appropriate owner and then to take corrective action in ongoing compliance testing.
• Tags provide the context to determine if an application has the appropriate level of security applied for its data classification.
• Without tags, a compromised asset with no ownership data may need to be forcefully locked down and then  potentially causing interruption to your business.

Conclusion: AWS tagging rules

In conclusion, Managing assets in the cloud effectively requires coordination across stakeholder interests.  A consistent tagging standard enables you to audit, authorize, bill, communicate and secure resources in the cloud more quickly. Then  Additional tags can be used in many more useful ways that are more application or department specific.

Reference

1. https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html
2. https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pd