AWS DevOps Agent in Practice: Agent Spaces, Investigations, Release Checks and Skills

Operations teams burn a lot of hours on chores that repeat: working out why a pipeline broke, checking the state of infrastructure, lining up logs against metrics, and fielding the daily "what is broken now?" question. AWS supplies fine building blocks for this, among them CloudWatch, IAM, CodePipeline and Lambda, yet a gap remains between raw signals and conclusions someone can act on.

What follows is a practical walk through AWS DevOps Agent: how an Agent Space is set up, what an investigation looks like end to end, what the newest release-management features add, and how Agent Skills let the agent absorb a team's own procedures. The audience is DevOps, SRE, platform and AI engineers who already run workloads on AWS and want automation that goes past simple scripts.

What a DevOps agent is, and is not

Here the term means an operational assistant that does not replace engineers. It is a system that:

• has read access to AWS resources, and sometimes limited write access
• understands the operational context of the environment
• can answer questions such as why a deployment failed, what changed in the past hour, or which service is behind a rise in errors
• acts as a connecting layer between AWS APIs, logs, metrics and the humans on call

It does not take the place of engineers. Its job is to lower the mental load of routine investigation and to make that investigation faster.

Creating an Agent Space

Find the service

Open the AWS Management Console and search for AWS DevOps Agent. The core production-operations features are generally available. The newer release-management capabilities, covered below, are still in preview.

Create the space

Choose Create Agent Space and supply two things: a name, such as Demo-DevOps-Agent, and a short description of the environment or its purpose. The Agent Space becomes the logical boundary around investigations, topology and recommendations.

Grant resource access

Under the section for giving the space access to AWS resources, pick the option that auto-creates a new DevOps Agent role. AWS builds and attaches an IAM role with scoped permissions that allow it to read CloudWatch metrics and logs, inspect EC2 and related resources, and build topology graphs. Most of the IAM friction that normally stalls adoption disappears at this step.

Switch on the web app

In the Enable web app section, keep the auto-create role choice selected. This turns on the interactive interface used for investigations, chat and dashboards. After that, create the Agent Space.

Open the operator view

Go to the new Agent Space and open Operator Access. Three areas live here: DevOps Center, Incident Response and Prevention.

DevOps Center and topology-aware visibility

Inside the space, DevOps Center shows a live topology graph of the AWS environment. Several things stand out at once. Resources appear connected and not isolated, dependencies between services are visible, and the agent works from relationships and not from metrics alone. That topology matters a great deal for root cause analysis later on.

Running an investigation

Incident Response is where the agent starts to earn its keep. From the dashboard, choose Start Investigation. The problem can be described in plain language, or a common trigger can be picked, such as high CPU, a spike in error rates, or missing metrics and logs.

The example here was a missing-data incident. The request read: can you check why CloudWatch CPU data is not visible for my EC2 instances? Right away the agent pinpointed the affected instances, placed them on the topology view and queried CloudWatch metrics in the relevant region.

Timeline and findings

The investigation timeline lays out how the work progressed: gathering context, discovering resources, evaluating metrics and developing findings. One design choice deserves attention. When metrics are absent, the agent says so outright and does not fail silently. It is a small decision with a large effect on trust.

Root cause analysis

On the Root Cause tab, the agent named several contributing causes, not just one:

• Detailed monitoring disabled on the EC2 instances. The instances showed Monitoring: disabled, and without detailed monitoring those CPU metrics are never published to CloudWatch.
• No CloudWatch agent installed. Nothing was configured on the instances, so the finer-grained CPU data was unavailable.
• Instances stopped. They had been stopped for a long stretch, and stopped instances emit no metrics.

What counts is how the agent worked. It did not settle on one explanation, it ranked the causes sensibly, and it supported each with evidence pulled from AWS APIs.

When no action is the right answer

The Mitigation Plan tab reported that no immediate mitigation action could be identified. That is a good result, not a poor one. The system was behaving exactly as configured. No regression or recent change had caused the symptom. Any fix would amount to a planned configuration change and not incident mitigation. Drawing that line matters in production, since it prevents needless rollbacks.

Prevention

The Prevention tab studies earlier investigations and decides whether proactive recommendations are warranted. Here nothing new was generated, and the agent correctly saw no recurring operational risk. The categories it evaluates are infrastructure, observability, governance and code optimization.

Why teams might care

This is not just one more monitoring product. The value lies in four things: shorter investigation times, structured root cause analysis, less alert fatigue, and a way for teams to learn why their systems behave as they do. Engineers would otherwise piece together CloudWatch, EC2 settings, IAM state and deployment history by hand. The agent performs that correlation on their behalf.

Release management capabilities (preview)

A newer capability pushes the agent earlier, before code ever reaches production.

Release readiness review. Each code change is evaluated against production-readiness criteria, cross-repository dependency risk and any standards the organization defines, falling back to general best practices when none are set. Specific checks include the effect of a change on downstream services in other repositories, and IAM or access-control edits measured against the AWS Well-Architected Framework. The agent additionally boots the build inside an isolated environment that AWS manages, and exercises it with a few light user-journey tests. These confirm that the build succeeds, that the app runs and that basic functional checks pass, all before the change enters the pipeline.

Findings show up in the DevOps Agent console and as pull request comments on GitHub or GitLab. They can also be triggered on demand from an IDE through the Kiro power or the Claude Code plugin, so developers catch dependency risk, standards violations and access-control problems before committing.

