Much like the noble duck-billed platypus, it’s easy to round AWS’s service deprecation policy to “it doesn’t exist,” but in both cases, that’s not exactly accurate.
AWS does indeed turn things off in the fullness of time. The problem is that it simply fails to talk about them in quite the same way as it does for new service or feature launches.
I have no problem with AWS deprecating things. If anything, I wish they did it slightly more frequently in service of a consolidation for customers. In an ideal world, there wouldn’t be 17 ways to run containers; there’d be perhaps five. Let’s break down four noteworthy examples of AWS service deprecations — and why you might not have heard about them.
As a quick review, Lambda runtimes are environments that offer specific versions of specific programming languages that AWS maintains. In the fullness of time, things like NodeJS 4.3 and Python 2.8 are no longer supported by upstream, and you absolutely do not want customers building on top of them. On the other hand, you don’t want to break things that are working well for existing customers. It’s a dilemma that AWS has solved rather elegantly.