AWS deprecates two dozen services (most of which you've never heard of)
36 comments
·November 15, 2025rs186
Anyone can predict what's going to happen with Amazon Q?
The only people that I know or have seen using Amazon Q are internal employees. Almost nothing on reddit.
easton
It’s definitely fine for a while, it’s the closest thing they have to an internal chatbot product and they need that to sell enterprises on adopting AWS.
IgorPartola
AWS has so many services at this point and it feels like so many of them overlap too. Seems like for a while they basically just took any open source project that was somewhat popular and offered a managed version of it. Plus there is a marketplace where others can offer services. The landscape is so vast it feels overwhelming to even try to get a basic layout.
For personal projects I end up avoiding AWS and instead prefer things like the Backblaze S3-compatible object storage, Vultr for VMs, and so on just to avoid the power user features that will only get in the way.
With that, I am curious how people who do not have an enterprise-size team to manage their AWS infrastructure navigate their offerings.
sethhochberg
I always find the idea that there's something to navigate kind of curious - as you say, its lots of managed versions of open source tools and a mix of proprietary management frameworks on top. Some of what they offer are genuinely unique products for niche use cases, but if you have that niche you probably know what services can support it, like the people in the other comments here mentioning the IoT APIs.
But me (or my teams) are rarely asking the question of "how should I run my service on AWS" in general, its much more typically "I need a managed Postgres database, what AWS product offers that" or "I have an OCI image, what managed platform can I run that in" or even "I want this endpoint to be available all the time, but its usage is very unpredictable/intermittent, so I don't want to pay for idle compute". There might still be a couple of possible answers for those questions, but by the point I arrive there I'm solving for a specific problem.
Its sort of like walking into a kitchen hungry and seeing 3 knives and a stove and oven and a dozen peelers and can openers etc etc and being very overwhelmed by all of this (do I need the knife with a smooth edge or the serrated one?) until you decide you want to eat a grilled cheese, and then grabbing a skillet to put onto a burner and everything making sense once you actually start to cook a specific thing.
tyre
They've gotten much better at streamlining setup and suggesting sane defaults over the years. I hear the GP that there soooo many knobs. I've found that AWS does a pretty good job, like in the postgres compatible RDS case, of suggesting defaults that make sense for most people. And when you run into issues / scaling problems, you can Claude your way to which settings to research.
The only one that still drives me insane is IAM. That product makes me feel dumb every time I use it, even for simple use cases like "I want a managed redis compatible instance that can only be accessed by these resources." The groups and users and roles and VPCs have never felt intuitive to me, despite having a clear idea of what I want the end state to be.
mooreds
> For personal projects I end up avoiding AWS and instead prefer things like the Backblaze S3-compatible object storage, Vultr for VMs, and so on just to avoid the power user features that will only get in the way.
The author wrote an article about this too: https://www.theregister.com/2025/11/04/aws_genz_misery_nope/
> With that, I am curious how people who do not have an enterprise-size team to manage their AWS infrastructure navigate their offerings.
I've been a startup CTO that used selected AWS infra (s3 buckets, RDS) along with an easier PaaS solution (Heroku, in my case). So I think the answer to your question is: using some of the managed services, which are rock solid, and using easier solutions for compute or some of the more complex AWS services.
I know folks who started similarly, but then moved to AWS fully when it made business sense (in one case, because of HIPAA regulations and the cost difference between AWS and Heroku for the BAA).
Reason077
> ”AWS has so many services at this point and it feels like so many of them overlap too.”
Yep. I’ve also always found it frustrating how so many of them have names like “Snowball”, “Kenesis”, “Beanstalk”, “Fargate”, “Aurora”, etc, which don’t give you any real clue what they do.
dehrmann
Route 53 is one of the few intuitively named services they offer.
raw_anon_1111
In that case, you can still just use AWS Lightsail. It’s a simple service where you just spin up an EC2 and pay one price for VPC and an allotment of outbound data (inbound is free). You never have to worry about costs going out of control, VPCs, networking etc.
When you do need to graduate to real AWS, you can and your former Lightsale set up is treated like a VPC you can peer to.
sgarland
Except for the DB. The official way to migrate from a Lightsail DB to RDS is to do a logical dump and restore.
For MySQL, or if you have a monotonic column in Postgres, that might be doable if you dumped in parallel, but otherwise it’s an unacceptable amount of downtime when you reach the limits of Lightsail.
It is baffling to me that AWS doesn’t offer a one-click option to B/G from Lightsail —> RDS, as that’s a very reasonable growth pattern for many startups.
raw_anon_1111
If it is already in a DB, why wouldn’t that be treated as just a DB in the now peered Lightsail VPC?
pram
From my observations over the years a lot of “services” should literally just be features in stuff that already exists. Like Flink should have just been under MSK instead of the confusing mess it has gone through (first branded as part of Kinesis???)
YetAnotherNick
> enterprise-size team to manage their AWS infrastructure navigate their offerings.
You don't. You start with a problem and find solutions, not navigate solutions to make problems for. And even the worst AWS service I interacted has world class documentation and support.
Reason077
> ”You start with a problem and find solutions, not navigate solutions to make problems for.”
Ideally. But that’s often not how corporate IT works.
cperciva
AWS has done its quarterly housecleaning / “Googling” of its services
Note: This is actually two quarters of Googling, because they were revising their process during Q3 and put deprecations on hold.
null
topher200
This article is from mid-October.
gnabgib
Discussion (69 points, 1 month ago, 35 comments) https://news.ycombinator.com/item?id=45572613
Ayesh
Thank you. The linked third party article is a terrible incomplete rehash.
learned
CodeCatalyst is pretty surprising on that list. Maybe it tried to do too much?
Also, the deprecation alert on the CodeCatalyst site is incorrect at the moment:
> Important Notice: Amazon CodeCatalyst is longer open to new customers starting on November 7, 2025
raw_anon_1111
In my experience, any time AWS tries to create a service outside of the primitives, it’s a mess.
tyre
I'm guessing it's just harder to dogfood in a way that others can use without all of the other internal-only infra (including dev tooling) available internally. And to get to the point where you could dogfood at AWS scale, anything that's difficult to adopt incrementally is going to be a pain.
raw_anon_1111
Exactly, no one internally is going to use something like Amplify or Code Catalyst. That’s like internal developers didn’t use CodeCommit (AWS’s now deprecated Git service).
Even though it did hurt me when they got rid of CodeCommit. I work in consulting and I always ask for my own isolated dev AWS account in their organization with basically admin access. It was nice to just be able to put everything in CodeCommit without dealing with trying to be a part of their GitHub organization if their was red tape.
I miss Cloud 9 too. I didn’t have to bother with making sure their computers were setup with all of the pre requisites and it gave me a known environment for the handover
more_corn
Elastic beanstalk or GTFO
odie5533
I think they accidentally convinced too many people to use it and now they can't get rid of it.
hinkley
Does the service list fit on a 4k monitor with these removed?
CobrastanJorji
Man, deprecating an IoT APIs isn't going to affect most folks, but the folks it does affect are gonna be in a fuckload of trouble.
cowsandmilk
It says existing customers can continue to use the IoT apis, just not new customers.
Aurornis
AWS has been good at leaving deprecated services running for existing customers for a long time. They’re doing that here.
They’re deprecating it for new use cases.
NewJazz
Wasn't there a big post about this a few weeks ago?
I like how the article uses "Googling" as a verb meaning to shut down a service