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.
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
- Find every dependency. Search your repositories for
AWS::DevOpsGuruand DevOps Guru API calls.
- Capture new insights. Create an Amazon SNS notification channel so insights are archived until support ends.
- Export your history. Use the DevOps Guru API to export the insights you have already accumulated.
- Rebuild your alerting. Recreate the signals that matter as CloudWatch anomaly detection alarms.
- 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.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article