upvote
I get why it's like this.

Some background. I work at an Amazon sub. This is a good UI for the way we work. We don't spin up a single machine pretty much ever unless it's a cloud dev machine, at which point the price is listed at startup on a custom internal UI. They should consider putting that UI in the ec2 console.

When I spin up machines I pick an instance class by looking through specs and the price chart and set it via AI into a cdk construct. Usually pick a relatively normal machine type digging through all the ilvarious enterprise discounts (which are not reflectedin the prices in the console). Then as I roll out or when I get resource limit alarms on the fleet I adjust the instance types. Or when accounting asks me about price. In those cases I usually look if it's worth it to optimize.

The enterprise discounts are a big consideration. Every year new hires make bad decisions because they don't know about the discounts. They wildly affect total cost. Some things are more expensive (lambda first few years), and others are very cheap so we dog food. The console price in no way reflects reality.

In 15 years we've had about 1k services stood up, around 700 are active. 2000 or total counting tutorials and tests. That means out of an eng org of 500, we've made those decisions maybe 10k times total.

That's how Amazon thinks about it as well. So yeah I agree that the UI isn't meant to be like one where your spinning up a host. I haven't spun up a single host in like 5 years, but I've made many clusters.

But that doesn't mean it shouldn't be better to work for a wider audience. Customer obsession and all

reply
[dead]
reply
AWS UX isn't bad because engineers are bad at UX. It's because inside AWS it's every man for himself, and every team for itself. They don't collaborate, they don't talk, they compete to ship everything as quickly and cheaply as possible - quality, usability, and common sense be damned.
reply
FWIW, my team in AWS had help from UI designers who were cool people that impressed me with their work. We definitely had to push through some needless organizational friction, e.g., they were in a different org and frequently got left out of meetings, whereas we should really have been acting as one team. I don't think we saw it as everyone for themselves, we really tried to make it work and had a good, trusting relationship.

In the end, our leadership changed what we were building so often that all of the UI work was scrapped long before we shipped. We ended up launching a janky console, quickly assembled by SDEs who were racing against deadlines. We skipped virtually all operational readiness work to meet the launch deadline. After claiming the launch win, the director, two managers, and the pm promptly left for other orgs.

reply
Wow. Your story sounds like my company. Makes me feel less bad for the dysfunction I have to work with
reply
That's not just AWS. That's Amazon generally. All Amazon orgs I've worked for have been like this, and due to the nature of my work, I (and my teams) have been treated like pariahs for daring to suggest that there ought to be even a minimal amount collaboration, shared standards, and cross-pollination on ideas between teams.
reply
AWS UX is bad because there are too many products and features, but also still supported legacy.
reply
> My point is that maybe it was intentional, but just bad UX culture.

This may be valid, but even if it is someone (or a group of people) at Amazon are violating one of their core leadership principles - Customer Obsession

https://www.amazon.jobs/content/en/our-workplace/leadership-...

A useful (and hopefully delightful) UX is key to showing customer obsession.

That being said, I personally feel the UX at Amazon sucks overall, not just for pricing/packaging but even getting basic shit done. So perhaps Amazon (or at least AWS) doesn't think a good UX is a key ingredient to demonstrating Customer Obsession.

reply
Maybe their customer obsession culture did not extend to their AWS department?

AWS services names are notoriously bad at communicating what they actually do: https://expeditedsecurity.com/aws-in-plain-english/

reply
Everywhere on Amazon.com has bad UI/UX. For one example, the flow on checking out as a non-Prime member (not sure about Prime members) is janky and feels straight out of 2005. Like it reloads the page, taking ten+ seconds, every time you enter new data (address, credit card, personal info, etc.). I would be laughed out of the room if I tried to deliver this at work, but Amazon delivers it for millions of people.

So no, they care zero about their customers, except maybe for getting as much money as possible out of it.

reply
Just saying, you can be customer obsessed and still not have a good feel for UX...

Ask me how I know

