Amazon DevOps Guru End of Support: The October 29 Cutoff Before the 2027 Shutdown

AWS put Amazon DevOps Guru on the retirement list on 29 September 2026. Most of the coverage so far has led with the shutdown date, 30 September 2027, which reads like a problem for next year. It isn't. The date that changes what you can do is 29 October 2026, and after it passes an AWS account that was not already signed up can never turn DevOps Guru on. If you run account vending, that cutoff lands in your landing zone baseline before it lands in anyone's dashboard. Here is what the Amazon DevOps Guru end of support actually breaks, in what order, and what the replacement costs when you do the arithmetic.

Two dates, and the near one is the one that bites

The AWS end of support notice gives two:

| Date | What changes | Who it affects | |---|---|---| | 29 October 2026 | "Amazon DevOps Guru will no longer accept new customers" | Any account not signed up for the service by this date | | 30 September 2027 | Console, API and resource types all stop | Everyone, including IaC and downstream tooling |

Between those dates AWS commits to security patches, critical bug fixes and availability, and commits to no new features. That is the usual maintenance posture and it is fair enough. The asymmetry is what gets missed. The 2027 date gives you a year of notice on a monitoring service whose loss, in AWS's own words, "does not interrupt running workloads". The 2026 date gave you one month, on an enrolment door that does not reopen.

DevOps Guru was not alone in that announcement. The same service availability update set 29 October 2026 as the new-customer cutoff for Amazon Chime SDK SIP Media Application and Amazon WorkSpaces Secure Browser, ended support for Amazon Mechanical Turk on 29 September 2026, and gave the AWS Infrastructure Composer standalone console until 7 December 2026. Amazon Managed Blockchain and AWS Backint Agent for SAP ASE both run to 29 September 2027. If you were waiting for a signal that AWS is pruning, that is seven services in one post, counting DevOps Guru.

The sign-up cutoff is per account, which makes it an account-vending problem

Read the sentence that follows the cutoff carefully. AWS writes: "As an existing customer with an account signed up for the service before October 29, 2026, you can continue to use Amazon DevOps Guru features."

Signed up is scoped to the account, not to the payer and not to the organization. So a platform team with a Control Tower or custom account factory that enables DevOps Guru as part of its baseline has a dated failure waiting in that baseline. Accounts created on 28 October enrol. Accounts created on 30 October do not, and whatever your pipeline does when a baseline step fails is what it will do in production, repeatedly, for eleven months.

We would not wait on this. Grep your account baseline, your Terraform modules, your Service Catalog products and your AFTAccountCustomizations repository for devopsguru and devops-guru this week, and strip the enrolment step out before the date rather than after the first failed vend. The ambiguity in "new customers" is worth one email to your account team if you are mid-migration and need the answer in writing, but do not let the clarification block the removal. Removing the step is correct either way.

The reverse case is narrower and almost nobody is in it. If you have a genuine reason to keep DevOps Guru running through 2027 in an account that is not yet enrolled, enrolling before 29 October is the only way to buy that option, and it costs you whatever analysis you turn on. Weigh that against eleven months of a service receiving no new features.

Your IaC breaks before your monitoring does

This is the part of the notice that deserves the loudest heading, and AWS says so plainly: it is "the highest-severity impact".

Two CloudFormation resource types get withdrawn at end of support:

AWS::DevOpsGuru::ResourceCollection
AWS::DevOpsGuru::NotificationChannel

The Terraform equivalents, from the AWS provider, are aws_devopsguru_resource_collection and aws_devopsguru_notification_channel:

# illustrative: the two resource types to find and remove
resource "aws_devopsguru_resource_collection" "example" {
  type = "AWS_CLOUD_FORMATION"
  cloudformation {
    stack_names = ["ExampleStack"]
  }
}

resource "aws_devopsguru_notification_channel" "example" {
  sns {
    topic_arn = aws_sns_topic.example.arn
  }
}

