Amazon DevOps Guru Stops New Customers: An Operations Monitoring Migration Checklist

What changed on 29 October 2026

Amazon DevOps Guru stopped accepting new customers on 29 October 2026 under an availability change AWS announced on 29 September. Existing customers can continue using the service until its scheduled end of support on 30 September 2027. AWS recommends completing the transition by 30 June 2027 to allow time to compare the replacement monitoring setup with live operations. The relevant AWS transition guide explicitly distinguishes the new-customer cutoff from the later end-of-support date. This is not a newly announced retirement, but the cutoff is a real operational change effective today. Companies considering DevOps Guru for a fresh project should now plan around alternatives. Existing customers should avoid a rushed shutdown that removes alerting before equivalent coverage has been tested.

Why business owners should care about a technical retirement

A cloud monitoring product may sound like an issue for engineers, yet the consequences of poor monitoring are commercial. A failed checkout, delayed customer portal, unavailable booking tool or broken integration can interrupt revenue and damage trust. Many smaller companies outsource cloud administration, so management may not even know which product produces their alerts. A sensible response begins by asking the provider or internal engineer for an inventory of monitoring tools and critical dependencies. The objective is not to learn every technical detail but to establish who will detect an incident, who will respond and how the business will know whether a migration has reduced visibility. Operational continuity needs an accountable owner even when the technology is managed externally.

Distinguish new customer cutoff from service shutdown

The timing matters. AWS says new customers cannot start using DevOps Guru after the cutoff, while current users can continue until the 2027 end-of-support date. It also says the underlying workloads are not removed merely because DevOps Guru is retired; the monitoring layer and its insights are what need replacement. That does not mean there is no risk. An application may still run while the team loses anomaly alerts, investigation context or a notification route. Check whether any dashboards, runbooks, tickets or infrastructure templates depend on DevOps Guru outputs. Avoid telling colleagues that the entire AWS application is being switched off. Precise communication prevents unnecessary disruption and focuses effort on the components that actually change.

Inventory the current monitoring coverage

List the production services that DevOps Guru observes, including AWS accounts, regions, resource collections and related applications. For each, record the important signals, such as error rate, latency, queue backlog, database capacity, failed jobs or unusual logs. Identify the alerts that currently reach an employee or managed service provider, and the channels they use. Include after-hours arrangements and escalation contacts. Review infrastructure-as-code references as well as console settings; AWS specifically mentions resource collections, notification channels and log anomaly detection integrations in its transition instructions. An inventory is complete only when a person can explain how a significant service failure would be detected and who would act on it.

Map replacement functions rather than comparing product names

AWS points customers toward Amazon CloudWatch for anomaly detection and alerting, with Amazon DevOps Agent for AI-assisted investigation. These products do not necessarily reproduce every DevOps Guru behaviour through a single switch. Make a comparison table of the functions the business actually uses: metric alarms, log anomaly detection, database insights, incident investigation, notification delivery and reporting. Mark each as covered, requiring configuration, needing testing or intentionally retired. Ask engineers to demonstrate the replacement on a representative service. Do not assume that purchasing or enabling a product automatically creates equivalent monitoring. The key deliverable is verified detection and response, not a completed software subscription change.

Run both systems while validating

Where the existing environment and contract allow, maintain the current monitoring path while testing replacement alarms. Simulate a safe non-production failure or use controlled test events to verify that the right people receive notifications. Compare the time to detection, the information in each alert and the steps needed to diagnose it. Review false positives as well as missed events. Record exceptions rather than quietly ignoring them. AWS recommends a transition before the final support deadline, giving teams room for this validation. The exact parallel-running period depends on the application and risk level. Customer-facing systems handling payments or sensitive records deserve more careful change management than a non-critical internal dashboard.

Protect incident escalation and human ownership

A monitoring alert is useful only if it reaches someone authorised and equipped to respond. Define the first responder, backup contact, escalation threshold and decision maker for customer communication. Document what the responder can restart, roll back or isolate without further approval. For high-impact actions, require an appropriate second review. Keep runbooks in a location accessible during an outage; a guide stored only inside the affected system is not a reliable fallback. When using an AI-assisted investigation tool, treat its recommendations as evidence to inspect rather than automatic authority to change production. The best incident process connects machine-generated signals with clear human accountability.

Make the migration measurable

Establish baseline operational measures before changing the monitoring stack. Examples include the number of critical incidents detected, average time from event to alert, proportion of alerts with an identified owner, unresolved incident backlog and the number of repeat failures. These are metrics to calculate from your own logs, not industry benchmarks that can be copied into a report. During the transition, compare like with like and note changes in instrumentation. If a new system generates many more low-priority alerts, that may increase workload without improving protection. Conversely, fewer alerts are not necessarily good if coverage has been lost. Review both detection quality and the team’s ability to act.

Avoid an accidental infrastructure-as-code gap

AWS advises checking CloudFormation, CDK, Terraform and CLI configurations that reference DevOps Guru resource collections or notification channels. A team may remove a resource manually and later recreate it through a deployment pipeline if the template was not updated. The reverse is also possible: a new environment may be deployed without monitoring because the old service no longer accepts new customers. Assign someone to review templates and deployment documentation. Test the provisioning path in a controlled environment. Record which configurations were changed, which approvals were obtained and how the change can be rolled back. This is ordinary change control, but service retirements make it especially important.

A practical calendar for existing customers

Start now by confirming whether DevOps Guru is in use and identifying affected accounts. In the next planning cycle, approve a migration owner and target architecture. Build replacement monitoring in a test environment, then validate it against a small production service. Expand gradually and keep evidence of alert delivery and incident response. Aim to finish well before AWS’s recommended 30 June 2027 transition date, rather than treating the September support deadline as the start of work. These are planning steps, not promises about implementation duration. Complex environments, regulated data and contractual support arrangements can require additional time and specialist review.

How ClayoCraft can support the operating process

ClayoCraft does not need to pretend to be the vendor’s security engineering team to add value. Our Operations and Business Systems work can help define ownership, document service dependencies, coordinate handoffs and build reporting around a technical migration. Our Fractional Business Support offering may help businesses coordinate internal teams and external providers when permanent project-management capacity is limited. Qualified cloud engineers should perform and validate the technical configuration. A useful consultation starts with the services customers depend on, the people who receive alerts and the decisions that must be made during an outage.

The action to take this week

Ask the technical owner a specific question: do any live systems, alerts or deployment templates depend on Amazon DevOps Guru? If the answer is no, record that finding and move on. If yes, request a short inventory and a proposed replacement plan referencing AWS’s current guidance. Verify that customer-facing services will retain monitoring throughout the change. Keep a copy of the existing alert routes and incident runbooks, and set a review date before the recommended transition deadline. Do not purchase an unrelated monitoring product simply because a retirement notice appeared. The right response is a controlled change that protects the business outcome: reliable services and timely incident response.

Frequently asked questions