AWS DevOps Agent

Bringing Agentic AI to Release Management and Production Operations

AI coding assistants have increased how quickly teams can generate and modify software. However, producing more code does not automatically make that code safe to release or easier to operate. Pull requests still need review, dependencies must be understood, infrastructure permissions must be checked, tests must reflect the actual change, and production incidents still require engineers to correlate information across monitoring, deployment, ticketing, and source-control systems.

AWS DevOps Agent is AWS’s attempt to address this broader operational problem.

Rather than operating only as a conversational assistant, AWS DevOps Agent is designed to work across software release management and production operations. It builds an understanding of applications, resources, dependencies, telemetry, code, and deployment history, and then uses that context to review releases, investigate incidents, recommend mitigations, and identify improvements intended to prevent repeated failures.

An important distinction must be made before examining the service:

• Production operations capabilities are generally available.

• Release readiness review and autonomous release testing are currently in preview.

During the preview, release-management functionality is available only in the US East (N. Virginia) Region, us-east-1.

What is AWS DevOps Agent?

AWS describes DevOps Agent as an AI-powered, always-available agent covering two areas:

1. Production operations

2. Release management

For production operations, the service can investigate incidents, correlate operational evidence, produce root-cause findings, recommend mitigation steps, and analyze historical incidents for recurring reliability problems.

For release management, it can review code changes for production readiness and generate change-specific tests before software reaches production. The release-management features are currently in preview.

AWS DevOps Agent uses Amazon Bedrock foundation models. AWS also states that customer content processed by the service is not used to train those models.

The service is not limited to AWS-hosted applications. AWS documents support for AWS, Azure, multicloud, and on-premises environments. For non-AWS environments, the agent obtains context through supported observability platforms, pipeline integrations, Microsoft Entra ID for Azure resources, and private or remote Model Context Protocol servers.

The foundation: production intelligence

For an AI agent to investigate an operational problem reliably, it needs more than a collection of logs. It must understand which resources form an application, how services depend on one another, which deployment changed them, and which telemetry belongs to each component.

AWS DevOps Agent addresses this by automatically discovering applications, component services, AWS resources, and relationships between them. It represents those relationships as a dynamic topology that is updated as the environment changes and as the agent learns more about the application.

The topology can be correlated with:

• Metrics, logs, traces, and alarms

• Application and infrastructure code

• Source-control changes

• CI/CD deployments

• Incident tickets

• Existing operational procedures

• Historical investigations

This context allows the agent to examine an incident as a connected system rather than as an isolated alarm.

AWS also supports reusable agent skills. These skills can encode organizational runbooks, investigation procedures, architectural standards, and operational practices. The purpose is to make the agent follow repeatable, organization-specific procedures instead of relying only on general model behaviour.

Autonomous incident investigation

AWS DevOps Agent can begin an investigation when an alert, incident ticket, or supported event is received. It can also be asked to investigate manually through its web application or conversational interface.

During an investigation, the service can correlate information from observability systems, source repositories, deployment pipelines, and application topology. AWS says that the agent explores hypotheses and records its observations before producing root-cause findings. It is designed to investigate several categories of operational failure, including:

• Recent system or code changes

• Unexpected application inputs

• Resource and service limits

• Component failures

• Dependency failures

• Configuration problems

Once a root cause is identified, the service can produce a mitigation plan containing remediation actions, validation steps, and rollback guidance when applicable. It can also produce implementation-ready instructions that can be handed to another coding agent or an engineer.

Findings can be routed through existing operational channels such as Slack, ServiceNow, and PagerDuty. The agent can also create an AWS Support case from an investigation and include the collected investigation context for AWS Support engineers.

Correlating related alarms

A single infrastructure or application failure can produce several downstream alarms. Without correlation, operations teams may treat each alarm as a separate problem, open duplicate incidents, and divide the investigation across multiple responders.

AWS DevOps Agent can correlate alarms that appear to originate from the same underlying event. AWS also documents a triage capability that assesses incidents and links duplicate tickets to a primary investigation instead of automatically starting separate investigations for each duplicate.

This capability is intended to reduce alert noise and focus investigation effort on the originating failure rather than every symptom produced by it.

Proactive incident prevention

AWS DevOps Agent is not limited to resolving active incidents. It can examine patterns across completed investigations and recommend changes intended to reduce the likelihood or impact of similar incidents.

AWS groups these recommendations into four areas:

• Observability

• Infrastructure optimization

• Deployment pipeline improvement

