Monitoring production systems is not just about collecting metrics. Development teams also need to identify unusual behavior, connect related failures, and understand what changed before an incident affects customers.
Amazon DevOps Guru was designed to help with this work by analyzing operational data from AWS resources and generating insights about potential application problems. However, AWS has announced that Amazon DevOps Guru will reach end of support on September 30, 2027.
New customers will no longer be accepted starting October 29, 2026. Existing customers can continue using the service until September 30, 2027, but AWS will not introduce new features during the remaining support period.
AWS recommends moving metric anomaly detection and alerting workflows to Amazon CloudWatch. Teams that depend on AI-assisted operational investigation should also evaluate Amazon DevOps Agent.
For DevOps engineers, the important task is not simply replacing a monitoring service. It is identifying every dependency on DevOps Guru, preserving historical insights, rebuilding alerting workflows, and validating the replacement before the shutdown date.
What Is Amazon DevOps Guru?
Amazon DevOps Guru is a managed operational monitoring service that uses machine learning to identify unusual behavior in applications and supporting AWS infrastructure.
It analyzes operational information such as Amazon CloudWatch metrics, AWS CloudTrail events, and other supported resource information to identify anomalies and generate insights.
These insights can include related events, affected resources, metrics, and recommendations that help teams investigate potential operational problems.
For example, consider an application running on Amazon EC2 with an Amazon RDS database. A sudden increase in database connections might coincide with higher application latency and an increase in failed requests.
DevOps Guru can identify unusual patterns and group related signals into an operational insight, helping engineers investigate the issue.
The service also supports notifications through Amazon Simple Notification Service (Amazon SNS) and integration with AWS Systems Manager OpsItems for tracking operational work.
Its retirement matters because some teams may have built their monitoring dashboards, incident workflows, infrastructure templates, and automation around these capabilities.
What Is Changing and When?
AWS announced the retirement on September 29, 2026, as part of its service availability updates.
Date | Change | Impact on teams |
|---|
September 29, 2026 | Retirement announced | Teams should begin inventory and migration planning |
October 29, 2026 | New customers can no longer sign up | Organizations not already using the service should choose an alternative |
September 30, 2027 | End of support | Existing customers lose access to the service and its APIs |
Until September 30, 2027, existing customers can continue using DevOps Guru. AWS will maintain service availability and performance, provide security patches and critical bug fixes, and continue offering support through AWS Support channels.
However, the service will not receive new features.
After the end-of-support date:
The DevOps Guru console will no longer be accessible.
DevOps Guru API operations will no longer be available.
Previously generated insights will no longer be retrievable through the service.
DevOps Guru CloudFormation resource types will be withdrawn.
CloudFormation or AWS CLI operations that depend on those resource types will fail.
The retirement does not mean that applications monitored by DevOps Guru will stop running. DevOps Guru is a monitoring service, not the runtime hosting those applications.
The risk is the loss of operational visibility and the failure of automation that still depends on the retired service.
Which AWS Services Should Replace DevOps Guru?
AWS recommends different migration paths depending on how a team uses DevOps Guru.
Amazon CloudWatch for Anomaly Detection and Alerting
Amazon CloudWatch is the primary alternative for teams that use DevOps Guru to monitor metrics, detect unusual behavior, and notify operators.
CloudWatch provides metrics, alarms, dashboards, logs, and anomaly detection capabilities. Teams can configure alarms to identify deviations from expected metric behavior and send notifications when defined conditions are met.
For example, an application team can configure monitoring for:
Elevated HTTP error rates
Increased response latency
High CPU utilization
Database connection saturation
Unusual request volume
Increased queue depth
CloudWatch anomaly detection can establish an expected range for supported metrics and help identify deviations from that range.
However, replacing DevOps Guru insights with CloudWatch alarms is not a one-to-one migration. Teams must decide which metrics matter, define alarm conditions, configure notification channels, and validate the resulting incident workflow.
Amazon DevOps Agent for Operational Investigation
Amazon DevOps Agent is the alternative AWS recommends exploring when teams depend on AI-assisted investigation, correlation of operational signals, and incident troubleshooting.
The distinction is important: CloudWatch provides the monitoring and alerting foundation, while DevOps Agent is intended to help investigate operational problems using available context.
A team that previously relied on DevOps Guru for both anomaly detection and investigative guidance may need both services to preserve its existing workflow.
Requirement | Recommended direction | Main responsibility |
|---|
Metric monitoring | Amazon CloudWatch | Collect and analyze operational metrics |
Metric anomaly detection | CloudWatch anomaly detection | Identify deviations from expected behavior |
Alerting | CloudWatch alarms and supported notification integrations | Notify operators when conditions are met |
Operational dashboards | CloudWatch dashboards | Present metrics and operational signals |
AI-assisted incident investigation | Amazon DevOps Agent | Help investigate and correlate operational problems |
Historical insight retention | Export from DevOps Guru before retirement | Preserve records needed for future reference |
Teams should evaluate the current capabilities, availability, permissions, and costs of each replacement before finalizing their architecture.
Step 1: Inventory Every DevOps Guru Dependency
The first migration task is identifying where DevOps Guru is used.
A team may have enabled the service directly in the AWS console, but the dependency could also exist in infrastructure-as-code templates, deployment pipelines, scheduled scripts, internal dashboards, and incident-management integrations.
Start by reviewing the AWS accounts and Regions in which DevOps Guru is enabled.
Then inspect the following areas:
Resource coverage: Identify the AWS resources, CloudFormation stacks, and tags included in DevOps Guru analysis coverage.
Notification channels: Find the Amazon SNS topics used to distribute insights.
Systems Manager integration: Identify automation that creates or processes OpsItems from DevOps Guru insights.
API consumers: Search application code, scripts, dashboards, and integrations for DevOps Guru API calls.
Infrastructure as code: Locate DevOps Guru resources in CloudFormation, AWS CDK, Terraform, and related deployment configurations.
Operational documentation: Find runbooks that instruct engineers to investigate incidents through DevOps Guru.
Create an inventory that records each dependency, its owner, its replacement, and its migration status.
This prevents teams from replacing the console workflow while leaving a critical API integration or infrastructure template unchanged.
Step 2: Replace Metric Monitoring and Alerting
For each existing DevOps Guru monitoring workflow, determine which CloudWatch metrics and alerts are required to preserve the operational outcome.
Suppose a team uses DevOps Guru to identify unusual behavior in an API service.
A migration plan might include the following:
Existing requirement | Replacement implementation |
|---|
Monitor request failures | CloudWatch metrics and alarms for error rates |
Detect unusual latency | Appropriate CloudWatch metrics and anomaly detection |
Monitor database pressure | Database metrics and threshold or anomaly-based alarms |
Notify the on-call team | CloudWatch alarm actions and supported notification channels |
Display service health | CloudWatch dashboards |
Track incident investigation | Existing incident-management workflow or an approved replacement |
The exact metrics depend on the application and its AWS services.
Do not copy every metric into a separate alarm without considering its operational value. Too many alarms can create notification fatigue and make genuine incidents harder to identify.
Instead, define the conditions that require action and establish an owner and response procedure for each important alert.
Example: Creating a CloudWatch Alarm
The following AWS CLI example creates a basic alarm for a custom application metric.
aws cloudwatch put-metric-alarm \
--alarm-name "Orders-High-Error-Rate" \
--namespace "MyApplication" \
--metric-name "ErrorCount" \
--statistic Sum \
--period 300 \
--evaluation-periods 2 \
--threshold 50 \
--comparison-operator GreaterThanThreshold \
--treat-missing-data notBreaching
This example creates an alarm when the sum of ErrorCount exceeds 50 for two consecutive five-minute evaluation periods.
The metric namespace, metric name, threshold, and missing-data policy are illustrative. Your application must publish the corresponding metric, and the threshold should reflect the service's actual requirements.
The example also omits alarm actions. In production, configure the appropriate notification or automation actions so that the alarm reaches the team responsible for responding.
This illustrates the difference between migrating a monitoring requirement and copying a service configuration. Teams must translate the intended operational behavior into the appropriate CloudWatch metrics, conditions, and response mechanisms.
Step 3: Migrate AI-Assisted Incident Investigation
Metric alerts can identify a problem, but they do not necessarily explain its cause.
A production incident may involve multiple services, a recent deployment, database pressure, and a sudden change in request volume. Engineers need to correlate these signals before deciding what to change.
Teams that use DevOps Guru for this investigative context should evaluate Amazon DevOps Agent and determine how it fits into their incident-response workflow.
A practical investigation process can include:
Detect an anomaly through CloudWatch.
Notify the responsible team through the configured alerting channel.
Gather relevant metrics, logs, traces, deployment events, and configuration changes.
Use the approved investigation workflow to correlate the available evidence.
Validate the suspected root cause before taking corrective action.
Record the findings and update the incident runbook.
AI-assisted investigation can help reduce the effort required to collect and interpret operational evidence, but its findings still require verification.
Teams should define which actions an agent can perform independently and which require human approval. Production changes, destructive operations, and privileged remediation should remain subject to appropriate controls.
Step 4: Update Infrastructure-as-Code Templates
One of the most important migration risks is leaving DevOps Guru resource types in infrastructure-as-code definitions.
AWS identifies two resource types that teams need to review:
After the service reaches end of support and these resource types are withdrawn, CloudFormation stacks or other automation that attempts to create or update them can fail.
A single failed resource may block an otherwise unrelated stack operation.
For example, a shared infrastructure stack might manage application monitoring, notification topics, and several application resources. If the stack still contains a retired DevOps Guru resource, an update to the stack could fail even if the requested change concerns another component.
The migration process should be deliberate:
Search all templates and modules for DevOps Guru resource types.
Identify the corresponding monitoring and notification requirements.
Configure the replacement CloudWatch alarms and notification paths.
Remove the DevOps Guru resources from the templates.
Deploy the template changes while the existing service is still available.
Validate the resulting stack and alerting behavior.
Do not delete resources manually in the console while leaving them declared in infrastructure as code. That can create drift between the actual infrastructure and the templates that manage it.
For Terraform or AWS CDK projects, inspect the generated or declared infrastructure and update the source definitions so future deployments do not attempt to recreate the retired resources.
Step 5: Migrate API Integrations and Export Historical Insights
Some teams consume DevOps Guru insights programmatically.
An internal dashboard might retrieve insights through the API, or a script might create incident tickets when a new insight appears. These integrations will stop receiving data from DevOps Guru after its APIs become unavailable.
Search application repositories and automation scripts for DevOps Guru API operations. Replace those integrations with the appropriate CloudWatch data sources or a redesigned workflow.
Not every DevOps Guru API response has a direct equivalent in CloudWatch. Teams should map the business purpose of each integration rather than simply replacing API calls mechanically.
Historical insight data also requires attention.
AWS states that previously generated DevOps Guru insights will no longer be retrievable after September 30, 2027. If those records are needed for audits, incident reviews, or operational research, export them before the deadline.
AWS recommends using both of the following approaches where appropriate:
Store exported records in an approved location with suitable access controls and retention policies. Verify that the exported data is readable and complete before reducing or disabling DevOps Guru coverage.
Common Migration Mistakes to Avoid
Assuming Running Applications Will Stop
DevOps Guru does not host the monitored applications. Its retirement affects monitoring, insights, and dependent automation rather than the runtime of the applications themselves.
Replacing Every Insight With a Simple Threshold
A fixed threshold may not reproduce the behavior of anomaly detection. Review the operational objective and choose an appropriate CloudWatch monitoring strategy.
Ignoring CloudFormation Dependencies
Leaving retired resource types in a shared template can block future stack updates. Search all accounts, repositories, and infrastructure modules rather than only the primary application stack.
Forgetting Historical Data
Once DevOps Guru is unavailable, historical insights cannot be retrieved from the service. Export records before disabling the service or reaching the retirement deadline.
Migrating Alerts Without Testing Notifications
An alarm that exists but does not notify the right team is not a successful migration. Verify the alarm state transitions, notification delivery, escalation process, and runbook.
Waiting Until September 2027
The service remains available until the end-of-support date, but the migration involves monitoring, infrastructure, APIs, incident procedures, and historical data. Delaying the work increases the risk of missing a hidden dependency.
A Practical Migration Checklist
Use the following checklist to track progress across accounts and applications.
Inventory DevOps Guru coverage across AWS accounts and Regions.
Identify notification channels, OpsItems, API integrations, and dashboards.
Locate DevOps Guru resources in CloudFormation, CDK, and Terraform.
Map anomaly detection requirements to CloudWatch metrics and alarms.
Evaluate Amazon DevOps Agent for AI-assisted investigations.
Export historical insights and validate the exported records.
Update infrastructure templates and deployment automation.
Test alert delivery and incident-response procedures.
Remove obsolete DevOps Guru dependencies from source control.
Verify that all workloads remain observable through the replacement architecture.
Assign an owner and completion date to each item. For large organizations, track progress at the account, Region, and application level rather than treating migration as a single global change.
Conclusion
AWS recommends Amazon CloudWatch for metric anomaly detection and alerting, and Amazon DevOps Agent for AI-assisted operational investigation. Existing applications will continue running, but monitoring workflows, API integrations, historical insights, and infrastructure-as-code resources that depend on DevOps Guru require attention.
The most effective migration begins with a complete dependency inventory. Replace monitoring and alerting deliberately, update infrastructure templates, migrate API consumers, and export historical insights before the service becomes unavailable.
Treat this as an observability migration rather than a simple product replacement. A successful transition preserves the signals, notifications, investigation workflows, and operational records that your team needs to keep production systems reliable.
Join the conversation! Your thoughts help the community grow.