They’re deprecating it for new use cases.
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
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
Doesn’t it adjust? But in any case, does it fit in any orientation at all?
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.
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.
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.
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.
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.
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.
Ideally. But that’s often not how corporate IT works.
Imagine for a moment that you didn’t know that S3 was a thing. You would end up rolling some sort of home grown solution that would be less robust and possibly more expensive. You don’t need to use it, but knowing that it exists and being able to reason about its basic promise is a good thing.
AWS has grown so huge that they have everything from hosted Valkey to satellite launchers. And knowing that launching satellites is an option is valuable, but unless you know to look for it you won’t find it. And the larger the number of offerings the more difficult it is to keep up with what is possible.
To bring it back to the concept of an enterprise team to manage stuff, doing something like managing 10,000 EC2 instances manually is less good than using something like Cloud Formation. But is Cloud Formation better than some other orchestration system? You can hopefully see where this is going.
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).
As a startup, I'd probably bite the bullet of one-time setup pain for a database, blob store, load balancer, and service hosting at a major cloud provider because those systems will be rock-solid with well-understood APIs. Full disclosure: I work for a major cloud provider.
Wonky bandwidth limits and throttling are my main problem, but also had some issues with login at one point which apparently wasn't unique to me. Would never trust it for anything mission critical after that.
The nice thing about S3 is even if you screw up your usage patterns, you can pay/engineer your way out guaranteed. You can slurp up as much data as you want as often as you want and it may not be cheap, but it will work and it can be made extremely fast.
I'm coming to find that's not universal for these S3 compatible services. Really scary to build a business knowing that.
It almost feels like if you were not there to see these interfaces in their infancy and didn’t grow up with them then you will not get their current much more complex form.
Back in 2008 I worked for an organization that relied heavily on an IBM mainframe and employed a department of people who managed it and wrote software for it. The divide between those folks and those who grew up on Linux/BSD was so solid that if someone asked me to switch teams I honestly wouldn’t even know where to start learning. This is kind of what this feels like.
To be fair I have successfully deployed multiple things with AWS. But it is always by mostly using things like EC2, Route 53, S3, and sometimes CloudFront. Tried their app engine and container runner and went back to running Docker on a Linux VM as a saner solution.
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.
Note: This is actually two quarters of Googling, because they were revising their process during Q3 and put deprecations on hold.
The only people that I know or have seen using Amazon Q are internal employees. Almost nothing on reddit.
And my guess is that people have that same experience and give up. Because the admin permissions are probably stored in a yaml config somewhere and it will require a meeting with a devops admin and ultimately be a huge waste of time for answering 1-2 questions.
jjtheblunt•2mo ago
devin•2mo ago
Here it actually makes some sense. There are _so_ many AWS services. It’s similar to the quiz about AWS service icons that demonstrated that not only are the icons broadly unknown, there are myriad unknown services which further complicates things.
jjtheblunt•2mo ago