Naming & Tagging Standards

Establish consistent resource naming conventions and mandatory tagging for cost allocation, security, and governance

16 stars

Best use case

Naming & Tagging Standards is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Establish consistent resource naming conventions and mandatory tagging for cost allocation, security, and governance

Teams using Naming & Tagging Standards should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/naming-tagging-standards/SKILL.md --create-dirs "https://raw.githubusercontent.com/diegosouzapw/awesome-omni-skill/main/skills/devops/naming-tagging-standards/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/naming-tagging-standards/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How Naming & Tagging Standards Compares

Feature / AgentNaming & Tagging StandardsStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Establish consistent resource naming conventions and mandatory tagging for cost allocation, security, and governance

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Naming & Tagging Standards

## Overview

Consistent **naming conventions** and **mandatory tags** are essential for:
- **Cost allocation** and tracking across teams, projects, and environments
- **Security** and ownership identification
- **Automation** and resource discovery
- **Compliance** and audit trails

Without standards, infrastructure becomes unmanageable at scale.

```mermaid
flowchart LR
    subgraph "Naming Convention"
        N1[Prefix: org-env-app]
        N2[Resource Type]
        N3[Optional: region/az]
    end

    subgraph "Mandatory Tags"
        T1[Environment]
        T2[Owner]
        T3[Project]
        T4[CostCenter]
        T5[ManagedBy]
    end

    subgraph "Enforcement"
        E1[Policy as Code]
        E2[CI/CD Checks]
        E3[SCPs]
    end

    N1 --> E1
    T1 --> E1
    E1 --> E2
    E2 --> E3

    style E1 fill:#FFD700
```

## Key Concepts

### Naming Pattern
A consistent pattern like `{org}-{env}-{app}-{resource}-{suffix}` ensures predictability:
- **org**: Organization or team prefix (e.g., `acme`)
- **env**: Environment (e.g., `dev`, `staging`, `prod`)
- **app**: Application name (e.g., `api`, `web`)
- **resource**: Resource type (e.g., `vpc`, `subnet`, `role`)
- **suffix**: Optional disambiguator (e.g., region, AZ, counter)

### Tag Categories
1. **Technical Tags**: Environment, Version, ManagedBy
2. **Business Tags**: Project, CostCenter, Owner
3. **Security Tags**: DataClassification, Compliance
4. **Automation Tags**: Backup, Schedule, Terraform

### Case Sensitivity
- **Resource names**: Use lowercase with hyphens (`my-vpc`)
- **Tag keys**: Use PascalCase (`CostCenter`, `Environment`)
- **Tag values**: Use lowercase (`production`, `team-a`)

## Best Practices

1. **Enforce via Policy as Code** - Use OPA/Conftest to validate naming and tags
2. **Default tags at provider level** - Apply common tags to all resources
3. **Document standards** - Maintain a living document with examples
4. **Validate in CI/CD** - Block non-compliant resources before apply
5. **Use tag policies** - AWS Organizations tag policies for enforcement
6. **Automate tagging** - Use Terraform locals/CDK aspects for consistency
7. **Reserved prefixes** - Protect system prefixes like `aws:` or `k8s:`
8. **Length limits** - Stay within AWS limits (256 chars for names, 128 for tags)

## Anti-Patterns to Avoid

❌ Inconsistent capitalization (`MyVPC` vs `my-vpc`)
❌ Using spaces in resource names
❌ Hardcoding tags in every resource (use defaults)
❌ Optional tags for required metadata (Owner, Environment)
❌ Mixing naming conventions across the same project
❌ Using generic names like `main`, `default`, `test`

---

## Example 1: Terraform - Default Tags + Naming Convention

This example demonstrates:
- Provider-level default tags applied to all resources
- Consistent naming using local variables
- Validation of naming pattern and tags via Conftest

📁 **Location**: Inline example (apply to your Terraform modules)

### Key Features

```hcl
# Provider with default tags
provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Environment       = var.environment
      ManagedBy        = "Terraform"
      Owner            = var.owner_email
      Project          = var.project_name
      CostCenter       = var.cost_center
      TerraformWorkspace = terraform.workspace
    }
  }
}

# Naming convention using locals
locals {
  # Pattern: {org}-{env}-{app}-{resource}
  name_prefix = "${var.org_prefix}-${var.environment}-${var.app_name}"

  # Common tags (merged with default_tags)
  common_tags = {
    Application      = var.app_name
    DataClassification = var.data_classification
    BackupPolicy     = var.backup_enabled ? "daily" : "none"
  }
}

# VPC with consistent naming
resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr

  tags = merge(local.common_tags, {
    Name = "${local.name_prefix}-vpc"
  })
}

# Subnet with AZ suffix
resource "aws_subnet" "private" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 4, count.index)
  availability_zone = var.availability_zones[count.index]

  tags = merge(local.common_tags, {
    Name = "${local.name_prefix}-private-${var.availability_zones[count.index]}"
    Tier = "private"
  })
}

# IAM Role with descriptive name
resource "aws_iam_role" "lambda_execution" {
  name = "${local.name_prefix}-lambda-exec-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })

  tags = merge(local.common_tags, {
    ServiceType = "Lambda"
  })
}
```

