Developing an AWS tagging strategy can feel like wrangling different cooks in the same kitchen. Engineers want to innovate, fix issues, and improve existing code. Finance wants to know if the company is making a healthy return on technology investments. Yet, the cloud is like a menu without the pricing.
In their quest for continuous improvement, engineers can innovate without slowing down. And this can consume more computing resources than expected, leading to a surprise AWS bill.
What’s worse is not knowing what’s driving up the costs; like where, when, or who is doing it. This makes it tough for engineers and finance to pinpoint where they can minimize waste and maximize ROI.
How does that relate to AWS tags? We’ll explore how tags contribute to everything, from AWS cost management to performance optimization.
We’ll also share key tagging best practices you can apply immediately to minimize endless tagging exercises and make the most of AWS tags – even if you have messy tags.
What Are Tags In AWS?
Tags hold the metadata you need to label and identify different resources across your Amazon Web Services environment. This data enables you to distinguish various aspects of your cloud, such as resource consumption, associated costs, and performance metrics organized under team, department, project, and other attributes.
An AWS tagging strategy outlines the specific rules and practices your organization needs to follow to make the most of tags.
For example, the strategy can help your team decide exactly how to use tags (such as what format to use), who should create them, and how the tags should be maintained over time.
Amazon EC2 instances, Amazon S3 buckets, Redshift, Amazon RDS databases, and EFS all support tagging, as do many other AWS services.
How Does Tagging Work In AWS?
A tag consists of a key and value pair. For each resource, you can create a unique key with only one value.
Imagine managing a large office with diverse departments, projects, and equipment. To keep everything organized, you’d use sticky notes. These sticky notes are analogous to AWS tags.
Here’s what we mean.
Labeling, identifying, and categorizing
Just as you can stick notes on equipment, desks, and documents to identify them, you can tag AWS resources to label them. Each sticky note (tag) has a key (like a category) and a value (specific information).
For example, you might have a sticky note that says “Department: Finance” on a filing cabinet. In AWS, this could be a tag on an EC2 instance like “Department: Finance”.
Organizing and managing resources
You can use sticky notes to group related items together. In the office, you might use different colors or categories to keep track of which department uses which resources. Similarly, in AWS, you use tags to group resources. For instance, all resources related to a specific project might have a tag like “Project: Alpha”.
Tracking costs and ownership
In an office, you might use sticky notes to allocate costs to different departments. For example, you can label each printer with a sticky note indicating which department should be charged for its usage.
In AWS, tags like “Cost Center: Marketing” help track and allocate costs to specific departments or projects, making it easier for CFOs to manage budgets.
Automating processes
You might use sticky notes to remind yourself of tasks, such as “Refill roast coffee every Monday and Thursday”. These notes can help you automate mundane tasks.
AWS tags can use policies and scripts to automate tasks. For instance, an EC2 instance tagged with “Schedule: Office_Hours” could be automatically started and stopped based on a specific team’s working hours.
Improving security and compliance
Imagine you have sensitive documents that need special handling. You place a red sticky note on them saying “Confidential”. This ensures everyone knows to handle these documents carefully.
In AWS, tags like “Compliance: GDPR” or “Security: High” ensure resources are handled according to regulatory and security requirements.
Just as sticky notes help you organize, manage, and track different items in an office, AWS tags help you manage, organize, and optimize your cloud resources. This also means tagging your AWS resources can help your organization to:
- Analyze resource usage by specific areas, such as by team, department, project, customer, software feature, and so on.
- Improve visibility into your cloud components, such as tracking the specific workloads that drive your AWS cloud costs.
- Use tagging metadata to identify resources that you need to update.
- You can improve accountability by revealing who has activated which resources, what instances they have activated, and limiting access to certain resources.
Consider these examples:
Key | Values |
Team | DevOps |
Team | Engineering |
Team | Product |
Team | Marketing |
You can assign more than one value to one key. Among the most popular keys are Business Unit, Account, Project, Owner, Environment, and Cost Center. These types of tags can help you identify which team owns a particular resource, in what environment it runs, and to which business unit it belongs.
The following table shows multiple keys and the unique values they contain:
Key | Values |
Team | DevOps |
Team | Engineering |
Team | Product |
Team | Marketing |
Ultimately, the tagging feature helps you add descriptive metadata to assets, including Amazon EC2 instances, S3 buckets, RDS databases, and Lambda functions. Tags add context to a resource by providing additional information about its usage.
The two types of AWS tags
There are two types of AWS tags:
- AWS-generated tags – These are tags that AWS automatically generates, so you cannot alter them. Their prefix is usually aws: (aws:createdBy), and they typically contain a string of numbers and letters. You can tell who created the resource by looking at the createdBy tag. Subnet IDs and instance IDs are two examples of AWS generated tags.
- User-generated tags – These are tags you create, define, and implement as you see fit for your use cases. AWS lets you add 50 tags to a single resource.
Credit: AWS Docs
Let’s talk about AWS cost allocation tags
They are based on ordinary AWS tags. However, you need to take an extra step and designate specific tag(s) as cost allocation tag(s). And if at some point you decide to move an account to another organization as a member, you must re-activate these cost allocation tags again.
In addition, only a management account or a single account that isn’t a member of an organization can access cost allocation tags in Billing and Cost Management.
There’s more.
- You can only see your cost allocation tags in Billing and Cost Management if you’ve also enabled AWS Cost and Usage Reports, AWS Cost Explorer, legacy reports, or AWS Budgets.
- You cannot tag the resources you created before tagging. Neither can they be backdated.
- Unmetered resources can be tagged, but they do not appear in the Cost Management suite.
- Since Billing and Cost Management does not decode or encode tags for you, you have to manually tag your resources to start collecting and making sense of your AWS spending.
The Three Major Challenges Of Tagging In AWS
Implementing proper AWS tagging can be challenging for several reasons:
- Lack of an AWS tagging strategy or late adoption – It can be challenging to develop a comprehensive tagging strategy that requires input from many different parts of the organization. Many companies have yet to undergo this process or are trying to do it as their cloud usage grows.
- Inadequate governance and enforcement/consistency issues – As organizations scale and add new teams and cloud services, any existing tagging structures will inevitably break down without effort to hold them in place.
- Being unaware of available tools and platforms – Tagging can be complex, but you don’t have to go it alone. Platforms like CloudZero are here to help, whether your tagging is perfect or far from it.
Related Read: 8 Issues With AWS Tags and How to Overcome Them For Good
That said, tagging can help you answer critical questions about your business, such as:
- What is the most expensive feature of our product?
- How much does this product cost per user or instance?
- Which projects cost us the most to support?
- What features do most of our customers use?
These are a few of the many benefits of AWS tagging that you’d love to take advantage of. So where do you start?
How To Implement A Comprehensive AWS Tagging Strategy
From the AWS Console, use the AWS Tag Editor to tag different resources. You can add or remove tags from individual and/or multiple resources using the service.
Suppose you deploy resources automatically (with Cloud Formation templates). In that case, you can embed tagging requirements in the template so that resources can launch automatically with the proper tags applied.
You can also use AWS Config rules as your business grows and develops its cloud environment. This can alert you to assets that are not appropriately tagged.
They can also provide your developers with pre-selected tag values to avoid capitalization and naming mistakes. Or, they can prevent assets from launching altogether if they aren’t correctly tagged.
So, how do you implement a suitable tagging strategy for your AWS needs?
You’ll want to start by answering a few questions about People, Processes, and Technology. We recommend involving different departments. That includes obtaining feedback from all stakeholders who plan on using the cloud environment.
Consider this:
- People – Do you have buy-in from different business units and leaders? Do you have a dedicated team in place to lead the initiative?
- Process – How complex is your cloud environment, and how complex do you want your AWS tagging strategy to be? What is the process for adding or deleting new tags? What is the organization looking to achieve or to see through its tagging system? What are the reporting needs that we need our tagging structure to support? What prior tagging structures should be retained or changed?
- Technology – Do you (or the team tasked with this initiative) have an understanding of tags and the products and services that support them? What is the team’s overall level of familiarity with AWS Tag Editor and AWS Config?
A few standard categories and dimensions serve as a great starting point for actual tagging. These categories are certainly not exhaustive, and multiple buckets can and should be used simultaneously.
Technical (Used to describe what a resource is doing) | Cluster ID | Identify resource farms that share common identification |
Version | Identify different version of applications | |
Name | Individual Resource Name | |
Automation (Used to automate certain functions) | Date/Time | Identify when a resource shot bet started, stopped, rotated or terminated |
Opt In/Out | Indicate whether a resource should be automatically included in an automated activity (such as resizing) | |
Security | Determine requirements such as encryption and to identify tables or security groups that deserve extra scrutiny | |
Business (Used to translate AWS environment into business contexts) | Owner | Identify who is responsible for the resource |
Cost Center / Business Unit | Identify which cost center is associated with a resource for cost allocation tracking | |
Customer | Identify a specific client that a particular group of resources serve | |
Project | Identify the project(s) the resource supports | |
Security (Especially important in compliance-heavy industries like healthcare or financial services) | Confidentiality | Identify the level of data confidentiality a resource supports |
Compliance | Identify workloads designed to adhere to specific requirements |
With the answers to these high-level questions, there are many more granular questions related to the tagging itself that you’ll want to consider:
- What casing will you standardize on? (Keys and values are case-sensitive in AWS, and we recommend always using a standardized, case-sensitive format)
- Will your tags be used for resource control, automation, or both?
- Which tags will be allowed or blocked?
- Will you use automation such as AWS Config to assist in your tagging?
- How many tags should you use? As more tags lead to more granularity in reporting, we recommend erring on the side of using too many tags instead of too few.
- How will future changes to your business impact your tagging strategy? If you use tags to regulate access control, automation, or billing reports, understand how changing those tags will affect the related processes.
- What naming or service restrictions do you need to take into consideration?
- How will your tagging strategy promote regulatory compliance, if desired or necessary for your business?
[Checklist] 15 Best Practices For Tagging AWS Resources
Below are some high-level tips for improving your AWS tagging strategy.
- Identify and brainstorm tag requirements with a cross-functional team.
- Name your tags, so every employee in your organization knows the key, values, and purpose for the tag — and how to use it consistently.
- Standardize your tagging format to prevent duplications, mix-ups, and inconsistencies.
- More tags are better. Your AWS visibility improves as you tag more resources in your AWS environment.
- Bulk-tag resources with AWS Tag Editor.
- Don’t use tags to store confidential data, such as your personal information. Tags are applied across services, so the information could be accidentally shared.
- Automation tools, such as CloudFormation templates, can help you tag resources proactively, especially as you scale.
- Use AWS Identity and Access Management (IAM) to restrict who has access to the resources you tag.
- Get notified automatically when tags are incorrect or missing.
- Tag costs with your business categories, segments, etc. This will help you organize your data in the context of your business.
- Configure alert management and anomaly detection to ensure your team gets rapid alerts. Limit the number of alerts they receive to prevent alert fatigue.
- Designate a tag owner. This is the individual who owns a specific tag and can demonstrate its value to the organization.
- Avoid compound tags (tags with multiple values) in favor of single-value tags to minimize complexity.
- Meet regularly to review, revise, and reinvent AWS tagging best practices based on your changing needs.
- Choose a platform to meet your tagging needs where you are – such that it can deliver accurate cloud insights regardless of tagging quality.
Those are the foundations. Here are more advanced AWS tagging techniques you can apply right away.
Automate tagging with AWS Lambda and AWS Config
This combo can help you automatically apply tags to newly created resources. The AWS Config lets you set up rules to enforce tagging policies using Lambda functions. This ensures that all your resources are tagged consistently and prevents untagged resources from being created.
You can create Lambda functions that check for mandatory tags and apply default tags if they are missing. This automation will save you time and reduce manual tagging errors.
Tag policies with AWS Organizations
AWS Organizations enables you to create and enforce tag policies across all accounts in your organization. Tag policies define rules for allowed tag keys and values. And this ensures consistency and compliance across multiple AWS accounts.
Advanced cost allocation and chargeback
Apply tags such as Project, Department, and Team to generate granular cost reports and allocate costs more accurately. Then integrate AWS Cost Explorer and AWS Budgets with your tagging strategy to monitor and analyze costs based on tags.
You can use this best practice to automatically shut down or scale down resources based on specific tag values, as two examples.
Integrating tags into CI/CD pipelines
The goal here is to ensure that all deployed resources are properly tagged. You can use tools like AWS CloudFormation or Terraform to define tags within your infrastructure as code (IaC) templates.
Tip: You’ll want to incorporate tagging checks into your CI/CD workflows to enforce tagging standards before resources are deployed. This ensures that all resources are tagged correctly at creation.
Tag-based access control with IAM policies
Tag-based access control enables you to create more granular and flexible access policies. How? Start by defining IAM policies that allow or deny actions on resources based on specific tag conditions. For example, you can restrict access to Amazon EC2 instances tagged with say “Environment: Production” to authorized users only.
Tag inheritance in nested resources
This is so that sub-resources inherit tags from their parent resources. This is particularly useful in complex deployments where resources are hierarchically organized.
You can use automation scripts or tools, such as AWS Resource Groups, to propagate tags from parent resources to child resources. For instance, ensure that tags applied to an EC2 instance are also applied to its attached EBS volumes and network interfaces.
Tagging for governance and compliance:
You’ll want clear ownership and accountability for tag management. And that requires reviewing and updating your tagging strategy to meet your changing needs. In that case, use AWS Config and AWS Organizations to enforce tagging policies and generate compliance reports. As a result, your AWS environment will have consistent tagging.
There’s more.
If you are looking for specific nuggets, here are additional tagging best practices for select core AWS services.
Tagging Best Practices For Amazon EC2 Instances
Consider the following tagging best practices for Amazon EC2 instances:
- Maintain a consistent naming convention: Use a clear and consistent naming convention for your EC2 instance tags. You can use a mix of business context, technical details, and/or ownership information. This will make it easier to search, filter, and manage your instances.
- Identify your baseline tags: Define a core set of mandatory tags that must be applied to all EC2 instances, such as environment, application, and cost center. The baseline tag set will be the basis for creating a consistent tagging strategy.
- Automate EC2 tagging: Leverage automation tools like AWS Config, AWS CloudFormation, or third-party solutions to automatically apply tags to newly created EC2 instances. This can help you reduce the risk of human error and ensure thorough tagging.
- About tag inheritance: Set up your EC2 instances to inherit tags from related resources, such as Amazon EBS volumes or Elastic IP addresses. This is great for propagating tags across your infrastructure and maintaining data lineage.
- Configure access control: Use tags as condition keys in IAM policies to control access to EC2 instances based on tag values. You can restrict what actions someone can take based on the purpose or ownership of the instances.
- Use tags for cost allocation: Take advantage of tags to track and allocate costs for your EC2 instances via AWS Cost Explorer and other AWS cost management tools.
- Continuous improvement: Regularly audit your EC2 instances to ensure tags are applied correctly and consistently. This will help maintain compliance with your organization’s tagging policies and support regulatory requirements.
Tagging Best Practices For Amazon S3
- Audit all your Amazon S3 buckets: Use tools like AWS Tag Editor and S3 Inventory to track and report on your objects’ replication and encryption status.
- Tag buckets to specify their environment, such as “Environment: Production”, “Environment: Development”, or “Environment: Testing”. This will help you organize and group resources based on their operational context.
- Use tags to manage data lifecycle policies. For example, “Lifecycle: Archive_After_30_Days” or “Retention: Permanent” automates data archiving, deletion, or transitioning to different S3 storage classes based on its lifecycle stage.
- Implement tags that classify the sensitivity of data stored in the buckets: For example, “Data Sensitivity: Confidential”, “Data Sensitivity: Public”, or “Data Sensitivity: Internal”. And this can improve your buckets’ security and access controls.
- Monitor key metrics like PutRequests, GetRequests, 4xxErrors, and DeleteRequests. Use AWS CloudWatch for this. Set up server access logging to obtain detailed records of requests and use AWS CloudTrail to track actions taken on your S3 buckets.
- Use AWS CloudTrail: Use it to configure a trail that enables you to continuously record activities on your S3 buckets. Set up CloudTrail to log specific data events such as GetObject, DeleteObject, and PutObject to monitor object-level API activity.
- Use tags like Cost Center, Billing Code, or Project to allocate and track storage costs. For example, Cost Center: This will help you associate your S3 storage costs with specific departments, teams, projects, etc.
- Tag buckets to associate them with specific applications or services: For example, use “Application: WebApp” or “Service: Backup” to specify the purpose of each bucket and manage resources based on their application context.
- Enable Multi-factor Authentication (MFA) delete: This feature requires additional authentication before permanently deleting an object version or changing the bucket’s versioning state, which can add an extra layer of security.
- Use tags to identify and manage S3 resources that require more sophisticated security risk management. Keep bucket policies from granting access using wildcards. Additionally, routinely update policies to ensure they grant access to specific entities.
Tagging Best Practices For Amazon RDS
Consider the following for RDS databases:
- Use tags to link databases to specific applications or services: For example, use “Application: CRM” or “Service: Inventory_Management” to identify the purpose of each database and simplify application management.
- Use tags that indicate compliance and security requirements, such as “Compliance: PCI-DSS” or “Compliance: HIPAA”, or “Security: High”. You certainly want your databases to meet regulatory standards and security protocols.
- About backup and recovery tags: Add tags to manage backup policies and recovery plans, like “Backup: Daily” or “Retention: 30_Days”. This will help you automate the backup and retention processes.
- Assign tags to indicate database ownership and access levels: Examples here include “Owner: Database_Team” or “Access: Restricted”. The goal here is to encourage accountability and ensure that only authorized personnel can access the databases.
- Performance and monitoring tags: Create tags for performance monitoring and maintenance purposes, such as “Performance: Critical”.
- Automate tagging for RDS databases: AWS CloudFormation, AWS Lambda, and AWS Systems Manager can help you automatically apply tags to new RDS databases with minimal error.
- Avoid creating excessive RDS tags. Yes, you can have up to 50 tags per RDS resource. Yet it’s prudent to only use necessary and valuable tags. It helps reduce complexity.
- Ensure proper tag inheritance: Confirm that your RDS resources inherit tags from related resources, such as EC2 instances or EBS volumes. This will help you maintain data lineage and consistency across your AWS infrastructure.
Tagging Best Practices For AWS Lambda
- Set up your Lambda functions to inherit tags from related resources, including Amazon VPC subnets and Amazon CloudWatch Logs. This propagates tags across your infrastructure and maintains data lineage.
- Tag Lambda functions with the environment they belong to. Examples here include “Environment: Production”, “Environment: Development”, or “Environment: Testing”. You want to be able to organize, filter, and manage your functions according to their operational context.
- Tag Lambda functions to indicate their deployment stage, such as “Stage: Dev”, “Stage: QA”, or “Stage: Prod” in the development and deployment pipeline.
- Usage and schedule tags: Create tags to manage function usage and scheduling, for example, “Usage: High” or “Schedule: Nightly”. The purpose of this is to understand usage patterns so you can optimize execution times.
- Use tags to pinpoint the application or service the Lambda function is part of. It will help you group related functions and manage them together.
- Add tags to specify the type of function, such as “API Gateway”, “Scheduled”, or “Event-driven” — handy for filtering and managing functions based on their purpose.
- Assign tags to indicate the AWS region in which the Lambda function is deployed. It helps manage functions across different regions and track costs accordingly.
- Use tags to define the architecture or technology stack used in each Lambda function. The goal is to ensure compatibility with other resources and manage functions according to their technical requirements.
- Apply tags to identify the version of each Lambda function. By doing this, you can manage different versions of functions and track changes over time.
- Create tags to indicate the trigger or event that invokes each Lambda function. Managing events-driven functions and configuring them correctly becomes easier this way.
How AWS Tags Affect Cost Allocation And Reporting
Most cost management tools, including AWS Cost Explorer, rely heavily on tags to provide cost analysis.
By assigning tags such as “cost center”, “project”, “environment”, and “owner” to specific AWS resources, you can allocate costs to specific departments, projects, or teams.
This level of detail can help you identify cost drivers for precise cost visibility, budget tracking, and cost optimization. You can also filter, group, and analyze your AWS cost data based on tags that can provide valuable insights to support decision-making and continuous improvement.
You can also use tags to automate cost-saving actions. That can include auto-terminating non-production resources during off-hours or scaling down resources based on usage patterns or demand.
Better yet, you can use tags to enforce cost control policies, such as budget limits or resource quotas, across your AWS environment.
Ultimately, the more comprehensive your tagging is, the more you can generate detailed reports on resource usage, costs, and other metrics. You can tailor these reports to meet the needs of different stakeholders, including finance, engineering, and business teams.
So, what do you do if your tags are already a mess?
How To Allocate Costs Without Perfect Tags
Whatever your organization’s approach to tagging, you’ll want to have a solid understanding of how you’ll execute your AWS tagging strategy.
We recommend that you create dynamic documents that outline your organization’s answers to the questions above and provide a place for any questions, rules, or rationales related to tagging.
Yet tagging is not enough
As time passes and your team evolves, be sure to have regular check-ins and updates across teams to reinforce your chosen approach. Accordingly, you’ll want to regularly update and circulate it to all relevant teams.
Additionally, we recommend checking out our article, “Messy AWS Tags? Confidently Allocate Costs Without a Perfect Tagging Strategy”, to learn more about ways you can allocate costs without perfect tagging.
Better yet, you can stop wasting time on tagging when you use CloudZero. CloudZero meets you where you are in your tagging strategy:
With CloudZero, you can:
- Get hourly, granular cost information including Cost per Customer, Cost per Feature, and Cost per Team (plus custom dimensions like Cost per Customer per Feature), without endless tagging. Yes, this means you can tell exactly who, what, and why your AWS costs are changing and fix it.
- Allocate 100% of your AWS spend in moments, even if you have a complex environment — not days or months. You’ll have the complete picture to make cost decisions with confidence.
- Get the same level of cost insight across shared, containerized, and non-containerized resources.
- Follow your allocation edits in real-time and be audit-ready in as little as minutes, not weeks.
- You’ll have a single source of truth for all your cloud costs because CloudZero works where you do; AWS, Azure, GCP, Oracle, Snowflake, Kubernetes, MongoDB, Databricks, New Relic, and more. No separate dashboards, tools, or subscriptions are required.
- Receive timely, context-rich, and immediately actionable cost anomaly alerts to detect and fix issues before they cause budget overruns.
Drift and New Relic are just some of the brands that trust CloudZero to deliver. Drift already saved $2.4 million. Here’s your chance, too.
The Cloud Cost Playbook
The step-by-step guide to cost maturity
