Azure SRE Agent Alternative: Open Source (2026)
Azure SRE Agent is Azure-locked, always-on billed, and closed source. Aurora is the Apache 2.0, self-hosted, multi-cloud open source alternative.
Key Takeaways
- Azure SRE Agent went generally available on March 10, 2026. Microsoft says it runs the agent across its own services: 1,300+ agents deployed, 35,000+ incidents mitigated, and over 20,000 engineering hours saved internally.
- Billing never sleeps. The agent bills a fixed 4 Azure Agent Units per agent-hour from creation until deletion, even while stopped, plus token-based active-flow AAUs. At the East US rate of roughly $0.10 per AAU (per Azure's Retail Prices API), always-on alone is about $292 per agent per month before any usage. There is no free tier.
- It is Azure-native by design. The agent manages the full range of Azure services; AWS is reachable only through an MCP proxy bolt-on, and the agent itself deploys in three Azure regions as of July 2026.
- Approval is the default, not a guarantee. Review mode is the agent-level default, but incident response plans and scheduled tasks default to Autonomous.
- Aurora is the open source (Apache 2.0) alternative: self-hosted anywhere, investigating AWS, Azure, GCP, OVH, Scaleway, and Kubernetes natively, with no per-agent meter and a 7-layer guardrail stack.
Azure SRE Agent is the strongest argument yet that AI SRE has gone mainstream: Microsoft dogfooded it across its own estate and now sells it as "an autonomous agent that diagnoses issues, orchestrates mitigations, and optimizes cloud operations with intelligent precision". If your infrastructure is genuinely all-Azure, it deserves a serious look. This post is an honest account of where it excels, where the single-cloud scope and always-on meter bite, and how the open source Aurora project fits teams that need the same capability across more than one cloud, or on infrastructure they control.
What is Azure SRE Agent?
Azure SRE Agent is Microsoft's AI operations agent, generally available since March 10, 2026. It monitors Azure resources, investigates incidents, proposes mitigations, and can execute them. Microsoft's launch numbers are internal but striking: the company says it runs 1,300+ agents across its own services, with 35,000+ incidents mitigated and over 20,000 engineering hours saved, and cites early adopter Ecolab reducing daily performance alerts from 30-40 to under 10.
Its real strengths are worth naming plainly. It covers the full range of Azure services, from AKS and App Service to Azure SQL and Cosmos DB, and can automate any Azure CLI operation through runbooks, subagents, and hooks. Its safety model is genuinely thought through: Reader and Privileged permission levels with on-behalf-of elevation, Review and Autonomous run modes, and a pre-execution permission gate on every tool call. It connects to PagerDuty, ServiceNow, Grafana, GitHub, Azure DevOps, Slack, and Teams, plus 40+ MCP connectors. And its model picker is a detail worth knowing: per Microsoft's pricing docs, Claude Opus 4.6 is metered at roughly three times the AAU rate of GPT 5.3 Codex for input tokens.
What is Aurora?
Aurora is an open source, Apache-2.0 AI SRE platform built by Arvo AI. Like Azure SRE Agent, it autonomously investigates incidents and produces root-cause analyses. Unlike it, Aurora is self-hosted and vendor-neutral: its LangGraph-orchestrated agent queries AWS, Azure, GCP, OVH, Scaleway, and Kubernetes natively, runs kubectl and cloud CLIs in sandboxed pods, correlates alerts against a Memgraph dependency graph that spans providers, and generates post-mortems that export to Confluence, Notion, or SharePoint. Every agent-issued command passes a 7-layer guardrail stack with human-gated writes, and because it is bring-your-own-LLM with Ollama support, it can run fully air-gapped.
Azure SRE Agent vs Aurora: the head-to-head
Scope: one cloud natively, others by bolt-on
Azure SRE Agent's evidence reach is Azure-shaped. Within Azure it is deep: VMs, App Service, Container Apps, AKS, Functions, databases, networking, and the Monitor stack. Outside Azure, reach arrives through MCP connectors, and the flagship example is AWS with Azure SRE Agent: a local proxy to the official AWS MCP server that exposes 23 tools and can call AWS APIs, bounded by the IAM policies you grant it, with write access as a separate opt-in permission. It works, but it is a connector to another cloud, not management of it; the agent's native constructs, permission levels, managed resource groups, and identity all apply to Azure resources only.
Aurora inverts the model. Multi-cloud is the native case: discovery populates one dependency graph with services from AWS, Azure, GCP, OVH, Scaleway, and Kubernetes, and an investigation traverses all of them in a single reasoning loop. For teams whose incidents cross provider boundaries, that is the difference between an investigation and a handoff, as we cover in multi-cloud incident management.
Billing: an always-on meter vs no meter
This is the most concrete difference, and Microsoft documents it clearly. Azure SRE Agent bills two flows: an always-on flow of 4 AAUs per agent-hour, charged from agent creation until deletion, explicitly including time the agent is stopped, and an active flow metered per token since April 15, 2026. Azure's Retail Prices API lists the AAU at roughly $0.10 in East US, which puts the always-on flow alone at about $292 per agent per month before the agent does anything. Microsoft's own examples price a single incident investigation at about 35 AAUs and a full remediation at about 86 on Claude Opus 4.6, or roughly 12 and 30 on GPT 5.3 Codex. The pricing docs are direct about the entry cost: there is no free tier, and if you set a monthly active-flow limit and hit it, the agent becomes unavailable for chat and actions until the next month while always-on charges continue.
Aurora has no meter. It is free and open source; you pay for the infrastructure it runs on and the LLM you point it at, and a local Ollama model makes inference cost effectively fixed. For the deployment-control argument in full, see self-hosted AI SRE.
Autonomy and guardrails: read the defaults
Azure SRE Agent's approval story is better than most, and more nuanced than its marketing summary. Review mode, where the agent proposes and a human approves, is the default at the agent level. But incident response plans and scheduled tasks default to Autonomous, and approval gates apply to Azure infrastructure operations specifically. That is a reasonable design; it is also exactly the kind of default an evaluator should read the docs on rather than assume.
Aurora's equivalent posture is stricter where it matters: gated actions in background and scheduled runs are denied outright rather than executed autonomously, every command passes deterministic policy and signature checks plus a fail-closed LLM judge before execution, and the pull-request path is structurally human-gated. The full architecture is in our AI agent guardrails deep dive.
Deployment and auditability
Azure SRE Agent is SaaS, deployable in three Azure regions (Sweden Central, East US 2, Australia East) per Microsoft's FAQ at the time of writing, with expansion under way; it manages resources in any region, and the chat interface supports English only. The reasoning system is closed. Aurora deploys via Docker Compose or Helm on any infrastructure, anywhere, air-gapped if needed, and every line of the agent that touches production is auditable on GitHub.
Comparison table
| Dimension | Azure SRE Agent | Aurora |
|---|---|---|
| License | Proprietary, closed source | Open source, Apache 2.0 |
| Deployment | SaaS, 3 Azure regions (July 2026) | Self-hosted anywhere, air-gapped capable |
| Native scope | Full range of Azure services | AWS, Azure, GCP, OVH, Scaleway, Kubernetes |
| Other clouds | AWS via MCP proxy, IAM-bounded | Native, one dependency graph across providers |
| Pricing | 4 AAU/agent-hour always-on + token-based active flow, no free tier | Free + infrastructure and LLM cost |
| Autonomy defaults | Review at agent level; incident plans and schedules default Autonomous | Human-gated writes; background runs deny gated actions |
| LLM choice | Claude Opus 4.6 or GPT 5.3 Codex / GPT 5.2 | Bring-your-own-LLM, including local Ollama |
| Guardrail transparency | Documented, closed implementation | 7 documented layers, open implementation |
What about AWS and Google's agents?
Every hyperscaler now ships a cloud-locked operations agent, which is itself the strongest argument for a neutral layer. AWS DevOps Agent went GA on March 31, 2026, billed at $0.0083 per agent-second with a 2-month free trial, and notably charges nothing while idle, a pointed contrast with Azure's always-on flow. Google's Gemini Cloud Assist investigations remains in preview and analysis-only, and since April 10, 2026 it is restricted to Premium Support customers or teams granted access by their Google account team. Each agent is excellent inside its own cloud and a guest everywhere else. If your incidents live in one cloud, use that cloud's agent or a neutral one; if they cross clouds, the neutral layer is the only architecture that sees the whole failure. Our 15 best AI SRE tools roundup covers the full landscape.
Which should you choose?
Choose Azure SRE Agent if your estate is all-Azure, you want first-party integration with Azure Monitor and the Azure control plane, and the per-agent economics work at your scale. It is a credible, well-documented product with a real safety model, and Microsoft's internal usage numbers are evidence it works.
Choose Aurora if your infrastructure spans more than one cloud or includes significant Kubernetes and on-prem, if your incident data cannot leave your perimeter, if you want to audit the agent's guardrails in source rather than trust a closed implementation, or if an always-on per-agent meter does not fit how you budget. If you are weighing several options, our AI SRE platform evaluation framework walks through the criteria.
The two also compose: teams running Azure SRE Agent for Azure-native toil can run Aurora as the cross-cloud investigation layer above it, since Azure is one of Aurora's native providers.
You can read the code, deployment guides, and connector list in the Aurora repository on GitHub.
All claims sourced from Microsoft's official documentation, pricing pages, and launch blogs, the Azure Retail Prices API, AWS and Google official pages, and Aurora's public repository and docs. Pricing and availability change; verify against the linked pages. Last verified: July 15, 2026.