GCP Resource Naming Convention

Small world. Big idea!

Consistent naming strategy is important and should be an essential part my working. It is often overlooked at the beginning of a small project. But it quickly becomes critical as the number of managed resources grows.

How should you name your GCP resources?

Where is it being used? Environment - Dev, UAT, Production, etc.
What type of resource is it? Workload type - VM, CloudSQL, VPC, GKE, etc.
Who owns it? Business unit(BU) - Finance, IT, etc.

Benefits

Consistent and descriptive naming of resources has many benefits:

Indicates the role and ownership of a resource.
Prevents name clashes when resource names must be unique.
Makes resources easier to locate.
Allows to sort and filter resources quickly.

Main Properties

Good naming convention must provide clarity and work in both directions:

Clearly define how newly created resources should be named.
Identify and indicate the purpose and ownership of existing resources. We’ll focus on how a naming convention for cloud-level resources should look like. GCP is used in our examples, but the concepts and strategies are generic and can be easily adapted to other cloud providers.

Concept Organizations, folders, and projects

To go into detail about each resource, I need to briefly introduce the concept of organization in GCP.

Let’s begin by defining some terms that will help us understand the discussion about host projects. Some of these terms are related to Google Cloud’s Organizational Hierarchy, which consists of four tiers: organization, folders, projects, and resources, as shown in the diagram below.

flowchart TB
    subgraph OrgHierarchy[Google Cloud Organizational Hierarchy]
        direction TB
        
        Org[Organization]
        
        subgraph Folders[Folders]
            Folder1[Folder]
            Folder2[Folder]
            Folder3[Folder]
            Folder4[Folder]
            Folder5[Folder]
        end
        
        subgraph Projects[Projects]
            Proj1[Project]
            Proj2[Project]
            Proj3[Project]
            Proj4[Project]
            Proj5[Project]
            Proj6[Project]
        end
        
        subgraph Resources[Resources]
            Res1[Resource]
            Res2[Resource]
            Res3[Resource]
            Res4[Resource]
            Res5[Resource]
            Res6[Resource]
            Res7[Resource]
            Res8[Resource]
        end
        
        Org --> Folder1
        Org --> Folder2
        Folder1 --> Folder3
        Folder1 --> Folder4
        Folder2 --> Folder5
        
        Folder3 --> Proj1
        Folder3 --> Proj2
        Folder4 --> Proj3
        Folder2 --> Proj4
        Folder2 --> Proj5
        Folder5 --> Proj6
        
        Proj1 --> Res1
        Proj1 --> Res2
        Proj1 --> Res3
        Proj2 --> Res4
        Proj2 --> Res5
        Proj2 --> Res6
        Proj3 --> Res7
        Proj3 --> Res8
    end
    
    style OrgHierarchy fill:#fff,stroke:#000,stroke-width:2px
    style Org fill:#fff,stroke:#000,stroke-width:1px
    style Folders fill:#fff,stroke:#000,stroke-width:1px
    style Projects fill:#fff,stroke:#000,stroke-width:1px
    style Resources fill:#fff,stroke:#000,stroke-width:1px
    style Folder1 fill:#fff,stroke:#000,stroke-width:1px
    style Folder2 fill:#fff,stroke:#000,stroke-width:1px
    style Folder3 fill:#fff,stroke:#000,stroke-width:1px
    style Folder4 fill:#fff,stroke:#000,stroke-width:1px
    style Folder5 fill:#fff,stroke:#000,stroke-width:1px
    style Proj1 fill:#fff,stroke:#000,stroke-width:1px
    style Proj2 fill:#fff,stroke:#000,stroke-width:1px
    style Proj3 fill:#fff,stroke:#000,stroke-width:1px
    style Proj4 fill:#fff,stroke:#000,stroke-width:1px
    style Proj5 fill:#fff,stroke:#000,stroke-width:1px
    style Proj6 fill:#fff,stroke:#000,stroke-width:1px
    style Res1 fill:#fff,stroke:#000,stroke-width:1px
    style Res2 fill:#fff,stroke:#000,stroke-width:1px
    style Res3 fill:#fff,stroke:#000,stroke-width:1px
    style Res4 fill:#fff,stroke:#000,stroke-width:1px
    style Res5 fill:#fff,stroke:#000,stroke-width:1px
    style Res6 fill:#fff,stroke:#000,stroke-width:1px
    style Res7 fill:#fff,stroke:#000,stroke-width:1px
    style Res8 fill:#fff,stroke:#000,stroke-width:1px