### Variables Definition

```hcl
variable "org_prefix" {
  description = "Organization prefix for resource naming"
  type        = string
  default     = "acme"

  validation {
    condition     = can(regex("^[a-z0-9-]+$", var.org_prefix))
    error_message = "org_prefix must be lowercase alphanumeric with hyphens only"
  }
}

variable "environment" {
  description = "Environment name"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "environment must be dev, staging, or prod"
  }
}

variable "owner_email" {
  description = "Email of the team/person responsible"
  type        = string

  validation {
    condition     = can(regex("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$", var.owner_email))
    error_message = "owner_email must be a valid email address"
  }
}
```

---

## Example 2: CDK - Tag Aspect + Naming Helper

This example creates:
- A CDK Aspect that automatically tags all resources
- A naming helper construct for consistent names
- Validation of required tags

📁 **Location**: Inline example (apply to your CDK apps)

### Key Features

```typescript
import * as cdk from 'aws-cdk-lib';
import { Construct, IConstruct } from 'constructs';
import { IAspect } from 'aws-cdk-lib';

// Naming helper class
export class NamingConvention {
  private readonly prefix: string;

  constructor(
    private readonly org: string,
    private readonly environment: string,
    private readonly app: string
  ) {
    this.prefix = `${org}-${environment}-${app}`;
  }

  public resource(resourceType: string, suffix?: string): string {
    const parts = [this.prefix, resourceType];
    if (suffix) parts.push(suffix);
    return parts.join('-');
  }

  public validate(): void {
    const pattern = /^[a-z0-9-]+$/;
    if (!pattern.test(this.prefix)) {
      throw new Error(`Invalid naming prefix: ${this.prefix}. Must be lowercase alphanumeric with hyphens.`);
    }
  }
}

// Mandatory tagging aspect
export class MandatoryTagsAspect implements IAspect {
  constructor(
    private readonly environment: string,
    private readonly owner: string,
    private readonly project: string,
    private readonly costCenter: string
  ) {}

  public visit(node: IConstruct): void {
    if (cdk.TagManager.isTaggable(node)) {
      cdk.Tags.of(node).add('Environment', this.environment);
      cdk.Tags.of(node).add('Owner', this.owner);
      cdk.Tags.of(node).add('Project', this.project);
      cdk.Tags.of(node).add('CostCenter', this.costCenter);
      cdk.Tags.of(node).add('ManagedBy', 'CDK');
      cdk.Tags.of(node).add('DeployedAt', new Date().toISOString().split('T')[0]);
    }
  }
}

// Usage in a stack
export class NetworkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Initialize naming convention
    const naming = new NamingConvention('acme', 'prod', 'api');
    naming.validate();

    // Apply mandatory tags to entire stack
    cdk.Aspects.of(this).add(new MandatoryTagsAspect(
      'production',
      'platform-team@acme.com',
      'customer-api',
      'eng-1001'
    ));

    // Create VPC with consistent naming
    const vpc = new ec2.Vpc(this, 'VPC', {
      vpcName: naming.resource('vpc'),
      maxAzs: 3,
      natGateways: 2,
    });

    // Additional tags specific to VPC
    cdk.Tags.of(vpc).add('NetworkTier', 'application');
    cdk.Tags.of(vpc).add('DataClassification', 'confidential');

    // S3 bucket with naming
    const bucket = new s3.Bucket(this, 'DataBucket', {
      bucketName: naming.resource('data-bucket', cdk.Stack.of(this).region),
      encryption: s3.BucketEncryption.S3_MANAGED,
    });

    cdk.Tags.of(bucket).add('DataRetention', '90-days');

    // IAM Role with naming
    const lambdaRole = new iam.Role(this, 'LambdaRole', {
      roleName: naming.resource('lambda-exec-role'),
      assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
    });

    cdk.Tags.of(lambdaRole).add('ServiceType', 'Lambda');
  }
}
```

### Application Entry Point

