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.

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.

> ”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.

> 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).

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.

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???)

> 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.