First +10 years of AWS service lifecycle management was just continous stream of announcements about new services and features. And many (most?) of the services that got out to public are still there with backwards compatibility all the way to the beginnings. But it isn’t realistic to think one could just continue building new stuff year after year. At some point you must start end-of-life process for features and services that no longer meet customer demand, have been replaced by more efficient alternatives or have become blocker for future development.

AWS Services

In the past there was no that many complete services being depricated but this year (2024) AWS has been busy with EOLs. Some of these services weren’t really main stream so if you haven’t heard of Amazon Lookout for Vision|Metrics|Equipment or Monitron, you’re not alone. But that was a whole set of industrial AI/ML services that were put into maintenance mode, with many others, in October 2024.

Similar, but more main stream, clean up did happen in development tools where CodeCommit, CodeStar and Cloud9 are no longer available for new customers.

Common way for AWS to depricate a service or feature, is block new customers from start using it. It can be that your existing deployments will continue work, and you might be able to make changes too (but not always) or you could even be able to deploy new instances of service on accounts where you had given service in use.

Any deprication can have a major effect for a customer if critical services are build to depend on it, but in global scale there is one breaking change that will dwarf all others …

EC2 Autoscaling Launch Configurations

Through a series of deprecations spanning multiple years, AWS is slowly killing off EC2 Auto Scaling Launch Configurations in favor of EC2 Launch Templates. On October 1, 2024, only those accounts that have previously used Launch Configurations can continue to do so.

While this has been public information since October 2021, I think there are still a lot of ‘legacy’ Cloudformation and Terraform code depending on launch configuration being available. Just a simple search from aws-samples github repositories found +180 references to Cloudformation resource type AWS::AutoScaling::LaunchConfiguration

Now after October 1st, 2024, those templates will continue work if you have previously used launch configurations on the account, but on any account that was created after October 1st, or didn’t previously have launch configurations, the same template will fail.

Conversion process from launch configuration to launch template isn’t very complex in most of cases, but tricky part can be finding the all the code and CI/CD processes. For services that are not in active development mode this can be a challenging reverse engineer task.

3rd Party Software

When the service is all about hosting 3rd party software, there is obvious dependency to availability and support for given software version. Major services in this category are

For databases minor and even major version upgrades are often backwards compatible, so your application will work with next version without changes. Upgrade effort is then reduced to testing (which shouldn’t be underestimated) and scheduling the upgrade. However it can be your application is certified only with certain versions and while it could work after upgrade, loosing your application vendor support might be too risky for business critical service.

Kubernetes control plane (EKS) upgrades takes a bit more planning because there is no warranty new version is compatible with previous one. It is your responsibility to judge if breaking changes between versions are something you should be worried or not. To resolve upgrade issues you might need to make changes to your applications or find a new combination of versions for middleware services you run in the cluster.

If you feel dead-lines for RDS and EKS updates are coming too fast for you, there is an option to buy extra time but it doesn’t come for free.

For Lambda the serverless promise was you don’t need to manage servers (OS) or runtimes. While that is true, no-one ever said you can just deploy and be done with it. When Lambda runtime is deprecated functions you have deployed will continue working but you can not create any new or update existing functions, ie. deploying bug fixes or new features to your code isn’t possible. Python 2.7 EOL announcement is old but good example how Lambda runtime EOL process works.

Keep Yourself Updated

I wish there would be a single timeline of all EOL plans for AWS services. Unfortunately there isn’t, or if you find one, please let me know too. The Best thing I’ve found is aws_breaking_changes -git repo mainteined by Scott Piper. README has the list recent and upcoming deprecations, or breaking changes. Past changes are archieved in archive.md.

EDIT: Also aws-news.com dedicated feed for service deprecations is worth subscribing to.

Other good sources are AWS service documentation (e.g. above links for RDS, EKS & Lambda) and subscribing AWS blogs from categories that are most relevant for you.