AWS says its generally available DevOps Agent can reduce mean time to resolution by up to 75%, speed investigations by 80%, and achieve 94% root-cause accuracy, supposedly enabling incidents to be resolved 3–5 times faster. Has anyone outside AWS seriously tried it? How well does it work with services like EKS and external observability tools, and does it provide meaningful value beyond using a general-purpose coding or troubleshooting agent?
5 Answers
It may be valuable for larger teams that already have complete telemetry in one place, but the cost and setup could make it less attractive for smaller organizations. Paying for AI analysis on top of logs, metrics, and traces can add up, although it may still be cheaper than having several engineers spend hours searching manually. I’d want a measured comparison using the same incidents before accepting the 3–5x improvement claim.
Agents can absolutely reduce triage time by searching several contexts at once, but that isn’t necessarily the same as reducing total MTTR by 75%. Once the likely cause is known, someone still has to decide whether to roll back, scale out, drain a node, or make another production change. The biggest gains are probably in figuring out what is happening, not in completing the remediation.
The main concern is safety. Even if the diagnosis is often useful, an agent that has broad production access needs strict controls around what it can inspect or change. We’ve seen AI tools recommend suppressing an error, rewriting large parts of a network configuration, or treating a timeout as a reason to redesign everything. Read-only investigation and human approval for remediation seem like the sensible default.
That’s also why comparing it with a general-purpose agent is tricky: AWS may have deeper built-in access to account resources, but the extra access only helps if the permissions and suggested actions are carefully constrained.
We use it fairly often, mainly because it’s inexpensive for our organization. It’s useful for surface-level AWS problems and for correlating telemetry when it can see multiple sources. Once we gave it access to our AWS account and observability platform, it became much better at connecting logs, metrics, traces, and alarms into a plausible root-cause explanation. That said, Claude and Codex have generally been more helpful for deeper application debugging.
Are you giving it read-only access, or can it make changes? And have you measured whether the actual investigation and RCA time improved?
The cross-service correlation sounds like the strongest use case. Surface-level AWS failures are usually obvious, while application-level problems are where the real investigation time goes.
The headline numbers need a lot more explanation. “94% root-cause accuracy” is meaningless unless AWS describes the incident dataset, what qualifies as a correct answer, whether humans verified the results, and how it performs on novel or cascading failures. A tool might do very well on familiar, single-service incidents while struggling with the complicated multi-service failures that consume most on-call time.
Exactly. In real incidents there can be several contributing causes, and the useful result is often a safe next action rather than one definitive label.
This distinction matters because vendor metrics often count investigation time more clearly than the full period from alert to verified recovery.