The Hyperscaler Copilots Are Real Now — Which Makes the Comparison Worth Doing Properly
For most of 2026 the conversation about AI operations agents has been about announcements. That phase is over. AWS DevOps Agent reached general availability on 2026-03-31 (launched at re:Invent 2025), and Microsoft’s Azure SRE Agent reached general availability by March 2026 (announced at Build 2025). Both are now shipping, paid products doing autonomous incident investigation and SRE work in real customer environments. AWS also brought its Security Agent to GA in the same spring window.
When the hyperscaler copilots were previews, “wait and see” was a reasonable posture. Now that they are GA and billed, a head-of-platform evaluating an operational-layer purchase has to actually compare them — to each other, and to the independent active-operational-layer alternative. This piece does that on the five axes that decide the buy: scope and multi-cloud reach, billing shape, governance and approval gates, audit-trail surface, and the model-key / BYOK posture. It is a fair comparison; where IAN differs, the difference is structural, not a feature checkbox.
See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →
Axis 1 — Scope and Multi-Cloud Reach
AWS DevOps Agent is positioned as an always-available operations teammate that resolves and prevents incidents, optimizes reliability and performance, and handles on-demand SRE tasks, and the GA release notably added the ability to investigate applications in Azure and on-prem environments alongside AWS. Azure SRE Agent is the equivalent for the Azure estate. Both are strong inside their home cloud and improving at reading across the fence.
But the structural point survives the feature parity: a single-cloud copilot is built and incentivized to deepen dependence on its own cloud. Even when AWS DevOps Agent reads Azure telemetry, the gravity of the product — the billing, the deepest integrations, the roadmap incentives — pulls toward AWS. That is not a criticism of the engineering; it is the economics. A hyperscaler cannot credibly become the neutral multi-cloud operations layer without hurting its parent’s core business, because the parent’s business is selling more of its own cloud. An organization running AWS and Azure and GCP and on-prem is asking the copilot to be neutral about exactly the question its vendor cannot be neutral about.
The active operational layer is multi-cloud by design because it does not own a cloud. IAN runs a team of specialized agents — cost, security, incident/SRE, deployment, resource-operations — across whatever clouds the customer runs, with no incentive to favor one. (Live on AWS today, with GCP, Azure, Kubernetes, and on-prem as the next adapters.)
Axis 2 — Billing Shape
With general availability, AWS DevOps Agent is no longer free; it is billed based on the cumulative time the agent spends on operational tasks, billed per second. That is a clean, usage-aligned model, and it is honest about the thing being sold: agent working time.
The questions a buyer should ask of any time-metered model are about predictability and incentive. Time-on-task billing means a noisy incident week costs more than a quiet one — which is reasonable, but it also means the vendor’s revenue rises with the agent spending more time working, and the buyer carries the variance. IAN’s model is usage-based with a monthly minimum, priced on per agent action, per connected cloud account, per operation class, so small teams get a predictable floor and the unit being charged for is the discrete operation, not elapsed time. The deliberate structural choice underneath it is the next axis.
Axis 3 — Governance and Approval Gates
This is where an operational-layer evaluation should spend the most time, because it decides whether the thing is deployable in an enterprise with real compliance requirements. An agent that can act on infrastructure needs an answer to “which actions run automatically, which require a human, and who can change that policy.”
IAN’s answer is the capability-tier model — Observe / Operate / Administer. Observe-tier work (read-only audits, cost analysis, security scans, drift detection) auto-executes and is fully audited. Operate-tier work (deployments, tagging, resource changes, remediation PRs) auto-executes for reversible, scoped, in-policy changes and hits approval gates for anything irreversible or out-of-policy. Administer-tier work (org-level changes, billing, IAM, the approval policy itself) always requires explicit approval, with separation of duties enforced. Customers choose which tiers are enabled per cloud account, per team, and per agent. A buyer evaluating any copilot — AWS, Azure, or otherwise — should demand the equivalent explicit, per-tier, per-scope governance model and not settle for an implicit “the agent is careful” assurance.
Axis 4 — Audit-Trail Surface
Closely related, and just as load-bearing for a regulated buyer: what record exists of what the agent did. When an agent operates infrastructure, the audit trail is not a nice-to-have logging feature — it is the compliance deliverable, the incident-forensics source, and the thing the cyber-insurance underwriter and SOC 2 auditor actually ask to see.
IAN appends every agent action, regardless of tier, to an immutable audit trail — that is the design point, not an add-on, and the web administration surface exists primarily for audit-trail review and approval-queue management rather than day-to-day operation. The evaluation question for any copilot is the same: is there a complete, immutable, auditor-readable record of every action the agent took, who or what approved the irreversible ones, and when? A buyer should treat “where is the immutable audit trail and what is in it” as a gating requirement.
Axis 5 — Model Keys and BYOK Posture
The last axis is quieter but matters for procurement and margin. Most copilots wrap the underlying model and bill the inference back to the customer at a markup, inside the cloud vendor’s own billing relationship. IAN’s posture is BYOK — bring your own model keys: customers bring their own Claude / model keys and pay inference costs directly to their model provider, while IAN charges only for the orchestration and coordination layer.
That choice does three things a buyer can verify. It produces higher gross margins than a wrap-and-markup model, which is a sustainability signal. It removes an enterprise procurement blocker, because the customer’s model-provider spend is usually already approved. And it keeps the model keys under the customer’s own rotation and governance policy rather than parked inside a vendor wrapper. For an organization that already has Anthropic or OpenAI spend approved, BYOK turns the model relationship into something they already control.
The Honest Summary of the Comparison
None of this says the hyperscaler copilots are bad products. AWS DevOps Agent and Azure SRE Agent are real, GA, and genuinely useful inside their home clouds — and for a committed single-cloud shop, the home-cloud copilot may be the pragmatic choice. The competitive point is narrower and structural: the single-cloud copilots cannot take the shape of a neutral, multi-cloud, governance-first active operational layer, because their economics point the other way. They are incentivized to make one cloud stickier; the active operational layer is incentivized to run whatever the customer runs.
That is the same frame IAN has argued all year. DevOps is not a tool category that needs a better single-cloud copilot. It is a human-delivered service function now being delivered by software, and the layer that wins is the one that operates infrastructure across clouds with humans in the loop only where judgment matters — not the one locked to a parent cloud’s roadmap.
How IAN Helps: The Active Operational Layer the Copilots Cannot Be
IAN runs a coordinated team of specialized agents — a cost agent, a security agent, an incident/SRE agent, a deployment agent, and a resource-operations agent — that share context about the environment and escalate to each other when work crosses domains. The team is multi-cloud by design, governed by the Observe / Operate / Administer capability tiers with approval gates on everything irreversible, recorded in an immutable audit trail, priced usage-based with a monthly minimum on BYOK model keys, and driven through an MCP-first interface so the engineers already in Claude, Cursor, and Claude Code operate it from the clients they already use. That is the combination — multi-cloud, governance-first, audit-complete, BYOK, MCP-native — that a single-cloud copilot is structurally unable to offer.
The Three-Phase Rollout
Observe. The agent team connects read-only across the customer’s clouds, runs the cost, security, and reliability audits, and leaves a concrete report — multi-cloud from the first run, no action taken, every finding kept regardless of next steps.
Operate. With approval gates configured, the team begins executing the reversible, in-policy operations — remediation PRs, rightsizing, tagging, deployment health checks — auto-executing the scoped changes and gating the irreversible ones behind explicit approval, every step audited.
Cross-agent loop. The cost, security, incident, deployment, and resource-operations agents run as a coordinated team across every connected cloud, escalating across domains, with the immutable audit trail capturing the whole record — the active operational layer doing the work the dashboards and the single-cloud copilots only ever surface.
The 2026 read: the hyperscaler copilots are real and GA, the right way to evaluate them is on scope, billing, governance, audit trail, and BYOK, and the shape they structurally cannot take — neutral, multi-cloud, governance-first — is exactly the shape of the active operational layer.
Next step: talk to the team
30 minutes. We'll look at your cloud together and scope what we'd take off your plate — see pricing.