Today we are going to talk about Naming Conventions for Azure resources, and how and when we should enforce them with Azure Policy.
This article accompanies the video I did for the Festive Tech Calendar. Big thanks to CloudFamily.info for this initiative and for the opportunity to be part of the event. Make sure you check FestiveTechCalendar.com for new surprise content for every day of December and the YouTube Channel where most of the videos are located.
There are many Azure resource types, and in the ideal world, every resource type should have its naming standard. But we don’t live in the ideal world, and enforcing that would bring more work, potentially limit some workflows. Strict naming conventions will also not directly benefit functionality, performance, or cost in our environment. In this session, Vukasin will explain the real benefits of naming conventions, and how to create Azure Policies to enforce them where it makes sense.
Today we are going to answer 4 questions:
- WHY do we need to define a naming convention for our Azure Resources?
- HOW to prepare Naming Conventions for Azure Resources?
- WHEN to have it strictly enforced with the Azure Policy?
- WHAT else can we do instead of enforcing?
Answer to these questions with examples and a short demo can be found in this video:
And here you can find the Azure Policy Definition from the demo:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
{
"mode": "All",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Resources/subscriptions/resourceGroups"
},
{
"field": "name",
"notLike": "networkwatcherrg"
},
{
"field": "name",
"notLike": "AzureBackupRG*"
},
{
"field": "name",
"notLike": "RG-Prod-*"
},
{
"field": "name",
"notLike": "RG-Dev-*"
},
{
"field": "name",
"notLike": "RG-Test-*"
}
]
},
"then": {
"effect": "deny"
}
},
"parameters": {}
}
In case you have any questions, you can always DM me on Twitter or LinkedIn. Keep clouding around.
Vukašin Terzić