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.
> 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'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.
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.
Yes, but when your starter project takes off and you start to get serious traffic, there’s no good path to migrate off. It’s all very manual, and involves a fair amount of downtime unless you have the requisite knowledge to set up logical replication; even then, unless you know how to chain replication, you’re going to thrash your buffers, and cause slow queries for existing traffic.
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.
I see what you are saying but we are speaking of slightly different things. Let’s say you need a piece of software that effectively is full text search but you don’t know that such a thing exists. Since you don’t know what you don’t know you are at a disadvantage when looking for a solution. But knowing that something like Elastic Search or Postgres’ full text search is a thing will mean that I can have a starting point to look at what is possible.
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.
AWS really needs to focus on simplifying their offerings for the next generation that is not very "computer savvy" for starters. You can host a website on ec2, you can also host it on elastic beanstalk, you can also host it on lightsail? See the problem? Instead of making us focus on how to adapt to your services, why not focus on how you can adapt to the customer needs. Introduce something called AWS WebServer or something and deprecate everything else except EC2. let people run their docker and lightsail and static hosting from this Amazon WebServer service. Do the same for databases. Why offer a separate Amazon Aurora postgres and an amazon RDS. Offer a service called Amazong DB and let the user decide if it is posgres, server oriented, serverless from there. Let it also handle dynamoDB
AWS makes money being the Hoster of Fortune 500 companies. They want lots of complicated shit. AWS has no problem that hobbyists or small business choose simpler solutions elsewhere
Ah good old IoT Greengrass and Lambda that made me fail a job interview as it was my only AWS experience and the interviewers didn't belief it existed.
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.
Anecdotally, I tried using Amazon Q when trying to generate configs and get questions answered for Aws ses configs. However even though: the icon was on my screen and fully functioning and I could enter a question, I could not send the question or use it because my admin had not granted my dev profile access to use Amazon Q.
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.
They tried to do a LOT. An absolutely huge amount of work trying to abstract all of the existing Code* services, big chunks of other AWS services, and then corp (and non corp!) identity. The last part, getting human identity in to AWS, is such a fundamental gap. In the end its unsurprising that they couldnt get to a competitive place against gitlab/github/etc. I do hope theres more success with identity center picking up some of those IdP pieces.
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.
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
Why do you think they’re “lazy”? The point is usually to bait you: “You’ll never guess this one weird trick!”
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.
Discussion (69 points, 1 month ago, 35 comments) https://news.ycombinator.com/item?id=45572613
Thank you. The linked third party article is a terrible incomplete rehash.
I mean, I liked the explanation of what the services were, and why I should care, versus just a simple list…
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?
Your options are severely limited for Lightsail; it maxes out at 8 GB RAM and 240 GB storage for a DB.
Isn’t that enough for a starter project as a hobbyist?
Yes, but when your starter project takes off and you start to get serious traffic, there’s no good path to migrate off. It’s all very manual, and involves a fair amount of downtime unless you have the requisite knowledge to set up logical replication; even then, unless you know how to chain replication, you’re going to thrash your buffers, and cause slow queries for existing traffic.
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.
I see what you are saying but we are speaking of slightly different things. Let’s say you need a piece of software that effectively is full text search but you don’t know that such a thing exists. Since you don’t know what you don’t know you are at a disadvantage when looking for a solution. But knowing that something like Elastic Search or Postgres’ full text search is a thing will mean that I can have a starting point to look at what is possible.
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.
> ”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.
AWS really needs to focus on simplifying their offerings for the next generation that is not very "computer savvy" for starters. You can host a website on ec2, you can also host it on elastic beanstalk, you can also host it on lightsail? See the problem? Instead of making us focus on how to adapt to your services, why not focus on how you can adapt to the customer needs. Introduce something called AWS WebServer or something and deprecate everything else except EC2. let people run their docker and lightsail and static hosting from this Amazon WebServer service. Do the same for databases. Why offer a separate Amazon Aurora postgres and an amazon RDS. Offer a service called Amazong DB and let the user decide if it is posgres, server oriented, serverless from there. Let it also handle dynamoDB
AWS makes money being the Hoster of Fortune 500 companies. They want lots of complicated shit. AWS has no problem that hobbyists or small business choose simpler solutions elsewhere
Ah good old IoT Greengrass and Lambda that made me fail a job interview as it was my only AWS experience and the interviewers didn't belief it existed.
Does the service list fit on a 4k monitor with these removed?
Horizontal or vertical orientation?
It’s been a while since I was dumb enough to try to use the menu system. What a useless sea of unhelpful product names and icons.
Doesn’t it adjust? But in any case, does it fit in any orientation at all?
This article is from mid-October.
Thanks, but the date is at the top of the article.
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.
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.
Anecdotally, I tried using Amazon Q when trying to generate configs and get questions answered for Aws ses configs. However even though: the icon was on my screen and fully functioning and I could enter a question, I could not send the question or use it because my admin had not granted my dev profile access to use Amazon Q.
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.
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
https://codecatalyst.aws/explore
They tried to do a LOT. An absolutely huge amount of work trying to abstract all of the existing Code* services, big chunks of other AWS services, and then corp (and non corp!) identity. The last part, getting human identity in to AWS, is such a fundamental gap. In the end its unsurprising that they couldnt get to a competitive place against gitlab/github/etc. I do hope theres more success with identity center picking up some of those IdP pieces.
In my experience, any time AWS tries to create a service outside of the primitives, it’s a mess.
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.
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
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.
Reminds me of the '168 AWS Services in 2 minutes' song
https://youtu.be/BtJAsvJOlhM
Wasn't there a big post about this a few weeks ago?
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.
It says existing customers can continue to use the IoT apis, just not new customers.
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.
Elastic beanstalk or GTFO
I think they accidentally convinced too many people to use it and now they can't get rid of it.
I like how the article uses "Googling" as a verb meaning to shut down a service
Thank you, I failed to understand what he means.
language rant: titles with assertions that "you" have or have not $whatever...they seem lazily worded.
Why do you think they’re “lazy”? The point is usually to bait you: “You’ll never guess this one weird trick!”
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.
bait is definitely a better description, though i still think bait could be more effectively worded.