AWS’s Deprecation Policy Is Like a Platypus
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.
1. Lambda Runtimes
The first is something of a gimme: AWS has a published deprecation policy for Lambda runtimes.
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.
In short, AWS splits the deprecation into two phases. In the first phase, you can no longer create functions that use the existing runtime, but you can update existing functions that are already using it. This is a decent compromise, and it’s accompanied by emails warning customers who are running affected runtime versions what’s happening.
In the second phase of the deprecation, AWS blocks updates to existing functions on the deprecated runtime as well. In other words, it becomes frozen in time like a fly in amber; any further changes to that function require that it be updated to a supported runtime version. This strikes an elegant balance between “keep your stuff updated” and “not destroying customer applications out from underneath them.”
2. S3 BitTorrent Support
The second example of AWS deprecating something goes back to the mists of yesteryear, when we had a radically different internet than we do today. Bandwidth was constrained in many cases, and AWS was cognizant of this. Originally, S3 supported BitTorrent as a native function. The internet has evolved, BitTorrent isn’t nearly as useful at solving (legitimate!) problems as it once was, and AWS began deprecating the capability slowly, in stages.
Initially, it stopped supporting BitTorrent entirely in S3 regions that were launched after 2016. This makes sense; there were no users of the feature because the regions were new and had no users to begin with, so it wasn’t that big of a concern.
Next, AWS stopped supporting enabling the feature as of April 29, 2021. At the same time, AWS said that BitTorrent would stop working for existing users after 12 months. Since there was no public announcement (indeed, most of the buzz around this came out two months later, when someone spotted a change to the documentation), it would be easy to believe that they simply broke existing users.
I don’t accept that narrative. Given what I know about AWS, I strongly suspect that it reached out to impacted customers directly and individually. After all, how many S3 users could there really be that were still using BitTorrent in 2021? Since the only hue and cry that was raised was apparently by folks who weren’t using the feature itself, I’m reasonably confident in that assessment.
3. Amazon Sumerian
Amazon Sumerian was launched at Midnight Madness at re:Invent 2017. I was in the room; indeed, it was the first re:Invent that I ever attended!
It was always a bit of an odd service: It was an AR/VR-aligned offering that let people build virtual worlds, characters, and the like. It was a bit goofy at the time. Only recently, with talk about the metaverse hitting a fever pitch, did the service really start to make any kind of particular sense.
So it was rather surprising when I went to the Amazon Sumerian site to see what was being talked about, only to encounter a very terse pair of sentences:
“Amazon Sumerian will be transitioning the existing experience and functionality to allow customers to author scenes using Babylon.js and publish with AWS Amplify. The Amazon Sumerian service is no longer accepting new customers.”
This is singularly odd as far as deprecations go. This tells me that either there were so few customers that it wasn’t worth maintaining or that the customers who tried it all evacuated it after their trial, citing that it didn’t solve a real problem that they had.
Let’s be clear: If a service isn’t working for customers, it should absolutely be shut down. It was just odd that I didn’t hear more about this as the process unfolded.
4. RDS on VMware
In 2018, AWS announced that RDS on VMware was a service in public preview that let customers run RDS instances on-prem within vSphere. While not for me, it’s certainly something that an awful lot of customers would have interest in.
Recently I came across a mention of the service and was somewhat surprised to learn that while some old blog posts still reference it, it’s still called out in VMware’s documentation, and there’s clearly still a strong VMware + AWS partnership, all traces of this service are gone.
A visit to the RDS on VMware product page results in a redirect, not to their current partnership service VMware Cloud on AWS, but rather to their standard RDS marketing page.
I can only assume this was a corporate deal that expired or a new partnership supplanted the old. No matter how you look at it, it’s damned odd for a service developed in partnership with VMware and loudly trumpeted by both companies to just disappear down the memory hole. Even Google Cloud is better about announcing its deprecations.
The deprecation is real
There you have it: Four different pathways to deprecation that AWS has trod over the past few years. Some approaches are more customer- or partner-friendly than others, while others are painfully slow or silently abrupt. One thing all four deprecations have in common is that I’ve yet to encounter a single customer who’s upset that something they were actively using was yanked away from them.
Given AWS’s perspective on long term support of their services, I’m not entirely sure that I ever will find one. After all, you can still sign up for SimpleDB.