Reading AWS's Next 3 Years from re:Invent Announcements - Service Lifecycles and the Rules of Deprecation
Face the reality that AWS services have lifespans, examining cases like CodeCommit's enrollment freeze and SimpleDB's de facto end, and provide a technology selection perspective for identifying services that will endure.
AWS Services Have Lifespans Too
AWS has long operated on an implicit trust that "once a service is released, it won't be deprecated." However, the situation changed in July 2024. AWS announced that several services - including CodeCommit, Cloud9, S3 Select, CloudSearch, and SimpleDB - would stop accepting new customers. Existing customers could continue using them, but no new features would be added. OpsWorks Stacks was fully terminated in May 2024. These moves clearly demonstrate that AWS services have lifecycles and are not permanent fixtures. The assumption that "it's an AWS service, so it's safe" no longer holds unconditionally in technology selection.
Common Traits of Deprecated Services
Services that have been deprecated or scaled back share common patterns. SimpleDB was released in 2007 as one of AWS's early NoSQL databases, but rapidly lost relevance after DynamoDB launched in 2012. It disappeared from the AWS service listing and became inaccessible from the console, though its API was maintained for years. New customer enrollment was finally stopped in 2024. CodeCommit was AWS's managed Git repository service but couldn't compete with dedicated services like GitHub and GitLab. Cloud9 was a browser-based IDE that became difficult to differentiate against VS Code's remote development features and GitHub Codespaces. OpsWorks was a configuration management service using Chef and Puppet, but demand for traditional configuration management tools shrank as containers and serverless gained adoption. What these share in common is that superior alternatives emerged, they were peripheral tools rather than core AWS infrastructure, and their user counts fell below a certain threshold.
The Four Stages of a Service Lifecycle
AWS service lifecycles can be divided into four stages. The first stage is Preview. Services are announced at events like re:Invent and offered as limited previews. At this stage, there is no SLA, APIs may change, and they are not suitable for production workloads. Notably, some services remain in Preview and never reach GA. The second stage is GA (General Availability). SLAs are established and production use becomes possible. However, services immediately after GA may have incomplete documentation or unstable behavior in edge cases. It's prudent to allow about a year after GA for careful evaluation. The third stage is Maturity. Features stabilize, best practices are established, and an ecosystem (third-party tools, community, books) forms. S3, EC2, Lambda, and DynamoDB are at this stage, receiving continued large-scale investment as pillars of AWS revenue. The fourth stage is Decline/Consolidation. New feature additions stop, documentation update frequency drops, and mentions at re:Invent disappear. Eventually, new customer enrollment is frozen or migration to successor services is recommended.
Conditions for Services That Endure
Services that persist long-term share common characteristics. First, they serve as foundations for other services. S3 is used as a data store by numerous AWS services, making its deprecation virtually impossible. EC2 is the execution platform for ECS, EKS, RDS, Redshift, and many other services. IAM is the authentication and authorization foundation for all services. These foundational services have extremely high deprecation costs due to the depth of their dependencies. Second, they are pillars of AWS revenue. EC2 and S3 account for a significant portion of AWS sales, ensuring continued investment. Third, they are tied to industry standards and open-source ecosystems. EKS is tied to Kubernetes, RDS to PostgreSQL and MySQL, and Lambda to the FaaS (Function as a Service) concept itself. Services based on industry standards will have successors provided as long as the standard persists. Conversely, services based on AWS-proprietary technology with weak ties to industry standards face higher deprecation risk when alternatives emerge.
A Practical Framework for Technology Selection
When deciding whether to adopt a new AWS service, the following framework is effective. First, check how long the service has been since GA. Services that have been GA for over two years with continuous feature additions are likely entering maturity and represent stable choices. Next, verify whether the service serves as a foundation for other AWS services. Services frequently referenced in AWS documentation and architecture guides occupy a central position in the ecosystem and can be judged as low deprecation risk. Then, ask yourself the most important question: what would you do if this service didn't exist three years from now? Designing an exit strategy in advance is the greatest risk mitigation measure in technology selection. Specifically, rather than depending directly on service-specific APIs, adopt designs with abstraction layers that make service switching easier. Secure data export mechanisms and periodically verify that exports work correctly. Research alternative service candidates in advance and roughly estimate migration paths. To deepen your knowledge of technology selection and architecture decisions, related books (Amazon) can also be helpful.
Summary
AWS services have lifecycles and are not permanent. The 2024 enrollment freezes for CodeCommit, Cloud9, SimpleDB, and others made this fact clear. The conditions for enduring services are: serving as foundations for other services, being revenue pillars, and being tied to industry standards. In technology selection, always carry the question "what if this service doesn't exist three years from now" and design exit strategies in advance - this is the key to building long-term stable systems.