AWS DevOps Agent: Incident Investigation, Cost and Accuracy

The pitch for an AI SRE is always the same: the alarm fires at 2 a.m., and by the time you open your laptop something has already pulled the metrics, read the deploy history and written down a hypothesis. AWS made that pitch official on 31 March 2026, when DevOps Agent left preview, and it bundled usage credits into AWS Support plans, which makes it the default thing every other AI SRE tool gets compared against.

I have not run this against a production account, so this is a reading, not a field report. Everything below comes from the AWS announcement, the pricing page and three pages of the user guide, re-read on 17 October 2026, plus one independent write-up from Versent. Where a number is AWS's claim rather than something anyone measured, I say so, and the last third of the post is about how to measure it on your own stack.

What happens between the alert and the answer

An investigation is a pipeline, not a chat. The user guide describes five stages, and knowing them tells you where to put your own controls.

1. Trigger. An investigation starts from a built-in integration such as ServiceNow, from a webhook (the guide's examples are PagerDuty tickets and Grafana alarms), or manually from the Incident Response tab of the agent space web app.
2. Triage. An external event is processed within seconds to decide whether it is a new investigation or belongs to one already running.
3. Investigation. The agent builds a plan, collects findings and can delegate to parallel sub-agents. Each shows up in the timeline with its tool calls and runtime, for example ec2-cpu-metrics with 5 tool calls and 50s.
4. Steering. You can send a message to a running or finished investigation. It is queued and read between reasoning steps, never mid tool call, and a message can be up to 32,768 characters. You can also fork an investigation to test a different hypothesis without losing the original.
5. Mitigation. After root cause analysis the agent shows mitigation proposals inline. Each lists the recommended action, expected outcome and prerequisites, and you can refine its parameters and choose whether to apply it.

Two details matter later. First, the agent correlates telemetry, code and deployment data, and the GA announcement lists CloudWatch, Datadog, Dynatrace, New Relic, Splunk, GitHub Actions, GitLab CI/CD, ServiceNow and Slack as existing integrations, with PagerDuty, Grafana, Azure DevOps and EventBridge added at GA. Second, Versent's preview-era write-up called it read-only and advisory, while the current guide says you choose whether to apply each proposal. I did not test what applying does, so check the write path in your own space before you rely on either description.

Triage decides whether you pay for a second investigation

Triage is the stage that most directly controls cost, because a duplicate alert that gets linked does not start its own investigation. The agent compares a new incident with active investigations inside a look-back window the guide gives as typically 20 minutes, weighing component similarity, geographic region and timing.

Both correction paths are manual. You can also write custom correlation rules as a skill and attach it to the triage stage, which is the lever I would reach for first if two unrelated alarms keep being merged. Triage is also the cheapest place to stop noise: a skipped incident is dismissed without an investigation, while an investigation of a flapping alarm consumes billable agent time.

Setting it up from the CLI instead of the console

The CLI onboarding guide says the whole setup takes about 20 minutes and works in six Regions: N. Virginia, Oregon, Sydney, Tokyo, Frankfurt and Ireland. There are two roles. The agent space role is what the agent assumes to read your resources, and its trust policy is pinned to your account and to agent spaces in your account. A separate operator app role, with the AIDevOpsOperatorAppAccessPolicy managed policy, gives people access to the web app. The first block creates the agent space role and an agent space.

# 1. The agent space role. The trust policy is what stops a confused deputy:
#    only an agent space in YOUR account may assume it.
cat > devops-agentspace-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "aidevops.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "<MONITORING_ACCOUNT_ID>" },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:<REGION>:<MONITORING_ACCOUNT_ID>:agentspace/*"
        }
      }
    }
  ]
}
EOF

aws iam create-role --region <REGION> \
  --role-name DevOpsAgentRole-AgentSpace \
  --assume-role-policy-document file://devops-agentspace-trust-policy.json

# AWS-managed policy. Start here, then narrow it for production.
aws iam attach-role-policy \
  --role-name DevOpsAgentRole-AgentSpace \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy

# 2. One agent space per application, not one per company.
aws devops-agent create-agent-space \
  --name "checkout-service" \
  --description "AgentSpace for the checkout service" \
  --region <REGION>

# 3. Associate the account. "monitor" = the account that hosts the agent
#    and is used for topology discovery. Extra accounts use "source".
aws devops-agent associate-service \
  --agent-space-id <AGENT_SPACE_ID> \
  --service-id aws \
  --configuration '{
    "aws": {
      "assumableRoleArn": "arn:aws:iam::<MONITORING_ACCOUNT_ID>:role/DevOpsAgentRole-AgentSpace",
      "accountId": "<MONITORING_ACCOUNT_ID>",
      "accountType": "monitor"
    }
  }' \
  --region <REGION>

