In many of the Azure environments I review, nobody thinks seriously about monitoring until the first outage. Then everyone starts asking which alerts actually exist, whether anyone receives them and whether they fire at the right moment. Azure Monitor Baseline Alerts (AMBA) have made a real difference here. AMBA is Microsoft's open-source, recommended collection of alert rules and policies for Azure landing zones, and it gives you a ready-made foundation. It covers the classic metrics for VMs, storage, networking and key vault, and it also includes service health and resource health. If you want monitoring in Azure that is reliable and repeatable, AMBA is quickly turning into the standard rather than an optional extra.

AMBA gives you a curated monitoring baseline for Azure

Azure Monitor Baseline Alerts are a curated set of alert rules, action groups and alert processing rules that Microsoft maintains in the open (Azure Monitor Baseline Alerts). The idea is to give you a practical monitoring baseline you can build on, whether you run one subscription or dozens of landing zones. In my experience, most enterprises gain a lot from enforcing a baseline at the start of every new environment. It stops the usual sprawl of scattered, inconsistent or missing alerts, and it cuts down on alert fatigue caused by useless noise. One point I want to stress: AMBA goes beyond CPU usage and storage thresholds. Service health and resource health get the same attention, so you also hear about outages that are outside your control.

AMBA rolls out through the portal accelerator or your landing zone code

You have two practical options for implementing AMBA. The first is the AMBA portal accelerator. It walks you through a wizard to deploy the baseline alert set across subscriptions or management groups, and it sets up centralized recipient lists through action groups. The second option, which I prefer for infrastructure-as-code projects, is to make AMBA part of your landing zone rollout. It fits well with Bicep or Terraform. If you are building landing zones from scratch or modernizing existing ones, keep landing zone governance in mind, along with diagnostic settings at scale, which matter a great deal here. When diagnostic settings are applied inconsistently, your alerts miss important signals because resource logs and metrics never arrive in the central Log Analytics workspace. Baseline alerting only works properly when it is paired with a unified diagnostics and log strategy.

One thing to understand before you roll out: the service health alerts AMBA recommends do not need Log Analytics, because Azure platform events trigger them directly. Metric-based alerts, such as those for VM performance, are different. They need monitoring enabled and the right metrics exposed on each resource. If you are filling gaps in an existing environment, start with storage accounts, VMs and key vaults.

Action groups and alert processing rules keep alert fatigue in check

A mistake I see all the time is that the alerts exist but the recipient logic is a mess. In larger environments this quickly gets chaotic, with emails landing in personal mailboxes, in service accounts or nowhere at all. The fix is consistent action groups (central mailing lists, Teams channels, webhooks) combined with alert processing rules that filter out noise and escalate only what matters. AMBA's guidance is straightforward:

  • Service/resource health alerts go to central ops addresses
  • Metric-based alerts go to the app/service teams responsible
  • Alert processing rules take care of maintenance windows and prioritization
  • Avoid floods of duplicate or low-value alerts
  • Review action groups regularly so the recipients stay current

When you define action groups centrally (in the portal or in IaC), you can reuse them everywhere. That saves time and prevents alerts from going to the wrong place. Alert processing rules are what you use during maintenance periods or to send only critical issues to incident responders, so plan them deliberately. This is where a well-run environment clearly separates itself from an ad-hoc setup.

Pro tip: Before creating a new action group, look under Azure portal → Monitor → Action groups to see what already exists. Updating one central group is usually better than ending up with hundreds of one-off lists.

Service health and resource health alerts are the bare minimum

I consider service and resource health alerts the absolute minimum for any Azure setup. They tell you about outages at the Azure service, regional or resource level, no matter how good your resource-level monitoring is. To set up the rules, go to Service Health → Health alerts in the Azure portal (see Microsoft docs). Pick the recipients carefully so that someone is always in a position to act. For production I always recommend sending these alerts to central ops or on-call mailboxes rather than to individuals.

Many companies lean heavily on resource-level monitoring and forget that a regional Azure outage can have much wider consequences. Only service health alerts cover that case, and without them you have no visibility into it. Resource health alerts also warn you early about degraded VMs, storage or databases, which helps enormously when troubleshooting.

# Quick check: List all Service Health activity log alerts
# Go to Azure portal → Service Health → Health Alerts to create rules
# This PowerShell just lists configured rules:
Get-AzActivityLogAlert | Where-Object { $_.Name -like '*ServiceHealth*' }

AMBA changes day-to-day operations for the better

Rolling out Azure Monitor Baseline Alerts is more than a compliance checkbox. Operations genuinely become calmer, provided you keep the setup maintained. In landing zones built with IaC and policy in particular, a standard baseline prevents both noisy chaos and missed incidents. You still need to review rules and action groups regularly, because org structures and responsibilities change. Getting full coverage while keeping noise low is still the hardest part. AMBA gives you a solid starting point, but it does not replace custom alerting for your most critical workloads.

The diagram below shows the alert flow for a VM, from the metric through to the notification. With a proper AMBA implementation, you control every step along the way.

flowchart TD
    Metrics["VM metric"] --> AlertRule["Alert rule (AMBA)"]
    AlertRule --> ActionGroup["Action group"]
    ActionGroup --> AlertProcessing["Alert processing rule"]
    AlertProcessing --> Notify["Recipient/Incident"]

Figure: Azure Monitor Baseline Alert trigger path for a VM

A baseline with central action groups gives you less noise and more signal

If you manage Azure at scale, you need a baseline, and AMBA is the best-documented and most practical starting point I have come across. Without central action groups and regular upkeep, though, you won't get the full benefit. For me, service health and resource health alerts are not up for debate, and everything else builds on top of them. I now include AMBA by default in every new tenant I help deploy. It brings order to the alerting and makes sure the right signals reach the right people at the moment they matter.