Naming Conventions
We recommend designing and deciding upon a set of naming conventions for all resources you deploy into OCI.
Having a set of naming conventions early in the design process will help ensure consistency across many deployments. Consistency is key. Naming conventions enable OCI administrators to quickly find and understand the nature and scope of any resource on which they intend to work. For example, having a naming convention for compute resources that include environment type (prod/non-prod) can help to ensure that administrative steps are appropriate to the resource and minimizes mistakes.
If an incident occurs, naming conventions can help establish the “blast radius” associated with the incident. For instance, a naming convention across various resource types with a geographical label can highlight regionally occuring issues.
Use the following guidelines and recommendations to help you establish the optimal naming conventions for your organization.
Compartments - Naming Convention
Below is a proposed generic notation to be used for naming Compartments:
[Compartment code]-[entity/sub-entity]-[environment]-[function/department]-[project]-[custom]
The table below provides high-level guidelines on compartment naming. This will align with the compartment levels and hierarchy.
| Parameter | Description | Examples |
|---|---|---|
| Compartment | Compartment shortened to “cmp” | cmp |
| Entity/Sub-Entity] | Business entity or Group division/responsibility | lg, opco, central, jv, etc |
| Environment | Environment type/purpose of use | p,n,d,t etc |
| Function/Department | Functional or Department responsibility | foundation, security, networking, dept1, etc |
| Project | Project or Solution name | |
| Custom | Optional but recommended string can be a series of numbers and letters and hyphens. Can help distinguish similar projects | tools-01, project-01, etc |
We also recommend that you follow the principles below:
- The name segments above are separated by “-“
- Within a name segment, avoid using
and “.” - Aim to use intuitive, standardized abbreviations (e.g. “central“ compared to “central.cloud.team”)
- When referring to a compartment’s full path, use “:” as a separator, e.g. cmp-lg:cmp-legacy:cmp-legacy-security
Here are some examples of names that follow this approach;
- cmp-lg
- cmp-opco
- cmp-central
- cmp-networking
- cmp-opco01-app-prod
Compute Resources - Naming Convention
Below is a proposed generic notation to be used for naming Compute instances:
[application]-[custom]-[arch tier][custom]-[environment]-[instance type]
The table below provides high-level guidelines on Compute naming.
| Parameter | Description | Characters | Examples |
|---|---|---|---|
| OCI Region | OCI Region where the system will be installed | 3 | AMS, FRA |
| Environment | Host environment | 1 | P-Production, etc |
| Platform/Role | Platform/application and Role of service running on host | 6 | Based on LG coding |
| Region | Region system is provided for | 2 | Based on LG coding |
| NSA Level | Network Security Architecture Level | 1 | 2-NSA Level |
| Num ID | Position/placement of system | 2 | 01 – unique system identifier |
| VM | Suffix to declare instance nature | 2 | vm |
VCN Resources - Naming Convention
Below is a proposed generic notation to be used for naming VCN elements:
[VCN code]-[entity/sub-entity]-[function]-[environment]-[custom]
The table below provides high-level guidelines on VCN naming.
| Parameter | Description | Examples |
|---|---|---|
| Label | VCN code name | vcn |
| Entity/Sub-Entity] | Business entity or Group division/responsibility | lg, opco, central, jv, etc |
| Function/Tier | Function or tier | foundation, security, networking, web, app, db, pilot |
| Environment | Environment type/purpose of use | p,n,d,t etc |
| Custom | Optional but recommended string can be a series of numbers and letters and hyphens. Can help distinguish similar projects | tools-01, project-01, etc |
We also recommend that you follow the principles below:
- The name segments above are separated by “-“
- Within a name segment, avoid using
and “.” - Aim to use intuitive, standardized abbreviations (e.g. “central“ compared to “central.cloud.team”)
Some examples of naming are given below:
- vcn-central-networking-01
- vcn-lg-pilot-01
- sn-central-networking-priv-01
- sn-lg-pilot-01-prv-01
Subnet Resources - Naming Convention
Below is a proposed generic notation to be used for naming Subnet elements:
[Subnet code]-[entity/sub-entity]-[function]-[environment]-[access]-[custom]
The table below provides high-level guidelines on Subnet naming.
| Parameter | Description | Examples |
|---|---|---|
| Label | Subnet code name | sn |
| Entity/Sub-Entity] | Business entity or Group division/responsibility | lg, opco, central, jv, etc |
| Function/Tier | Function or tier | foundation, security, networking, web, app, db, pilot |
| Environment | Environment type/purpose of use | p,n,d,t etc |
| access | Access type (private/public) | priv, publ |
| Custom | Optional but recommended string can be a series of numbers and letters and hyphens. Can help distinguish similar projects | tools-01, project-01, etc |
We also recommend that you follow the principles below:
- The name segments above are separated by “-“
- Within a name segment, avoid using
and “.” - Aim to use intuitive, standardized abbreviations (e.g. “central“ compared to “central.cloud.team”)
Some examples of naming are given below:
- sn-central-networking-priv-01
- sn-lg-pilot-01-prv-01
Storage Resources - Naming Convention
Below is a proposed generic notation to be used for naming Block Volume Storage:
[application]-[custom]-[arch tier][custom]-[environment]-[block volume][custom]
The table below provides high-level guidelines on block volume naming and which align closely to the respective Compute instance
| Parameter | Description | Examples |
|---|---|---|
| Application | Application codename | peal, off, etc |
| Custom App | Custom code to distinguish application, e.g. app number, country, opco, etc | at, sk, etc. |
| Arch tier | Architecture tier | web, app, service, etc. |
| Custom Ins | Custom code to distinguish instance, e.g. node number in a cluster | 01, 02, etc. |
| Environment | Environment type/purpose of use | p, n, d, t, etc. |
| Custom Vol | Custom code to distinguish block volume, e.g. number. Use “0” for boot volume | 0, 1, 2, etc |
We also recommend that you follow the principles below:
- The name segments above are separated by “-“
- Within a name segment, avoid using
and “.” - Aim to use intuitive, standardized abbreviations (e.g. “central“ compared to “central.cloud.team”)
Some examples of naming are given below:
- off-at-app01-p-bv0
- off-at-app01-p-bv1
- off-sk-osb02-p-bv0