AWS Builder Center

AWS Is Retiring 7 Services: A Builder’s Survival Guide for 2026–27

Seven AWS services are closed, closing or already gone. This guide gives you the dates, a migration plan for Amazon DevOps Guru, and the habits that keep your stack safe from surprise retirements.

Undergrad Software Engineering Student at UBIT

Introduction

Most builders follow AWS launches closely. Far fewer follow AWS retirements, and that is how a team ends up reading an “end of support” notice with no time left to react.
In September 2026, AWS published a batch of service availability changes. Seven services are now closed to new customers, scheduled for sunset, or already out of support. This article lists them with their dates, walks through a migration plan for the most widely used one, and ends with a short checklist you can apply today.

The 7 Services and Their Dates

Service
Status
Date
Amazon Mechanical Turk
End of support
Sept 29, 2026 (already in effect)
Amazon Chime SDK SIP Media Application
Maintenance (closed to new customers)
Oct 29, 2026
Amazon WorkSpaces Secure Browser
Maintenance (closed to new customers)
Oct 29, 2026
AWS Infrastructure Composer (standalone console)
End of support
Dec 7, 2026
Amazon Managed Blockchain
Sunset
Sept 29, 2027
AWS Backint Agent for SAP ASE
Sunset
Sept 29, 2027
Amazon DevOps Guru
Sunset
Sept 30, 2027
Two points are worth noting:
  • Infrastructure Composer’s standalone console is the nearest deadline. Check your team’s bookmarks, runbooks and documentation now.
  • “Maintenance” does not mean “broken.” Existing customers can keep using those services, but new projects cannot start on them.

Deep Dive: Planning Your DevOps Guru Exit

Amazon DevOps Guru is the most widely used service on the list, so it deserves a real plan. Here is what AWS documents.
Until September 30, 2027:
  • The service keeps working, with security patches and critical bug fixes.
  • No new features will be added.
  • It stops accepting new customers on October 29, 2026.
After September 30, 2027:
  • The console and API are no longer available.
  • The  AWS::DevOpsGuru::*  resource types are withdrawn, so CloudFormation, CDK or Terraform code that still references them will fail.
  • Insights generated by the service can no longer be retrieved.
  • Your workloads are not affected. DevOps Guru is a monitoring service, so you lose visibility, not uptime.
Migration targets named by AWS:
  • Amazon CloudWatch for metric anomaly detection and alarms.
  • Amazon DevOps Agent for AI-assisted investigation of operational issues.

A Five-Step Migration Plan

  1. Find every dependency. Search your repositories for  AWS::DevOpsGuru  and DevOps Guru API calls.
  1. Capture new insights. Create an Amazon SNS notification channel so insights are archived until support ends.
  1. Export your history. Use the DevOps Guru API to export the insights you have already accumulated.
  1. Rebuild your alerting. Recreate the signals that matter as CloudWatch anomaly detection alarms.
  1. Clean up your IaC. Remove DevOps Guru resources from your templates before they break a deployment.

What Is Taking Their Place

AWS is also shipping a wave of agent-focused services:
  • Amazon Bedrock AgentCore harness (generally available since June 2026): define a model, system prompt and tools, and AWS runs the agent loop. It supports multiple model providers and managed memory, with pay-per-use pricing.
  • Amazon Bedrock Managed Agents powered by OpenAI (public preview): agents that run inside your AWS account under your existing identities, permissions and governance controls.
  • Kiro workflows: multi-agent task execution with less supervision.
  • AWS Well-Architected Agent (preview): analyzes your environment and gives recommendations on cost, security, performance and resilience.
In my view, and this is my own interpretation rather than an AWS statement, the pattern is clear. Many retired tools were consoles that people operate by hand, while many new launches are agents that operate on your behalf. DevOps Guru naming DevOps Agent as a migration target fits that trend.

A 10-Minute Survival Checklist

  • Subscribe to AWS service availability updates so retirements never surprise you.
  • Inventory which retiring services you use, and assign an owner to each migration.
  • Use infrastructure as code. A stack you can read is far easier to migrate than one built by clicking.
  • Favor durable primitives such as Amazon S3, AWS Lambda and Amazon CloudWatch for workloads that must last years.
  • Ask an exit question before adopting any new service: “What is my plan if this changes?”

Conclusion

Retirements are a normal part of a platform that keeps moving, and they only hurt when you find out late. Review the list above, pick one service you rely on, and write down its exit plan this week.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article