See also Sogeti Cloud Reference Architecture standards naming conventions.
For Cloud provider specific naming see:
Guidelines
1. Any name must be unique.
Any resource name must be unique within the customer landscape and subscriptions for objects of the same type. For example, although technically possible, it is not allowed to have two VMs with the same name in two different VNETs.
2. Use of characters.
Names must start with a character or number and can contain only alphanumeric characters and hyphens. Only by exception it is allowed to deviate from this rule with a clear description about the reason and the used naming convention for the exception.
3. Writing the name.
All names are written in lower case. If hyphens can’t be used as separator, by exception capitalization can be used instead.
4. No use of spaces.
Spaces are not allowed except in the name of the Azure subscription. Hyphens can be used to separate different parts of the name for readability.
5. Name lifespan.
A name can’t be changed! If the object gets a new function or is being used for a different organizational unit it either keeps the name or it must be newly created with the correct name.
6. Names must support the automation tooling.
To create environments, tooling is being used for automation. All the names created must be supported by the tooling.
7. Tagging.
Tagging is used to differentiate cloud resources on specific characteristics like environment (DTAP), Cost Centre, CIA Rating, etc.
Naming Format
The generic format is:
< customer > - < resource type > - < application name> - < environment >[-< region >]
< customer > The customer part is optional and will only be used when multiple customers are maintained by the Cloud CoE. For clarity, it is recommenced to use the department name for the < customer > value. This should not contain more than 5 characters.
< application name >. The application name or product this resource belongs to. This should not contain more than 5 characters.
< environment >. The environment name (DTAP). This should not contain more than 1 character.
< resource type> The resource type on Azure or AWS.
< region > optional. In case multiple resources for the same customer, same application name and with the same resource type exists across regions, a ‘region code’ is added to make the name unique across regions. This region code should not exceed 3 characters.
Note: with a single region deployment or when the resource type is a global service, the region code can be omitted
Lifecycle Management
When this naming convention document is updated, existing resources that are already deployed are not updated. Typically the deployment scripts need to be updated to adhere to the updated naming convention(s).
Region Codes
Extra information is added to the name based on the type of resource deployed. See the tables below for an overview of the abbreviations used for the generic naming format.
Environment
Depending on the release strategy environment codes are added for different stages of the cloud resources.
| Region | Abbreviation |
|---|---|
| Lab | l |
| Development | d |
| Test | t |
| Acceptance | a |
| Production | p |
Note: For Cloud resources on Azure the Environment code is extracted from the Resource Group name, which should have this Environment information.
Resource type
To make it clear what kind of resource is behind the underlying name a default set to type definition is used in the cloud resource name.
Multi Region Deployments
By default, all Azure resources are deployed in a single region. If the system requires a multiple region deployment, all Azure resources deployed in second region get a ‘–area’ suffix in their name to indicate the data center. For example:
In case a multi region setup in West Europe and North Europe, the resources in North Europe uses an extra ‘-NE’ in their names.
Azure resources deployed in the West Europe region don’t get this indicator in their naming.