Skills and triggers are where your own runbooks enter. A skill is a SKILL.md the agent loads when relevant. The GA announcement says skills can target On-demand, Incident Triage, Incident RCA, Incident Mitigation or Evaluation agents, and the guide's example uses the generic agent type. The second block shows the guide's own skill and daily trigger.

# A skill the agent loads when relevant. Procedures live here, not in a prompt.
aws devops-agent create-asset \
  --agent-space-id <AGENT_SPACE_ID> \
  --asset-type skill \
  --metadata '{"name":"rds-performance-investigation","description":"Investigation procedures for RDS performance issues.","agent_types":["GENERIC"]}' \
  --content '{"file":{"path":"SKILL.md","body":{"text":"# RDS Performance Investigation\nUse this skill when investigating database latency, connection errors, or query timeouts."}}}' \
  --region <REGION>

# A time-based trigger that runs a custom agent daily. Pause it with
# update-trigger --status Inactive instead of deleting it.
aws devops-agent create-trigger \
  --agent-space-id <AGENT_SPACE_ID> \
  --type TIME_BASED \
  --condition '{"schedule":{"expression":"rate(1 day)"}}' \
  --action '{"actionType":"create:task","task":{"agent":"custom:<CUSTOM_AGENT_ASSET_ID>"}}' \
  --status Active \
  --region <REGION>

Third-party sources work the same way. Registering Dynatrace, Splunk, New Relic or Datadog and then calling associate-service returns webhook information you can point their alerting at, whereas GitHub and Datadog must first be registered through the console OAuth flow. Turn on the APPLICATION_LOGS vended log type early: it records events such as an inbound event dropped, a third-party provider call failed and webhook validation fails, which are exactly the silent failures of an alert pipeline.

What it bills for, and the arithmetic

Billing is $0.0083 per agent-second for investigations, evaluations and on-demand SRE tasks. The pricing page defines agent time as the cumulative time the agent spends actively working across all activities for a task, and says there is no charge while it is idle or waiting. That is $0.498 per agent-minute, so an 8-minute investigation is about $3.98. The table reproduces the pricing page's own examples; the 8-minute duration is AWS's assumption, not a measurement.

Two offsets exist. New customers get a 2-month free trial, each month covering up to 10 agent spaces, 20 hours of investigations, 15 hours of evaluations and 20 hours of on-demand tasks. Customers on paid AWS Support plans get monthly credits calculated from the prior month's Support charge: 100% for Unified Operations, 75% for Enterprise Support and 30% for Business Support+. The credits expire at the end of each month, so they are a discount, not a balance.

Read the last sentence of the pricing page before budgeting: other AWS services the agent queries, such as CloudWatch Logs Insights queries or trace retrievals, are billed by those services at their standard rates. The agent-second rate is therefore a floor on what an investigation costs, and the bigger the log group it scans, the less that floor says.

A daily budget alarm, because I found no spend cap

I found no setting that caps monthly agent time in the pricing page or the guide pages I read, and billing is by duration, so a noisy alarm that triggers long investigations is the way to a surprise invoice. The service publishes its own CloudWatch metrics, which is enough to build a guardrail. The guide's own example alarms on ConsumedOnDemandTime with the Sum statistic, a 1 day period and a threshold of 36000 seconds, which is 10 hours or $298.80. The block below applies the same idea to investigations; the 9600 second threshold is my example, 20 investigations of 8 minutes, not a recommendation.

# metrics.json: a daily budget alarm over ConsumedInvestigationTime.
# Metric math alarms cannot use SEARCH(), so list each agent space explicitly.
# FILL(..., 0) stops a quiet space from turning the sum into "no data".
[
  {
    "Id": "space1",
    "MetricStat": {
      "Metric": {
        "Namespace": "AWS/AIDevOps",
        "MetricName": "ConsumedInvestigationTime",
        "Dimensions": [{ "Name": "AgentSpaceUUID", "Value": "<SPACE_1_UUID>" }]
      },
      "Period": 86400,
      "Stat": "Sum"
    },
    "ReturnData": false
  },
  {
    "Id": "space2",
    "MetricStat": {
      "Metric": {
        "Namespace": "AWS/AIDevOps",
        "MetricName": "ConsumedInvestigationTime",
        "Dimensions": [{ "Name": "AgentSpaceUUID", "Value": "<SPACE_2_UUID>" }]
      },
      "Period": 86400,
      "Stat": "Sum"
    },
    "ReturnData": false
  },
  {
    "Id": "total",
    "Expression": "FILL(space1, 0) + FILL(space2, 0)",
    "Label": "Investigation seconds per day",
    "ReturnData": true
  }
]

# 9600 seconds = 20 investigations of 8 minutes = about $79.68 at $0.0083/s.
aws cloudwatch put-metric-alarm \
  --alarm-name devops-agent-daily-investigation-budget \
  --metrics file://metrics.json \
  --comparison-operator GreaterThanThreshold \
  --threshold 9600 \
  --evaluation-periods 1 \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:<REGION>:<MONITORING_ACCOUNT_ID>:finops-alerts