```typescript
#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib';
import { NetworkStack } from '../lib/network-stack';

const app = new cdk.App();

// Stack-level tags (inherited by all resources)
cdk.Tags.of(app).add('Repository', 'github.com/acme/infrastructure');
cdk.Tags.of(app).add('TeamSlack', '#platform-team');

new NetworkStack(app, 'acme-prod-api-network', {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: 'us-east-1'
  },
  description: 'Production API network infrastructure',
  tags: {
    Compliance: 'SOC2',
    BackupPolicy: 'daily'
  }
});

app.synth();
```

---

## Validation Checklist

- [ ] All resources follow naming convention: `{org}-{env}-{app}-{resource}`
- [ ] Required tags present: Environment, Owner, Project, CostCenter, ManagedBy
- [ ] Tag keys use PascalCase, values use lowercase
- [ ] Default tags configured at provider/app level
- [ ] CI/CD pipeline validates naming and tags via Conftest
- [ ] Documentation updated with examples
- [ ] AWS Organizations tag policies enabled (if applicable)
- [ ] No hardcoded tags in individual resources

## Related Skills

- [Compliance Tagging](../compliance-tagging/SKILL.md) - Enforce tags for compliance
- [Cost Governance](../cost-governance/SKILL.md) - Use tags for cost allocation
- [Policy as Code](../policy-as-code/SKILL.md) - Validate naming with OPA
- [GitOps Workflow](../gitops-workflow/SKILL.md) - Automated validation in PR checks

Related Skills

caf-naming-validation

16
from diegosouzapw/awesome-omni-skill

Validate Azure Cloud Adoption Framework (CAF) naming conventions in Terraform modules and examples. Use this skill to ensure resource names follow Microsoft CAF standards and prevent naming conflicts.

write-coding-standards-from-file

16
from diegosouzapw/awesome-omni-skill

Write a coding standards document for a project using the coding styles from the file(s) and/or folder(s) passed as arguments in the prompt.

standards-typescript

16
from diegosouzapw/awesome-omni-skill

This skill provides TypeScript coding standards and is automatically loaded for TypeScript projects. It includes naming conventions, best practices, and recommended tooling.

standards-python

16
from diegosouzapw/awesome-omni-skill

This skill provides Python coding standards and is automatically loaded for Python projects. It includes naming conventions, best practices, and recommended tooling.

standards-frontend

16
from diegosouzapw/awesome-omni-skill

Frontend component and UI development standards for modern React/Next.js applications. Includes React 19 patterns, Tailwind CSS v4, Server Components, accessibility, and the Anthropic frontend-design aesthetic philosophy.

security-environment-standards

16
from diegosouzapw/awesome-omni-skill

Security and environment configuration standards for web applications, including environment variable management, secure coding practices, and production deployment security. Use when setting up environments, configuring security, or deploying applications.

modern-python-standards

16
from diegosouzapw/awesome-omni-skill

Strict adherence to modern (3.11+), idiomatic, and type-safe Python development.

mcp-standards

16
from diegosouzapw/awesome-omni-skill

MCP server standardization patterns for Claude Code plugins. Use when implementing MCP servers, designing tool interfaces, configuring MCP transports, or standardizing MCP naming conventions. Trigger keywords - "MCP", "MCP server", "MCP tools", "MCP transport", "tool naming", "MCP configuration".

global-standards

16
from diegosouzapw/awesome-omni-skill

Project-wide coding standards and conventions specialist. Use PROACTIVELY when writing code, making architectural decisions, or establishing project conventions. Covers coding style, commenting, error handling, validation, tech stack consistency, and project conventions across all languages and frameworks.

frontend-ui-tailwind-standards

16
from diegosouzapw/awesome-omni-skill

Standardized guidelines and patterns for Frontend Ui Tailwind Standards.

Frontend Responsive Design Standards

16
from diegosouzapw/awesome-omni-skill

Build responsive, mobile-first layouts using fluid containers, flexible units, media queries, and touch-friendly design that works across all screen sizes. Use this skill when creating or modifying UI layouts, responsive grids, breakpoint styles, mobile navigation, or any interface that needs to adapt to different screen sizes. Apply when working with responsive CSS, media queries, viewport settings, flexbox/grid layouts, mobile-first styling, breakpoint definitions (mobile, tablet, desktop), touch target sizing, relative units (rem, em, %), image optimization for different screens, or testing layouts across multiple devices. Use for any task involving multi-device support, responsive design patterns, or adaptive layouts.

engineering-standards

16
from diegosouzapw/awesome-omni-skill

Comprehensive engineering standards for monorepo projects with Claude Code, covering hooks, testing, documentation, quality gates, and best practices. Use when setting up new projects, validating compliance, or extracting patterns from existing codebases.