惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 三生石上(FineUI控件)
月光博客
月光博客
S
SegmentFault 最新的问题
有赞技术团队
有赞技术团队
Stack Overflow Blog
Stack Overflow Blog
Engineering at Meta
Engineering at Meta
T
The Blog of Author Tim Ferriss
The GitHub Blog
The GitHub Blog
小众软件
小众软件
Hugging Face - Blog
Hugging Face - Blog
IT之家
IT之家
宝玉的分享
宝玉的分享
A
About on SuperTechFans
Vercel News
Vercel News
P
Proofpoint News Feed
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
博客园 - 【当耐特】
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
V
Visual Studio Blog
Jina AI
Jina AI
Y
Y Combinator Blog
T
Tailwind CSS Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Last Week in AI
Last Week in AI

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
AWS DevOps Agent: Worth It?
JASON WOOD · 2026-05-07 · via DEV Community

AWS DevOps Agent: Worth It?

AWS DevOps Agent is now GA — and it’s in Sydney!

At AWS re:Invent 2025, AWS introduced DevOps Agent as a service designed to be “your always-available operations teammate that resolves and proactively prevents incidents, optimizes application reliability and performance, and handles on-demand SRE tasks.” With general availability, AWS has expanded beyond the initial preview, adding support for more real-world scenarios including hybrid, on-premises, and multi-cloud environments.

Once enabled, DevOps Agent begins by learning your environment: your resources, configurations, and telemetry. From there, it can detect issues, investigate what’s happening, and suggest likely root causes. By the time a human operator steps in, a large portion of the initial triage may already be done.

That sounds pretty awesome… but also a little bit scary.

So, what’s it actually like to use in practice — and what does it cost?


What is AWS DevOps Agent?

AWS DevOps Agent isn’t just a simple AI tool. It’s what AWS refers to as a frontier agent: an autonomous system designed to operate independently, scale as needed, and run with minimal human oversight.

It is designed to help teams investigate incidents, identify root causes, and prevent recurrence by analysing signals across your environment. To do this, it pulls together data from services like Amazon CloudWatch, AWS Systems Manager, and resource APIs to build a picture of what’s happening when something goes wrong.

According to AWS, DevOps Agent works by:

  • Learning your resources and their relationships
  • Integrating with your observability tools, code repositories, and CI/CD pipelines
  • Correlating telemetry, code, and deployment data to understand how your application behaves
  • Supporting applications across multi-cloud and hybrid environments

Core capabilities

There are three key areas that DevOps Agent focuses on:

Incident investigation

DevOps Agent can take a natural language prompt and begin investigating issues immediately. Instead of manually jumping between metrics, logs, and dashboards, it gathers relevant data and presents a summary of what it believes is happening.

In practice, this means pulling:

  • Metrics from CloudWatch
  • Logs from CloudWatch Logs
  • Recent changes or events
  • Resource configuration details

All of this gets stitched together into a single story.


Root cause analysis

Once it has the data, the agent attempts to correlate signals and identify likely root causes. This is where things get interesting — it’s effectively doing the “join the dots” work that operators normally do manually.

Rather than just showing symptoms, it aims to answer a much more useful question:

What actually caused this?


Recommendations and remediation guidance

Finally, DevOps Agent suggests possible next steps. These might include configuration changes, scaling actions, or further investigation paths.

It’s important to note that, at least in its current form, this is primarily advisory. It helps you understand and decide. DevOps Agent isn’t making changes for you. A human still needs to do that side.


What’s it actually like?

My colleague Tony and his customer both attended AWS re:Invent 2025 and drank the DevOps Agent cool-aid. While I’ve only played with it in my own environment, he was able to put the preview through its paces in a real-world setting.

When you configure DevOps Agent, you start with an Agent Space. This defines the boundary of what the agent can see and interact with, and it’s not restricted to a single account within your Organisation.

Tony tested this in a development environment that spanned multiple accounts and included hundreds of services, Lambda functions, and supporting resources. Quite impressively, the agent was able to map out the services and their interconnectivity across the environment. With that many components, this process took some time, and the resulting view was understandably complex.

AWS recommends using Agent Spaces to represent smaller, application-focused environments. In practice, that makes a lot of sense. Smaller, more targeted spaces provide clearer visibility and allow the agent to focus more effectively. Or more accurately, they make it easier for the human operator to interpret what’s going on.

Tony has pointed out that having too many Agent Spaces isn't ideal, either. If you have similarly architected environments, grouping them into a single Agent Space may make management easier.

One thing that stood out was the agent’s ability to infer workload structure based on naming conventions. Tony’s team follows consistent, well-structured naming practices for Lambda functions and other resources, which helped the agent quickly establish relationships and understand how components were expected to interact.

It’s a good reminder of the old rule: garbage in, garbage out. The better your environment is structured, the better the results you’ll get from tools like this.

While DevOps Agent can integrate with tools like Slack and ServiceNow, it currently doesn’t make changes within your AWS environment. It operates in a read-only, advisory capacity.

In a world where AI is still finding its place in production environments, that’s a reassuring design choice. The agent can investigate, analyse, and recommend — but the final decision, and the execution, still sits firmly with a human.


What does it cost?

For you? I’ll give you a couple of months free! (Well, AWS will.)

At the time of writing, AWS provides a free tier for the first two months:

“Each trial month includes up to 10 agent spaces, 20 hours of investigations (incident response), 15 hours of evaluations (incident prevention), and 20 hours of on-demand SRE tasks (chat). Standard pay-as-you-go pricing applies for usage beyond these limits and after your trial ends.”

The included amounts give you a great opportunity to try out AWS DevOps Agent. You can then review what your spend would have been and decide if it works for you.

One of the more interesting aspects — and something I haven’t really seen before — is a discount for those on AWS Support contracts. The What’s New post states:

AWS Support customers receive monthly DevOps Agent credits based on the prior month's gross AWS Support spend: 100% for Unified Operations, 75% for Enterprise Support, or 30% for Business Support+.

Outside of the free tier or support discounts, the costs for DevOps Agent are:

  • $0.0083 per agent-second for investigations (incident response)
  • $0.0083 per agent-second for evaluations (incident prevention)
  • $0.0083 per agent-second for on-demand SRE tasks (chat)

This “agent-second” model reflects the time the agent spends analysing, correlating, and generating responses. It’s a slightly different way of thinking about cost compared to typical request-based pricing.

You’ll also want to consider any underlying costs from services like Amazon CloudWatch, especially if large volumes of logs or metrics are queried as part of the investigation.


What’s next?

What now? Well, you’ve got two free months, so give it a go!

I’d recommend keeping your Agent Space targeted. Focus on a single application, ideally one that’s well structured. When you’re trialling the service, you want to see what it can do at its best.

Then try a second Agent Space with something a bit messier. I don't want you to be discouraged by results that aren't great due to the environment. It's sort of like doing a Well Architected review of your entire environment rather than the workload it's designed for. You'll likely get something useful, but not optimal.

This service doesn’t replace your ops team — it enhances them. It reduces the time spent gathering and correlating data, but the judgment, context, and decision-making still sit with your engineer.