
Troubles with the AWS web console - curtis
https://old.reddit.com/r/aws/comments/c8xgsc/i_am_stupefied_every_day_by_the_awfulness_of_the/
======
adreamingsoul
These comments are fascinating to me.

I was responsible for designing, leading, and building the frontend for an AWS
service. One of the challenges was with obtaining useful feedback from a
diverse range of people. During the product definition phase, the majority of
the feedback, input, and feature priority was for customers who were planning
to dedicate a large budget towards using said service. I often felt that
stakeholder decisions sacrified usability for feasibility.

Regardless, it was the responsibility of my service team to seek and obtain
feedback, input, and data points that could help us inform our decisions. But
from what I witnessed, it only went as far as to validate our exisiting
concepts and user personas of how people use AWS services. Going beyond that
was seen as unnecessary.

The universal thinking within AWS is that people will ultimately use the
API/CLI/SDK. So, investment into the console is on a case by case basis. Some
services have dedicated engineers or teams to focus on the console, but most
don’t.

I’m proud of what I built. I hope that my UI decisions and focus on usability
are benefiting the customers of that service that I helped build.

A little known fact, in the AWS console exists a feedback tool (look in the
footer) that will send feedback straight to the service team. I encourage you
to submit your thoughts, ideas, and feedback through that tool. There are
people and service teams who value that feedback.

~~~
Terretta
Noting your verb tense, “I was”, I’m assuming you’re no longer in that role.
This isn’t feedback, just discussion.

I talked to Jassy after his keynote in 2018: “Your message says AWS is for
‘builders’. Why do you keep saying ‘just click and ...’ instead of ‘just call
the API and’?”

In short, to your point: AWS is for builders... who pay. And right now all the
growth is in enterprise, where we don’t know how to make API calls from a
command line.

We don’t know how, because two decades of IT practices and security practices
made sure we _couldn’t_ make API calls from a command line. (No access to
install CLI tools, no proxy, firewall rules from the S3 era still classify AWS
as cloud storage and block it, etc.) So we can’t adopt AWS at all if that’s
the only path in. But our proxy teams _can_ figure out how to open a console
URL. For this market, giving a point and click web page with magic infra
behind it is a big deal: the modern ‘service catalog’.

So I think he’s right, that’s the dominant use case by dollar count and head
count, and he’s speaking to those deciders.

At the same time, I think it’s terrible when capabilities show up in the
console first or only, as the infra-as-code builders can’t code infra and
services through the console.

So to anyone following along from a team with two pizzas: invest in the UI,
but please nail the APIs first, and then use those from the console. Keep
yourselves honest to the Bezos imperative from 15 years back: if you want it
in the console, so do IaC developers, so let there be an API for that.

~~~
cloakandswagger
Most AWS services' console/API are 1-1. Occasionally a console might offer
some convenience features which are just a combination of API calls, but I'm
not aware of any service that has functionality solely offered in the console.
As the original comment touched on, this would be really unusual in AWS where
most attention goes to the APIs/SDKs which are what larger customers use.

~~~
lukev
There are definitely some API-only things. Mostly edge cases. For example,
last week I ran into the fact that it's only possible to associate a Route 53
Hosted Zone with a VPC from a different account via the API.

~~~
pests
Your parent comment is stating the reverse. That there is no web console only
features.

------
slovenlyrobot
Since starting to use Google Cloud for bits and pieces I've come to appreciate
the AWS UI approach much more than previously. All those little spartan
pockets of UI means nothing gets overengineered, the tools feel more like a
quick Intranet web app (and generally load as quickly!) than anything else

Meanwhile over in GCloud, almost /any/ operation whatsoever will spam you with
an endless series of progress meters, meaningless notification popups, laptop
CPU fans on, 3-4 second delays to refresh the page (because most of their
pages lack a refresh button), etc., and the experience is uniform regardless
of whatever tool you're using.

The uniform design itself was clearly done by a UI design team with little
experience of the workflows involved during a typical day. For example,
requiring 2 clicks and at least one (two?) slow RPCs to edit some detail of a
VM, with the first click involving the instance name with any 'show details'
button completely absent from the primary actions bar along the top. The
right-hand properties bar in GCloud is also AFAIK 100% useless. I've yet to
see any subsection that made heavy use of it

