My Problem with AWS

I’ve been using AWS for about two years now. I first got exposed to it in a cloud computing class I took back when I was majoring in cybersecurity in college.

At first, I thought the whole idea behind cloud computing was kind of dumb. Like, why would I pay for a service that lives in “the cloud” when the cloud is really just someone else’s server sitting in a data center? In this case, that someone else is Amazon.

It also did not make a ton of sense to me because I already had my own on-premises “server” at home. Obviously, it was not on the same level as AWS in terms of compute power, scalability, availability, or anything like that, but for what I needed, it worked fine.

It was basically a Ryzen 7 3700X build with 64 GB of RAM, a bunch of M.2 SSDs and HDDs, and Proxmox installed on it. So, in my mind, I had basically built a PC, installed a hypervisor, and boom, I had my own server.

Was it anywhere near what AWS offers? No. Not even close.

But for me at the time, it got the job done.

The Classic AWS Billing Lesson

After a while, I started messing around with AWS more. I used the free tier, played around with some services, and eventually paid for a few things here and there.

Then I learned one of the classic AWS lessons: billing can sneak up on you.

This was something I had been warned about a lot, especially when we were doing labs in class. But after that class ended, I stopped using AWS for a couple of months.

The problem was that my AWS account was tied to my school email, and I barely checked that email unless I had to message a professor or handle something school-related. So, while I was ignoring that inbox, AWS was apparently sending me billing emails.

At first, it was small stuff. Like, 12 cents. Then maybe a dollar the next month. Then another small charge after that. You get the idea.

Eventually, my AWS account was basically shut down because of the unpaid balance.

At the time, I remember thinking, “Why would I even pay this? I’m probably never going to use AWS again.”

And then, of course, a couple of months later, I needed to use AWS again.

So I ended up paying what I owed, going through support, and eventually making a new AWS account with my personal email instead. That whole situation was annoying, but to be fair, it was also kind of on me. I should have been checking the email tied to the account.

But honestly, that is not even my main problem with AWS.

My Real Problem with AWS

My real problem with AWS is the naming.

AWS has some of the weirdest, most overcomplicated names for its services. Sometimes the names make sense once you understand what the service does, but when you are new, they can feel way more confusing than they need to be.

Take EC2, for example.

I understand why it is called Elastic Compute Cloud. Technically, the name makes sense. But when someone is first learning AWS, why not just call it something closer to what it actually feels like? Like a virtual machine service.

Because that is how most people are going to understand it at first.

To be fair, AWS does get some names right. IAM is a good example. Identity and Access Management makes sense. That name actually tells you what the service does. Beautiful. Amazing. No complaints there.

But then you have stuff like S3 and EBS.

Yes, I know S3 stands for Simple Storage Service. Yes, I know EBS stands for Elastic Block Store. But from the perspective of someone learning AWS, those names still feel kind of abstract.

Why not just call them something more obvious? Object storage. Block storage. Something like that.

It feels like AWS had to create its own naming system for everything, even when regular names already existed.

Why That Gets Annoying

I already know some people would argue that these services are not exactly the same as traditional infrastructure concepts. And honestly, that is fair.

S3 is not just “storage” in the same way a random hard drive is storage. EC2 is not just a regular virtual machine with no extra context. AWS services have their own features, integrations, and behaviors that make them different.

I get that.

But when you are new to AWS, the naming makes the learning curve feel worse than it needs to be. You are not just learning cloud concepts. You are also learning AWS’s specific language for those concepts.

And sometimes that language feels ridiculous.

For example, RAM is RAM. We all call it RAM. But I swear, if AWS had the chance to rename RAM, they would call it something like AWS RCHA, which stands for “RAM Compute High Availability” or some nonsense like that.

Obviously, I am joking, but that is the vibe some of these service names give off.

It is like they looked at a normal infrastructure concept and said, “How can we make this sound more confusing?”

I Know AWS Is Not Really Made for Me

Another thing I understand is that AWS is not exactly built for power users, home labbers, or random people who just want to mess around with a few cloud services.

AWS is built for enterprise customers. It is built for large companies, developers, engineers, DevOps teams, and businesses that need serious cloud infrastructure.

I get that.

But even then, I feel like the naming could still be better.

I am sure there are IT people, engineers, software developers, and DevOps teams at enterprise companies who have looked at certain AWS service names and thought, “Why is it called that?”

Because in a lot of other areas of tech, the names are more consistent.

For example, there are a bunch of companies that make PC parts. ASUS, MSI, Gigabyte, and others all make graphics cards. But at the end of the day, we still call them GPUs.

Intel and AMD both make processors, but we still call them CPUs.

There are different models, brands, architectures, and features, but the general name still stays the same. That makes it easier for people to understand what they are dealing with.

With AWS, it sometimes feels like every service needs its own branded name, even when a simpler name would probably make more sense.