Naming conventions

[cveld]

I am exploring the templates you provide. What is the naming convention you apply?

I found the following guidance as part of the cloud adoption framework documentation: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming

Which suggests the following convention: Resource Type - Workload - Environment - Location - Instance

Whereas in the templates for example I find the following in the file hubspoke-connectivity.json :

"azFwName": "[concat(parameters('topLevelManagementGroupPrefix'), '-fw-', parameters('location'))]",

Which suggests: Management group prefix - Resource Type - Location

Related: https://github.com/Azure/Enterprise-Scale/issues/545

[jtracey93]

Will add naming scheme used in ESLZ to our FAQ.

[CRYP70N1X]

Hello, We need to provide our customers the ability to name their own resources during the deployment of the CAF Reference implementation that we provide on GitHub. We ask our customers to make a decision on resource name during the CAF Design phase but when they deploy the ref implementation we don't truly follow up on their decisions. Also we should respect our own naming convention recommendations when creating resource via ARM template. https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations

The request from my side is to add an option such as text box in which the customer can add their own name which we will take and build resource such as RG's or LAW's or AKV with the name they chose. For example we could have a second page on the ARM deployment that says something like "define the names for the resources deployed" and there list all the resources we will deploy, store those in different variables and reference those variables when building each resource individually. For the Azure Policy Side we can keep the current automation to avoid putting the customer through having to chose the names of 60+ policies (or perhaps give them a yes/no option if they really want to micro manage naming convention of resources). Here are a couple of examples of bad naming convention for deployed resources

.

[brianabrams]

Is there an estimated timeframe for this issue resolution?

[jtracey93]

Hi @brianabrams,

Are you referring to us providing the ability for naming your own resources as part of the accelerator (portal) experience or when we will update or docs and share the naming schemes used today for resources?

For adding the ability to name your own resources, then we are still planning this but we are looking probably around July/August time on current planning/spring cycles.

Let us know if this is a blocker to you and we can chat offline 👍

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 5 days.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 5 days.

[mattvanvuuren]

hi @jtracey93,

Can you please confirm if you will be implementing the CAF best practices naming conventions as stated in this article? https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming

We would like to see some sort of resource naming convention wizard in the Accelerator in which we can define the components of the resource name.

[jtracey93]

Hi @mattvanvuuren,

We are currently reviewing the delta between what we deploy today across all our accelerators for ALZ and also the AVD one from what we name things today and the CAF naming standards that you linked above and this one https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations

Once we have completed this delta analysis, we will be deciding on what the naming standards will be for ALZ and also the AVD accelerator as some of them do not make sense, like Private DNS Zones (prefixing them with pdnsz- is not something that we in ALZ would recommend and would break private link scenarios for example).

When we have this decided between us internally, we will share in an issue, possibly here, for the community to review and input before then starting the efforts to implement in the tooling options we provide.

However, our current thinking is that in the ALZ Accelerator (portal) experience we will not provide many options to customize the name for each resource as it is designed to be the "easy" button and fastest way to get to the target architecture.

If customers want to fully customize their naming for each resource, we will advise them to use ALZ-Bicep or ALZ Terraform where this customization can be done at a more granular level.

Hope this makes sense and welcome any feedback 👍

Thanks

Jack

[mdlister]

Hi @jtracey93, we've been exploring the code, and it's been easy to set up so far in our sandbox before we deploy to production however we're having trouble renaming the resources from the default values you set to match the naming conventions we have defined inhouse. We've been using the extend options defined and we can customise the RGName for an example resource we are testing for landing-zones but when we try the same on management it doesn't work. You mentioned in the thread that using custom names would be something coming July \ Aug is that still the case? Screenshots of trying to extend the Deploy-Log-Analytics code to both Landing Zones and Management, one is successful, and the other isn't. We'd want to change the name on other resources, but we thought we'd start testing on just the RG.

[jtracey93]

Hey @mdlister,

It may not be July/August, but certainly still high on our list to do.

However, I see you are using the ALZ Terraform module which I know does allow some renaming already today so looping in @matt-FFFFFF & @krowlandson to see if they can assist further here

[jtracey93]

Trigger ADO Sync 1

[jtracey93]

Trigger ADO Sync 2

[mundayn]

Hi @jtracey93

Is there any conclusion / update on the naming convention for the "Azure landing zone accelerator".

I know the naming convention is really a client by client decision, but most of our clients just use the CAF recommendation, if this accelerator followed CAF it'll make this deployment so much easier, rather than editing the code / recreating the pieces we want to rename manually.

And when I say follow CAF, I mean the "pip-sharepoint-prod-westus-001" recommendation from https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming.

So in the deployment from the blueprint, here is the changes I'd recommend if it was to follow the CAF(ish):

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

Resource | ESLZ Name (Current) | CAF Recommended Name -- | -- | -- RG for Management | mg-contoso-mgmt | rg-hub-mgmt-wu2-001 Automation Awu2ount | mg-contoso-aauto | aa-hub-mgmt-wu2-001 Log Analytics | mg-contoso-law | log-hub-mgmt-wu2-001 RG for Private DNS | mg-contoso-privatedns | rg-privatedns-con-wu2-001 RG for Hub VNET | mg-contoso-vnethub-wu2 | rg-hub-con-wu2-001 VNET (HUB) | mg-contoso-hub-wu2 | vnet-hub-con-wu2-001

[mundayn]

Hey @jtracey93

Following up on this if there is any comment?

Thanks!

[jtracey93]

Ill add it to our team discussion for next week for re-triage

[YY-VV]

Please share any news about the "naming Conventions"

[jtracey93]

@YY-VV, what news would you be looking for? Are you currently blocked by this?

Any info, helps us prioritise and triage further, currently this is on our backlog to do for the portal experience but we do not have an ETA