Underengineering beats massive overengineering? Something like that. Either
way, the GCloud UI definitely pushes me to AWS for quick tasks when a choice
is available, because the GCloud UI is the antithesis of quick

~~~
Legogris
Wow, I have the complete opposite experience. Monitoring, metrics graphs and
logs are just miles ahead in Google IMO. It's so much easier for getting
visibility.

Do you really prefer Cloudwatch to Stackdriver? How about having a Lambda
being triggered both on SNS messages and HTTP requests (setting up a proxy)
and having that Lambda deployed with a CD pipeline - compared to doing the
same with Cloud Functions?

But I guess it also really boils down to which products you make the most use
how, how and your scale. Clearly we have different preferences.

I guess I am not seeing the bad parts you do because 1) Apart from DNS and
some IAM, most infra changes are done from Terraform or CLI and 2) I have
pretty high-end workstation.

~~~
slovenlyrobot
A series of loaded questions does not convince anyone :) With large accounts
all of these tools start to break down, by that point it's much easier to work
from the command line than, say, navigating GCloud's single global view of VMs
which becomes actively harmful in this case. I run 1500 instance load tests on
GCloud quite regularly, so this is not some imaginary problem, and genuinely
large accounts can easily grow to 10x that

I'll always prefer the ability to quickly hit refresh than waiting 4 seconds
because I made the mistake of ctrl-clicking a link, and now a new tab is
'booting'. But I guess this preference depends on how quickly one expects to
be able to get their job done

~~~
Legogris
I was actually genuinely curious, I guess ^^

Oh yeah, the inconsistency in which links open in new tabs by default and
which you can ctrl-click and not is a bit frustrating in GCP for sure.

------
drchewbacca
I hate AWS so much.

I spent 3 hours trying to get a bucket to host a static single page of html
and failed completely.

I use amazon polly. I wanted to know how many characters I was using each
month. I spent 2 hours searching through hundreds of pages and literally
couldn't find that information.

I thought of trying to start a little text to speech service for dyslexics to
make it easy to use Polly but one of the main thing putting me off is having
to get my arms mangled in the AWS machine.

The whole thing is so totally maddening. I would love to be able to sit in on
their meetings where they talk about usability, what do they say? Do they
think everything is fine? Do they know it's totally broken and don't care? Are
they unable to hire a UX designer? What is the problem?

~~~
m0xte
For me that isn't the problem. It's mapping the several-thousand acronym
riddled hairballs into reality. The reality matches no other reality which
means the knowledge is probably useless in 20 years time, much as the
knowledge I had of proprietary stuff then is useless now. My head has only a
certain amount of space and motivation for ephemeral complexity hairballs like
AWS.

At this point I have to wonder if this is intentional. It makes it difficult
to escape if all you know is AWS's reality abstractions.

~~~
makebelieve
I second this. I found it easier to spin up servers on other services and run
big install scripts than to try do decode Amazon's naming/acronym hell. The
requirement to connect invented names to computational activity is big
overhead.

I guess each AWS service get's named it's own thing as it is developed and
those names just stick forever. it is maddening. Reading the docs outloud
often sounds like a weird technical Dr. Seuss. I've never looked at Azure, but
since Microsoft has been the king of making up their own names for things, I
expect it to be just as bad.

I wonder how this naming issue comes about. If AWS devs and early adopters are
doing this as their first big rodeo, then everything might seem new and they
get to invent names - as if the computing were new. But after these devs and
early adopters work on 2 or 5 of these kinds of projects in different
environments they will see that special naming is a mistake, because it makes
it incredibly hard to communicate about the same computing tasks using dozens
of different names and acronyms.

I know computing requires continuous learning, but specialized naming tends to
obfuscate higher order abstractions. And if you grok the higher order
abstraction and want to dev a system, then the naming and minute computing
differences make development on any given service harder than it needs to be
because it requires learning specialized lingo. As human beings we need to get
much better at getting to standard names and conventions faster. It will speed
all our development.

~~~
meddlepal
> I've never looked at Azure, but since Microsoft has been the king of making
> up their own names for things, I expect it to be just as bad.

I use Azure and the naming is pretty straightforward. It's entirely unlike
Amazon in that regard and also very unlike classic Microsoft.

