Additionally, negatively-biased phrasing on a public survey could also attract mostly those with negative views. This would skew your sample even further than solely priming.

With that said, I have no idea what any of those icons are.

Just from my own experience, I have used the overwhelming majority of these services and even worked at Amazon for several years and I could not answer more than a couple of those questions. The icons are so divorced from any real world meaning that when I make systems diagrams in Lucid Charts I use the AWS icons to represent abstract systems rather than the real AWS-specific meaning.

I also think the quiz is to prove a point. Those icons are not helpful at all. The opposite of the MS Office icons which are so recognizable all other office suites copied the color scheme.

Amazon badly needs some serious UX power...

It wouldn't be a very sustainable business, but you could make good money selling a chrome extension that cleans up AWS similar to what Reddit Enhancement Suite does.

Also, presenting options such as "dried arterial blood red" and "slightly but not too radioactive green" might also make you less likely to put in effort to select the real one, rather than just picking randomly.

Admittedly, I can't use them to identify any specific services, but they're cool looking.

Some entities have a name and a description field that are immutable on creation, even though they also have a unique id. I now have drop downs everywhere that list "Rds creation wizard VPC" or something long those lines.

Its not clear what fields are drop downs so I have to type stuff into them to see if they'll give me a list of options.

The UI uses the same styles but inconsistent language. In ECS there's a list of entities. To delete an entity you have to go into it and delete all its children. Then the entity disappears.

I know there's engineering reasons for all this, but I feel like they can do better than settle for engineer grade UI.

Yes, there was a mandate for everything to be SOA. However, AWS built almost every service from scratch. For example, S3 and EC2 were NOT used for production in Amazon until well after launch (it was a huge migration when the company did it years later).

My team built a world class transcoding service for video and were surprised to find later that AWS had built it's own (much less good) transcoding service. As part of that we also built a 5-10x optimization to multi-part fully-encrypted S3 uploads with a user-friendly client and the response from the S3 team was a shrug, they just weren't interested.

It is actually really common at Amazon for five teams to be building almost the same thing. Some of it is on purpose as a sort of insurance policy or bake-off.

But almost every AWS service was built in the AWS org, even if there was something similar in place at Amazon, at least when I was there (2006-2015).

I think it's more true than false though; tldr: there was effectively a super-fugly internal set of services that were the prototype for many of the real AWS services.

Some of the computing capacity AWS itself used was built on the internal services that Amazon had been using. Provisioning capacity on those internal services required weeks as the API was very primitive compared to EC2. I think also it wasn't until VPC became quite stable that they could start to move Amazon to AWS.

So for a long time, you essentially had AWS service teams having to file paperwork for capacity (decommissioning capacity could sit in a queue for months just like in a regular data center) while AWS customers could spin up capacity via EC2. As you can imagine, AWS would build on AWS, and then they promptly ran into problems when they had to stand up new regions because they had dependency cycles... There was also a ton of tooling built around requesting all the capacity and dependencies, and maintaining the configuration for all that.

So the SOA story is really that there were a bunch of AWS-like services that were absolutely awful, and those were often the prototypes for the AWS services themselves. And many services like Lambda are now possible because they've been solving all the obscure security issues and dependency problems associated with having AWS be their own customer.

For instance, the genesis of one service was that a large customer was using EC2 and had some specialized hardware; they were big enough they said, "hey, we'd like to move this hardware out of our datacenters" and AWS stood up an incredibly primitive service that literally routed some specialized racks into this customer's VPCs. There was no API, you'd email the service team and they'd run some scripts. That's gradually morphed into a real service that's unrecognizable from the early days.

The funny thing is, some of the AWS services are indeed quite primitive compared to their Amazon internal equivalent.

On top of that: it’s not like all services were build at the same time. Some of them are the “bedrock” of Aws (S3, EC2), some of them are experiments that went viral.

On top of that: Aws is meant to give you building blocks. The magic happens at API/sdk level. The console is there to help you discover and play with the service in a few basic scenarios (and to maybe observer your resources). If you click your way through settings things up you’re going to probably have a bad time.

I don’t think I’ve ever used the CLI to manage infrastructure on AWS.

I usually use the console for one offs. When something needs to be repeatable, I’ll create a Cloud Formation template.

Anything that’s more conplicated, I’ll either use Python directly or create a custom resource that gets called from CF.

For instance we have a process that sends sns messages for alerts. It’s just as easy to go into the console and subscribe to the sns event notifications (emails and sms).

Second example. I initially configure passwords with CF (of course with parameters that are added when you run it.) It’s easier to go into the console afterwards to change passwords as it would be to update the stack and renter the passwords.

You aren’t going to store passwords in source control anyway.

I agree it doesn't add much value for a single user rotating their own password.

Then when you have the Lego design you want, yes, you whip out cloudformation or bash scripts or Python scripts or ansible or whatever else.