[mundayn]

@YY-VV, what news would you be looking for? Are you currently blocked by this?

Any info, helps us prioritise and triage further, currently this is on our backlog to do for the portal experience but we do not have an ETA

Hi Jack!

Good to hear it is on the backlog!

Can you share any more details around your discussion?

I guess all I want to know is that at some point the new portal experience will deploy following a more "CAF Friendly" naming convention? Or..?

[jtracey93]

Hey @mundayn,

Yup the intent will be to make the default naming pattern for resources deployed by the ALZ portal experience to align, where it can, to the CAF recommended abbreviations

[darrenhull]

Is there an ETA on this long running issue or a workaround?

It is a very difficult conversation to have with customers after guiding them through the CAF, agreeing to naming conventions and designing resource naming around: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming to then say we cannot currently do that.

[cveld]

@darrenhull We moved to the terraform module and there we are perfectly capable of customizing the names of all resources. https://github.com/Azure/terraform-azurerm-caf-enterprise-scale

[jtracey93]

Yup @darrenhull, we recommend the Bicep or Terraform implementation options as these allow naming flexibility as @cveld has shared 👍

• https://aka.ms/alz/tf
• https://aka.ms/alz/bicep

[tdysko-cf]

@cveld We could use some documentation and examples of how to easily get to CAF recommended naming convention:

RG for Management - rg-hub-mgmt-wu2-001 Automation Awu2ount - aa-hub-mgmt-wu2-001 Log Analytics - log-hub-mgmt-wu2-001 RG for Private DNS - rg-privatedns-con-wu2-001 RG for Hub VNET - rg-hub-con-wu2-001 VNET (HUB) - vnet-hub-con-wu2-001

Right now it's about going to the source code and checking how it's done internally and how/if I can override each element.

[alenat10]

Yup @darrenhull, we recommend the Bicep or Terraform implementation options as these allow naming flexibility as @cveld has shared 👍

• https://aka.ms/alz/tf
• https://aka.ms/alz/bicep

Hi Jack, do I understand correctly it is recommended to pre-create resource groups with CAF-compliant names so the module won't create a non-compliant name and after that set CAF-compliant suffix for resources? I am trying to deploy management resources (as per the module example) and cannot get proper names even with suffixes set in settings... Any advice/quick snip from the code showing how to get rg and resources named properly? Thank you!

[jtracey93]

Hey for bicep you do indeed create the resource group first as shown in this example here https://github.com/Azure/ALZ-Bicep/tree/main/infra-as-code/bicep/modules/logging#powershell. In terraform you must use the advanced blocks e.g. https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/blob/main/tests/modules/settings/settings.management.tf#L50-L53

[alenat10]

Hey for bicep you do indeed create the resource group first as shown in this example here https://github.com/Azure/ALZ-Bicep/tree/main/infra-as-code/bicep/modules/logging#powershell. In terraform you must use the advanced blocks e.g. https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/blob/main/tests/modules/settings/settings.management.tf#L50-L53

Jack, quick question regarding Advanced block for Terraform - is it documented anywhere? I am trying to give a proper name for -dns resource group containing private DNS links, but cannot find information how parameter name should be set. It looks like for management we can use Advanced block for "management" secrion: advanced: asc_export_resource_group_name: custom_settings_by_resource_type: azurerm_resource_group: management: name: so, I am trying to find a syntax and parameter names for Advanced block for other sections. Thank you!

[SvenAelterman]

Hey for bicep you do indeed create the resource group first as shown in this example here https://github.com/Azure/ALZ-Bicep/tree/main/infra-as-code/bicep/modules/logging#powershell. In terraform you must use the advanced blocks e.g. https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/blob/main/tests/modules/settings/settings.management.tf#L50-L53

Jack, quick question regarding Advanced block for Terraform - is it documented anywhere? I am trying to give a proper name for -dns resource group containing private DNS links, but cannot find information how parameter name should be set. It looks like for management we can use Advanced block for "management" secrion: advanced: asc_export_resource_group_name: custom_settings_by_resource_type: azurerm_resource_group: management: name: so, I am trying to find a syntax and parameter names for Advanced block for other sections. Thank you!

Here's a sample of this for DNS in config.yaml:

    advanced:
      custom_settings_by_resource_type:
        azurerm_resource_group:
          dns:
            "${default_location}":
              name: "${dns_resource_group_name_cnc}"

[SvenAelterman]

While I agree that aligning all names by default to the CAF pattern is a great improvement, that pattern is flawed IMHO (see below).

The best approach would be to allow the customer to specify their naming pattern as a string using placeholders that are then replaced at runtime. For example:

Aelterman-{workload}-{env}-{type}-{region}-{instance} might turn into Aelterman-hub-prod-vnet-eastus-01 at runtime.

UPDATE: I recognize that this will require taking into account max lengths and other restrictions that apply to various resource types. I have a Bicep module that will generate valid Azure resource names given a naming convention and a resource type. Something like that might need to be further developed first.

My dislike with the CAF suggested convention is because of:

• Having the resource type first will (in an alphabetical listing) show all resources of the same type together. It seems more desirable to me to list all resources belonging to the same workload together.
• There is no organization identifier, which helps greatly with ensuring global uniqueness when required. Different orgs will put this in different places (front or back are most common).

[jtracey93]

For clarity this is only for the Alz portal experience to start with.

Would all of your suggestions apply there still?

Also for some of your requirements I'd argue that tagging may be a better more flexible way. As departments and orgs change. And changing resource names is a no go.

[SvenAelterman]

I would say that the use of naming conventions would be applicable to any deployment method, yes.

Tagging for department or organization names is a good approach for a variety of reasons but it doesn't help with global uniqueness. Another approach is to have a placeholder for a random string of a certain length.