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.
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.
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.
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.
Note: This is actually two quarters of Googling, because they were revising their process during Q3 and put deprecations on hold.
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
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.
Doesn’t it adjust? But in any case, does it fit in any orientation at all?
They’re deprecating it for new use cases.
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.