Part 1 of 4. Overview · Setup · EC2 · Network · RDS
AWS DevOps Agent is an AI agent that investigates operational incidents in your AWS (and multicloud) environment. Before it can investigate anything, you need to give it a scope. That scope is called an Agent Space.
This post covers the setup I went through in the AWS DevOps Agent Workshop for Incident Investigation. It takes about 5 minutes.
What is an Agent Space?
An Agent Space is a logical container that defines:
- what the agent can see, meaning which AWS accounts, telemetry tools, repositories and pipelines
- what the agent can do, meaning read-only investigation, plus optional write actions that need your approval
- who can use it, through the web app that your operators work in
You can have several Agent Spaces, for example one per product team or per environment.
Step 1: Open the service
In the AWS Console (region us-east-1), search for DevOps Agent and click Begin setup.
The left nav has two items: Agent Spaces and Capability Providers. Capability providers are registered at the account level and then attached to individual spaces.
Step 2: Create the Agent Space
The form has five sections:
| Section | What I chose | Why it matters |
|---|---|---|
| Agent Space details | Name enterprise-workshop-space, description |
Shown to your operators in the web app |
| AWS resource access | Auto-create a new DevOps Agent role | The read role the agent uses to investigate the primary account |
| Agent Actions | Enabled, auto-create role | A separate role for write actions. "Every change requires your explicit approval before it runs." |
| Tags | none | Optional |
| Enable web app | Auto-create a new DevOps Agent role | The role behind the operator web UI |
For each role you get three options: auto-create, assign an existing role, or create one from a policy template. In production you'll likely want the template option so the role goes through your normal IAM review.
There's also an optional Agent response language setting. Findings and investigation output can come back in 17 languages:
Click Create.
Step 3: The agent starts mapping your environment
Right after creation, the banner says "DevOps Agent is Mapping entities: Analyzing resources and their relationships." By default the agent builds a topology of resources managed by CloudFormation, or of resources that carry tags you specify. That topology grows as it:
- runs investigations
- learns from what you tell it in the web app
- gets new capabilities
This topology is what lets it work out later that "this alarm is on this ASG, which is behind this target group, which belongs to this stack".
The space page has tabs for Capabilities, Access, Configuration, Summary report and Environments. On the Capabilities tab, the Primary source account shows both a read-role status and an Actions role status. Both should say Valid.
Step 4: Explore the capabilities
This is where the agent gets more than a basic CloudWatch reader. Each capability type adds a new data source or a new way to interact:
| Capability | What it adds |
|---|---|
| Cloud | Secondary AWS accounts for cross-account investigations, and Azure |
| Sandbox (Preview) | Controls outbound network access and pre-installed packages for the agent's sandbox |
| Telemetry | Dynatrace, Datadog, New Relic, Splunk, Grafana |
| Pipeline | GitHub, GitLab, Azure DevOps, so the agent can link incidents to code changes |
| Communications | Slack, ServiceNow, PagerDuty (with bidirectional support) |
| MCP Server | Any MCP server (OAuth 3LO, client credentials, or API key) |
| Remote Agent | Other agents over the A2A protocol |
| Webhooks | Let third-party systems start investigations (HMAC or API-key auth) |
The Capability Providers page shows the full list. 14 of 17 were available to register in my account:
💡 The MCP and A2A options stood out to me. You can plug in your own internal tooling (a runbook service, a CMDB, a home-grown deploy tool) without waiting for AWS to build a native integration.
Step 5: Open the web app
The console is for admin tasks: creating spaces, wiring integrations and managing permissions. Day-to-day incident work happens in the web app, which you open with Launch via IAM (the workshop calls this Operator access).
The web app gives you:
- a chat with prompts such as "Give me a health summary" (with a Balanced mode selector)
- Incidents, the investigation dashboard
- Improvements, proactive recommendations
- Releases (Preview), release-readiness checks on code changes
- Artifacts and Topology
- Agents, Knowledge and Settings
The Incident Response Dashboard is where you start investigations. It also shows an Investigation hours used counter, which is worth watching from a cost point of view:
Checklist
By the end of setup you should have:
- ✅ An Agent Space with primary account status Valid
- ✅ The Actions role Valid, if you enabled Agent Actions
- ✅ The web app opening through Launch via IAM
- ✅ An empty Incident Response Dashboard, ready for the first incident
In Part 2 I break something on purpose: an Auto Scaling Group at 100% CPU that doesn't scale. Then I let the agent work out why.
Top comments (0)