All metrics live in the AWS/AIDevOps namespace with one dimension, AgentSpaceUUID, and a query without that dimension returns no data points. They are published every 5 minutes except the topology metric. Metrics count seconds, not dollars, so multiply by 0.0083 yourself.

One trap from the guide: agent spaces created before 13 March 2026 do not get these metrics until you create the AWSServiceRoleForAIDevOps service-linked role yourself with aws iam create-service-linked-role and the service name aidevops.amazonaws.com. Newer spaces get it automatically. And because the metrics cover agent time only, they will not warn you about the CloudWatch query charges from the previous section.

Sanity-checking the 94% root cause accuracy

The GA announcement attributes up to 75% lower MTTR, 80% faster investigations, 94% root cause accuracy and 3 to 5x faster incident resolution to customers and partners in preview. It does not say how they were measured: not the number of incidents, not who judged a root cause correct, not whether a root cause that needed human steering still counted. The two customer stories are single incidents. Western Governors University went from an estimated two hours to 28 minutes, which AWS calls a 77% improvement, and Zenchef from an estimated 1 to 2 hours to 20 to 30 minutes. In both, the baseline is an estimate.

That does not make the claims false. It means they cannot be compared with a number from your system until you have one. The product gives you the means: after an investigation you can add feedback with a required verdict, the actual root cause if the agent was wrong, whether steering was needed, and whether the mitigation was correct. You can also ask the agent in chat to summarise your feedback history, and it reports a count, an accuracy percentage and a breakdown by verdict. Marking an investigation incorrect with the true cause also writes a memory so the same alarm is less likely to repeat the mistake.

// Wilson score interval for "k root causes judged correct out of n".
// The point estimate hides how little n tells you.
function wilson(k, n, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const margin = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [centre - margin, centre + margin];
}

wilson(18, 20);   // 90% observed  -> about 0.70 to 0.97
wilson(47, 50);   // 94% observed  -> about 0.84 to 0.98
wilson(94, 100);  // 94% observed  -> about 0.88 to 0.97

The catch is sample size. A percentage from 20 reviewed investigations is wide. By the Wilson score interval, 18 of 20 correct is 90% observed but plausibly anywhere from about 70% to 97%, and even 94 of 100 spans about 88% to 97%. That arithmetic is mine, not AWS's, but it shows why a team of 10 incidents cannot confirm or refute a headline number. Track steering separately from correctness, because an answer that was right only after you nudged it is a different product from one that was right alone.

Where it can cost you, and where it can mislead

The failure mode I would plan for first is not a wrong answer but a confident answer built on a topology that does not match reality. Four constraints come straight from the documentation and Versent's test.

• Environment shape drives quality. In Versent's preview test across multiple accounts with hundreds of services, the agent inferred workload structure from naming conventions, and consistent naming helped. Their summary was garbage in, garbage out.
• Triage can merge unrelated incidents. A wrong link means one investigation carries two problems until a human unlinks it, and the look-back window is typically 20 minutes.
• Cost follows duration, not incident count. Ten short investigations can cost less than one that wanders, and I found no hard cap, only the alarm above.
• Escalation shares data. Ask for human support passes the investigation timeline, affected resources, relevant metrics, logs and traces, recent changes and remediation attempts to AWS Support. Basic Support cannot create technical cases, and Developer Support can create them but must use the Support Center to correspond.

A caution on dates: Versent's testing was on the preview, before the triage stage, skills and code indexing that the GA announcement lists, so its findings are a prior, not a verdict. Retest on your own estate.

What to do on Monday

Treat the free trial as an experiment with a stop rule rather than a rollout. The aim is twenty reviewed investigations and a decision, not a dashboard.

1. Pick one well-structured application, preferably in a non-production account, and create one agent space for it with the managed AIDevOpsAgentAccessPolicy role.
2. Connect the alert source you already page on, a PagerDuty or Grafana webhook or ServiceNow, and enable APPLICATION_LOGS delivery so dropped events and webhook validation failures are visible.
3. Create the daily budget alarm before the first real investigation, sized to the trial limits you intend to stay inside.
4. Replay recent, already-solved incidents by starting investigations manually; the dialog lets you adjust the date and time of the incident. Add feedback with a verdict on every one, and record whether steering was needed.
5. After about twenty reviewed investigations, compute the interval and decide. Check at the same time whether your Support plan's credit percentage covers the projected agent time.

If the lower bound of your interval is lower than the accuracy you would accept from a junior on-call engineer, you have your answer: use it for triage and evidence gathering, and keep the root cause call with a human.

The rule I would carry out of this: price an AI SRE by agent time you can alarm on, and judge it by a verdict you recorded yourself. AWS DevOps Agent makes both possible, through per-second billing, CloudWatch metrics and a feedback form, but it ships neither a spend cap nor your accuracy number, so you build the first and earn the second.