• Application resilience

Examples documented by AWS include improving alarm thresholds, introducing more targeted metrics, correcting infrastructure bottlenecks, enabling deployment rollback mechanisms, and adding validation steps that could have detected a failure before deployment.

The service can also identify gaps in monitoring coverage that caused an incident to remain undetected for too long. These recommendations are intended to reduce mean time to detection, not only mean time to resolution.

Recommendations can include agent-ready specifications for changing application or infrastructure code. However, teams still need to evaluate those recommendations against their architecture, risk controls, approval process, and change-management requirements.

On-demand SRE tasks and custom agents

AWS DevOps Agent includes a natural-language interface for operational questions. Operators can ask about application health, deployments, incident history, resources, alarms, and reliability recommendations without manually navigating between each connected platform.

The interface can also create, save, and share charts and reports, including operational health reports and error-trend analysis.

Teams can create custom SRE agents within an Agent Space. These agents can run on a schedule or in response to events. AWS provides examples such as:

• A daily database health report

• Analysis of slow database queries

• Database parameter-tuning recommendations

• Review of logs from the previous 24 hours

• Detection of anomalies requiring investigation

Custom agents can be assigned skills and configured to produce artifacts or recommendations.

Release readiness review

Release readiness is one of the two release-management capabilities currently in preview.

The agent evaluates a code change against:

• Organization-defined standards

• Cross-repository dependencies

• Production requirements

• Access-control changes

• Infrastructure impact

• AWS Well-Architected best practices

AWS states that the service maps dependencies across repositories to identify changes that could break another service. It can also evaluate infrastructure permission changes using deterministic mathematical verification to identify permissions that extend beyond the application’s requirements or expected best practices.

Organizations can provide standards as plain-English instructions. These instructions can cover areas such as infrastructure configuration, encryption, network access, observability, data handling, and sensitive-data requirements.

When organization-specific instructions have not been configured, AWS says the agent applies general best practices.

As part of a readiness review, the agent can run the software inside an AWS-managed isolated verification environment. It performs lightweight functional checks to verify that the application builds, starts, and completes basic user journeys.

The findings can appear in the AWS DevOps Agent console and as comments on GitHub pull requests or GitLab merge requests. Reviews can also be invoked from supported IDE integrations and coding agents.

Autonomous release testing

Release readiness review determines which areas of a change appear risky. Autonomous release testing uses that analysis to generate a test plan specific to the change.

Instead of running only a fixed regression suite, AWS DevOps Agent can generate tests targeting the functionality, dependencies, and integration paths affected by the code modification. It currently supports release testing for web and API-based applications.

These tests run in a customer-provisioned, production-like environment. AWS says that testing can cover:

• Functional behaviour

• User-experience issues

• Behavioural regressions

• API interactions

• Integration failures

Each test run produces structured evidence such as metrics, logs, traces, an execution summary, and test results.

This distinction between the two environments is important:

• Release readiness includes functional verification in an AWS-managed isolated environment.

• Autonomous release testing runs in a customer-provisioned, production-like environment.

Neither capability should be described as testing directly in the production environment.

Agent Spaces

AWS DevOps Agent is organized around a resource called an Agent Space.

An Agent Space defines what a particular instance of the agent can access. It contains AWS account associations, IAM roles, source repositories, operational integrations, permissions, skills, instructions, memories, and configuration.

Organizations can create multiple Agent Spaces aligned to service boundaries, application teams, business units, environments, or operational responsibilities.

An Agent Space can access resources across multiple AWS accounts when the appropriate IAM roles and account associations are configured. It can also monitor resources deployed in AWS Regions other than the Region in which the Agent Space was created.

For release management, at least one GitHub or GitLab repository must be connected. The agent then indexes the code and creates a knowledge graph representing code, cloud, and cross-repository dependencies.

Integrations and extensibility

AWS DevOps Agent provides built-in integrations across several parts of a DevOps toolchain.

Documented integrations include:

• Amazon CloudWatch

• Datadog

• Dynatrace

• New Relic

• Splunk

• Grafana

• Prometheus

• GitHub

• GitLab

• Azure DevOps

• ServiceNow

• PagerDuty

• Slack

• Microsoft Teams

The exact capability available through an integration can differ. For example, an observability integration supplies telemetry, while a source-control integration supplies code changes and repository context.

The agent can also connect to private and remote MCP servers, allowing organizations to expose internal runbooks, proprietary platforms, custom tools, privately hosted observability services, or other controlled data sources.