Once those types are withdrawn, CloudFormation and CLI operations that create or update them fail. One failed resource blocks the whole stack operation, which means a template nobody has touched in two years can stop an unrelated deployment in October 2027. CDK is in the same position, because it synthesises the same resource types.

AWS's sequence is right and we follow it: stand up the replacement CloudWatch alarms and notifications first, then remove the DevOps Guru resources from the templates and deploy that change. Removing them out of band through the console leaves your stacks and your templates disagreeing, which is a worse problem than the one you were fixing.

To find what you actually have enabled, rather than what you think you have:

# per account and region
aws devops-guru describe-account-health
aws devops-guru get-resource-collection --resource-collection-type AWS_CLOUD_FORMATION
aws devops-guru get-resource-collection --resource-collection-type AWS_TAGS
aws devops-guru list-notification-channels
aws devops-guru list-monitored-resources --max-items 100

DevOps Guru did two jobs, and AWS split them between two products

DevOps Guru bundled statistical anomaly detection on your operational metrics with a correlation and recommendation layer on top. AWS has pointed each half somewhere different, and the migration is easier once you stop looking for a single replacement.

| What you used it for | AWS's path | What you should expect | |---|---|---| | Anomaly detection and alerting on metrics | Amazon CloudWatch anomaly detection alarms | A direct swap, cheaper, and you configure the bands yourself | | Enriching, correlating and investigating incidents | AWS DevOps Agent | A different product shape and a different billing model | | Insights pulled into dashboards or ticketing via the API | CloudWatch, per AWS's migration note | Rewrite, because there is no API shim | | Proactive "this will break later" insights | Nothing equivalent | This capability goes away, and pretending otherwise wastes a quarter |

That last row is the honest one. The reactive half of DevOps Guru has a clean CloudWatch successor. The proactive half, the part that flagged a table approaching a throughput limit before anyone paged, has no like-for-like replacement in the AWS catalogue today. Teams that got value from it should plan to encode those specific predictions as explicit CloudWatch alarms on the underlying metrics, which is more work and more accurate.

AWS DevOps Agent is the recommended path for the investigation half. It "monitors AWS infrastructure, performs automated root cause analysis on operational events, runs remediation procedures, and configures preventive measures". That remediation clause is a meaningful change in blast radius from a service that only ever wrote you an insight, and the question of how much autonomy to grant an agent in your production account is not a DevOps Guru migration question. We covered where we draw that line, and the build-versus-buy numbers behind it, in AI incident response automation. Read that before you wire an agent to anything that can call UpdateStack.

What the replacement costs, with the arithmetic

DevOps Guru bills per analysed resource per hour, and a resource counts as active in any hour it produced metrics, events or log entries. From the DevOps Guru pricing page: $0.0028 per resource per hour for price group A (Lambda functions, S3 buckets) and $0.0042 per resource per hour for price group B (EC2, RDS, DynamoDB tables, load balancers and others). API calls are $0.000040 each.

Take a mid-sized account with 400 active price group B resources, which is a normal number for one production environment:

400 resources x 730 hours x $0.0042 = $1,226.40 per month

Now the replacement. CloudWatch pricing charges $0.10 per alarm metric per month, and an anomaly detection alarm evaluates three standard-resolution metrics, so it lands at $0.30 per alarm per month. Say the DevOps Guru coverage you were paying for resolves into 60 anomaly detection alarms on the metrics you would actually wake someone for:

60 anomaly detection alarms x $0.30 = $18.00 per month

AWS DevOps Agent pricing is $0.0083 per agent-second for investigations, evaluations and on-demand SRE tasks, billed only while the agent is working. One hour of agent time is $29.88. Twenty investigations a month averaging twelve minutes of agent time each:

20 x 720 seconds = 14,400 agent-seconds
14,400 x $0.0083 = $119.52 per month

| Line | Monthly | |---|---| | DevOps Guru, 400 group B resources | $1,226.40 | | CloudWatch, 60 anomaly detection alarms | $18.00 | | DevOps Agent, 20 investigations at 12 minutes | $119.52 | | Replacement total | $137.52 | | Difference | $1,088.88 |

