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.

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.

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 Name:

Syntax: {organization}-(type of project)-{environment}-{service description}
Value: {organization}-{h/s+p/sa}-{prod/stag/all}-{service description}

Example:

Project ID:

Syntax: {h/s+p/sa}-{prod/stag/all}-{service description}-{yyyy-mm-dd}

With hp is host project, sp is service project, sa is standard-alone project

Example: sp-prod-alpha-2024-01-11

VPC network:

Syntax: {vpc description}-vpc

Example: shared-vpc

Subnet:

Syntax: {type of project}-{environment}-{subnet description}-{zone}-{type of subnet}-subnet
Value: {h/s+p}-{prod/stag}-{subnet description}-{zone}-{pod/service} -subnet

Example: sp-prod-alpha-as-se1-pod-subnet

Firewall rule:

Syntax: {organization}-{source environment}-{source project description}-{source device}-{organization}-{destination environment}-{destination project description}-{destination device}-{protocol}-{port}-{action}
Value: {organization}-{prod/stag}-{project description}-{source-device}-{organization}-{prod/stag}-{project description}-{des device}-{protocol}-{port}-{action}

Example: swap-stag-alpha-nginx-beta-cicd-tcp-80-accept

DNS:

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

Example:

• podinfo.gke1.duyne.dev
• podinfo.gke1.duyne.uat
• podinfo.gke1.duyne.prod

Service Account:

Syntax: {team name}-{resources accessed}-{what your app does}

Example: [email protected]

GAR (Google Artifact Registry)

Syntax: LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY-GITHUB-IMAGE:VERSION

Example: us-east1-docker.pkg.dev/my-project/my-repo:1.0.0

Labelling:

You should also cover the use of labels (or tags)

country: vn
ou: vn # The organization unit
environment: dev # uat/prod
service: gke # Describe the google services
app_name: podinfo # like a pod service running on gke
app_type: gke # such as mongodb,kafka,rabbitmq, etc
team: product 

Conclusion

• The key to success with naming conventions is establishing them early on and ruthlessly following 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.