Example Google Organizational Hierarchy

In addition to the organization hierarchy, there are three important terms for understanding host projects, as further described in the Google documentation on VPC terminology and concepts.

Host Project: A host project provides shared network services across a project and can share network services across specific projects. All VPCs within that project are shared as part of the host project.
Service Project: Service projects reside outside the host project but subscribe to the host project’s network services.
Stand-Alone Project: Stand-alone projects do not use resources from a host project and have all network resources and operations established within their own project.

Below is a high-level diagram that shows the relationship between host projects, service projects, and stand-alone projects.

flowchart LR
    subgraph HostServiceStandalone[Host, Service, and Stand-Alone Projects]
        direction TB
        
        subgraph HostProject[Host Project]
            Alpha[Project Alpha<br/>Host Project]
            VPC1[VPC Network<br/>Shared Resources]
            Alpha --> VPC1
        end
        
        subgraph ServiceProject[Service Project]
            Beta[Project Beta<br/>Service Project]
            App1[Application 1]
            App2[Application 2]
            Beta --> App1
            Beta --> App2
        end
        
        subgraph StandAloneProject[Stand-Alone Project]
            Omega[Project Omega<br/>Stand-Alone Project]
            VPC2[VPC Network<br/>Independent]
            App3[Application 3]
            Omega --> VPC2
            Omega --> App3
        end
        
        Alpha -.->|Shares Network Services| Beta
        Alpha -.->|No Connection| Omega
    end
    
    style HostServiceStandalone fill:#fff,stroke:#000,stroke-width:2px
    style HostProject fill:#fff,stroke:#000,stroke-width:1px
    style ServiceProject fill:#fff,stroke:#000,stroke-width:1px
    style StandAloneProject fill:#fff,stroke:#000,stroke-width:1px
    style Alpha fill:#fff,stroke:#000,stroke-width:1px
    style Beta fill:#fff,stroke:#000,stroke-width:1px
    style Omega fill:#fff,stroke:#000,stroke-width:1px
    style VPC1 fill:#fff,stroke:#000,stroke-width:1px
    style VPC2 fill:#fff,stroke:#000,stroke-width:1px
    style App1 fill:#fff,stroke:#000,stroke-width:1px
    style App2 fill:#fff,stroke:#000,stroke-width:1px
    style App3 fill:#fff,stroke:#000,stroke-width:1px

Same host, service and stand-alone project

In our example diagram, Project Alpha is a host project, sharing all network resources within that project. Project Beta is a service project that subscribes to the host project’s network services. Project Omega does not subscribe to Alpha’s network services, and is thus a stand-alone project.

Now let’s get into greater detail about the naming convention in GCP resources.

Naming Convention

Project Naming

Project Display Name:

The display name is what appears in the GCP Console and can be changed at any time. It should be descriptive and human-readable.

Syntax: {Organization} - {Environment} - {Service Description}

Best Practices:

Use spaces and uppercase letters for readability
Include organization, environment, and service purpose
Can be changed later if needed

Examples:

ACME - Production - Web Application
ACME - Development - Data Analytics
ACME - Staging - API Gateway

Project ID:

The Project ID is globally unique, immutable, and used in all API calls and resource references.

Syntax: {org-prefix}-{env}-{service}-{region?}

Best Practices:

Use lowercase with hyphens as separators
Keep it concise but descriptive
Include organization prefix, environment, and service name
Avoid dates or timestamps (project IDs are permanent)
Use abbreviations for common terms (prod, dev, stag)