That is $13,066.56 a year out of one account, and the reason is not that CloudWatch is cheap. It is that per-resource-hour billing charges you for every resource in the coverage boundary whether or not you ever alerted on it, while alarms charge you for the signals you chose. Teams that enabled DevOps Guru at the account level and left it there have been paying for breadth they never read.

Two caveats so the number stays defensible. If your DevOps Guru estate is mostly price group A, or you set coverage by stack rather than account-wide, your starting figure is lower and the gap narrows. And DevOps Agent billing scales with how much you use it, so a busy month of incidents costs more than a quiet one, which is the opposite of the fixed-breadth model you are leaving. Model it on your own incident count before you promise the saving to anyone. If telemetry spend is the wider problem, the volume controls in OpenTelemetry Collector cost control move more money than this migration will.

Export the insights now, because they are not retrievable later

AWS is explicit that "insights previously generated by Amazon DevOps Guru will no longer be retrievable" after 30 September 2027. There is no archive and no grace period, which is the same pattern as the template deletion in the AWS Proton end of support migration a few weeks ago. AWS keeps your running infrastructure and discards the service's own data.

Do both halves of the export, which is what AWS recommends too. Add an SNS notification channel to capture insights from now until the shutdown, and pull the backlog through the API:

# insights already accumulated, by time range
aws devops-guru list-insights \
  --status-filter 'Any={Type=REACTIVE,StartTimeRange={FromTime=2025-10-01T00:00:00Z,ToTime=2026-10-01T00:00:00Z}}'

# then the detail and the recommendations, per insight id
aws devops-guru describe-insight --id "$INSIGHT_ID"
aws devops-guru list-recommendations --insight-id "$INSIGHT_ID"
aws devops-guru list-anomalies-for-insight --insight-id "$INSIGHT_ID"

Whether that history is worth keeping depends on one question: has anyone read a DevOps Guru insight from more than a month ago? For most clients the answer is no, and the export is a half-day of work producing a JSON file nobody opens. For teams in a regulated SDLC where operational findings and their resolution are audit evidence, it matters, and the retention requirement decides the format rather than convenience. Export before you set coverage to None, because setting coverage to None stops the analysis that produces what you are exporting.

What we tell clients to do this month

October 2026 is not the migration. It is the part of the migration that has a deadline.

| When | Action | Why now | |---|---|---| | Before 29 October 2026 | Remove DevOps Guru enrolment from account baselines, account factory customisations and Service Catalog products | After this date the step fails on every newly vended account | | Before 29 October 2026 | Decide, in writing, whether any not-yet-enrolled account needs DevOps Guru through 2027 | The option expires and cannot be bought back | | October 2026 | Inventory every template, module and script referencing the two resource types | Cheap now, and it sizes the rest of the work | | October 2026 | Turn on the SNS notification channel for forward capture | Every month you delay is a month of insights you cannot export | | Q4 2026 | Build the replacement CloudWatch anomaly detection alarms and run them beside DevOps Guru | Running both proves the alarm set before you lose the comparison | | Q1 2027 | Remove the resource types from IaC and deploy | Ahead of the stack failures, not after them | | Before 30 September 2027 | Export the insight backlog, then set coverage to None | Stops the billing, in the right order |

The sequence matters more than the speed. Teams that remove the IaC first lose the ability to compare the old insights against the new alarms, and teams that set coverage to None first lose the export.

When to Get Help

Most of this is an afternoon per account. It stops being an afternoon when DevOps Guru enrolment is buried in a landing zone that three teams have forked, when the proactive insights fed a dashboard an executive looks at, or when you are being asked to replace a retired AWS service and adopt an agent with remediation permissions in the same quarter. Those are different problems and they should not share a change window.

We run AWS service retirements as scoped migrations: inventory, replacement built and proven in parallel, IaC cleaned up, billing confirmed down. If you want the DevOps Guru work sized against your own account inventory, or a second opinion on how much autonomy to give AWS DevOps Agent before it touches production, get in touch.