Resource Group naming consistency and convention

[RichardYule]

Using the "Deploy to Azure" button workflow, I've deployed Enterprise Scale - Lite (single platform subscription) with no networking.

This gives me resource groups that follow a naming convention: rg-ama-prod-001 (suggested but editable on the Platform management, security and governance page) rg-amba-monitoring-001 (suggested but editable on the Baseline alerts and monitoring page)

and resource groups that do not: [enterpriseScaleCompanyPrefix]-asc-export [enterpriseScaleCompanyPrefix]-mgmt

Where enterpriseScaleCompanyPrefix is the "Resource Prefix (Root ID)" from the Azure core setup page I think - fine for management groups, but not for resource groups.

My request is for all resource groups to follow a single naming convention and be suggested, but editable through the accelerator configuration steps.

Background: I'm testing this configuration with a Partner VS Enterprise subscription and an M365 Dev tenant to give my colleagues an example of "Azure done right" with Policy, Monitor, Defender etc. If the resource groups names don't follow convention, it fails my "done right" criteria (inconsistent naming has caused all sorts of issues in my experience).

[Springstone]

@RichardYule really great observation, and we'll put this on our backlog.

Please note, there is a LOT of change coming in the next release that will be our focus for the short term.

[mundayn]

Hey @Springstone

There is already a long running issue here for naming also fyi - Jack advised it was on the backlog a while back: https://github.com/Azure/Enterprise-Scale/issues/674

But as per this issue, having everything namable by the portal accelerator would be awesome, so we can customize for each client easily.

Yes I know we can use bicep / terraform etc., but for quick deployments and for staff members who don't have the experience, this is an amazing tool, but, the naming issue is the biggest pain point for us.

[Springstone]

Will be reviewing this on our weekly triage call, but for now I'm thinking to update:

[enterpriseScaleCompanyPrefix]-asc-export [enterpriseScaleCompanyPrefix]-mgmt

to

rg-alz-asc-export-001 rg-alz-mgmt-001

For consistency. It will require a bit more effort to include options to rename these resource groups during provisioning. Let me know if this would work overall as a default.

[RichardYule]

Hey @mundayn I looked back over recent issues and searched for similar issues, not sure how I missed #674

I see in that issue you suggested a naming convention of

Resource	ESLZ Name (Current)	CAF Recommended Name
RG for Management	mg-contoso-mgmt	rg-hub-mgmt-wu2-001
Automation Account	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

I mentioned that I didn't deploy any networking, so the VNet rg and resources didn't concern me, but would be good to include these in any update. The automation account and log analytics workspace are a problem for me as they are: [enterpriseScaleCompanyPrefix]-aauto [enterpriseScaleCompanyPrefix]-aauto-TotalJob [enterpriseScaleCompanyPrefix]-law

This is becoming more complicated!

To answer @Springstone - would an update of the default rg naming work as a default: Yes, but is this interim step worthwhile?

1. @mundayn mentions more cases that would need to be included
2. These cases include other inconsistencies (wu2? list-locations uses westus2)
3. The environment part of the default varies from the established "prod" to less conventional "monitoring" and "con"

My questions:

1. Should the ESLZ provide default naming for all resources? I think it should as "an opinionated approach".
2. Should the defaults be editable? I think they should as many cannot be changed later.
3. Should the ESLZ have an opinionated naming convention? I think it should see Q1.
4. Does the ESLZ have a naming convention? As can been seen, it does not fully have this.

Much as I would like a quick fix, I think it might be best to define the default naming convention, set the default values and work towards making these all editable during configuration in that order.

I'm going to pause here to see if others think this is the right approach.

[mundayn]

Hi all!

@Springstone can you discuss with @jtracey93 and advise us what the plan/update is on the naming convention standardization to the CAF as discussed in this issue please? (From: https://github.com/Azure/Enterprise-Scale/issues/674)

"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"

Right now there is lack of adherence to a naming standard across the ES LZ experience, as shown in this deployment I just did (not all resource deployed, deployment failed for some reason).

Thank you so much in advance.

[Springstone]

Quick update: this is on the backlog for this current Policy Refresh cycle.

[mcdonamw]

Fwiw, I just went through an ES ALZ deployment myself with MS and noticed this same issue with naming. My goal with this deployment was to fix many issues our brownfield environment has, one of them specifically naming conventions. So now I have a bunch of new subscriptions/resources that have the same issue. Not very happy about that LOL. I might have to delete everything and try to edit all these templates myself (if that's even possible).

I hope this gets fixed soon.