AWS Tagging Rules to implement effctive Tagging Strategy

This article discusses the steps with AWS Tagging Rules. Read more to know how it helps you implement an effective tagging strategy.

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.

Restriction	Description
Maximum number of tags per resource	50
Maximum key length	128 Unicode characters in UTF-8
Maximum value length	256 Unicode characters in UTF-8
Prefix restriction	Do not use the aws: prefix in your tag names or values because it is reserved for AWS use. You can’t edit or delete tag names or values with this prefix. Then tags with this prefix do not count against your tags per resource limit.
Character restrictions	Tags may only contain Unicode letters, digits, whitespace, or these symbols: _ . : / = + – @

Mandatory Types of Tags

The following basic restrictions apply to 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.

Rationale

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

Share us

Get A Quote

Get in touch and Know more!

Email Us

info@peritossolutions.com

Optimize Dynamics CRM Customizations with goal management—set, track, and achieve business objectives using deal, task,…

Thinking about a project? Get in touch with us.

Connect with Us Today through the Details Below or Fill
Out the Form for a Prompt Response

Book Free Consultation

Guaranteed response within 8 business hours.

Trusted by Startups and Fortune 500 companies

07+ years of experience

We can handle projects of all complexities.

100+ satisfied customers

Startups to Fortune 500, we have worked with all.

20+ in-house team

Top 1% industry talent to ensure your digital success.

Software Consulting, Outsourcing & Training

Assessments

Cloud Consulting

Industry Types

Products & Offerings

AWS Tagging Rules to implement effctive Tagging Strategy