Terraform import is pretty painful but at least it can handle this.

Names and Icons on AWS were made by people who don’t realize who helpful names and icons can be.

If it’s a database, use the cylinder icon that everyone knows is a database and then add some identifier to show which database it is.

If it’s DNS, don’t be too clever and name it Route 53. Name it Amazon Cloud DNS. Then anyone knows how to look for it in the console, web search for it, etc.

If you want something that the marketing folks can feel proud about wasting time on, add the silly name to the descriptive name: Amazon DNS Potato

Please no. The unique AWS product names while occasionally inconvenient mean that you can at least find relevant information about them when searching, and you know that someone isn't confusing an AWS product with another platform or another style of deployment.

If you really don't like the AWS product names, then Azure is for you. Now go try to search for help with "Azure web apps" or "Azure sql database". Wade through the posts about locally deployed IIS, SQL server and the like.

I don’t use a search engine though because they have made a good documentation site.

Adding a small identifier (as I suggested, even though jokingly) solves your problem as it’s easy to index:

Azure Cloud SQL Photon

That’s easy to understand it’s a Database and easy to search

Azure Cloud SQL R364T11

That’s hard to remember but likely narrows the search content drastically

For example, RDS is definitely a service built on top of other core services (EC2, S3, KMS, Route 53), its name is "Amazon RDS" and not "AWS RDS".

When things came close to launch, AWS Marketing decided to just roll with those code names. I've a suspicion that some teams deliberately used copyrighted names for their internal pre-launch project names, just to force the matter.

1. Which service would you use for DNS record creation?

A) Route 53

b) Amazon Cloud DNS

I joke, its an extremely low quality question regardless of the name. Some of the questions on the exam were pretty insightful, especially the ones that covered problems and what steps you would take to resolve them. Overall, the AWS associate level certification did feel like a giant marketing ploy, but my company wanted me to have it and paid for me to study and take it, so it was a nice relaxing break from the day-to-day.

They could have named WorkSpace as Remote Desktop Service, which it is. Instead, many of my co-workers think AWS means only Amazon WorkSpace.

I agree these would be much more descriptive.

I actually find myself referring to “Amazon Web Services in Plain English” [0] every once in a while.

[0]: https://www.expeditedssl.com/aws-in-plain-english

However, it is absolutely a reasonable request of a logo that you be able to go from logo to designated product, and while quizzing about details like "which horizontal pole is higher" is definitely a bit of an ask, you should still see a lot of people getting that right from just "feeling" which seems right.

There's a clear attempt to create logical connections: 'directory' manages to evoke a bunch of cards in a file, EMR is a solid reduce block above a bunch of map blocks, and so on. The MediaFoo family is actually quite good - I swapped Package and Store, but otherwise got them all right despite never using the service. The family color scheming is genuinely very good, despite the weird outliers like grey.

But then there's all the rest. Kinesis and Cloudwatch are each a bar graph with a base, but Kinesis is rotated, and has 2 layers of floating base instead of 1 joined layer, so that totally clears things up. (And Athena is 1 layer floating base, with bars going both directions, to help confuse the existing two.)

ELBs and ECS are both multiple full-size layers on the left with a 4-rectangle split layer on the right, but ELB is 3 filled layers and a flat split layer. ECS is hollow layers and a 'long' split layer. Memorable!

Database Migration Service is a mix of Direct Connect and RDS theming, which actually makes sense, but also Elasticache is a disjoint version of Direct Connect in database coloring?

(I had a hell of a time looking these up to check, because about half the guides on Google Images are simply wrong about some services. Check out Elastic IP, which is listed with the icons of 3 other services!)

1) They can't find certain AWS icons (the problem is it's there, they didn't expect it to look like that).

2) They change and move between sets rather a lot. That was more a problem previously, the set hasn't actually changed yet this year.

If there's a designer out there willing to create an alternative set, we're more than willing to add it in and see what people prefer. Probably more constructive than just saying "they are bad", show us something better.

Asking for others to contribute to open source is a generally accepted concept.

https://github.com/jgraph/drawio

Their designers recently declared that colored icons were distracting (?) and are currently moving most of the them to gray. Quite confusing when gray usually means disabled.

I wouldn't say the icons are _good_, but I wonder if part of the reason the quiz is so hard is that Amazon doesn't really care if you know what the icons mean anyway. Seems like they're mostly used for branding and marketing, not anything users will see regularly.

That said, they're probably extremely easy to generate procedurally:

http://iquilezles.org/www/articles/distfunctions/distfunctio...

Icons had just come into vogue (yes, there was a time before icons). The CAD system in question used a puck on a big mat to choose functions from a grid of names, which were labels like GRAPH and CONNECT and DEL and so forth. But all-caps names weren't very sexy, so the company decided to replace them with more intuitive icons, cool little pictures of the operations. Getting rid of the tiresome and uncool simple text labels was going to win back market share!

