Opinion For years, Google has seemingly indulged a corporate fetish of taking products that are beloved, then killing them. AWS has been on a different kick lately: Killing services that frankly shouldn’t have seen the light of day.

The first was Amazon Sumerian (tagline: “You’re making that service up, right?”), which was followed over the years by a host of others, ranging from Honeycode (tagline: “What if we made a no-code platform that nobody asked for?”) to QLDB (“It’s awesome but nobody can seem to explain quite why”) to the Snowball Edge (“Please never Google either of those words”).

An unprecedented reversal

And yet, this week, we’re seeing what to my knowledge is the first time a hyperscaler has deprecated a product, then resurrected it. The service that AWS revived is Amazon CodeCommit (“What if GitHub had a UI that was forty times worse?”). This is a big deal, if for no other reason than it demonstrates that somewhere within the belly of the Amazonian beast, someone is still listening to customers and advocating for them.

The timeline

AWS announced CodeCommit at re:Invent way back in 2014. It was one of the original AWS services that started with the word “Code.” It went GA in July of the following year.

Customer response was largely tepid. If you’re used to GitHub, or GitLab, or even using git via CLI, the command-line experience was less than terrific, and hopes that this would improve eventually died.

It would have been far easier to quietly say nothing and deprecate it anyway

Last year, in 2024, Amazon announced that the service would be deprecated, by which they meant “not accepting new customers.”

Of course, if you’re not gonna invest in a thing, don’t let people use it as if you were still going to improve it. That only serves to tarnish your brand.

And then in the week before re:Invent 2025, AWS announced it was reversing course, which brings us up to the current day.

The mea culpa

What struck me about the company’s revival post is that they’re actually apologizing to customers. “If you invested time and resources planning or executing a migration away from CodeCommit, we apologize,” Amazon wrote. Think back to the last time you saw an apology for something that wasn’t a service outage. Pretty short list, right?

Why would they do this?

It turns out that you or I as individuals who may write code for fun and/or shitposting may not be the entirety of AWS’s customer base. They talk about CodeCommit’s “deep IAM integration, VPC endpoint support, CloudTrail logging, and seamless connectivity with CodePipeline and CodeBuild,” of which approximately zero developers who are building something out of love care about.

These are all big-E Enterprise concerns, and there is some distinct value here in having a native git repository option. A decade ago, I had to use S3 as a git repo backend for enterprise compliance reasons, and it was exactly as painful as you’d expect.

Being able to keep everything, including your code, inside of your AWS organization’s boundaries is no small thing with respect to reducing your auditable surface area, and without this, customers were looking at self-hosting all manner of nonsense to cope. I’m not surprised customers want this. I’m more surprised that a large company listened.

The plot twist

The thing that strikes me the most about AWS CodeCommit’s resurrection is that Amazon is not begrudgingly bringing it back – they’re actively investing in it. First up is an implementation of git-lfs to support large files and other binaries that really don’t belong in your git repositories but we all screw up and put there anyway.

They’re expanding to additional regions, which is a bigger deal for AWS than almost anyone would believe, which is why they’re always very impressed with themselves when they do a regional expansion but don’t seem to understand that virtually no customer cares unless they’re blocked on a particular region. And while I could point out that this was the sort of investment that they could have made far earlier when customers were still optimistic, better late than never.

This is a good thing

I want to be clear here: This is a very good thing that AWS has done. It would have been far easier to quietly say nothing and deprecate it anyway, or scrub the deprecation warnings and pretend nothing happened, or (most AWS-ian of all, it seems) launch a new service with a different bad name that does the same thing but costs more. They did none of this, instead choosing to own the misstep and take steps to correct it.

I don’t have any patience for whatever the hell the corporate version of speaking ex cathedra is, because I have little if any use for anyone who cannot be wrong about anything. That leads to some of the most odious blowhards you’ll ever meet in any walk of life. It’s refreshing to see AWS admit they were wrong about something and reverse course entirely. ®