2.3.4. AI-Assisted Operations: AWS DevOps Agent and Kiro
💡 First Principle: An alarm tells you that something is wrong; an investigation tells you why. The slow part of most incidents is not the fix but the search — correlating metrics, logs, recent deployments and dependencies across several accounts. AWS DevOps Agent automates that search and proposes a fix, but it is built so that investigating is autonomous while changing things is not: reading is on by default, and every change needs explicit opt-in plus a human approval for that specific action. Hold onto that split and most scenarios about the service answer themselves.
The SOA-C03 exam guide (v1.1) names AWS DevOps Agent and Kiro alongside CloudWatch, Lambda and Systems Manager as tools for analyzing performance metrics and automating remediation. They do not replace the deterministic trigger → route → act loop from the previous three sections. DevOps Agent shortens the diagnose step; Kiro is the AI coding agent an operator uses to write and change the scripts, templates and code that the loop runs on.
AWS DevOps Agent Building Blocks:
| Concept | What It Is | Why an Operator Cares |
|---|---|---|
| Agent Space | A logical container that defines which AWS accounts, third-party tools and users the agent can reach. Each one is an independent deployment | It is the investigation boundary. Investigation data, incident history and chat are isolated per Agent Space, so teams or prod/non-prod can be separated |
| Primary and secondary accounts | The account that holds the Agent Space, plus other accounts connected through IAM roles | An application spread across accounts needs every account connected, or the agent cannot see those resources |
| Topology | An automatically discovered map of applications, services, resources and their relationships | Context for investigations. It is not a permission boundary — IAM policies on the agent's roles are the only way to limit what it can read |
| Two consoles | Administrators use the AWS Management Console to create Agent Spaces, integrations and access. Operators use the Agent Space web app | The web app is where investigations, chat, the Topology page and the Improvements page live |
| Skills | Reusable Markdown instruction sets (a SKILL.md plus optional references) | Encode your runbooks and triage rules once instead of repeating them in chat |
An Agent Space created in one supported Region can investigate resources in all Regions of the accounts associated with it, so you do not need an Agent Space per Region.
How an Investigation Starts:
| Trigger | Example |
|---|---|
| Built-in integration | A ServiceNow incident ticket (the agent posts findings, root cause and mitigation plan back into the ticket), or a Dynatrace Workflow |
| Webhook | PagerDuty incidents, Grafana alerts, or any in-house tool posting to a generic webhook (HMAC or API-key authentication; each Agent Space can have one of each) |
| Manual | An operator describes the problem in the web app, or picks a starting point such as Latest alarm, High CPU usage or Error rate spike |
Before an alert becomes an investigation, a triage stage compares it with active investigations inside a look-back window (typically 20 minutes). The outcome is Linked (added to an existing investigation), Skipped (matches skip criteria defined in a skill) or Proceed (new investigation). Operators can unlink or unskip a decision in the web app.
What the Agent Reads: CloudWatch is a built-in integration that needs no extra setup — the agent reads CloudWatch telemetry through the IAM roles you supplied for the primary and secondary accounts. Reading S3 objects (for example, logs stored in a bucket) requires adding s3:GetObject and s3:ListBucket to the agent's role. Datadog, Dynatrace, Grafana, New Relic and Splunk connect as telemetry sources; GitHub, GitLab and Azure DevOps supply code and pipeline history; ServiceNow, PagerDuty and Slack carry the conversation. Anything else (Prometheus metrics, for example) connects through a webhook or an MCP server.
The default investigation role uses the AIDevOpsAgentAccessPolicy managed policy, which is read-only. On top of your role, the service applies a session-policy guardrail: the agent's effective permissions are the intersection of your role policies and that guardrail, so granting a permission the guardrail does not include has no effect.
Investigate vs. Act:
| Mode | Default | What Must Be in Place | Human Step |
|---|---|---|---|
| Read-only actions (describe resources, query metrics and logs) | On | The investigation role | None |
| Directed actions (create or modify a resource) | Off | 1. Directed actions enabled on the Agent Space. 2. An elevated IAM role registered for each account, trusting aidevops.amazonaws.com for sts:AssumeRole, sts:SetSourceIdentity and sts:TagSession. 3. For third-party tools, the tool classified or enabled as MUTATIVE | An operator approves each action in chat |
| Refused regardless of permissions | — | Deleting resources, setting or removing IAM permissions boundaries, and (by default) operations that pass an IAM role | Cannot be approved — the operator does it with their own credentials |
Four details carry most of the exam weight:
- Approval requests appear only in chat. If the agent tries a mutating tool during an autonomous investigation, the call fails rather than waiting for approval. Without directed actions, the agent still investigates and hands you manual remediation steps.
- Credentials are scoped per approval. The agent assumes the elevated role with a session policy limited to the approved operation and resource, valid for a bounded window. The role's policy is only the ceiling; tighten it with a customer-managed policy, SCPs or a permissions boundary.
- Every action is attributable. The API call appears in CloudTrail with a source identity naming the approving operator.
- Mitigation is proposed, then chosen. After root cause analysis, the agent presents inline mitigation proposals (action, expected outcome, prerequisites) that you review, refine and decide whether to apply.
Proactive Incident Prevention: On the Improvements page, the agent evaluates recent investigations (weekly by default, or on demand with Run Now) and recommends fixes in four categories: Observability, Infrastructure, Governance and Code optimization. A recommendation that involves code carries an agent-ready specification that can be handed to a coding agent such as Kiro. When the agent needs people, Ask for human support opens an AWS Support case that carries the investigation's context (not available on the Basic Support plan).
Monitoring the Agent Itself: AWS DevOps Agent publishes CloudWatch metrics in the AWS/AIDevOps namespace (per Agent Space) that measure consumption — for example ConsumedInvestigationTime and ConsumedChatRequests — so you can alarm on usage. Its vended logs (delivered to CloudWatch Logs, S3 or Data Firehose) record operational events such as an inbound alert that was received or dropped before processing, which is where to look when a webhook alert never became an investigation. Investigation outcomes themselves are published as EventBridge events (see 4.2.2).
Kiro in an Operator's Workflow:
Kiro is an AI coding agent available as an IDE, a CLI (kiro-cli) and a web app. For an operator, it is where runbooks, CloudFormation templates, Lambda remediation code and scripts get written and changed.
| Kiro Feature | What It Is | Operations Use |
|---|---|---|
| Specs | requirements.md (or bugfix.md for bugs), design.md and tasks.md, produced in a requirements → design → tasks workflow | Turn a DevOps Agent recommendation into a reviewed plan before any template or code changes |
| Steering | Markdown files that give Kiro persistent project knowledge — workspace scope in .kiro/steering/, global scope in ~/.kiro/steering/ (workspace wins on conflict). Inclusion modes: always (default), fileMatch, manual and auto (loaded when the request matches the file's description). AGENTS.md is also read | Record standards once: required tags, "all infrastructure changes go through CloudFormation", naming rules |
| Hooks | JSON files in .kiro/hooks/ that run a shell command or inject an agent prompt when an event fires. Pre Tool Use and Prompt Submit can block; Post Tool Use and Agent Stop cannot | Run a template linter after the agent edits a file, or block a tool call until a precondition is met |
Built-in aws tool | Makes AWS CLI calls (alias use_aws). toolsSettings.aws supports allowedServices, deniedServices and autoAllowReadonly. Shell, write and AWS calls prompt for permission by default | Let read-only calls run without prompts while mutating calls still ask, and keep whole services off-limits |
| Headless CLI | kiro-cli chat --no-interactive authenticated with KIRO_API_KEY; --trust-tools or --trust-all-tools pre-grants tools because nobody is there to approve | Run a scripted review or troubleshooting prompt inside a CI/CD pipeline |
| MCP | Connects Kiro to MCP servers, such as the AWS Documentation MCP server | Bring documentation and internal tools into the session |
⚠️ Exam Trap: AWS DevOps Agent does not change your environment on its own. Directed actions are off by default, need an elevated role and an approval for each action in chat, and are never used for deletes. If a scenario demands remediation with no human in the loop (close the public S3 bucket within minutes, restart the failed service), the answer is still the deterministic path — EventBridge or a Config rule driving Systems Manager Automation or Lambda. DevOps Agent is the answer when the question is finding the cause across accounts, telemetry sources and deployments.
Reflection Question: Your on-call team wants DevOps Agent to investigate every PagerDuty incident automatically and to be able to roll back a bad security group change — but only after a named engineer approves it, with the change traceable in CloudTrail. Which three settings or resources must exist, and which part of that flow can never run unattended?
