Comment by IgorPartola
5 hours ago
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.
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.
> ”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.
Route 53 is one of the few intuitively named services they offer.
> 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).
That article pretty much describes every experience I have had with AWS. But worse was when I tried to use the free tier of Oracle Cloud to see what that is all about. Oh my god what a mess. I am not new to a lot of these things. I know how to configure TLS, boot a Linux or BSD box when a hard drive fails, how to set up proper subnets and firewalls, hell I have written network services using raw IP packets that I crafted directly in C. But figuring out how to work the Oracle Cloud UI was beyond me.
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.
The problem is these small customers never drive enough sales to bother with—you're better off investing in a feature for a large customer. And by the time small customers get large enough to need things like complex permissioning, they've outgrown Heroku and will be onboarding anyway. Giving startups credits really might be the most effective way to handle rough edges for small shops.
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.
I used Backblaze and strongly regretted it.
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.
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.
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.
If it is already in a DB, why wouldn’t that be treated as just a DB in the now peered Lightsail VPC?
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.
> ”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.