Skip to content

Resource Naming

Closed Feb 8, 2022 100% complete

Naming conventions
In response to potential collisions and to better derive a readable/searchable known format a new naming convention is being adopted based on current best practices. These are based on existing work from the cloud adoption framework team and from early Azure guidance. Azure services fall into one of several different naming rules catego…

Naming conventions
In response to potential collisions and to better derive a readable/searchable known format a new naming convention is being adopted based on current best practices. These are based on existing work from the cloud adoption framework team and from early Azure guidance. Azure services fall into one of several different naming rules categories based on scope of service. For example, storage accounts are publicly addressable global services that require a globally unique name supported by standard HTTP/URL requirements.
For the purposes of Mission Landing Zone (MLZ) names will include additional identifiers that reflect region, product, or service offering. MLZ adopts a pattern that is repeatable to support idempotency as much as possible but also allows for repeatability by randomizing as much as possible when needed. For this purpose, the following key criteria drive the process utilized in the MLZ naming convention used.

  1. Repeatable – When uniqueness is required it should also be done in a repeatable pattern. The deployment should be able to derive the same random set of characters when needed for idempotency and reuse.
  2. Readability – To allow for a better understanding of architecture in portal views and reports the pattern should be recognizable. It should reference purpose, location and instance.
  3. Opinionated – While flexibility will remain a key concept of MLZ there is a need to be more opiniated to prevent collisions in subsequent deployments.
  4. Idempotency – Currently true idempotency is out of scope for MLZ but naming conventions should lend themselves to be repeatable incrementally.
    Architectural choices play a key role in in naming. These choices will manifest themselves in naming.
  • An overarching goal is to remain in Bicep with no scripting.
  • Multi subscription capable – Each hub and or spoke can be deployed to separate subscriptions.
  • Customizable – Some deployments require a specific naming convention
  • Multi region deployments – MLZ is deployed to a region but multiple MLZs should be supported in same region and additional regions.

This milestone is closed.

No open issues remain. View closed issues or see open milestones in this repository.