{"id":25564592,"url":"https://github.com/datachefhq/cloud-naming-strategy","last_synced_at":"2026-05-07T13:33:33.955Z","repository":{"id":278175043,"uuid":"934752071","full_name":"DataChefHQ/cloud-naming-strategy","owner":"DataChefHQ","description":"An open-source, domain-driven resource naming and tagging strategy for AWS, Azure, and GCP—aligned with Well-Architected best practices.","archived":false,"fork":false,"pushed_at":"2025-02-18T11:43:34.000Z","size":16,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"main","last_synced_at":"2025-02-18T12:23:13.896Z","etag":null,"topics":["aws","azure","gcp"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/DataChefHQ.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-02-18T10:52:01.000Z","updated_at":"2025-02-18T11:43:49.000Z","dependencies_parsed_at":"2025-02-18T12:23:15.475Z","dependency_job_id":"2164e337-0398-4f0f-b7b4-6f7f33227fa3","html_url":"https://github.com/DataChefHQ/cloud-naming-strategy","commit_stats":null,"previous_names":["datachefhq/cloud-naming-strategy"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DataChefHQ%2Fcloud-naming-strategy","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DataChefHQ%2Fcloud-naming-strategy/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DataChefHQ%2Fcloud-naming-strategy/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DataChefHQ%2Fcloud-naming-strategy/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/DataChefHQ","download_url":"https://codeload.github.com/DataChefHQ/cloud-naming-strategy/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":239915411,"owners_count":19717851,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","azure","gcp"],"created_at":"2025-02-20T21:20:50.964Z","updated_at":"2026-05-07T13:33:33.924Z","avatar_url":"https://github.com/DataChefHQ.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# **Hybrid Domain-Driven Resource Naming \u0026 Tagging Strategy for AWS, GCP and Azure**\n\n## Version History\n\n| Version | Date       | Description                                                                              |\n|---------|------------|------------------------------------------------------------------------------------------|\n| 1.0.0   | 2025-02-19 | Initial public release of the hybrid domain-driven naming and tagging strategy document. |\n\n## **1. Introduction**\n\nWithout a clear naming and tagging strategy, cloud environments become\nchaotic, making it hard to track costs, enforce security, and manage\nresources. Inconsistent naming leads to confusion, increases\noperational overhead, and slows down troubleshooting. Poor tagging\ncauses visibility issues, making automation, compliance, and reporting\nunreliable.\n\nWhen working across **AWS**, **Azure**, and **GCP**, a consistent and\n**domain-focused** naming and tagging strategy helps:\n\n1. **Identify** resource owners and intended purposes.\n2. **Track costs** per team or product.\n3. **Apply governance and compliance** (e.g., data classification).\n4. **Automate** certain operational tasks (backups, lifecycle\n   management, etc.).\n\nThis document defines a **short, domain-driven naming convention**\nplus a **robust tagging framework**, ensuring clarity, scalability,\nand alignment with **Well-Architected** best practices.\n\n\u003c!-- markdown-toc start - Don't edit this section. Run M-x markdown-toc-refresh-toc --\u003e\n**Table of Contents**\n\n- [**Hybrid Domain-Driven Resource Naming \u0026 Tagging Strategy for AWS, GCP and Azure**](#hybrid-domain-driven-resource-naming--tagging-strategy-for-aws-gcp-and-azure)\n  - [Version History](#version-history)\n  - [**1. Introduction**](#1-introduction)\n  - [**2. Why a Domain-Driven Approach?**](#2-why-a-domain-driven-approach)\n  - [**3. Naming Convention**](#3-naming-convention)\n    - [**3.1 Short, Domain-Centric Pattern**](#31-short-domain-centric-pattern)\n    - [**3.2 Cloud-Specific Adjustments**](#32-cloud-specific-adjustments)\n  - [**4. Tagging / Labeling Strategy**](#4-tagging--labeling-strategy)\n    - [**4.1 Recommended Tag/Label Keys**](#41-recommended-taglabel-keys)\n    - [**4.2 Policy Enforcement**](#42-policy-enforcement)\n  - [**5. Operationalizing the Strategy**](#5-operationalizing-the-strategy)\n    - [**5.1 Infrastructure as Code (IaC)**](#51-infrastructure-as-code-iac)\n    - [**5.2 Governance \u0026 Compliance**](#52-governance--compliance)\n    - [**5.3 Education \u0026 Adoption**](#53-education--adoption)\n  - [**6. Example End-to-End Scenario**](#6-example-end-to-end-scenario)\n    - [**6.1 Use Case**](#61-use-case)\n    - [**6.2 Tagging / Labeling**](#62-tagging--labeling)\n  - [**7. Alignment with AWS and Azure Well-Architected**](#7-alignment-with-aws-and-azure-well-architected)\n  - [**8. Conclusion**](#8-conclusion)\n    - [**Key Advantages**](#key-advantages)\n\n\u003c!-- markdown-toc end --\u003e\n\n---\n\n## **2. Why a Domain-Driven Approach?**\n\n- **Clarity**: Embeds your business domains (e.g., Marketing, Finance)\n  or key applications (e.g., “Analytics”, “Billing”) in resource\n  names, making it obvious which function the resource supports.\n- **Ownership**: Easier for teams to see which domain or application\n  they’re responsible for.\n- **Streamlined Governance**: Domain-driven naming aligns with your\n  organizational structure, so policies, cost allocation, and security\n  practices map naturally to your business capabilities.\n\n---\n\n## **3. Naming Convention**\n\n### **3.1 Short, Domain-Centric Pattern**\n\nCloud resources all have different length and character\nrequirements. Instead of packing *every* detail (like team, cost\ncenter) into the resource name, store additional meta data in **tags**\n(AWS/Azure) or **labels** (GCP).\n\nThis approach **requires** `domain/project`, `environment` to be\ndefined with the resource name. Optionally `region`, `resource type`\nand `optional id` can be used to further group resources, just keep in\nconsideration the name’s maximum length.\n\n**Naming Pattern**:\n\n```\n\u003cDomainOrProject\u003e-\u003cEnvironment\u003e-\u003cResourceName\u003e\n\u003cDomainOrProject\u003e-\u003cEnvironment\u003e-\u003cRegion\u003e-\u003cResourceType\u003e-\u003cResourceName\u003e-\u003cUniqueID\u003e\n```\n\n1. **DomainOrProject**\n    - The primary domain or application name.\n    - Examples: `marketing`, `finance`.\n2. **Environment**\n    - Standard designations such as `dev`, `test`, `uat`, `prod`.\n3. **Region** *(Optional)*\n    - Short code for the cloud region, e.g., `use1` = `us-east-1`.\n    - Use consistent abbreviations across clouds.\n4. **ResourceType** *(Optional)*\n    - Short 2–4 letter code describing the resource: `db`, `vm`,\n      `stor`, `func`, etc.\n5. **UniqueID** *(Optional)*\n    - Short numeric or alphanumeric identifier if global uniqueness is\n      required. Examples: `001`, `abc1`.\n6. **ResourceName**\n    - The name for you're resource\n\n**Example**:\n\n```\nprojecta-prod-masterdb\nmarketing-dev-use1-db-masterdb-01\n```\n\n### **3.2 Cloud-Specific Adjustments**\n\n\u003e [!NOTE]\n\u003e - Keep all naming parts as short as possible, by using abbreviations\n\u003e   where possible, for example; `mktg` instead of`marketing` and `prod`\n\u003e   instead of `production`.\n\u003e - Remove white space within a name part, so instead of `master-db`\n\u003e write `masterdb`. This is because the `-` symbol is used in our\n\u003e consistent naming format.\n\nNot all resources follow a standard naming convention; they vary in\nlength, allowed characters, and formatting rules. Here are a few such\nedge cases:\n\n- **AWS**:\n    - For S3 buckets, must be lowercase letters, numbers, hyphens only\n      (no underscores).\n    - EC2, RDS, and other services typically allow hyphens,\n      alphanumeric, and sometimes underscores.\n- **Azure**:\n    - **Storage accounts**: 3–24 characters, all lowercase\n      letters/numbers. You may need to abbreviate.\n    - **Resource groups**: 1–90 characters, can use alphanumeric,\n      underscores, parentheses, hyphens, periods.\n- **GCP**:\n    - **Project IDs**: 6–30 characters, must start with a letter, only\n      lowercase letters, digits, and hyphens.\n    - **Compute Engine**: Typically lowercase letters, digits, and\n      hyphens, up to 63 chars.\n\n---\n\n## **4. Tagging / Labeling Strategy**\n\n**Tags** (AWS \u0026 Azure) and **Labels** (GCP) let you store additional\nmetadata that doesn’t need to appear in the resource name.\n\n### **4.1 Recommended Tag/Label Keys**\n\n**ESSENTIALS**\n\n| **Key** | **Purpose** | **Example Values** |\n|--------------------|-------------------------------------------|------------------------------|\n| **Domain/Project** | High-level business area or project name. | `marketing`, `projecta` |\n| **Owner** | Contact email or distribution list.  | `data-eng@company.com` |\n| **Environment** | Environment name.  | `dev`, `test`, `uat`, `prod` |\n\n**OPTIONAL**\n\n| **Key** | **Purpose** | **Example Values** |\n|------------------------|--------------------------------------------------------------|----------------------------------------|\n| **Name** | The resource’s friendly name, mirroring your naming pattern. | `marketing-dev-use1-db-01` |\n| **TeamOrBU** | Team or business unit responsible.  | `DataEng`, `AppDev`, `FinOps` |\n| **CostCenter** | Finance/billing reference.  | `CC1234`, `BU5678` |\n| **DataClassification** | Indicates sensitivity (e.g., `internal`, `public`, `PII`).  | `internal`, `public`, `pii` |\n| **Compliance** | Regulatory tags (e.g., `GDPR`, `HIPAA`, `ISO27001`).  | `GDPR`, `SOX` |\n| **CreatedBy** | Identifies provisioning mechanism or user.  | `terraform`, `ci-pipeline`, `john.doe` |\n| **Expiration** | Date or condition for decommissioning if ephemeral.  | `2025-12-31` |\n\n### **4.2 Policy Enforcement**\n\n\u003e [!IMPORTANT]\n\u003e You can not be assured that all of your resources will be tagged if\n\u003e implementing only enforcement. The enforcement strategies listed below\n\u003e do not support 100% of that cloud’s resources. See 5.2 for operational\n\u003e audits.\n\n- **AWS**: Requires a range of services for an effective strategy;\n  Organization SCPs, Organization Tag Policies and AWS Config rules\n- **Azure**: Use **Azure Policy** to deny, append, or modify tags at\n  resource creation.\n- **GCP**: Use **Organization Policies** or custom Cloud Functions to\n  check and correct labels.\n\n---\n\n## **5. Operationalizing the Strategy**\n\n### **5.1 Infrastructure as Code (IaC)**\n\n1. **Common Modules**:\n    - Create Terraform/Bicep/CloudFormation(CDK) modules that accept\n      inputs like `\u003cDomainOrProject\u003e`, `\u003cEnvironment\u003e`, `\u003cRegion\u003e`,\n      `\u003cResourceType\u003e` and generate a **standardized name** plus\n      **mandatory tags**.\n2. **Pipeline Enforcement**:\n    - Include naming/tagging checks in your CI/CD pipeline. A pipeline\n      step can verify that each resource block follows the pattern and\n      required tag keys. Use tools like checkov, CFN nag (or CDK nag)\n      to enforce this at build time.\n3. **Templates**:\n    - Provide templates or example code for typical resource types\n      (e.g., VM, container registry, database, storage) so teams can\n      replicate the pattern quickly.\n\n### **5.2 Governance \u0026 Compliance**\n\n- **Regular Audits**:\n    - Scan resources to ensure all are properly named and\n      tagged. Tools like **AWS Config**, **Azure Resource Graph**,\n      **GCP Asset Inventory** can assist.\n- **Automated Remediation**:\n    - Optionally configure serverless functions (AWS Lambda, Azure\n      Functions, GCP Cloud Functions) to fix or notify owners about\n      non-compliant resources.\n\n### **5.3 Education \u0026 Adoption**\n\n- **Style Guides**:\n    - Provide a single reference doc with standard abbreviations for\n      domains, resource types, and region codes.\n- **Workshops**:\n    - Run short training sessions explaining the importance of\n      domain-driven naming, how to use the modules, and how to pass\n      the correct variables in IaC.\n- **Quick Reference Examples**:\n    - Show examples for each resource type in each environment. Make\n      sure new hires and existing teams can find these quickly.\n\n---\n\n## **6. Example End-to-End Scenario**\n\n### **6.1 Use Case**\n\n- **Domain/Project**: `marketing`\n- **Environment**: `prod`\n- **Region**: `use1` (AWS US East 1)\n- **ResourceType**: `db` (database)\n- **ResourceName:** `masterdb`\n- **UniqueID**: `001`\n\n**Resource Name**:\n\n```\nmarketing-prod-use1-db-masterdb-001\n```\n\n### **6.2 Tagging / Labeling**\n\n**Required Tags** (AWS) or **Labels** (GCP) example:\n\n- `Name = \"Billing-prod-use1-db-001\"`\n- `DomainOrProject = \"Finance\"` (if “Billing” is a subdomain of\n  Finance)\n- `TeamOrBU = \"FinOps\"`\n- `Environment = \"prod\"`\n- `Owner = \"finops-team@company.com\"`\n- `CostCenter = \"CC9876\"`\n- `DataClassification = \"internal\"`\n- `Compliance = \"SOX\"`\n- `CreatedBy = \"terraform\"`\n- `Expiration = \"\"` (not applicable if permanent)\n\nBy following this approach:\n\n- The **resource name** is concise yet descriptive.\n- **Tags** hold details about domain, ownership, cost center, data\n  classification, etc.\n\n---\n\n## **7. Alignment with AWS and Azure Well-Architected**\n\nBoth AWS and Azure Well-Architected frameworks emphasize:\n\n1. **Consistent Naming**: Simplifies operational tasks, resource\n   discovery, and automation.\n2. **Detailed Tagging**: Supports cost optimization, security,\n   compliance, and operational excellence pillars.\n\nThis hybrid strategy:\n\n- Keeps the resource **name** short, focusing on environment, region,\n  resource type, and the broader domain/application.\n- Leverages **tags**/labels for ownership, cost, compliance, and data\n  classification—directly aligning with recommended practices for cost\n  allocation, security posture, and operational governance.\n\n---\n\n## **8. Conclusion**\n\n### **Key Advantages**\n\n- **Simplicity**: Short, domain-driven names are easy to read,\n  remember, and type.\n- **Clarity**: Teams instantly see which environment (e.g., `prod`)\n  and region (e.g., `use1`) a resource belongs to.\n- **Robust Metadata**: Detailed tagging satisfies governance, cost\n  tracking, and compliance requirements without cluttering the\n  resource name.\n- **Cross-Cloud Consistency**: Works equally well in **AWS**,\n  **Azure**, and **GCP** with minimal adjustments for each platform’s\n  naming limits.\n\nBy **combining** a concise resource naming pattern with\n**comprehensive tagging**, you strike a balance between **immediate\nclarity** and **rich metadata**—exactly what data and application\nteams need to streamline operations, control costs, and maintain\ncompliance in a multi-cloud environment.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdatachefhq%2Fcloud-naming-strategy","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdatachefhq%2Fcloud-naming-strategy","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdatachefhq%2Fcloud-naming-strategy/lists"}