Hello guys
I've been hearing about AWS DevOps Agent for a while now, kept seeing it pop up in AWS blog posts and re:Invent announcements. Finally decided to just sit down and try it out myself last night.
What is AWS DevOps Agent?
So basically it's an AI-powered SRE teammate that AWS built on top of Amazon Bedrock. The idea is simple - when something breaks in your AWS environment, instead of you waking up at 2AM and manually digging through CloudWatch logs, DynamoDB metrics, Lambda errors... the agent does it for you automatically.
It connects to your alarms, your code repos, your ticketing system, and investigates the root cause on its own. Then posts the findings to Slack or wherever you work.
The main use cases I found interesting:
- Autonomous incident response - alarm fires → agent investigates → posts RCA with fix recommendations, all in under 5 minutes
- Release readiness - checks your PRs for breaking changes before merge
- Proactive reliability - analyzes past incidents and recommends improvements
Setup
First I provisioned a sample environment using Terraform - a classic URL shortener app with Lambda, DynamoDB, API Gateway, and CloudWatch alarms.
Then I went to the AWS Console → AWS DevOps Agent → Create Agent Space. The console is straightforward, took maybe 5 minutes.
The thing I actually like
One thing that stood out to me - the permission model.
When I use Kiro (the AI coding agent), it runs under my IAM role. That means it inherits all my permissions. Some companies don't allow you to create separate roles for tools like that, so Kiro ends up with whatever access you have. That always felt a bit risky to me.
With AWS DevOps Agent, it creates its own dedicated IAM role with least-privilege permissions scoped specifically for investigation tasks. You get three options when setting it up:
I picked Auto-create a new DevOps Agent role - easiest option, it creates
DevOpsAgentRole-AgentSpace-* automatically with just the permissions it needs. The agent can only read what it needs - CloudWatch, Lambda configs, DynamoDB metadata - it can't go rogue and do destructive things.For companies with strict IAM policies, this is actually a big deal.
Configuration
The Agent Space has a Capabilities tab where you connect different data sources. The primary AWS account connected and showed Valid right away:
Other sections you can add:
- Telemetry - Datadog, Dynatrace (optional)
- Pipeline - GitHub, GitLab (optional, helps correlate deployments with incidents)
- Communications - Slack, ServiceNow (optional, for auto-posting findings)
- MCP Server - custom tools (optional)
For this test I only needed Cloud since CloudWatch is built-in via the primary account connection.
Triggering a test investigation
Once the agent finished mapping my resources, I manually set a CloudWatch alarm to ALARM state:
1
2
3
4
5
aws cloudwatch set-alarm-state \
--alarm-name devops-agent-demo-dynamo-throttles \
--state-value ALARM \
--state-reason "Manual test for DevOps Agent learning" \
--region us-east-1Then clicked Operator access to open the Web App. I asked it for a health summary first:
The agent picked up all 4 alarms I created - DynamoDB throttle (ALARM), API Gateway 5xx, and both Lambda error alarms (INSUFFICIENT_DATA since no traffic yet). It even knew the DynamoDB alarm was a manual test because the actual metrics showed zero real throttle events.
The Key Takeaways section was the most impressive part. It said:
"This looks like a newly provisioned demo environment. The DynamoDB alarm showing ALARM state was manually triggered for testing - actual metrics show zero throttle events."
It used 15 tools and 1 agent to produce that summary. It checked CloudWatch metrics, Lambda invocation history, DynamoDB actual usage, and AWS Health events - all automatically.
Honest thoughts
The mapping phase takes time - when I first created the Agent Space it showed "0 relationships mapped" and was still analyzing. So if you fire an alarm too early before the agent finishes mapping your topology, it won't auto-trigger an investigation. You have to ask it directly in the chat.
Also the real value comes when you connect multiple accounts as secondary sources so the agent has full visibility across your org. Single account is good for learning but production setups will want cross-account visibility.
But even with a minimal single-account setup, the health summary and observability gap analysis were genuinely useful. It correctly identified the infrastructure, understood the alarm state context, and gave actionable findings - all without me explaining anything about my setup.
What's next
I want to try:
- Connecting a GitHub repo as a Pipeline source so the agent can correlate code deployments with incidents
- Setting up a real alarm trigger flow with the investigation auto-starting
- Testing the cross-account monitoring with a service account
If you're curious about AWS DevOps Agent, the best way to start is just provision a simple serverless app with some CloudWatch alarms and create an Agent Space pointing at that account. Takes maybe 30 minutes total.
That's it for now. Will write more as I explore further.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article