AWS DevOps Agent also operates as a managed remote server supporting MCP and Agent-to-Agent protocols. This allows IDEs, coding agents, planning agents, and other applications to invoke investigations, operational queries, and release checks.

Security and auditability

Access to AWS environments is controlled through IAM roles associated with an Agent Space. The Agent Space defines the accounts, integrations, and resources the agent is permitted to inspect.

AWS states that:

• Customer content is not used to train models.

• Customer data is encrypted at rest using AES-256.

• AWS-managed encryption keys are supported.

• Customer-managed AWS KMS keys are also supported.

• Agent Space data is stored in the Region where the Agent Space is created.

• Agent activity is recorded in investigation journals.

• Agent activity is captured through AWS CloudTrail in the hosting account.

AWS also supports private connections for integrations that must access services running inside a VPC or internal network without exposing those services through a public endpoint.

These controls do not remove the need for least-privilege IAM design. The value and risk of an Agent Space depend directly on the accounts, tools, repositories, telemetry sources, and actions exposed to it.

Regional availability

As of July 28, 2026, AWS DevOps Agent is available in 11 AWS Regions:

• US East (N. Virginia)

• US West (Oregon)

• Canada (Central)

• South America (São Paulo)

• Asia Pacific (Mumbai)

• Asia Pacific (Singapore)

• Asia Pacific (Sydney)

• Asia Pacific (Tokyo)

• Europe (Frankfurt)

• Europe (Ireland)

• Europe (London)

Production operations, on-demand DevOps tasks, and custom agents are available in all supported Regions.

Release readiness review and autonomous release testing remain in preview and are available only in US East (N. Virginia), us-east-1.

Although an Agent Space is created in a specific supported Region, it can discover and investigate associated AWS resources deployed in other Regions. Investigation data, topology information, and recommendations remain stored in the Region containing the Agent Space.

Pricing

AWS DevOps Agent production-operations usage is billed according to the time the agent actively spends performing a task. Billing is calculated per agent-second, with no charge while the agent is idle or waiting for work.

The published pay-as-you-go rate is $0.0083 per agent-second for:

• Incident investigations

• Site-reliability evaluations

• On-demand SRE tasks

• Custom SRE agents

Release-management capabilities are available at no additional cost during the preview period.

Connected AWS services can generate separate charges. For example, queries executed through CloudWatch Logs Insights, trace retrieval, storage, or other supporting services are billed according to the pricing of those individual services and are not included in the AWS DevOps Agent rate.

AWS also provides DevOps Agent credits for eligible paid AWS Support plans. The credit percentage depends on the support plan and is based on the previous month’s AWS Support charge.

What AWS DevOps Agent changes

The main change introduced by AWS DevOps Agent is not simply the addition of another chat interface.

Its intended value comes from combining information that is normally divided among monitoring tools, source repositories, deployment systems, cloud accounts, incident platforms, and internal operational knowledge.

The service attempts to create a continuous loop:

1. Understand the application and its dependencies.

2. Review changes before release.

3. Test the areas affected by those changes.

4. Investigate failures after deployment.

5. Learn from completed investigations.

6. Recommend improvements that reduce repeat incidents.

7. Encode organizational knowledge as reusable skills and instructions.

That lifecycle is broader than conventional alert correlation or AI-assisted log summarization. However, its effectiveness will depend on the accuracy of the topology, the quality of connected telemetry, repository access, deployment information, IAM boundaries, and organization-specific skills and instructions. This conclusion follows from the service architecture documented by AWS: its investigations and reviews are grounded in the context and integrations configured within each Agent Space.

Conclusion

AWS DevOps Agent represents AWS’s move from isolated AI assistance toward an agent that participates across release management, incident response, SRE analysis, and reliability improvement.

Its production-operations capabilities are generally available and include autonomous investigations, root-cause analysis, mitigation planning, incident coordination, proactive recommendations, operational chat, and custom SRE agents.

Its newer release-management capabilities extend that model into code review and testing. However, those capabilities remain in preview and are currently limited to us-east-1

The practical value of the service will not come from granting an AI agent unrestricted access and expecting it to replace engineering judgement. It will come from providing controlled access to accurate operational evidence, defining clear organizational standards, encoding proven runbooks as skills, and evaluating its findings against real incidents and release outcomes.

Used within those boundaries, AWS DevOps Agent could become a shared intelligence layer connecting software delivery with production operations—two areas that DevOps teams have traditionally managed using separate processes and fragmented tools.