FAQ

Do I need to have Azure Landing zones deployed for this to work?
Can I deploy to the Tenant Root Group?
Do I need to deploy to each region that I want to monitor?
Do I need to use the thresholds defined as default values in the metric rule alerts?
Why are the availability alert thresholds lower than 100% in this solution when the product group documentation recommends 100%?
Do I need to use these metrics or can they be replaced with ones more suited to my environment?
Can I disable the alerts being deployed for a resource or subscription?
How much does it cost to run the ALZ Baseline solution?
Can I access the Visio diagrams displayed in the documentation?
Can I use AMBA-ALZ without cloning/forking a GitHub repository
Can I deploy a local template by using -TemplateFile
What characters can I use when creating Azure resources or renaming Azure subscriptions?
Can I exclude Management Groups or Subscriptions from policy assignment?

No, Azure Landing Zones are not required. However, you must use Azure Management Groups. Currently, our focus is on resources commonly deployed as part of Azure Landing Zone implementations.

Although it is recommended to implement the alert policies and initiatives within an Azure Landing Zone (ALZ) Management Group hierarchy, it is not a technical requirement. However, avoid assigning policies to the Tenant Root Group to minimize the complexity of debugging inherited policies at lower-level management groups. For more information, refer to the CAF documentation.

No, deployment to multiple regions is not required. The definitions and assignments are scoped at the management group level and are not specific to any region.

The provided thresholds are intended as a starting point, based on Microsoft’s recommendations and field experience. You may need to adjust these thresholds to suit your specific environment. Monitor the alerts and adjust the thresholds accordingly: increase the threshold if the alerts are too frequent, or decrease it if the alerts are not triggering when they should. Once you have determined an appropriate threshold, consider sharing your findings with us for broader use.

Setting a threshold of 100% can sometimes result in false alerts, creating unnecessary noise. By lowering the threshold slightly below 100%, this issue can be mitigated while still ensuring alerts for service availability. If the default threshold is not stringent enough, you are encouraged to adjust it upwards. Additionally, you can provide feedback by filing an issue in our GitHub repository: GitHub Issue.

The metric rules provided are based on Microsoft’s recommendations and field experience. Your usage of Azure resources may vary, so it is advisable to customize the alerts to meet your specific requirements. The primary objective of this project is to facilitate scalable Azure Monitor alerts. You are encouraged to create new rules with your own thresholds. We welcome feedback on your custom rules, so please share your findings with us.

Yes, you can disable the alerts for a specific resource or subscription. For detailed instructions, please refer to the Disabling Policies documentation.

The cost of running the ALZ Baseline solution varies based on several factors, including the number of alert rules deployed, the number of subscriptions inheriting the baseline policies, and the resources within each subscription that match the policy rules. Each alert rule costs approximately $0.1 per month¹.

• Alert rules are charged based on the number of evaluations.
• If the alert rule evaluates data continuously throughout the month, the cost is approximately $0.1¹.
• If the rule evaluates data intermittently (e.g., due to the monitored resource being down and not sending telemetry), the cost is prorated based on the time the rule was actively evaluating data.
• Using Dynamic Thresholds doubles the cost of the alert rule, resulting in a total cost of approximately $0.2 per month¹.
• The solution configures an email address as part of the Action Groups deployment (one per subscription), with a charge of approximately $2 per month for every 1,000 emails¹.

It is advisable to evaluate the costs in a non-production environment before full deployment to ensure a clear understanding of the potential expenses.

For detailed cost estimates related to your deployment, please refer to the Azure Monitor Pricing page. Additionally, you can collaborate with your local Microsoft account team to develop a rough order of magnitude (RoM) cost estimate. ¹ Note that costs may vary slightly depending on the deployment region. The costs mentioned are based on pricing as of April 2023.

Yes, you can access the Visio diagrams in the media folder.

Yes, as long as the ARM templates are publicly accessible. This solution includes several linked templates that must be accessible publicly. When the top-level ARM template is submitted to Azure Resource Manager, the linked templates are not automatically uploaded and need to be pulled in at deploy time from Azure. Therefore, they must be referenced using a URL accessible from Azure (e.g., via a public GitHub repository).

Alternatively, you can use Template specs. Instead of maintaining your linked templates at an accessible endpoint, you can create a template spec that packages the main template and its linked templates into a single entity for deployment. The template spec is a resource in your Azure subscription, making it easy to securely share the template with users in your organization. You can use Azure role-based access control (Azure RBAC) to grant access to the template spec. This feature is currently in preview.

References:

• Template specs
• ARM Private deployment

No, using the -TemplateFile parameter is not feasible because the ARM template includes linked templates. When referencing a linked template, the URI value cannot be a local file or a file accessible only on your local network. Azure Resource Manager must have access to the template, which requires the templates to be referenced using a URL accessible from Azure (e.g., a public GitHub repository).

Not all characters are allowed when creating Azure resources or renaming Azure subscriptions. For a comprehensive list of supported characters, refer to the Naming rules and restrictions for Azure resources documentation. For example, alert suppression rules permit only alphanumeric characters, underscores, and hyphens.

• a through z (lowercase letters)
• A through Z (uppercase letters)
• 0 through 9 (numbers)

Using unsupported characters when creating an Azure resource or renaming a subscription can lead to the following issues:

• Resource creation will fail.
• Deployment of action groups and/or alert processing rules will fail. For AMBA-specific issues, refer to the Failed to deploy action group(s) and/or alert processing rule(s) section in the Known Issues documentation.
• Editing action groups will result in an Azure portal page error. For AMBA-specific issues, refer to the Failed to edit action group(s) section in the Known Issues documentation.

For deployments (update or new) happening after March 2025 the 25th using the code in either the main branch or any new release, it is possible to configure some new parameters to perform the exclusion at scale during the deployment. Read more at Exclude Management Groups and/or Subscription from Policy Assignment.

When deploying at scale, we include all management groups and subscriptions under the pseudo root management group hierarchy. This might results in the inclusion of unwanted or unnecessary resources. Should this be the case, it is possible to exclude them after the deployment. To do so, it is necessary to:

1. Open the Azure portal and navigate to Policy

   

2. Click on Assignment

   

3. Click on Scope, set the scope to management group the relevant assignment is targeted to (for example the Identity) and click Select

   

4. Select and click on the assignment to perform the exclusion on. Notice that the list will include both the assignments inherited from the parent MG those applied to child management groups.

   

5. In the assignment blade, click on Edit

   

6. Click on the ellipsis next to the Exclusion box to select what to exclude. A new context windows, will show the hierarchy of resouces that could be added to the exclusion scope based on the assigned scope. Notice that the list will include the parent scope and only child resources. Make the selection, click Add to Selected Scope and then click Save

   

7. Now the Exclusion contains the excluded resource names. Click on Review + Save

   

8. and then Save

   

9. If remediation has been already performed, it will be necessary to delete the related alerts. If not, perform the remediation according to guidance provided at Remediate Policies. Alerts for resources in the excluded scope will not be created.