Autonomous release testing. This moves the idea ahead to the pre-merge stage. Rather than running a fixed suite, it generates test plans specific to the change, run against production-like environments that the customer provisions, for web and API applications. Since it reasons about the meaning of the diff, it can build functional-correctness, regression and cross-service integration tests that a hand-maintained suite might never anticipate. Every run produces structured artifacts, namely metrics, logs, traces and an execution summary, which give reviewers a consistent and auditable record of test coverage and outcomes for each change.

Both features are in preview and carry no additional cost during that period. They are available in the US East (N. Virginia) Region.

What Agent Skills are

Skills are modular instruction sets that extend the agent with specialized domain knowledge and investigation methods fitted to a team's own infrastructure and practices. A skill is a self-contained directory of Markdown instructions that gives the agent a new capability. The service supports a subset of the open Agent Skills specification, accepting only non-executable material: Markdown instructions, PDFs, images and data files.

Each skill needs a SKILL.md file holding the instructions. Beyond that, a skill may include:

• Investigation workflows for particular scenarios or infrastructure types
• Reference material, such as architecture patterns and operating procedures
• Agent type targeting, which aims a skill at specific agent types (Generic, On-demand, Incident Triage, Incident RCA, Incident Mitigation or Evaluation) to save context and sharpen focus

Why bother

Skills turn a general-purpose assistant into a specialist for a particular environment. A one-off instruction typed into chat is gone afterward, while a skill is reusable and loads by itself when a task calls for it. Four benefits follow:

• Specialization. The agent picks up investigation procedures, good practice and organizational knowledge particular to the infrastructure.
• Less repetition. A workflow written once is used automatically across every relevant investigation, so the same guidance need not be restated.
• Composition. Several skills combine into a complete workflow. The agent can read many during a run, for example one that fetches deployments from a custom CI/CD pipeline and another that searches code repositories.
• Better use of custom tools. A skill can tell the agent when to call a given MCP server tool, which parameters suit different scenarios, and how to read the results.

How they get used

When the agent meets a relevant task, it loads the matching skills and follows them. A skill called Database Performance Investigation, for instance, could hold step-by-step procedures for RDS throttling, steering the agent through alarm status, connection metrics and slow queries in a systematic way.

Skill layout

A skill is a directory:

my-skill/
├── SKILL.md              # Main skill instructions
├── references/           # Optional: additional reference documentation
└── assets/               # Optional: images, diagrams, data files

The SKILL.md file is the one mandatory piece. It should describe when and how the skill applies, give step-by-step investigation procedures, include decision trees for different scenarios, and state expected outputs and success criteria.

Sample skills and uploading one

AWS publishes a sample collection of skills built for this runtime in the aws-samples GitHub organization. They are not generic Agent Skills. They are tailored to the DevOps Agent runtime, its agent types and the workflows it runs inside an Agent Space.

To use one, download the wanted zip from the repository, or build a package with this structure:

<skill-name>.zip
├── SKILL.md              # Required: main instructions + YAML frontmatter
├── references/           # Optional: reference documentation
│   ├── architecture.md
│   └── troubleshooting.md
└── assets/               # Optional: images, diagrams, data files

Place SKILL.md at the root of the zip with valid frontmatter containing name and description. A sample frontmatter would carry a name such as eks-resilience-checker-skill-devops and a description along the lines of: investigation procedures for Amazon EKS resiliency assessment, covering control plane health, data plane scaling, networking and observability gaps, to be used when assessing or fixing cluster resiliency posture.

Then work through the upload steps:

1. Check that the zip has no scripts/ directory and totals 6 MB or less.
2. Open the Operator Web App and go to the Skills page.
3. Choose Add skill, then Upload skill.
4. Drag the .zip into the modal, or browse for it. Only zip files up to 6 MB are accepted.
5. Pick the Agent Types that should use the skill. Generic is preselected and applies to every type. Deselect it to target On-demand, Incident Triage, Incident RCA, Incident Mitigation or Evaluation.
6. Read the validation results shown by the form, then choose Upload to add the skill to the Agent Space.

Managing skills afterward

• List and view: any skill on the Skills page can be opened to browse its files (SKILL.md, references/, assets/), read-only.
• Activate or deactivate: toggle Active or Inactive on the detail view. Inactive skills stay stored but do not load for new investigations.
• Retarget: the choice of agent types can be edited whenever needed.
• Replace: a skill that came from a zip gets updated by uploading a newer version.

Creating a skill in the UI

A single SKILL.md with no references or assets can skip the zip entirely:

1. On the Skills page choose Add skill, then Create skill.
2. Enter a Name in lowercase letters, numbers and hyphens, at most 64 characters, neither starting nor ending with a hyphen.
3. Enter a Description, ideally at least 100 characters and no more than 1024.
4. Choose a Status (Active or Inactive) and one or more Agent Types.
5. Paste the Markdown into the Instructions field.
6. Choose Create. The system generates SKILL.md with the right frontmatter automatically.

Where it fits

For anyone running AWS at scale, this service is worth trying, especially for incident triage and post-incident analysis. In plain terms, it behaves like an autonomous on-call teammate that works around the clock. It starts investigating the moment an alert fires, shortens time to resolution by correlating telemetry, code and deployment history, and helps head off future outages across AWS, hybrid and multi-cloud environments.