How can we improve Azure Governance?

Azure Policy - Support for RegEx in Match Conditions

Right now, the "Match" and "notMatch" conditions only support # for digit placeholders and ? for letters. This is okay, but it would be much more useful to support regex expressions. This would needed for define complex naming policies and tagging standards.

76 votes
Sign in
Sign in with: Microsoft
Signed in as (Sign out)

We’ll send you updates on this idea

DanM shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Microsoft
Signed in as (Sign out)
  • Jason commented  ·   ·  Flag as inappropriate

    I agree regex would be helpful but you can get further than some people here seem to realize by using value functions and conditionals. For example the use case from Marlo Bell below can be handled by:

    "if": {
    "anyOf": [{
    "field": "name",
    "matches": "???-#"
    "field": "name",
    "matches": "???-##"
    // etc.

    Some of the others can be done via something like:

    "if": {
    "allOf": [{
    "value": "[substring(field('name'), 0, 3)]",
    "match": "???"
    "value": "[substring(field('name'), 4, 2)]",
    "match": "##"
    // etc.

  • Stefan Rapp commented  ·   ·  Flag as inappropriate

    Complex naming conventions with RegEx would be great as our customers request it. The current functionality with "match" and "notMatch" is unfortunately not enough. To use "allOf" to apply multiple patterns makes the Azure naming policy more complex and difficult for administration.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Hi, seconding this. We are recommending to have a naming convention in Azure as a best practice, but currently we are not giving the right tools to enforce these naming conventions. RegEx and having the possibility to use multiple wildcards on Like and Match would allow the enforcement of a proper naming format.

  • Hally, John commented  ·   ·  Flag as inappropriate

    agreed, regex pattern matching is needed to do any real policy control for naming conventions. Please add another vote to the feature request pool

  • Daniel commented  ·   ·  Flag as inappropriate

    Looking forward to RegEx for a more robust naming audit/enforcement. It is difficult to enforce if the pattern is limited to specific characters and lengths.

  • Dieter Wijckmans commented  ·   ·  Flag as inappropriate

    For your reference but also to be notified when there's an update.


  • Anonymous commented  ·   ·  Flag as inappropriate

    Basic regex pattern matching functionality is urgently required to enable proper enforcement of tags and naming conventions:
    * character classes / sets - [a-z0-9]
    * anchors - ^ $
    * alternation - abc|def|hij
    * grouping - ()
    * repetition - ? + * {n} {n,m}


  • Chris Lewis commented  ·   ·  Flag as inappropriate

    We use Management Groups, and I'd love some simple matches like "all subscriptions in a Management Group"

  • Marlo Bell commented  ·   ·  Flag as inappropriate

    Need to track App or IT Service ID in tags. Current implementation isn't sophisticated enough to be a good enforcer. ???-#### doesn't work because it doesn't control the prefix and the number on the end isn't always 4 digits.


  • Brooks Vaughn commented  ·   ·  Flag as inappropriate

    We need more robust pattern matching. RegEx would work but in-lieu of that, then at least support what PowerShell supports.

    Why have Like with no support for many wildcards?
    Why have Match with no wildcards?

    I need something to support a rule where only UDR names that Match "PZI-G???-?-UDR-SLBR-*" are allowed:
    "not": {
    "field": "Microsoft.Network/virtualNetworks/subnets[*]",
    "notLike": "/subscriptions/*/resourceGroups/*/providers/Microsoft.Network/routeTables/PZI-G???-?-UDR-SLBR-*"

  • Marcio Parente commented  ·   ·  Flag as inappropriate

    I'm trying to apply the following regex expression and no success.

  • Jan commented  ·   ·  Flag as inappropriate

    One would expect regex when it is named match.
    Current options cannot be used to match our naming standard. At least more complex conditions needed, for example multiple asterisks.
    But why invent something new, when there is a good and relative standard way of doing this (already supported by .net).

  • Steve Keeler commented  ·   ·  Flag as inappropriate

    Please consider implement basic regular expression pattern matching. If ReDoS is a concern, then limit so extensions such as back-tracking not implemented. I have multiple customers requesting this functionality.

  • Nick C commented  ·   ·  Flag as inappropriate

    I second this idea. Either allow more complex conditions, or allow regular expressions. Even allowing two wildcards within a 'like' condition would be enormously helpful. Right now, enforcing naming policy is cumbersome.

Feedback and Knowledge Base