Policy Based Alerting - Why It's Awesome

Have you ever wondered if you’ve configured all your monitoring and alerting correctly?
Perhaps you’re worrying if you’ve enabled monitoring and alerting for all your resources?

If only there was a way to make sure that all your Azure resources are configured according to best practices and to receive the correct alerts.

Azure Monitor Baseline Alerting to the rescue

Azure Monitor Baseline Alerts (AMBA) solves exactly this problem by providing a policy-based alerting framework that ensures consistent monitoring across your entire Azure environment. The beauty of this solution lies in its use of Azure Policy to automatically deploy and maintain alert configurations.

Framework Capabilities

AMBA really shines when you’re following the Azure Landing Zone pattern. The framework is designed around the Cloud Adoption Framework (CAF) management group structure, providing initiatives that align perfectly with:

• Platform management groups (for core infrastructure)
• Landing zone management groups (for application workloads)
• Sandbox and decommissioned management groups

But here’s the thing - you don’t need a perfect CAF/WAF setup to benefit from AMBA.

Works Great in Brownfield Environments Too

Even if you’re working with existing environments that don’t follow the textbook Azure Landing Zone structure, AMBA is still incredibly valuable. You can deploy it using a single management group approach, and thanks to Azure’s inheritance model, all child management groups and subscriptions will automatically receive the policies.

This means whether you have a complex multi-management group hierarchy or just everything under one management group, the solution adapts to your environment.

Automation Made Easy

One of the best aspects of AMBA is how well it integrates with your existing automation workflows:

PowerShell Integration: The framework provides the option to use PowerShell scripts that make deployment and management straightforward. You can easily script the entire deployment process. In case that’s not you’re strong point, you can of course use Azure CLI or the Azure Portal (but where’s the fun in that? 😉)

CI/CD Ready: Whether you’re using Azure DevOps or GitHub Actions, AMBA deployments fit naturally into your pipeline workflows. You can version control your alert configurations and deploy them consistently across environments.

Built-in Remediation: They’ve included scripts for both remediation and cleanup. This means you can not only deploy alerts but also fix configuration drift or completely remove the solution if needed.

Pro Tip: Automated Remediation with Azure Automation

Here’s something I’ve found particularly useful - with a slight modification to the provided remediation script, you can set it up in an Azure Automation Runbook to auto-remediate all initiatives every 12 hours. This ensures your alert configurations stay compliant even as your environment changes.

Version Control Your Deployment

My strong recommendation: fork the official AMBA GitHub repository to your own public repository before deploying. This gives you several advantages:

• Version Locking: You control exactly which version of AMBA you’re deploying
• Protection Against Breaking Changes: The project has had breaking changes in previous releases, so having your own fork protects you

Note that the repository needs to be public due to how the ARM template deployment process works - it needs to be able to access the files publicly because the ARM template includes linked templates.

Why This Matters

Policy-based alerting transforms monitoring from a manual, error-prone process into an automated, consistent practice. Instead of wondering “did I set up monitoring for that new resource?”, you know that every resource automatically gets the appropriate alerts based on best practices.

The combination of Azure Policy’s “Deploy If Not Exists” (DINE) capability with best practice alert definitions by Microsoft FTE’s means you’re not just deploying alerts - you’re deploying knowledge and best practices at scale.

So much information, what to do next

And that’s not even half of it, I could talk about this for hours (and perhaps I will do a follow-up post about this in the future).

My recommendation on the whole platform is:

You can’t really break anything as it just adds new things to your environment.
See if it meets your requirements, read up more on their well documented website (FOR A CHANGE!! THANK YOU!!) and if need be just remove it when done testing.

Happy scripting! 😀