------
KaiserPro
I know many people will disagree, but I really miss the VMware fat windows
client. (vsphere 5, before they ruined it with the weird flash hybrid that
didn't work properly)

That, was a paragon of design reliability and speed compared to the AWS
console.

What annoys me the most is the sheer weight of each page. If you have to
context change, its multiple seconds before the page is useable.

A classic example is lambda. I click on the function, page reloads (no
problem) 1-2 seconds later the page is fully rendered, I can _then_ click on
the monitoring tab, another couple of seconds, and then I can jump to the
latest log, in cloudwatch.

Cloudwatch can get fucked. Everything about it is half arsed. Search? all of
the speed of splunk, combined with its reliability, but none of the
usefulness.

The standard answer is "you should use Cloudformation" I do, it too is
distilled shart. (anything to do with ECS can cause a 3 hour, uninterruptible
hang, followed by another timeout as it tries to roll back.)

It also lazy evaluates the acutal CF, which means that parameter validation
happens 5 minute in. Good fucking job there kids.

What I really want is a QT app in the style of the VMware fat client (you know
with an inbuilt remote EC2 console, that'd be great...) that talks to AWS. The
GUI is desgined by the same team, and is _tested_ before a release by actual
QAs who have the power to block things until the change is released.

~~~
kristianpaul
You know that nothing stops you from using aws apis and making you own UI
right?

~~~
omni
In many cases AWS's absurd rate limits would make it hard to build a
functional UI even if we wanted to. I imagine this is one major reason why
list views and filtering/searching them is a disaster in every major AWS
service.

~~~
cthalupa
If you're building your own management tools, I'd probably suggest persisting
the data in your own system as well, rather than constantly hitting the AWS
APIs. 10 users going to your tool to look at EC2 instances at the same moment
don't need 10 different calls to AWS. Have your management tool query the API
once, and persist the data for a period of time. It all being json responses
makes this a fairly reasonable and easy use case for mongodb or postgres.

~~~
omni
A management UI showing me stale data sounds like a terrible experience,
honestly

~~~
cthalupa
It works well enough for Netflix - [https://medium.com/netflix-techblog/edda-
learn-the-stories-o...](https://medium.com/netflix-techblog/edda-learn-the-
stories-of-your-cloud-deployments-ade4f4edd9cd) \- and Target (
[https://tech.target.com/2017/04/07/how-and-why-we-moved-
to-s...](https://tech.target.com/2017/04/07/how-and-why-we-moved-to-
spinnaker.html) ) :). I've only ever used Edda as part of a Spinnaker setup,
but there's no reason it couldn't be used with something else, or the same
idea in general reused.

You don't have to cache it for very long, but you get two benefits here: Being
able to query the data and search through it ways you simply can't do when
making an API call to AWS, and having primarily only one system munching
through your API throughput limits. If you've got a large account with a lot
of resources and a lot of people or systems that are querying the API
frequently, you'll probably have more consistently available data, rather than
having systems sitting around doing retries and getting throttled there, on
repeat.

~~~
omni
Just wanted to say thanks for replying with these links!

------
SilasX
One of my pet peeves about it (might have since been fixed) is that AWS will
gladly walk you through the wizard to set up an EC2 server, and only at the
very end say “oh you don’t have permission to do that lol”.

I compared it to a bartender who immediately recognizes that you’re underage
but offers you alcoholic drinks, gives you samples, asks about preferences,
counts out your change, and only after all of that stops you from drinking it.

[http://blog.tyrannyofthemouse.com/2016/02/some-of-my-
geeky-t...](http://blog.tyrannyofthemouse.com/2016/02/some-of-my-geeky-tech-
jokes-with.html)

------
jrockway
I am pretty sure the AWS business model is to get you to write your own code
that interacts with the API so that when you think about switching to another
provider, you realize that you're throwing away months of work and decide not
to. They also make the API requests take so many parameters that are specific
to your particular use case that nobody will ever be able to write a generic
tool that does what you want. Ever run "awscli help" and find anything useful?
Didn't think so. Write your own tool if you want help!

Amazon is very much in that "we were here first so we'll do whatever we want"
mentality. They can provide worse service for more money, and people love
them. Nobody ever got fired for picking AWS!

~~~
mk89
> I am pretty sure the AWS business model is to get you to write your own code
> that interacts with the API so that when you think about switching to
> another provider, you realize that you're throwing away months of work and
> decide not to.

Same applies to all other cloud providers.

Typically, you solve this problem partially with tools like Terraform, etc.
However, of course there is never a one-size-fits-all solution for such
things. Vendor lock-in is an issue that many companies try to solve by
adopting standard solutions, but that's it. Kubernetes for example is one of
these solutions.

~~~
wikibob
While Terraform the tool can be used across cloud providers, Terraform
configurations cannot.

Each terraform file uses modules that are quite specific to the individual
services provided by a given cloud. These cannot be simply swapped out without
rewriting the config.

~~~
mk89
Unfortunately that's true.

In general, that's something that should be known in advance when someone
chooses a cloud provider. As I mentioned, there is no one-site-fits-all
solution. :/ Vendor lock-in is a serious issue for some enterprise companies,
and in such cases you could propose something like a hybrid cloud. It's an
expensive effort that could save your butt in the future.

------
underwater
The example I ran I to the other day was so typical of AWS. I was trying to
set a monthly budget for my account but the "Continue" button was greyed out.
After staring at every field for a long, long time (and attempting to
undisable the button through the dev tools) I realised that the value of "80"
in the percent usage trigger field was not in fact a pre-populated value, but
a value in the "placeholder" field. I needed to manually enter a value (and
chose to enter "80").

This is not just bad UX, this is the territory of never even bothering to sit
down with someone to see how they might use the product. Amazon love to tout
their focus on the customer and amazing leadership principles, but they sure
produce some mediocre experiences.

------
nickjj
On the other hand, their CLI tool is very good.

I wrote some video training material 3 years ago that goes over setting up an
ECS cluster and I decided to use the CLI for just about everything. We
interact with a number of resources (S3, load balancers, EC2, ECS, ECR, RDS,
Elasticache, etc.) and other than a single flag to login to ECR it all works
the same today.

I'm happy I chose not to use the web console. The only time I used the web
console was for creating IAM roles and I've had to make a bunch of updates
since the UI changes pretty often. It would have been a disaster if I used it
for everything.

~~~
llimllib
Their CLI manages to completely lock up my up to date MacBook Pro when simply
downloading files and has very strange and conflicting choices of parameters.
It is comprehensive, but I wouldn’t call it good

~~~
acdha
I won’t defend their CLI arguments other than noting that they usually closely
follow the also poorly-named APIs[1], but locking up is highly unusual — do
you have something like AV software or other quasi-malware which might be
interfering with normal I/O? We’ve used it for many millions of files over the
years and that’s never been an issue on macOS or Linux.

1\. AWS needs a Chief Consistency Officer who can block shipping until you
cleanup the prototype slop

~~~
llimllib
Doing an ‘aws s3 sync ...’ on a directory with large files causes 100% CPU
usage

~~~
acdha
How would you compare hashes without calculating them? Any operating system
more advanced than Windows 95 shouldn’t “lock up” with a CPU-bound task.

~~~
llimllib
An extremely naive program can sha1 hash 1 million 100 byte strings on my
computer in less than half a second:
[https://gist.github.com/llimllib/72f60aa33b32e422962d876ddf0...](https://gist.github.com/llimllib/72f60aa33b32e422962d876ddf0a4660)

This is literally the first program I came up with, no attempt to optimize it
at all.

There is zero chance that the AWS sync command is filling my CPU just by
hashing bytes

edit: I'm going to try not to let you nerd snipe me into doing the profiling
the AWS CLI needs to be doing, for them. Because that's now what I desire to
do.

~~~
ptomato
so 200 megabytes/second? I'm not sure what your definition of large files is,
but hashing anything sizable with SHA1 is trivially CPU-bound with any modern
SSD, in the absence of a processor with the sha asm extensions.

that being said, quick glance at the source suggests that awscli's s3 sync
only compares files by size & timestamp, not etag, so it's not hashing
anything client-side.

------
kristiandupont
It seems to me that there is a quite profitable business case in a thin
abstraction over AWS/Azure/Google App Engine (or whatever it's called now).

There are lots of services like Zeit Now and Heroku that supply a complex
abstraction to the point where it feels like an entirely different product.
What I would want is something that allows me to host docker images/K8s on one
of the big three (I guess others as well) and lets me to use configuration as
code to the extent possible, but with UI/command line/API helpers that create
a uniform abstraction so that can easily switch.

~~~
tomhoward
This is what Cloudkick [1] was setting out to do when they were funded by YC
back in early 2009. But they were acquired by Rackspace [2] less than 2 years
later, the product was discontinued, and nothing seems to have filled the void
ever since. Seems like that kind of service is more necessary now than ever.

[1]
[https://www.crunchbase.com/organization/cloudkick](https://www.crunchbase.com/organization/cloudkick)

[2] [https://techcrunch.com/2010/12/16/rackspace-buys-server-
mana...](https://techcrunch.com/2010/12/16/rackspace-buys-server-management-
platform-cloudkick/)

------
Cpoll
Search in the UI is my particular bane.

Sometimes it works great (searching for EC2 instances).

Sometimes you need to construct restricted search queries (slightly aided by a
slow dropdown auto-complete) that look like `Name: Begins With: /blah/`
(ParameterStore).

Sometimes search is client-side, and only searches the page you're currently
on (ECR, I think? I can't remember what does this). I think in this case it's
sometimes form just following the limited functionality of the API.

I have a _lot_ of scripts that are just ways to extract data quicker than I
can in the UI.

~~~
__david__
IoT is one of those client side searches. And worse, it's an endless scrolling
page, so to do the search proper you have to repeatedly scroll down until
you've loaded all the data (20 or more pages on our infra), then scroll back
to the top and search. It's so bad I don't even know what to say—it's like no
one ever tried to use it.

------
aytekin
Here is a startup idea for grabbing: Make a better interface for AWS/Google
Cloud.

Since their APIs covers everything this should be possible. Be the first
UXaaS.

A killer feature: a server by server breakdown of Google Cloud expenses. It is
impossible to understand what you are paying for on Google Cloud. They lump
everything together in an incredibly confusing bill.

~~~
whitepoplar
I think that's why DigitalOcean is winning so much these days.

~~~
Can_Not
Imagine if DO had lambda.

------
noneeeed
The three things that annoy me the most about the console:

1) state management/sync is frequently terrible. E.g you are looking at a page
with some health indicator and a log view. The last entry in the log is some
variation of "transitioned from busted to not busted", but the state indicator
doesn't update until you refresh.

2) if you have multiple tabs open at a time (pretty common use case) there is
a good chance it will suddenly decide that you have to reload the page for
some reason, often when you are in the middle of something

3) live updating. Why the hell do I have to sit there hitting refresh on so
many of the views to get up to date data? I've often sat there waiting for
something to finish, only to realise it's been done for a while but the page
has not updated. This seems closely related to (1).

I find the overall design of the console fine, generally the UI is manageable,
but the actual implementation is a steaming pile.

~~~
mdaniel
> 2) if you have multiple tabs open at a time (pretty common use case) there
> is a good chance it will suddenly decide that you have to reload the page
> for some reason, often when you are in the middle of something

I so strongly agree with that observation, and have repeatedly and _often_
submitted feedback through their in-page feedback mechanism about please, I'm
begging you, never involuntarily reload my page. That's why @adreamingsoul
([https://news.ycombinator.com/item?id=20903229](https://news.ycombinator.com/item?id=20903229))
saying "send us complaints, we read your feedback" is like spitting into the
wind for me

I thought your "multiple tabs" was also going to mention that they have
_exactly the same browser title_, no matter what subsection you have open. So,
if one EC2 tab is looking at volumes, and another at instances, and another at
autoscaling groups, well, too bad for you because you're just going to have to
click on them all or have a good memory/tab-management scheme

I kind of figure the console doesn't get any engineering love because of what
other people in here have said: they want you to use the APIs

~~~
noneeeed
It can be incredibly annoying when doing something like updating a
cloudformation stack. I might open RDS in another tab to grab a snapshot ID or
EC2 to check a sec group, and when I switch back to my half updated CF
parameters the damn page forces a reload and loses the setting I've entered.

I can't work out what it is they are doing that nesessitates these reloads

------
40four
I've never liked the web console much either. Never found it very intuitive,
or easy to use. But, once you navigate the maze, & learn where the few things
you need are, it does get the job done. And to be fair it is fast.

Not sure why, but for some reason I like clicking around in the web app, so
makes me wish it was a better experience. In contrast, compare this to the
Digital Ocean web console. It has beautiful design that is nice to look at.
It's un-complicated & clutter free. Overall a very pleasurable web app, I've
always been inpressed with their UX.

But as people have pointed out, it seems Amazon expects us to use the CLI &
APIs, and the web console is not a priority. So maybe I'll start moving in
that direction with my AWS services.

------
pgt
The Law of Better is Worse:

User-friendly tools prevent skilled middlemen from monetizing their expertise,
which stifles adoption of that tool. So on-sellable tools that are too easy-
to-use, don't get on-sold.

Some examples by contradiction: tax returns, AWS Dashboard, many programming
languages.

~~~
dammitfoo
> Some examples by contradiction: tax returns, AWS Dashboard, many programming
> languages.

By programming languages, do you mean Rust?

~~~
pgt
Absolutely Rust and JavaScript. Rust would be a far better language if it used
S-expressions and didn't try to reinvent a macro syntax. But then it would not
be as popular.

In this way Lisp suffers from having no syntax, although it's a slightly
different argument. When you can't have flamewars about a language's syntax,
fewer articles are written about it. So instead, people will argue about the
encoding of the AST - the parentheses.

Similarly, well-designed languages like Clojure, Haskell and Erlang have fewer
questions on StackOverflow and older GitHub issues, so there are fewer
flamewars about them (although monads are Haskell's saving grace here).

The NPM crowd are quick to ask, "Is this project abandoned?" when it hasn't
had any activity for a year. In Clojure country, we dislike using libraries
that haven't been stable for at least five years. As Alan Kay put it, Computer
Science is very much a pop culture.

The phenomenon needs a good name, though. Perhaps the Moving Target Paradox,
since developers are more likely to run after a moving target.

~~~
bergoid
> The phenomenon needs a good name, though.

Jamie Zawinski calls this the CADT model: "Cascade of Attention-Deficit
Teenagers".

[https://www.jwz.org/doc/cadt.html](https://www.jwz.org/doc/cadt.html)

------
Legogris
It's just so fragmented. Some parts are actually almost great (Lambda) while
others are downright awful. Batch is the worst, and it's been like this for
years. As soon as you go over a couple of hundred jobs per day, it becomes
unmanageable quickly.

You still have to do some trickery with the CLI too. Let's say I want to get
all logs from failed Batch jobs in the past day? This involves:

* Listing the Jobs (possibly paginated)

* Parsing out the log stream names from JSON (oh, and separate logs for separate attempts)

* Iterate through log streams and query Cloudwatch (each paginated)

* Parse JSON

I am sure we're all writing half-baked wrappers for our individual use-cases,
I am surprised no one's published something generally useful for stuff like
this.

Whereas with Kubernetes, that's all a single call with kubectl...

Don't get me wrong, we wouldn't be on AWS if it didn't make sense and they
have been pushing development forward a lot. But it's unfortunately
fragmented.

The only way to stay sane here is to use Terraform. That way you can stay out
of it at least for creation and modification of resources and will have an
easier time should you want to migrate.

EDIT: Another great example from Batch: Let's say you have a job that you want
to run again, either a retry or changing some parameters.

AWS Console:

* Find job in question (annoying pagination through client-side pagination where refresh puts you back on page 1).

* Click Clone Job

* Perform any changes. (Changing certain fields will reset the command, so make sure you stash that away prior to changing)

* Click Submit

* Job ends up in FAILED state with an ArgumentError because commands can not be over a certain length.

Turns out that the UI will split arguments up, sometimes more than doubling
the length of a string, and there's nothing you can do about it except resort
to CLI or split it up into smaller jobs if you have that option.

CLI:

* Get job details

* Parse JSON and reconstruct job creation command

* Post

It baffles me how container fields and parameters differ from what you can GET
and what you can POST; you really need to parse the job down, and reconstruct
the create job request.

I completely understand that it will be like this when services launch. But
it's been years now.

------
noncoml
The problem with AWS teams in general is their arrogance. I dread having to
deal with them. They are destroying Amazon’s reputation.

Don’t want to bother you with specific examples, but every interaction I had
with them was dreadful.

I think this attitude gets reflected in their console design.

~~~
omni
I'll share my frustrating experience with them just for fun
[https://github.com/boto/boto/pull/3093](https://github.com/boto/boto/pull/3093)

------
lukev
I don't find the console that frustrating, or when it is, I understand why.
UIs are hard.

What I do find frustrating is how much of the docs are written in a console-
first way. In most cases, the straightforward definitions of resources,
attributes and the relationships between them are tucked away (or not present
at all) in favor of "click this, then click that" style.

I am convinced that the best way to understand a cloud service is to
understand its internal data model and semantics, but this is too often hidden
behind procedural instructions.

------
gfodor
Reading these threads make me realize I am either a victim of Stockholm
syndrome or most developers are way more picky than me. I’ve never gotten
frustrated at the aws console, though I have noticed some of the rough edges.
I guess at this stage in my career I’ve internalized muddling through stuff
without letting it bother me. The only exception to this probably is when I
open the door and peek through to the latest insanity in JavaScript land,
which I find impenetrable. (I’m looking at you, redux/saga/whatever)

------
captn3m0
Surprised nobody has mentioned AWS's official (but no longer updated) GUI
client: ElasticWolf[0]. It is very much not-maintained but it does have some
benefits.

My understanding is that AWS hasn't officially closed it because of US-Gov
accessibility guidelines.

Are there any other similar clients?

[0]: [https://aws.amazon.com/tools/aws-elasticwolf-client-
console/](https://aws.amazon.com/tools/aws-elasticwolf-client-console/)

------
dandigangi
This is the specific one I never quite understood:

* Order column by X

* Type search into input

* Column order drops

* Can no longer apply ordering when search input is there

100% understand that larger companies will not typically, or at least
shouldn't, be directly manipulating infra via the web console but there is
1000s of customers that use web for small business. It's a valid customer to
think about it!

ps I logged into Reddit so to add to that thread. Felt this in my soul.

------
andreineculau
3 years ago i had some vague hope that things do improve although i am not
aware of the bugfixes so i started tracking the bugs as GitHub issues

Soon after i gave up. Too many silly bugs, and no fixes.

Reference: [https://github.com/andreineculau/fl-
aws](https://github.com/andreineculau/fl-aws)

------
mattbillenstein
I use the web console fairly sparingly - iam, billing, browsing around s3 from
time to time, etc. It's good enough - way better than it used to be, and
better than the firefox extension that I started with.

This is probably not a popular way of doing it, but I write python to
orchestrate the provisioning steps of a VM with specific roles, routes, etc in
a VPC (with public/private subnets in multiple AZs) and then I use other tools
for config-management and deploy.

I'm using few of AWS's services, it helps me do multi-cloud (another python
script doing the same thing on another cloud), and it helps me keep my local
dev environments in parity with production even on MacOS.

I do use S3 and route53 globally - they're simple enough to use using boto.
IMO if infra is now code, you should probably write code to manage infra...

------
cookieswumchorr
Maybe what the world really needs is a FOSS Framework that implements all the
features on a swarm of VPS/Hardware servers? It's really disturbing to see the
web reduced to a handful of giant cloud providers who also happen to suck at
doing their job

------
ppod
I'm a solo academic researcher user and there's one thing even simpler than
this that i can't stand: there is no way to check which EC2 resources are
running all at once. You have to click on every single region in turn to see
what is actually running. If you've had multiple types running across regions,
trying shut everything down without closing the account is a real pain. I am
not the only person with this problem:
[https://stackoverflow.com/questions/42086712/how-to-see-
all-...](https://stackoverflow.com/questions/42086712/how-to-see-all-running-
amazon-ec2-instances-across-all-regions)

~~~
journalctl
Out of curiosity, why are you running multiple EC2 instances across more than
two regions?

~~~
ppod
Honestly, because when I started I didn't understand AWS very well, which was
my fault. But it definitely ended up costing me more money than I expected.

------
mnm1
People pay for an awful product. What incentive do they have to improve? None.
It's not just aws. All Amazon products are this way. Two day shipping comes a
week later if it comes at all. Products are cheap knockoffs that break and
when you return them they close your account. Aws is aws: you know you're
getting ripped off but someone else is paying the bill and aws has convinced
them that the service is worth it. It's not but it'll take a week to migrate
away to another provider and we can't afford that. Never mind that we're
losing an hour each day in productivity. Perception is everything and
perception is on their side.

------
sakopov
I jokingly say that Amazon should have a couple of sessions at re:Invent where
they talk about the things they fixed in Console. I generally find that I no
longer mind most AWS UI quirks, but some things are really annoying like the
broken Parameter Store search which has been broken for years or CloudWatch
search which flat out doesn't work at times.

I really believe there is a business opportunity here. I think you could pick
a general use-case for AWS, like serverless, and build an intuitive UI around
AWS offerings typically utilized by the serverless stack.

------
ses1984
Why on earth are would you need to click around the ECR console that much?

------
empath75
Don’t use the console. Nobody who uses aws professionally spends any amount of
time in it. They have apis and cloud formation use that.

~~~
scarface74
I wouldn’t go that far. I use a combination of the console, Cloud Formation,
the CLI, and Python scripts for dev ops/infrastructure type work and Python,
JavaScript/Node and C# for development.

------
benburleson
AWS still needs to prioritize 100% CloudFormation support as a deliverable for
new features. Remove the need to use the console.

~~~
k__
Yes, CodeCommit support is laughable

------
peter_retief
Well I am glad I am not the only one who struggles to understand what is going
on with AWS. Everyone is all over the place with cryptic howto's. I think I
may have even "lost" a running container at some point. Google cloud also
seems to be out to confuse people, maybe its a strategy to stop users from
escaping :)

------
k__
My favorite is that every service asks you if you really want to delete but
CloudFormation.

------
surfsvammel
I have nothing against the AWS UI. I haven’t used it much, but it has never
been a problem to me. It must be increasingly difficult to build an UI for a
console like that, there are so many different users, use cases, services and
perspectives.

------
Trisell
I’ve been working at a company where I have had to fight with the
infrastructure team because they see no reason why I would need programmatic
cress to do anything on the cli or with the sdk. The reason why. They don’t
use it so why would I?

------
miguelmota
AWS has great APIs and SDKs and most of the time I use AWS services through
the command line and not so much though the web interface.

Even though AWS web interface has it's flaws, it's still 10 times better than
Azure's web UI.

------
jacobr
If you think you are in such a strong position that you can keep customers
even with the level of inconsistency of the AWS UI, siloed microfrontends
might be something to consider. Otherwise it’s probably not such a good idea.

------
besus
The AWS console is a thousand times better than the nightmare one in Azure.

------
jayess
It's been a few days but I'm still trying to figure out how to share access to
the billing console with one of my organization's members. It's just baffling
in every sense.

------
fortran77
The console works, but the real power is in the API. The PowerShell API works
extremely well and I write scripts for everything I need to do.

On the Python side, "boto" works well, too.

------
nickthemagicman
There seems to be a huge need for a boto3/django(or something) user interface
that you could run locally to interface with AWS.

~~~
bob33
You should give Commandeer
[https://getcommandeer.com](https://getcommandeer.com) a try. It is a Desktop
UI just for this.

~~~
nickthemagicman
Thank you! This is amazing. I want to contribute to this!

~~~
bob33
So, the main app is not opensource. We are in Beta mode, but do plan on having
it be paid for, but most likely, free for developers, but a charge for
companies to use the teams aspect. The other part we are doing is that we are
open sourcing the Terraform, Serverless, and other templates. We have a plan
to then enable the usage of them within the app. So you could just apply a
serverless template to your environment, and immediately be setup with let's
say an SQS queue, tied to a lambda. That repo is located here
[https://github.com/commandeer/open](https://github.com/commandeer/open) .
Happy to chat more about it, as we are very excited about this and are working
day and night on it.

------
deboflo
Then you haven’t tried the Google Cloud consoles.

------
alexnewman
try azure

------
mlthoughts2018
The only thing worse is the GCP web console.

~~~
ernsheong
Not sure how you came to this conclusion. GCP by far has the better UI, even
AWS engineers acknowledge this.

~~~
mlthoughts2018
I came to this conclusion after using GCP and AWS both for extended periods of
time across multiple jobs, and just noticing that AWS solved my problems in a
better way.