Examples:

acme-prod-webapp
acme-dev-data-analytics
acme-stag-api-gateway
acme-prod-shared-vpc (for host projects)

VPC Network Naming

VPC networks should clearly indicate their environment and purpose.

Syntax: {env}-{purpose}-vpc

Best Practices:

Include environment (prod, dev, stag)
Include purpose (shared, app, data)
Keep names concise but descriptive
Use lowercase with hyphens

Examples:

prod-shared-vpc - Production shared VPC for host project
dev-app-vpc - Development application VPC
stag-data-vpc - Staging data processing VPC

Subnet Naming

Subnets must follow DNS label naming rules and should include region and purpose.

Syntax: {env}-{region}-{purpose}-{type}

Best Practices:

Include environment and region for clarity
Specify purpose (pod, service, db, etc.)
Use standard GCP region codes (us-central1, asia-southeast1, etc.)
Keep under 63 characters

Examples:

prod-us-central1-pod-subnet - Production pod subnet in US Central
dev-asia-southeast1-service-subnet - Development service subnet in Southeast Asia
stag-europe-west1-db-subnet - Staging database subnet in Europe

Firewall Rule Naming

Firewall rules should be concise and clearly indicate direction, purpose, and action.

Syntax: {direction}-{env}-{source}-{destination}-{protocol}-{port}-{action}

Best Practices:

Start with direction (allow, deny)
Include environment for filtering
Specify source and destination clearly
Include protocol and port
End with action (accept, reject)
Keep names concise (avoid repeating organization name)
Use descriptive service names

Examples:

allow-prod-web-db-tcp-5432 - Allow production web to database on TCP 5432
allow-dev-api-cache-tcp-6379 - Allow development API to cache on TCP 6379
deny-all-external-ssh-tcp-22 - Deny all external SSH access
allow-stag-lb-backend-tcp-8080 - Allow staging load balancer to backend

DNS Naming

DNS names should follow standard domain naming conventions and include environment context.

Syntax: {application}.{resource}.{domain}.{env?}

Best Practices:

Use subdomains to separate environments
Include application name and resource type
Use consistent domain structure
Consider using environment-specific domains or subdomains

Examples:

podinfo.gke1.duyne.dev - Development environment
podinfo.gke1.duyne.uat - UAT environment
podinfo.gke1.duyne.prod - Production environment
api.backend.acme.com - Production API (no env suffix)
api-dev.backend.acme.com - Development API

Service Account Naming

Service accounts should clearly indicate their service and purpose, and must include the full domain suffix.

Syntax: {service}-{purpose}@{project-id}.iam.gserviceaccount.com

Best Practices:

Use service name and purpose
Keep account name concise
Always include the full domain suffix in documentation
Use descriptive names that indicate what the service account does

Examples:

[email protected] - Backend service account for webapp
[email protected] - API Gateway service account
[email protected] - Data pipeline service account

Google Artifact Registry (GAR) Naming

Artifact Registry follows a specific format for container images and other artifacts.

Syntax: {location}-docker.pkg.dev/{project-id}/{repository}/{image}:{tag}

Best Practices:

Use GCP region codes for location
Repository names should indicate purpose (e.g., app-images, base-images)
Use semantic versioning for tags
Keep repository names descriptive but concise

Examples:

us-east1-docker.pkg.dev/acme-prod-webapp/app-images:v1.0.0
asia-southeast1-docker.pkg.dev/acme-dev-api/base-images:latest
europe-west1-docker.pkg.dev/acme-stag-frontend/web-images:2.1.0

Compute Engine Instance Naming

VM instances should clearly indicate their role and environment.

Syntax: {env}-{role}-{instance-number?}

Best Practices:

Include environment prefix
Specify instance role (web, db, cache, etc.)
Add instance number for multiple instances
Use lowercase with hyphens

Examples:

prod-web-01 - Production web server instance 1
dev-db-primary - Development primary database
stag-cache-01 - Staging cache instance

