AWS DevOps Agent: what it costs a small team, and what it does.

What is AWS DevOps Agent, in plain words?

It is an AI on-call helper. When an alarm fires, it reads your metrics, logs, traces, recent deploys and code changes, works out what probably broke, and writes up the root cause with suggested steps to fix it. You can also chat with it about your environment and schedule small recurring jobs, like a daily database health report.

AWS calls it a "frontier agent". It was announced in preview in December 2025, free and only in US East (N. Virginia). It became generally available on 31 March 2026, and AWS started charging for it on 10 April 2026. On the day we checked, the docs list 15 Regions, including us-east-1, us-east-2, us-west-2, eu-west-1, eu-central-1 and eu-west-2.

There are two halves to the product:

• Production operations (generally available, paid): incident investigations, "evaluations" that look across past incidents for things to improve, and on-demand tasks such as chat and custom scheduled agents.
• Release management (preview since 17 June 2026, free during preview, us-east-1 only): it reviews pull requests for release readiness and generates tests for a change.

What it does well.

• The first 20 minutes of an incident. Matching "errors went up" to "this deploy went out" is tedious, and it's what the agent does first. Whoever picks up the page starts from a summary, not a blank dashboard.
• Working across your tools. Built-in integrations cover CloudWatch, Datadog, Dynatrace, New Relic, Splunk, Grafana and Prometheus for telemetry (how those monitoring tools compare); GitHub, GitLab and Azure DevOps for code and pipelines; Slack, PagerDuty and ServiceNow for where findings land. Anything else connects through an MCP server or a webhook.
• Mitigation plans you can review. After a root cause, it can generate a step-by-step plan in four phases (prepare, pre-validate, apply, post-validate) with suggested commands or infrastructure-as-code changes. It can also hand a spec to a coding agent.
• Staying read-only by default. The default role uses the AIDevOpsAgentAccessPolicy managed policy, which is read-only. Every step is logged in a journal and in CloudTrail.

What it does not replace.

The agent is a good investigator. It is not an owner. Someone still has to be responsible for production, and that's the part small teams most often lack. To be fair, AWS doesn't claim it does these jobs.

• Someone who owns production. A root cause is only useful if a person decides what to do, applies the fix and checks it worked. The agent proposes, people decide.
• On-call decisions. Rolling back, failing over, telling customers, waking someone up at 3am: those are judgement calls with business context the agent doesn't have.
• Infrastructure as code. It can suggest a Terraform or CloudFormation change. It won't design your network, environments and permissions, or keep them tidy over time.
• Patching and upgrades. Database engine versions, base images, Kubernetes versions and dependency updates still need a schedule and someone to run it.
• Backups and restore tests. It can tell you a database is unhealthy. It won't prove you can restore yesterday's snapshot; a quarterly restore test does.
• Good alarms. If nothing alerts, or logs are missing, there's little to investigate.

The basics behind all of this are in our DevOps for startups guide and the production readiness checklist.

Setup checklist for a small AWS account.

1. Pick the Region. Create the Agent Space in a supported Region close to your workloads. Its data is stored in that Region.
2. Create one Agent Space for production. An Agent Space is the boundary of what the agent can see: accounts, integrations and who can use it.
3. Let it create the two IAM roles. One is the role the agent assumes to read your resources; the other controls what people can do in the agent's web app. The auto-created agent role is read-only. Only add permissions you've thought about.
4. Check your SCPs if you use AWS Organizations. Investigations fail quietly if a service control policy blocks aidevops:* or bedrock:InvokeModel.
5. Tag your resources or use CloudFormation stacks, so the agent can map your application.
6. Make sure CloudTrail and CloudWatch are on, with log retention set, and ideally traces from OpenTelemetry. That's the minimum it needs to be useful.
7. Connect GitHub or GitLab so it can see what changed. OAuth tools are registered once per account, then attached to each space.
8. Connect Slack or PagerDuty so findings land where your team already looks.
9. Wire only your important alarms to trigger investigations, then set an AWS Budgets alert on the service so a noisy week doesn't surprise you.

If your account basics aren't in place yet (separate accounts, SSO, CloudTrail), start with AWS for startups.

Is AWS DevOps Agent worth it for a 2 to 15 engineer startup?

Usually yes to the trial, and then it depends on who's on call. At under $100 in a normal month the price is rarely the issue. The question is whether someone will act on what it finds.

It's worth it when you have paying customers and real alerts, engineers take turns on call without a platform specialist, incidents cross several services or tools, or you already use Datadog, Grafana or Splunk and want one place that reads them all. If the Datadog bill itself is the problem, see how to cut a Datadog bill.

It's not worth it yet when you have one service and few incidents, there's no alerting or logging to read, or nobody owns production and you hope the agent will. In the first two cases, Amazon CloudWatch investigations, which AWS offers at no extra cost inside AWS, may be enough. In the last, you get good reports nobody acts on.

For a team without a DevOps person, the agent fits well next to managed DevOps: it speeds up the investigation, and a named owner handles the fix, the follow-up and the boring work in between.