Predictably, users complained that they had a hell of a time trying to figure out which of the tiny, intuitive pictures corresponded to the concrete operations.

The company's response? Supply users with a printed cheat sheet that let them find the icon for each operation. To do a CONNECT, you'd look at the cheat sheet and find the corresponding essentially arbitrary (but intuitive!) squiggle, then search for the intuitive squiggle in a sea of other intuitive squiggles. ("No, not that one!")

But, I believe that at least two of the questions have incorrect/incomplete answers:

One of the questions that requires a typed answer (instead of multiple choice) shows an icon that is used for both EC2 & Appstream. However, only EC2 is considered correct.

In the Route53 icon question - there are multiple versions of the Route53 icon used in different places (do a google image search and you'll see a dozen variant). The icon in the top left ("Pole with two offset rectangles") is used in the console - but this is considered an incorrect answer. The icon in the top right ("Pole with two slightly less offset rectangles") is sometimes used elsewhere and is the only answer considered correct.

They’d be better off putting up a text file because then at least the IT guys would already know how to use it. And making changes would be a hell of a lot faster too.

I also wonder if they painted themselves into a corner early on by having them for their early services. I guess they're a big-boy company and have stopped doing this earlier but who knows.

[1]: https://aws.amazon.com/inspector/

Every icon in Google Cloud is a nearly-identical blue hexagon. They might as well not even have icons.

People suggesting that they follow Adobe's lead. That's all well and good, until you release like 1000 products a year. You tend to run out of two letter combos for your icons.

https://www.expeditedssl.com/aws-in-plain-english.

While using AWS services and leading huge migration projects, I've never thought to myself: "These icons are terrible and slowing down my progress". As in to say, sure the UX icons are a little wonky, but at the end of the day, do are they really impacting people from getting the value out of the services and using them quickly? Maybe Amazon is partaking in what is often sentiment around here: not optimizing things too soon.

Summary: while icons might be confusing and not great, I find zero impact in me architecting systems and communicating designs.

(Ok, I made the last two up, but I bet you would've had to look ...)

Just hover over the products menu at the top: https://aws.amazon.com/

I am more bothered by names that do not give you any clue as to what they are about, though there is also a limit to the amount of information you can put in a name.

(The main point of the survey came across very well, though.)

those are some garbage icons.

[1] https://preview.ibb.co/dd86RK/aws_dms_inspected.png

I don't think I could answer any of those questions. I actually gave up because it started to feel ridiculous, like I was just looking at random geometric shapes.

But my point is that I still use AWS and I find what I need without ever having seen those icons or remembered them. The console remembers my most used tools so usually I find them in that shortcut menu.

If not... who cares? They're not branded consumer products that need recognition, just a bunch of services and it's not like I'd have any even remotely good ideas for most of these jargony things anyways... :P

5/20

Working without any issues with aws daily.

Would be cool to do a similar quiz describing different failure modes of various services and having the user select which icon should be showing.

This is great though!

[1] https://status.aws.amazon.com

https://landscape.cncf.io/grouping=organization&organization...

The services don't even have consistent icons displayed between them, I tend to think the icons are actually completely meaningless.

Sorry if you worked on these icons I guess.

They got rid of the myriad of abstract icons, and now use a smaller set of recognisable icons, with related services grouped under the same icon.

I use the AWS console all day every day, and I couldn't name a single icon. So my guess is they are just intended to be art icons, nothing purposeful. Or they're too similar to be mnemonic.

Nice one.

I know this is mostly for fun, but that is a wildly faulty premise.

Which is good, otherwise ECS Fargate wouldn't have made a lot of sense.

[1] https://aws.amazon.com/ecs/

Also, the logos are color-coded by "service category" if I'm not wrong

Off-topic (and sort of translated):

Salut Virgile, complet de acord cu tine, dar dacă făceau textul colorat în culoarea "service category", viața era mai simplă pentru toată lumea :) (lume mică, domne, uite de cine dai pe net :D)

Ref offtopic: nu e cinstit, eu sunt usor de recunoscut dupa ID (plus am mailu' in profil). Nu stiu cine esti :)

https://i.imgur.com/e4BJrne.png

https://i.imgur.com/wSqVMp4.png

I actually would be curious now to see how a company like Apple might approach the problem. Apple’s well-known icons are largely focused on popular apps, which have very distinct and concrete functions. I wonder if there really is a clear and unambiguous icon for something esoteric like a NoSQL database store - I suspect that there isn’t, largely because (unlike apps) it just isn’t something that is in the public eye.

Indeed. It's hard to make changes like that since it often results in existing users getting pissed off. Even if it's for the better in the long run.

Same way with color coded money in most non-US countries, you just pick a note based on color.

I almost think this was a deliberate choice. Makes the services sound more important than what they are. At any rate, many engineers I know love to smugly use this acronym soup.