Cloud Storage Bucket Naming

Storage buckets must be globally unique and follow DNS naming rules.

Syntax: {org-prefix}-{env}-{purpose}-{region?}

Best Practices:

Use organization prefix to ensure uniqueness
Include environment and purpose
Optional region suffix for multi-region strategies

Examples:

acme-prod-app-data - Production application data
acme-dev-backups-us - Development backups in US
acme-stag-logs - Staging logs

Cloud SQL Instance Naming

Database instances should indicate their type, environment, and purpose.

Syntax: {env}-{db-type}-{purpose}

Best Practices:

Include environment and database type (mysql, postgres, sqlserver)
Specify purpose (primary, replica, analytics)

Examples:

prod-postgres-primary - Production PostgreSQL primary
dev-mysql-replica - Development MySQL replica
stag-postgres-analytics - Staging PostgreSQL for analytics

GKE Cluster Naming

Kubernetes clusters should indicate environment, region, and purpose.

Syntax: {env}-{region}-{purpose}-cluster

Best Practices:

Include environment and region
Specify cluster purpose (app, data, shared)
Use standard GCP region codes

Examples:

prod-us-central1-app-cluster - Production application cluster
dev-asia-southeast1-shared-cluster - Development shared cluster
stag-europe-west1-data-cluster - Staging data processing cluster

Cloud Functions / Cloud Run Naming

Serverless functions and services should indicate their service and environment.

Syntax: {env}-{service-name}-{function-name?}

Best Practices:

Include environment prefix
Use service name and optional function name
Keep names concise

Examples:

prod-api-processor - Production API processor function
dev-webhook-handler - Development webhook handler
stag-data-transformer - Staging data transformer service

Labeling

Labels (tags) are key-value pairs that help organize and filter resources. They are essential for cost tracking, automation, and resource management.

Syntax: {key}: {value}

Best Practices:

Use consistent label keys across all resources
Label values should follow a standard format
Include environment, team, cost-center, and service information
Use labels for automation and policy enforcement

Standard Label Keys:

environment: dev, uat, prod, stag
team: product, platform, data, security
service: gke, compute, storage, sql
app_name: Name of the application
app_type: Type of application (web, api, worker, etc.)
cost_center: Budget or cost center code
owner: Team or individual responsible
country: Country code (e.g., vn, us)
region: GCP region code
managed_by: How it’s managed (terraform, manual, etc.)

Example Labels:

environment: prod
team: product
service: gke
app_name: podinfo
app_type: web
cost_center: eng-001
owner: platform-team
country: vn
region: asia-southeast1
managed_by: terraform

General Best Practices

Character Limits Summary

Resource Type	Min Length	Max Length	Allowed Characters	Notes
Project ID	6	30	lowercase, numbers, hyphens	Globally unique, immutable
VPC Name	1	63	lowercase, numbers, hyphens	Must be valid DNS label
Subnet Name	1	63	lowercase, numbers, hyphens	Must be valid DNS label
Firewall Rule	1	63	lowercase, numbers, hyphens, underscores	Must be valid DNS label
Service Account	6	30	lowercase, numbers, hyphens	Before @ symbol
Storage Bucket	3	63	lowercase, numbers, hyphens	Globally unique, immutable
Compute Instance	1	63	lowercase, numbers, hyphens	Must be valid DNS label
Label Key	1	63	lowercase, numbers, hyphens, underscores	Case-sensitive
Label Value	0	63	lowercase, numbers, hyphens, underscores	Case-sensitive

Conclusion

The key to success with naming conventions is establishing them early on and consistently following them across your entire infrastructure. Automation helps a lot.
You should establish a consistent naming convention as one of the first things when you start using cloud or on a new project. It’s one of those things that are really easy to do in the beginning, but much more difficult to fix later on.
Remember that some resource names (like Project IDs and Storage Bucket names) are immutable and globally unique. Choose these names carefully.
Use labels in addition to names for flexible resource organization and cost tracking.
Document your conventions and enforce them through automation and policy.