Resource Naming and Tagging Standard

Defines normalized naming, mandatory metadata, ownership, cost-allocation, data-classification, and lifecycle controls for cloud resources.

Purpose

This standard defines a consistent naming and metadata model for Azure, AWS, GCP, and OCI resources. Names support human recognition and technical integration; tags or labels provide authoritative metadata for ownership, cost allocation, policy, security, operations, and lifecycle management.

Names are not a substitute for tags. Names SHOULD remain concise and stable, while changeable business metadata MUST be stored in tags, labels, or the enterprise resource catalog.

Normative language

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY are normative:

• MUST / MUST NOT: mandatory for in-scope platforms and workloads.
• SHOULD / SHOULD NOT: expected unless a documented risk-based exception is approved.
• MAY: optional and selected according to workload requirements.

Where a cloud-provider feature cannot implement a requirement directly, the implementation MUST provide an equivalent control and record the equivalence in the architecture decision record (ADR).

Naming and metadata principles

1. Stable names, mutable metadata. Do not encode information in a name when it is expected to change.
2. Provider constraints are authoritative. The normalized model MUST be adapted to service-specific length, character, uniqueness, and immutability rules.
3. No sensitive data. Names and tags MUST NOT contain secrets, personal data, customer names, or regulated identifiers unless specifically approved.
4. Metadata has controlled vocabulary. Required keys and enumerated values MUST be centrally defined.
5. Ownership and cost are mandatory. Every billable resource MUST be attributable to an accountable owner and cost object.

Mandatory requirements

Metadata flow

Standard naming model

The preferred logical pattern is:

<organization>-<application>-<component>-<environment>-<region>-<instance>

Not every element belongs in every provider resource name. The implementation MUST define service-specific abbreviations and maximum lengths. Omit elements that are already unambiguous from hierarchy or that cause invalid or unstable names.

Examples:

acme-payments-api-prod-cac-01
acme-data-lake-dev-use1
acme-shared-dns-prod-global

Abbreviations MUST be centrally published. Teams MUST NOT invent new abbreviations when an approved value exists.

Required metadata dictionary

Optional metadata SHOULD include business_unit, product_owner, expiry_date, backup_policy, patch_group, compliance_scope, and service_level when relevant.

Enforcement hierarchy

1. Naming and tagging functions in reusable modules.
2. CI policy-as-code before deployment.
3. Provider organization policy at deployment time.
4. Scheduled inventory scans and remediation.
5. Cost and security reports using the same metadata dictionary.

Automatic inheritance MAY reduce duplication, but the effective metadata on a resource MUST be queryable and reliable for its consumers.

Multi-cloud implementation mapping

Provider products are implementation examples, not exemptions from the normative requirements. Equivalent services MAY be used when they satisfy the same control objective.

Validation

Adoption checklist

• Publish approved name components and abbreviations.
• Implement provider-specific naming functions.
• Define controlled metadata vocabulary.
• Enforce required tags in IaC and policy.
• Map metadata into cost, security, and support systems.
• Scan for PII and secrets in names/tags.
• Report unknown owners and unallocated spend.
• Integrate decommissioning with inventory updates.

Assurance evidence

Evidence MUST be reproducible and retained according to the enterprise records schedule. Acceptable evidence includes:

• version-controlled configuration and policy;
• pipeline logs and approval records;
• policy evaluation results;
• configuration snapshots or inventory exports;
• test and recovery reports;
• dashboards with query definitions; and
• approved ADRs and exception records.

Screenshots alone SHOULD NOT be treated as primary evidence when machine-readable evidence is available.

Governance, exceptions, and enforcement

The Cloud Center of Excellence owns this standard. Platform engineering, security, reliability, application, data, and FinOps teams are accountable for implementing controls within their scope.

Exceptions MUST:

1. identify the unmet requirement ID;
2. describe business justification and quantified risk;
3. define compensating controls;
4. name an accountable owner;
5. include an expiry date not exceeding 180 days; and
6. be approved by the control owner and the relevant risk authority.

Expired exceptions are non-compliant. Automated policy checks SHOULD block new non-compliant deployments. Existing non-compliance MUST be tracked through a remediation backlog with owners and due dates.

Review cycle

This document MUST be reviewed at least annually and after a material change to cloud-provider capabilities, regulatory obligations, enterprise risk tolerance, or the operating model. Changes MUST preserve requirement identifiers where the underlying control intent remains unchanged.

Related topics

• Cloud Security and Zero-Trust Standard
• Repository Structure and Documentation Standard
• Backup, Recovery, and Resilience Standard

References

• Microsoft Cloud Adoption Framework: Define your naming convention
• AWS Tagging Best Practices
• GCP: Creating and managing labels
• OCI Tagging Overview
• Microsoft Azure Well-Architected Framework
• AWS Well-Architected Framework
• GCP Well-Architected Framework
• OCI Cloud Adoption Framework