reply
Personally I think the UI flow is geared towards the idea that engineers don't really see the costs, they just build stuff and then management pays at the end of the month.

Often I see something that's supposed to be leaner - like Fargate is leaner than renting a whole server to run docker, right?

So it's cheaper as well? - Well, no.

Also if you reach any appreciable level of complexity, you should move to IaC - configuring all that stuff on the UI, and getting it right is torture.

reply
Engineers are not entirely cost-oblivious entities.
reply
They're not but if they don't talk to the pricing team, and most devs don't want to talk to business people, they'd never coordinate on where it makes sense to show pricing to customers.
reply
You didn’t read the comment I replied to, did you? The premise was :

> the UI flow is geared towards the idea that engineers don't really see the costs, they just build stuff and then management pays at the end of the month.

So this is about the engineers consuming AWS, not the ones who designed and implemented AWS

reply
A core part of an engineers job is including thinking about cost in what they do.
reply
Right - nobody who’s had a formal education in engineering would think that way, because cost considerations are part of the curriculum from the start.
reply
I don't think a lot of formal education places teach AWS's resource pricing structure, which can be incredibly confusing, but can be boiled down to: if you want to be as cheap as possible, just use EC2 for everything and maybe S3 for storage.
reply
I'm very surprised you expect any formal education to teach any specific pricing structure. You teach how to evaluate solutions for their price impact. No one was claiming any curriculum includes AWS's resource pricing structure.
reply
I can't recall cost ever coming up as a consideration during my years of formal computer science studies in school. Big-O efficiency, sure, but the cost of compute, storage, bandwidth, nope, not once.

It was absolutely hammered into me in the years of working for startups that followed, though.

reply
Just noticed you did say computer science, not computer engineering. Two very different things.
reply
I would argue that the intentions don't matter at all, the end result is all that matters both for the buyer and seller. In systems design, it is often said that The Purpose of a System Is What It Does. Good intentions can produce very bad systems with bad outcomes, and neutral/bad intentions can create good systems that benefit everyone.

I think that applies both to Amazon's dev system and pricing system. From what I hear about the insides, alignment is chaotic neutral inside of Amazon, but that shouldn't affect how we judge the system itself.

reply
> Some devs have a good product/UX sense but the vast majority are horrendously bad at UX.

I think the problem is that nobody understands the size of the problem.

For most tasks, the accomplishment is getting something to work. That takes 90% of the time. But the UI requires polish, working things out, backing out and trying again, and takes the OTHER 90% of the time.

I remember talking to a friend who worked with apple to port some dvd authoring software. And steve jobs started with the UI, and said "this is what you do". I think it was just a blank screen and you drag your video onto it. the software they were porting was a bunch of windows type confusing nonsense, and they had big changes to make.

That said, AWS might be a dark pattern. Remember the cable companies that didn't WANT to show the hidden fees? because $29.99 a month was really $71.41?

reply
Prior to AWS at Amazon hosts were provisioned as “host classes” and typically operated on in that way. We were encouraged to make them “touchless”, which meant the infrastructure team could replace that host without contacting the team first. The deployment tool deployed to host classes (though you could put an individual server there if you wanted). EC2 wasn’t quite the same, but not very foreign either. We didn’t originally even use the AWS interface (at the team level). They were managed by a team working on the transition.
reply
It just goes to show if you are the first big player in a space, you can have whatever UX. No UX will override that first mover advantage. I could cite countless examples, where the first commonly known company rules the space and no newcomer with a flashy UX can come close, no matter how hard they try.
reply
Judging by how much things jump around on the screen when I navigate from one view to another I agree.
reply
Honestly UX became irrelevant in the last years (infra as code) and even more in the last year (coding agents). What you need is well structured API and a CLI that does not limit you. You can call it UX if you want, but the skillset is different.

When I started my latest project my first rule was: I never have to login to AWS console. I didn’t achieve ‘never’ but I am pretty close and the experience is a lot better

reply