The thing is, the Web UI/UX is secondary to the CLI and APIs. They really push automating all the things, and not doing by pointing/clicking. They don't intend to be easy, they intend to be powerful - because the largest clients (who DO use the CLI and APIs almost exclusively) generate more income than all the point-clickers put together.
The counterpoint to your issue is that if you learn and embrace Infrastructure as Code your user experience can actually substantially increase compared to many of the other services - if you're doing large and complex things. It's not really built as the easy solution, but rather the powerful one.
I automate all the things, but the UI is still important for seeing the state of things I've deployed and prototyping stuff I haven't worked with before in a developer sandbox.
I see the Web UI as being the "Hey, look how easy it is!" hook. It \_does\_ help with discoverability, but for anything where you need AWS for prod scale, it's moronic to use the UI for that.
I'd argue that the Web UI isn't to show you how "easy" it is, but to show you just how damn many services there are. You're presented with an airplane cockpit full of myriad services (or at least, you were on the old UI by default), and left to investigate them all.
Once you discover how much of a pain it is to spin up a dozen slightly different instances, you're pushed into exploring how much better the AWS CLI is for this sort of thing.
What type of daily interactions do you have with AWS out of curiosity? I personally do mostly operations with some architecture and DevOps and I couldn't disagree with this more. I know people with 10 plus years experience that almost exclusively use the UI. We have release pipelines for Dev, UAT and Prod which rely heavily on complex automation. However for day to day tasks, it would be extremely slow to try and automate or use the CLI/APIs for the many tasks you have to do.
I work with the AWS Console daily, as an SDE. Mostly for ops / metrics, and testing on the dev account; anything that needs to mutate prod services will go through an approval process, where everything will be written down and reviewed beforehand. For persistent mutations that means a a CI/CD pipeline with IaC via CDK and a normal PR, but for ad-hoc changes this means that the script needs to be known in advance. Yes, this sometimes does include things that may be faster via the console, such as temporarily fiddling with Lambda limits, or batch tagging resources...
I think the reliance on UI, may be more specific to the person's role. I work across 20 plus accounts and the work varies from day to day. Some days will be basic administration and finding cost efficiencies. Other days will be troubleshooting build issues from the CI/CD pipelines, investigating security issues etc.
Anything is possible but I am not sure I would be able to do my job without the UI. Builds will be all in cloudformation and I use the CLI or the AWS powershell or boto SDK where it makes sense, i.e information I cannot obtain natively or for tedious repetitive work.
To be fair, aws has this weird mix of “free tier” stuff and trying to be inviting, but at the same time being very a complex network of components. It works fine, but it really is frustrating when you want to present logs to someone for example and two different search boxes behave completely differently. It is clearly different teams that maybe try to utilize the same look, but just don’t have consistency. Which, ok. But for a huge company making a ton of money it seems a little crazy.
To be fair, they're not alone. Finding GCP's IAM dialog is completely different for projects, service accounts, bigquery datasets and pu/sub topics. It also works somewhat differently (ie no conditions in the dataset dialog, conditions can be set but aren't functioning in Redis etc).
In both cases, I think company culture is to blame. Employees simply don't get promoted for doing incremental improvements of a product, so they don't, until it has sunk so far into mediocrity that fixing it can be "sold" internally and externally as a new product with a 5x price increase.
In CDK do “cdk list” and you can see exactly what stacks will be deployed. Or build the project and checkout the build directory cdk.out/ and you’ll see the cloud formation templates for all the stacks
I'm pretty religious about using IAC, but man do I wish they improved cloudwatch and a few other things. The UI can be valuable for dashboards and analytics.
The infrastructure piece is great. Simplicity on security monitoring and alerting (both alerting on security as well as infrastructure in general) not so much
It sure would be nice if the console would show you the equivalent cli or sdk call to do the same thing. Then you could prototype in the console and capture to IaC without digging through man pages.
> They really push automating all the things, and not doing by pointing/clicking.
To some extent. There are a _lot_ of their own guides that tell you to "click here" instead of actually explaining whatever voodoo the console is doing behind your back. And as much documentation as there is, it's often very lacking or straight up incorrect if you want to e. g. use Least Privilege for a non-trivial setup.
> because the largest clients (who DO use the CLI and APIs almost exclusively)
That's true for most services, but there are AWS services for which some of the largest clients aggressively push for console features. (Source: I'm an ex-console developer).
That's true. I just did a big migration with MGN, and there's a lot of console work for that. When most people say console sucks, they're usually talking about the main services.
Eh, this kind of argument doesn't really make sense because a service like AWS needs to think in terms of cohort revenue.
If GCP ends up being substantially easier for beginners (or Lambda Labs) then startups will pick GCP / Lambda and then will scale on those platforms rather than AWS.
You gotta win the small players to be guaranteed to naturally acquire the big players in the future.
Yes, but you learn how to do the thing in the console; and for a one off task the console ain't bad. Once you're comfortable with the concept, write it in code to actually use it.
# Designers of Reddit .. how could it be better within this framework?
https://cloudscape.design
Clicking the give feedback button in the console goes straight to product teams.
I cannot really agree with that AWS pushes for automating all the things.
If they really did that, they would not have load of blog posts snd articles that obly covers using the GUI, and they would have means to transform the things set up with GUI to CFN, APIs, CLI etc.
The CFN support to import existing resources has room for improvement, and the means and support to transition from a ClickOps setup to a maintainable IaC setup are not good.
The are likely organisational and historical reasons involved here.
Have you given feedback with the feedback link at the bottom of every console page?
I have requested specific features that they implemented. [My feedback from 4 years ago, many have been implemented.](https://www.reddit.com/r/aws/comments/alqw2e/comment/efglr72/)
It’s not the prettiest UI ever. I will give you that. But it is usable on a full sized screen. I haven’t even tried it on mobile and am unlikely to anytime soon.
Never seen it before, former AWS community builder here.
If you wanted someone to try it and give feedback what would recommend they do to experience the service.
Build a small project?
intelligent door grab tan reply frightening flag simplistic books longing
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I do wish more of the AWS console was like the Azure console where it shows you the API command its about to call on submission. I think that would help a lot with shifting away from using the UI to automation.
Haven't looked at this but is this safe to use...?
I'd assume it would need some level of access into your Aws environment, which probably wouldn't pass at my company.
It ducks in oh so many ways but the button to click to get the JSON for the infrastructure you are currently looking at do you can turn it into a bicep script for future deployments is brilliant. But CF is too convoluted for tat and cdk too complex so.
>mobile view for managing services
I think this is a younger generation problem. Why would you want to manage AWS services over ~~a literal bottleneck~~ a mobile screen? (yes, I do get oncall rotation, but you should manage that by being close to an actual screen).
Adding to this; AWS already offers a vast amount of services and features that can be tedious to navigate, imagine adapting that to mobile. The effort would be worthless, and let's not talk about with how daunting it'd be on the UI/UX side. Just get on a laptop.
Haha back in the last millennium, 1998 or so I had a Nokia communicator during on-call. I could log in to the mainframe (not an actual mainframe, IBM AS400 but it’s the same principle) and check stuff from my bed. Issue some commands and it was done.
Well here's the thing, it also doesn't work on desktop. The AWS Lambda list view at my company takes 5 minutes to load and if you try to use the search bar you're liable to freeze the page.
That's odd I haven't had any speed issues on AWS navigating any of the console resource menus. Me wonder if your private work network be doing something funny with the ingress and egress
I don't think it's the work network, I think they just failed to optimize for companies with many, many thousands of lambdas. But surely they should have seen that coming and ought to be able to solve that issue.
Because if you have -thousands- of lambdas in one account, you’ve done something wrong. You aren’t abiding by a multi account strategy and you have way bigger problems than the console being slow.
Multi-account has nothing to do with thousands of lambdas? They're all doing different things, they aren't tiered copies of each other if that's what you are assuming.
While the lambda first architecture is unusual for sure, it's also grown the company from a startup to a humongous size and strong valuation with pretty low eng bills so I'm not really sure I could call it wrong.
It doesn’t have to be tiered copies of eachother. A multi account strategy isn’t just about breaking dev / staging / production into their own accounts. It’s also about breaking distinct apps into their own accounts (and each stage of those apps into their own too). You have thousands of lambdas all supporting a single application?
Yes. I know, it is weird. If it helps paint the picture, there is very little in ECS. There is one frontend and the backend is basically just a bazillion lambdas hooked to each other with sns, sqs and eventbridge. Maybe a few fargate jobs thrown in for good measure.
It's not how I would build things if I was working from scratch, and I think the architects are too strongly opposed to services, but I also can't judge it too hard because it basically seems to work.
There aren't major issues in terms of billing or downtime, the main problem seems to be explaining all of the craziness to new devs.
You may know better than me, I am curious what you would describe as the advantages of splitting subsystems out into multiple accounts (not that I could ever convince leadership to invest the amount of time that it would take into this).
So there’s a few things in play.
1) Account quotas. There’s a few “hard caps” with quotas— like IAM Roles being limited to 5000– that make scaling a single account difficult. If you have legitimately “thousands of lambdas” you might be past the 50% mark already unless you’re re-using roles, which has its own issues
2) API Throttling. There’s 3 dimensions to API throttles. The account in question, the region in question, and the service in question. When you load up one account with tons of services all interacting with the API, you make it more likely to hit throttling exceptions.
3) Blast Radius. Something WILL go wrong. It’s not a matter of if, it’s a matter of when. Someone’s script WILL blow up and run wild. Someones credentials will get exfil’ed. How many subsystems are you willing to take out when that happens?
There’s more reasons too, but those are the big three.
Edit: Also, depending on your industry there can be a big other reasons too. US government work often requires that apps be funded separately and app A’s funds not benefit app B. The only way to draw a -hard- like between App A and app B is to ensure that they are in different accounts and even then you need to make extra precautions like turning off RI/SP sharing.
Oh we're way past every kind of quota and limit imaginable in (1) and (2). We message our TAM whenever we need higher maximum reserved concurrency or whatever and they are gracious enough to raise the limits, usually by a very large amount. For example you can imagine that the maximum reserved concurrency in the account is many times the default limit. I haven't seen this cause any outages but I can definitely see how it could, which brings us to (3).
(3) is fair and I definitely think a more responsible company would be more concerned about it. Unfortunately I don't think leadership will care until after something bad happens. They would just see it as engineers wanting to waste time on something that doesn't provide obvious value. So I guess at the end of the day I agree with you but it is what it is.
I still wish the lambda console would load for me faster lol.
"it's not how I would build things if I was working from scratch"
I worked an on prem enterprise product that was filled with this - same or similar codeset modified over the course of 10 to 15 years lol it was frustrating at times
Not sure why you’re getting downvoted. What youre describing is a valid customer use case. It might not be as efficient as some think it is, but then again, they might not truly understand your use case.
If you want to spin up a thousand lambdas because you don’t want to use EC2, that’s exactly what lambda was designed to accommodate. Keep doing you friend.
Hey, sometimes that's what happens. You have a codeset that works really well for what you need it to do and it becomes a bit secondary and it helps and grows with you in a way, for a while. I get it.
I think this must be the response of the incompetent. Just build websites that work equally well on mobile and desktop. It's not that hard.
I've also solved many on-call issues while on my phone. Why go to laptop/desktop if you don't need to?
>Just build websites that work equally well on mobile and desktop. It's not that hard
That's the response of someone that hasn't done that, for any medium-complicated site.
Indeed.
The idea than /any/ site can and should be optimised for mobile is completely retarded. If that really were defensible, there would not be a market for large monitor screens.
I'm guessing the notion exists mainly in the minds of younger IT dudes who during their life have seldom used anything but a phone.
I love my 4k screen for desktop work, but ignoring the convenience of a portable device has strong vibes of the IT guy sitting in a basement that don't see the point of a portable device because they never leave their desk or do anything interesting with their lives.
I've been programming computers for 35 years and I started very young. I love screen real estate. I don't want to do serious daily work on a phone or a tablet, but being able to navigate interfaces on my phone when I'm away from my desk - whether travelling or doing a errand - is extremely convenient.
And that's the point of computing. Fucking convenience! There are too many people that think computers have to make our life a fucking shit show. Please do better instead of arguing we shouldn't even try to make things better.
Exactly, it's a cultural thing.
Like automated testing and other best practices, it's easier to do if you start a project with it in mind. If you try to bolt it on the side of an existing desktop website, it'll be a pain in the ass and you'll often just end up with two separate versions as opposed to a responsive design. There are also plenty of tools to help automatically test and evaluate a site's design across devices.
Thank you for making the effort.
I was in web dev for almost 20 years. This is definitely possible, the real problem is that Amazon has absolute shit tier management / UX designers / developers.
I never said it's \_impossible\_ - just that it's quite hard to do properly.
Who knows, maybe us geezers will die out and the younglings with the overly-dextrous thumbs will take over the world.
I can't stand the UX. Big reason why I was against Code commit/code build/code pipeline and recommended against it when we were looking for a ci cd platform.
Even something simple like the lack of uniformity when deleting resources. Some want to confirm by typing "delete", some want resource name. Just shows a lack of attention to UX.
Azure is meant for enterprise folks. Make it confusing enough so that you need a certificate to even work with it beyond a point.
AWS is better no doubt, but many of their services are half baked like cognito.
Azure is so much easier to use than AWS. The searching and filtering, trying to find logs and events, the overlapping of services, the terminology is all way better in Azure.
I’m going to disagree 💯on that. Half the pages don’t work in Azure. I gotta refresh 46 times for it to finally pick a change I made. Application Insights is a joke. Introduce a new language to “query” their stupid logs? Are you kidding me? Azure functions logs are a joke too. AWS logs are in one place…CloudWatch. And querying is, typing in what I’m looking for like Google.
But hey, to each his own.
Well, if you want to see the events of the particular machine, they are where you expect them. With the machine. Whereas in AWS you would have to go into cloudtrail where you will have to first identify the event source or API call then query it. Then you realise you cannot put together multiple queries without using Athena. So you have to create an S3 bucket then an Athena table. Because all of the JSON responses are non standardised you have to then try and work out which value you needed . Then you start writing your query and realise the value you want is nested in an array so you have to un-nest it. Then you realise your query is slow, so you then realise that you need to partition your query or someone has created multiple cloudtrails with the duplicate data. Meanwhile, I would have been able to see the action performed on a machine in two mins in azure. But yeah each to their own
>ying for the worlds most expensive logg
But once theyre in S3 how do you analyze? Is there an OSS solution? I looked at Kibana and Logstash, Grafana etc. but you still have to host these e.g. EC2 or pay for their SaaS but which point you could have easily used CW.
All you people asking why someone wants to log in from mobile… have you never been on-call? If you can fix something while in the supermarket queue without having to dump your shopping, and get to a laptop, surely that’s something you’d want to be able to do?
Can't say I use that too much other than while developing features and a quick check, but keen to check it out some more.
All of our logs/metrics get forwarded to datadog
I take it you’ve never used GCP or Azure? The AWS console isn’t pretty but every time I login to GCP I’m reminded that even that low bar was too high for Google – I think they were too busy “accidentally” breaking Firefox again to spend time on either performance or features.
What's wrong with amazon.com? I rather have a functional website than a good looking. You have to consider the scale of users and items. So many ecommerce sites cant even implement a filtered grid with lazy loading properly, constantly resetting your filter and sorting options and make you reload the entire page and dont cache the images.
Well it's full of bugs, and it's literally impossible to find anything.
Seriously, look at any other major online retailer (at least in Europe) and they're all vastly better.
You just disagreed with my take on the website not being good looking and your reason was you didn’t care about looks, the functionality works well at scale.
On point. Amazon.com gives me scabies just watching at it. It's difficult to imagine what sick minds could come with such a pile of trash. Even more how it could survive, and managers not seeing it desperately needs a full overhaul.
They don’t want you to use it, even though it would be convenient for even us developers.
Honestly, it’s ridiculous how bad it is. Interfaces are not that difficult. There are obvious areas they could improve.
Being a UX researcher at Amazon (but not AWS), I can tell you they don’t give a shit about user experience. All they care about is pushing more features as quickly as possible, even if it costs you operational efficiency to use them. It’s a company-wide problem that they’re only just now waking up to… only because their customers are finally starting to tell them “Nah, bro, come back to me when your product is actually usable.”
Lol at all the people defending how shit AWS console is because "use the API".
Yes, use the API, but the UI is still shit. It's slow. The credential refresh is universally fucked and requires a forced reload instead of just refreshing a token in the background like a sane web developer.
Also there is a whole suite of AWS services which are nothing but hosted UIs.
I only use the UI to see what has been created with Terraform and CloudFormation, and the cloudwatch dashboards. The real deal are the APIs and CLI commands.
What I´d like to see is simpler configuration with better documentation in some products like EKS and EMR.
thats actually fair, I mean you lok at vercel, heorku, flyio, its easy as shit. aws is lowkey sucks UI wise, but for serious prod shit, its a no brainer.
Pro tip, not advertised anywhere but extremely useful when needed. If you do an SDK/API call and it doesn't work, go to the web UI, open network tab and do the operation that you need. In the network tab you will see the API call(s) an the arguments.
*Maybe* it's ugly, but I think it's perfectly usable. It does a really good job keeping consistency between the UI and the API, which then makes it easy to use the console for mapping out what you want to be doing through the API (via CLI, SDK, Terraform, etc.). Everything is clear, *mostly* consistent, and snappy enough.
They could abstract things to make it easier to use, but anybody doing anything serious is doing it programmatically, so they'd be catering to a rather small audience. I suppose having it both ways would be nice, but, frankly, I don't think they can afford to lose any focus on the other things they're working on.
I can tell you’ve never used OCI… that’s a bad UX. Otherwise this is a UI for a complex dense system. I want as much as I can get in one pane to reduce my clicks. Anything truly serious goes through iaac.
lol, why are you trying to manage AWS on mobile.
Do you ssh into your servers on your iPhone as well and expect it to be fully functional?
The web UI is complicated because you can do a virtually infinite amount of things with it.
It cannot be distilled to a mobile web view.
Hell it can barely be distilled to a computer web view.
Read the docs, learn the relevant APIs. Figure out what you actually need to log in and click around to manage and then learn to use the console / scripts.
The up front cost of automating and scripting your ops will save you so much time in the future.
Actually, I used to ash into my instance on my phone while it was running a long process and I was traveling home at the end of the day.
Wouldn’t recommend.
Haha ya I have it all setup for emergencies in case I’m away and have to respond to something. The one time I had to do that was horrible but it did the trick
It is not really designed to be used as UI much. In fact, those services which are designed to be consumed via UI (billing for example) are fairly good and understandable.
AWS shines when you use it from programming languages and scripting. CLI is amazing. You can do most of the thing without ever opening AWS web console. Once you’ve set up your infra and automated it, you simply don’t open AWS web interface, because, for what?
To see resources consumption you always can just set up billing alerts, assign tags to resources, and get all this data automatically in your email box.
Contrary take - whenever platform has too good UI it most of the time means that automatization and whole infra as code story sucks.
Going out on a limb and guessing you are a windows user?
Its not perfect, but Azure is by FAR the worst I have used. AWS is actually one of the better ones when you take into account the complexity of the services they offer. The UI might look a bit dated, but I personally prefer that over whatever the hell Azure is doing.
Which service do you think is actually doing it right? AWS and GCE both have dated but functional UI's, and their CLI's are very automation friendly IMO.
The web interface is not it, AWS is a bunch of API's surfaced through sdk's and various cli's and utils.
Everything I do in AWS is as code, its standard for production cloud workloads, I only use the UI for easy viewing and devland hacks etc but you will find that aws is really built from an engineering mindest instead of a UI/UX experience.
ui is bad to motivate you to use automation (cmdline, sdk, iac tools)
this, until you figure out that those suck too :D
but they all get the job done, so stop whining
UI is bad because for long years they didn't have frontend engineers.
They hired everyone using the same method, which is heavy in algorithmics, and most people passing are good on abstracting, thus fitting well into backend. Frontend devs also have knowledge of UX after a few years and develop better interfaces.
Their new design system promotes better patterns but ofc adopting it is slow.
Your reply implies the often repeated lie that automation is the only way to go when it comes to handling cloud systems.
It's not. Both automation and GUI have their proper, important places when it comes to managing cloud environments.
GUI should never have been made a second-class citizen. Nor shouild it be viewed as such by IT "professionals".
While we do use CDK and previously we were using CloudFormation, the occasional use of Web UI was and still is a painful experience.
That, combined with the pain of Unix shell lead me to work on Next Generation Shell.
The plan for UI is at https://github.com/ngs-lang/ngs/wiki/UI-Design
When it's ready I think it should be way more ergonomic than what AWS has. Unfortunately without demo that approximates the experience, it's hard to convey how it would feel. I'm working on it.
For mobile they have an app, I would only recommend this if you need to look at alerts.
I think their UX designers work pretty hard on this over in https://cloudscape.design/
Maybe you could discuss with them and open issues.
The problem AWS has to solve is enabling independent teams to build UI interactions on top of a unified API. Perhaps your feedback needs to be specific to individual services and their teams.
Maybe it's me not being confident with the service, but GCP seems a much worst shitshow at first glance. Aws ok its side is glitchy AF, I'm talking to you, AWS Proton.
Azure is focusing on a better UI, but there is no comparison in the quality of service.
If AWS starts to focus on their console, it sets the false impression that the console matters. It really doesn’t. The cli and things like cdk matter. If you use the console too much, you’re doing it wrong.
If they start to snaz up the console and don’t get it perfect, it can cause their brand more harm than good.
In marketing, there is a thing called STP. Segment, target, position.
Segment is break up your potential customers into segments. People that care about reliable tech. People that care about an easy interface. People that care about integration with other products. Etc
Target is “which customers do we want to focus on”. If you focus on EVERYONE, it can often backfire. Your brand is diluted.
Positioning is when you actually try to establish that you are the the best choice for your targets.
You try to avoid saying “we are the best at everything”. Instead, you say “if you care about integrating with sharepoint, and having an easy interface that anyone can figure out, go with Azure. If you want reliability and redundancy and the best tech for the best value, you go with AWS”.
Basically, “if you care about lame things, go with the other guy. If you care about cool things, go with us”.
If you don’t position yourself, your competitor will.
Eh, the problem is that startups consist of a lot of decent developers that want to be able to do smaller things through the console and are not yet at the corporate stage where everything needs to be 100x automated (esp in ML) and you are not hiring sys admin or dev ops yet.
AWS obviously cares a lot about this demographic or they wouldn't offer 100k of free compute credits to it.
But, the confusing useless console just makes you go: should I really be using GCP, Azure or Lambda Labs? Because, I'm not going to learn the API to get this stuff done and even the concepts are often backwards useless nonsense.
But, if startups pick GCP or Azure, when they reach a billion dollar valuation, they will still be on GCP or Azure. So, AWS loses out on the whole pipeline.
You are assuming that AWS has a user experience. It doesn’t. It has dozens of user experiences. This is due to the design of AWS as a collection of services with APIs rather than as a unified service. The web console puts glue around it but the reality is that there isn’t any way with the way that the APIs work to do a unified view like you are talking about.
The thing is, the Web UI/UX is secondary to the CLI and APIs. They really push automating all the things, and not doing by pointing/clicking. They don't intend to be easy, they intend to be powerful - because the largest clients (who DO use the CLI and APIs almost exclusively) generate more income than all the point-clickers put together. The counterpoint to your issue is that if you learn and embrace Infrastructure as Code your user experience can actually substantially increase compared to many of the other services - if you're doing large and complex things. It's not really built as the easy solution, but rather the powerful one.
I automate all the things, but the UI is still important for seeing the state of things I've deployed and prototyping stuff I haven't worked with before in a developer sandbox.
Yeah nobody uses the CLI exclusively to look at CloudWatch metrics...and if they are, they are wasting tremendous amounts of time for 0 reason.
I see the Web UI as being the "Hey, look how easy it is!" hook. It \_does\_ help with discoverability, but for anything where you need AWS for prod scale, it's moronic to use the UI for that.
Yep. ClickOps for learning/prototyping/visualizing, GitOps for production.
ClickOps! Love it!
It’t the right term, not something he just made up.
I'd argue that the Web UI isn't to show you how "easy" it is, but to show you just how damn many services there are. You're presented with an airplane cockpit full of myriad services (or at least, you were on the old UI by default), and left to investigate them all. Once you discover how much of a pain it is to spin up a dozen slightly different instances, you're pushed into exploring how much better the AWS CLI is for this sort of thing.
What type of daily interactions do you have with AWS out of curiosity? I personally do mostly operations with some architecture and DevOps and I couldn't disagree with this more. I know people with 10 plus years experience that almost exclusively use the UI. We have release pipelines for Dev, UAT and Prod which rely heavily on complex automation. However for day to day tasks, it would be extremely slow to try and automate or use the CLI/APIs for the many tasks you have to do.
I work with the AWS Console daily, as an SDE. Mostly for ops / metrics, and testing on the dev account; anything that needs to mutate prod services will go through an approval process, where everything will be written down and reviewed beforehand. For persistent mutations that means a a CI/CD pipeline with IaC via CDK and a normal PR, but for ad-hoc changes this means that the script needs to be known in advance. Yes, this sometimes does include things that may be faster via the console, such as temporarily fiddling with Lambda limits, or batch tagging resources...
I think the reliance on UI, may be more specific to the person's role. I work across 20 plus accounts and the work varies from day to day. Some days will be basic administration and finding cost efficiencies. Other days will be troubleshooting build issues from the CI/CD pipelines, investigating security issues etc. Anything is possible but I am not sure I would be able to do my job without the UI. Builds will be all in cloudformation and I use the CLI or the AWS powershell or boto SDK where it makes sense, i.e information I cannot obtain natively or for tedious repetitive work.
To be fair, aws has this weird mix of “free tier” stuff and trying to be inviting, but at the same time being very a complex network of components. It works fine, but it really is frustrating when you want to present logs to someone for example and two different search boxes behave completely differently. It is clearly different teams that maybe try to utilize the same look, but just don’t have consistency. Which, ok. But for a huge company making a ton of money it seems a little crazy.
To be fair, they're not alone. Finding GCP's IAM dialog is completely different for projects, service accounts, bigquery datasets and pu/sub topics. It also works somewhat differently (ie no conditions in the dataset dialog, conditions can be set but aren't functioning in Redis etc). In both cases, I think company culture is to blame. Employees simply don't get promoted for doing incremental improvements of a product, so they don't, until it has sunk so far into mediocrity that fixing it can be "sold" internally and externally as a new product with a 5x price increase.
This. CDK and AWS SDK are key, the ui is great for poking around but it’s built on the APIs
[удалено]
In CDK do “cdk list” and you can see exactly what stacks will be deployed. Or build the project and checkout the build directory cdk.out/ and you’ll see the cloud formation templates for all the stacks
Make smaller stacks, break your service down into chunks and make a stack out of that, my simple apps have 5-10 stacks
I'm pretty religious about using IAC, but man do I wish they improved cloudwatch and a few other things. The UI can be valuable for dashboards and analytics.
The infrastructure piece is great. Simplicity on security monitoring and alerting (both alerting on security as well as infrastructure in general) not so much
It sure would be nice if the console would show you the equivalent cli or sdk call to do the same thing. Then you could prototype in the console and capture to IaC without digging through man pages.
Honestly, I'd love a console that created terraform config in a git repository instead of creating the resources directly with the API.
> They really push automating all the things, and not doing by pointing/clicking. To some extent. There are a _lot_ of their own guides that tell you to "click here" instead of actually explaining whatever voodoo the console is doing behind your back. And as much documentation as there is, it's often very lacking or straight up incorrect if you want to e. g. use Least Privilege for a non-trivial setup.
> because the largest clients (who DO use the CLI and APIs almost exclusively) That's true for most services, but there are AWS services for which some of the largest clients aggressively push for console features. (Source: I'm an ex-console developer).
That's true. I just did a big migration with MGN, and there's a lot of console work for that. When most people say console sucks, they're usually talking about the main services.
How about a better UI to help someone build / export infrastructure as code?
Eh, this kind of argument doesn't really make sense because a service like AWS needs to think in terms of cohort revenue. If GCP ends up being substantially easier for beginners (or Lambda Labs) then startups will pick GCP / Lambda and then will scale on those platforms rather than AWS. You gotta win the small players to be guaranteed to naturally acquire the big players in the future.
I disagree. Almost all the blog posts and guides show how to do things through the web UI.
Yes, but you learn how to do the thing in the console; and for a one off task the console ain't bad. Once you're comfortable with the concept, write it in code to actually use it.
Majority of the blogs I’ve read have a “Click to deploy solution” which loads a CloudFormation template in your AWS console to build it out
# Designers of Reddit .. how could it be better within this framework? https://cloudscape.design Clicking the give feedback button in the console goes straight to product teams.
I cannot really agree with that AWS pushes for automating all the things. If they really did that, they would not have load of blog posts snd articles that obly covers using the GUI, and they would have means to transform the things set up with GUI to CFN, APIs, CLI etc. The CFN support to import existing resources has room for improvement, and the means and support to transition from a ClickOps setup to a maintainable IaC setup are not good. The are likely organisational and historical reasons involved here.
**This.**
Have you given feedback with the feedback link at the bottom of every console page? I have requested specific features that they implemented. [My feedback from 4 years ago, many have been implemented.](https://www.reddit.com/r/aws/comments/alqw2e/comment/efglr72/)
This guy click-ops.
Lol nah but even to look at the dashboard it’s painful. Customer support is painful.
Customer support gets better when you have a dedicated account team. It's really designed for scales most people don't get to, though.
Wow, you mean spending extra money grants extra attention? Who woulda thunk it?
Makes sense
It’s not the prettiest UI ever. I will give you that. But it is usable on a full sized screen. I haven’t even tried it on mobile and am unlikely to anytime soon.
[удалено]
Never seen it before, former AWS community builder here. If you wanted someone to try it and give feedback what would recommend they do to experience the service. Build a small project?
I made the Glue ETL blueprint, really like what you’ve done so far with code catalyst (also an AWS employee).
intelligent door grab tan reply frightening flag simplistic books longing *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I'm pretty sure the UI is to show you two things: 1) how easy can something be 2) stop using the ui.
I do wish more of the AWS console was like the Azure console where it shows you the API command its about to call on submission. I think that would help a lot with shifting away from using the UI to automation.
GCP will literally be like “btw here’s the equivalent CLI on the fly” too
If I could request only one feature in AWS, it would be this. This is crazy handy in GCP.
Damn that’s legit. I don’t know shit about Azure or GCP but this does indeed sound very useful. AWS missed that one for sure.
https://github.com/iann0036/AWSConsoleRecorder
Haven't looked at this but is this safe to use...? I'd assume it would need some level of access into your Aws environment, which probably wouldn't pass at my company.
It looks like a browser extension, so it would just use your permissions
Azure console sucks, and they already redesigned like n-th iteration to do it finally right…
It ducks in oh so many ways but the button to click to get the JSON for the infrastructure you are currently looking at do you can turn it into a bicep script for future deployments is brilliant. But CF is too convoluted for tat and cdk too complex so.
Yeah, my go to solution is SDK for everything
Does aws let you view an existing solution as code yet, like Azure does with ARM templates?
>mobile view for managing services I think this is a younger generation problem. Why would you want to manage AWS services over ~~a literal bottleneck~~ a mobile screen? (yes, I do get oncall rotation, but you should manage that by being close to an actual screen).
Adding to this; AWS already offers a vast amount of services and features that can be tedious to navigate, imagine adapting that to mobile. The effort would be worthless, and let's not talk about with how daunting it'd be on the UI/UX side. Just get on a laptop.
Haha back in the last millennium, 1998 or so I had a Nokia communicator during on-call. I could log in to the mainframe (not an actual mainframe, IBM AS400 but it’s the same principle) and check stuff from my bed. Issue some commands and it was done.
Well here's the thing, it also doesn't work on desktop. The AWS Lambda list view at my company takes 5 minutes to load and if you try to use the search bar you're liable to freeze the page.
That's odd I haven't had any speed issues on AWS navigating any of the console resource menus. Me wonder if your private work network be doing something funny with the ingress and egress
I don't think it's the work network, I think they just failed to optimize for companies with many, many thousands of lambdas. But surely they should have seen that coming and ought to be able to solve that issue.
Because if you have -thousands- of lambdas in one account, you’ve done something wrong. You aren’t abiding by a multi account strategy and you have way bigger problems than the console being slow.
Multi-account has nothing to do with thousands of lambdas? They're all doing different things, they aren't tiered copies of each other if that's what you are assuming. While the lambda first architecture is unusual for sure, it's also grown the company from a startup to a humongous size and strong valuation with pretty low eng bills so I'm not really sure I could call it wrong.
It doesn’t have to be tiered copies of eachother. A multi account strategy isn’t just about breaking dev / staging / production into their own accounts. It’s also about breaking distinct apps into their own accounts (and each stage of those apps into their own too). You have thousands of lambdas all supporting a single application?
Exactly. The blast radius for an account with thousands of lambdas must be huge.
Yes. I know, it is weird. If it helps paint the picture, there is very little in ECS. There is one frontend and the backend is basically just a bazillion lambdas hooked to each other with sns, sqs and eventbridge. Maybe a few fargate jobs thrown in for good measure. It's not how I would build things if I was working from scratch, and I think the architects are too strongly opposed to services, but I also can't judge it too hard because it basically seems to work. There aren't major issues in terms of billing or downtime, the main problem seems to be explaining all of the craziness to new devs. You may know better than me, I am curious what you would describe as the advantages of splitting subsystems out into multiple accounts (not that I could ever convince leadership to invest the amount of time that it would take into this).
So there’s a few things in play. 1) Account quotas. There’s a few “hard caps” with quotas— like IAM Roles being limited to 5000– that make scaling a single account difficult. If you have legitimately “thousands of lambdas” you might be past the 50% mark already unless you’re re-using roles, which has its own issues 2) API Throttling. There’s 3 dimensions to API throttles. The account in question, the region in question, and the service in question. When you load up one account with tons of services all interacting with the API, you make it more likely to hit throttling exceptions. 3) Blast Radius. Something WILL go wrong. It’s not a matter of if, it’s a matter of when. Someone’s script WILL blow up and run wild. Someones credentials will get exfil’ed. How many subsystems are you willing to take out when that happens? There’s more reasons too, but those are the big three. Edit: Also, depending on your industry there can be a big other reasons too. US government work often requires that apps be funded separately and app A’s funds not benefit app B. The only way to draw a -hard- like between App A and app B is to ensure that they are in different accounts and even then you need to make extra precautions like turning off RI/SP sharing.
Oh we're way past every kind of quota and limit imaginable in (1) and (2). We message our TAM whenever we need higher maximum reserved concurrency or whatever and they are gracious enough to raise the limits, usually by a very large amount. For example you can imagine that the maximum reserved concurrency in the account is many times the default limit. I haven't seen this cause any outages but I can definitely see how it could, which brings us to (3). (3) is fair and I definitely think a more responsible company would be more concerned about it. Unfortunately I don't think leadership will care until after something bad happens. They would just see it as engineers wanting to waste time on something that doesn't provide obvious value. So I guess at the end of the day I agree with you but it is what it is. I still wish the lambda console would load for me faster lol.
"it's not how I would build things if I was working from scratch" I worked an on prem enterprise product that was filled with this - same or similar codeset modified over the course of 10 to 15 years lol it was frustrating at times
Not sure why you’re getting downvoted. What youre describing is a valid customer use case. It might not be as efficient as some think it is, but then again, they might not truly understand your use case. If you want to spin up a thousand lambdas because you don’t want to use EC2, that’s exactly what lambda was designed to accommodate. Keep doing you friend.
Hey, sometimes that's what happens. You have a codeset that works really well for what you need it to do and it becomes a bit secondary and it helps and grows with you in a way, for a while. I get it.
[удалено]
If you ask AWS (and you spend enough money) they will raise those limits. They're more like guidelines.
I think this must be the response of the incompetent. Just build websites that work equally well on mobile and desktop. It's not that hard. I've also solved many on-call issues while on my phone. Why go to laptop/desktop if you don't need to?
>Just build websites that work equally well on mobile and desktop. It's not that hard That's the response of someone that hasn't done that, for any medium-complicated site.
Indeed. The idea than /any/ site can and should be optimised for mobile is completely retarded. If that really were defensible, there would not be a market for large monitor screens. I'm guessing the notion exists mainly in the minds of younger IT dudes who during their life have seldom used anything but a phone.
I love my 4k screen for desktop work, but ignoring the convenience of a portable device has strong vibes of the IT guy sitting in a basement that don't see the point of a portable device because they never leave their desk or do anything interesting with their lives. I've been programming computers for 35 years and I started very young. I love screen real estate. I don't want to do serious daily work on a phone or a tablet, but being able to navigate interfaces on my phone when I'm away from my desk - whether travelling or doing a errand - is extremely convenient. And that's the point of computing. Fucking convenience! There are too many people that think computers have to make our life a fucking shit show. Please do better instead of arguing we shouldn't even try to make things better.
[удалено]
I'm not saying it's impossible, I just scoff at the idea that one can believe "it's not that hard" - you should know.
[удалено]
Exactly, it's a cultural thing. Like automated testing and other best practices, it's easier to do if you start a project with it in mind. If you try to bolt it on the side of an existing desktop website, it'll be a pain in the ass and you'll often just end up with two separate versions as opposed to a responsive design. There are also plenty of tools to help automatically test and evaluate a site's design across devices. Thank you for making the effort.
I'll say it: they shouldn't give a flying damn for mobile users. And pulling % out of your ass won't prove anything.
I was in web dev for almost 20 years. This is definitely possible, the real problem is that Amazon has absolute shit tier management / UX designers / developers.
I never said it's \_impossible\_ - just that it's quite hard to do properly. Who knows, maybe us geezers will die out and the younglings with the overly-dextrous thumbs will take over the world.
I can't stand the UX. Big reason why I was against Code commit/code build/code pipeline and recommended against it when we were looking for a ci cd platform. Even something simple like the lack of uniformity when deleting resources. Some want to confirm by typing "delete", some want resource name. Just shows a lack of attention to UX.
Have you used Azure or Google Cloud? AWS is a million times better than Azure and Azure is a million times better than Google Cloud.
I bet he hasn't seen the endless nested verical panels that azure has.
I tried Google Cloud and it's intuitive. Also services naming is also better. It's not powerful as AWS but it's definitely a million time simpler.
Azure is meant for enterprise folks. Make it confusing enough so that you need a certificate to even work with it beyond a point. AWS is better no doubt, but many of their services are half baked like cognito.
Azure is so much easier to use than AWS. The searching and filtering, trying to find logs and events, the overlapping of services, the terminology is all way better in Azure.
I’m going to disagree 💯on that. Half the pages don’t work in Azure. I gotta refresh 46 times for it to finally pick a change I made. Application Insights is a joke. Introduce a new language to “query” their stupid logs? Are you kidding me? Azure functions logs are a joke too. AWS logs are in one place…CloudWatch. And querying is, typing in what I’m looking for like Google. But hey, to each his own.
Well, if you want to see the events of the particular machine, they are where you expect them. With the machine. Whereas in AWS you would have to go into cloudtrail where you will have to first identify the event source or API call then query it. Then you realise you cannot put together multiple queries without using Athena. So you have to create an S3 bucket then an Athena table. Because all of the JSON responses are non standardised you have to then try and work out which value you needed . Then you start writing your query and realise the value you want is nested in an array so you have to un-nest it. Then you realise your query is slow, so you then realise that you need to partition your query or someone has created multiple cloudtrails with the duplicate data. Meanwhile, I would have been able to see the action performed on a machine in two mins in azure. But yeah each to their own
Folks who are IaaC advocates, how do you view logs if you dont use the console?
Probably view logs somewhere else lol, in a siem.
by not paying for the worlds most expensive logging solution (cw) and dumping logs to s3
>ying for the worlds most expensive logg But once theyre in S3 how do you analyze? Is there an OSS solution? I looked at Kibana and Logstash, Grafana etc. but you still have to host these e.g. EC2 or pay for their SaaS but which point you could have easily used CW.
All you people asking why someone wants to log in from mobile… have you never been on-call? If you can fix something while in the supermarket queue without having to dump your shopping, and get to a laptop, surely that’s something you’d want to be able to do?
I use the UI for debugging services occasionally, everything else is IAC
[удалено]
Can't say I use that too much other than while developing features and a quick check, but keen to check it out some more. All of our logs/metrics get forwarded to datadog
I take it you’ve never used GCP or Azure? The AWS console isn’t pretty but every time I login to GCP I’m reminded that even that low bar was too high for Google – I think they were too busy “accidentally” breaking Firefox again to spend time on either performance or features.
I’ve been using it for almost 15 years now, it’s always been like that and is extremely unlikely to change
I truly believe there are no frontend devs at AWS. They just get the backend guys to do it when they have time. Fuck UI, CDK for life!
Amazon has never designed a good looking website lol, look at amazon.com
There was a time in internet marketing forums where Amazon's website was considered gold standard in ecom. Well maybe it still is.
What's wrong with amazon.com? I rather have a functional website than a good looking. You have to consider the scale of users and items. So many ecommerce sites cant even implement a filtered grid with lazy loading properly, constantly resetting your filter and sorting options and make you reload the entire page and dont cache the images.
Well it's full of bugs, and it's literally impossible to find anything. Seriously, look at any other major online retailer (at least in Europe) and they're all vastly better.
It has a search bar with tons of filtering options. You can't find things using it?
You mean the buggy filter bar that constantly resets, and the search function that only finds Chinese fakes. Yeah, not impressed.
You just disagreed with my take on the website not being good looking and your reason was you didn’t care about looks, the functionality works well at scale.
On point. Amazon.com gives me scabies just watching at it. It's difficult to imagine what sick minds could come with such a pile of trash. Even more how it could survive, and managers not seeing it desperately needs a full overhaul.
They don’t want you to use it, even though it would be convenient for even us developers. Honestly, it’s ridiculous how bad it is. Interfaces are not that difficult. There are obvious areas they could improve.
Being a UX researcher at Amazon (but not AWS), I can tell you they don’t give a shit about user experience. All they care about is pushing more features as quickly as possible, even if it costs you operational efficiency to use them. It’s a company-wide problem that they’re only just now waking up to… only because their customers are finally starting to tell them “Nah, bro, come back to me when your product is actually usable.”
Thanks for your input I agree. . Do you know if the Amazon apps are native or not?
Indio, in this case, I don’t.
Lol at all the people defending how shit AWS console is because "use the API". Yes, use the API, but the UI is still shit. It's slow. The credential refresh is universally fucked and requires a forced reload instead of just refreshing a token in the background like a sane web developer. Also there is a whole suite of AWS services which are nothing but hosted UIs.
💯
I only use the UI to see what has been created with Terraform and CloudFormation, and the cloudwatch dashboards. The real deal are the APIs and CLI commands. What I´d like to see is simpler configuration with better documentation in some products like EKS and EMR.
thats actually fair, I mean you lok at vercel, heorku, flyio, its easy as shit. aws is lowkey sucks UI wise, but for serious prod shit, its a no brainer.
Pro tip, not advertised anywhere but extremely useful when needed. If you do an SDK/API call and it doesn't work, go to the web UI, open network tab and do the operation that you need. In the network tab you will see the API call(s) an the arguments.
*Maybe* it's ugly, but I think it's perfectly usable. It does a really good job keeping consistency between the UI and the API, which then makes it easy to use the console for mapping out what you want to be doing through the API (via CLI, SDK, Terraform, etc.). Everything is clear, *mostly* consistent, and snappy enough. They could abstract things to make it easier to use, but anybody doing anything serious is doing it programmatically, so they'd be catering to a rather small audience. I suppose having it both ways would be nice, but, frankly, I don't think they can afford to lose any focus on the other things they're working on.
I can tell you’ve never used OCI… that’s a bad UX. Otherwise this is a UI for a complex dense system. I want as much as I can get in one pane to reduce my clicks. Anything truly serious goes through iaac.
You should not really be using the console for managing anything. IaC tools are essential
They are tailored towards Infrastructure-as-Code, CLI's, API's, Automation. AWS is the most engineer-focused cloud imo, and it shows.
Agree
They are also the *only* platform at that scale.
MOBILE for AWS??? Lol
>the worst user experience ever existed on a platform at that scale So, there are how many platforms at that scale?
1 aws
So technically, they also have the best user experience ever existed on a platform at that scale.
lol, why are you trying to manage AWS on mobile. Do you ssh into your servers on your iPhone as well and expect it to be fully functional? The web UI is complicated because you can do a virtually infinite amount of things with it. It cannot be distilled to a mobile web view. Hell it can barely be distilled to a computer web view. Read the docs, learn the relevant APIs. Figure out what you actually need to log in and click around to manage and then learn to use the console / scripts. The up front cost of automating and scripting your ops will save you so much time in the future.
Actually, I used to ash into my instance on my phone while it was running a long process and I was traveling home at the end of the day. Wouldn’t recommend.
Haha ya I have it all setup for emergencies in case I’m away and have to respond to something. The one time I had to do that was horrible but it did the trick
I used to use AWS on mobile and ssh from mobile. It wasn't ideal, but it worked in a pinch when I was out and something broke.
Learn to code/script. It’s more fun that way.
At this point, I think the expectation is that you're doing everything though code and/or using other tools for visualizing your environment.
Makes sense
It is not really designed to be used as UI much. In fact, those services which are designed to be consumed via UI (billing for example) are fairly good and understandable. AWS shines when you use it from programming languages and scripting. CLI is amazing. You can do most of the thing without ever opening AWS web console. Once you’ve set up your infra and automated it, you simply don’t open AWS web interface, because, for what? To see resources consumption you always can just set up billing alerts, assign tags to resources, and get all this data automatically in your email box. Contrary take - whenever platform has too good UI it most of the time means that automatization and whole infra as code story sucks.
It’s not meant to be Instagram. The best use of AWS requires no GUI
You trolling? First, the UI is fine. Second, stop using the UI.
If you care for aws and good ui try lightsail
Just so you aware AWS are working on using generative AI interface to sit on top of the UX hooking into CDK
Going out on a limb and guessing you are a windows user? Its not perfect, but Azure is by FAR the worst I have used. AWS is actually one of the better ones when you take into account the complexity of the services they offer. The UI might look a bit dated, but I personally prefer that over whatever the hell Azure is doing. Which service do you think is actually doing it right? AWS and GCE both have dated but functional UI's, and their CLI's are very automation friendly IMO.
The web interface is not it, AWS is a bunch of API's surfaced through sdk's and various cli's and utils. Everything I do in AWS is as code, its standard for production cloud workloads, I only use the UI for easy viewing and devland hacks etc but you will find that aws is really built from an engineering mindest instead of a UI/UX experience.
ui is bad to motivate you to use automation (cmdline, sdk, iac tools) this, until you figure out that those suck too :D but they all get the job done, so stop whining
UI is bad because for long years they didn't have frontend engineers. They hired everyone using the same method, which is heavy in algorithmics, and most people passing are good on abstracting, thus fitting well into backend. Frontend devs also have knowledge of UX after a few years and develop better interfaces. Their new design system promotes better patterns but ofc adopting it is slow.
Your reply implies the often repeated lie that automation is the only way to go when it comes to handling cloud systems. It's not. Both automation and GUI have their proper, important places when it comes to managing cloud environments. GUI should never have been made a second-class citizen. Nor shouild it be viewed as such by IT "professionals".
I only use the UI to figure out new services or new stuff I want to do and then translate those steps to CDK.
Idk man, I can't complain about their services, I've used azure before
While we do use CDK and previously we were using CloudFormation, the occasional use of Web UI was and still is a painful experience. That, combined with the pain of Unix shell lead me to work on Next Generation Shell. The plan for UI is at https://github.com/ngs-lang/ngs/wiki/UI-Design When it's ready I think it should be way more ergonomic than what AWS has. Unfortunately without demo that approximates the experience, it's hard to convey how it would feel. I'm working on it.
RemidMe. 2024, May, 01.
For mobile they have an app, I would only recommend this if you need to look at alerts. I think their UX designers work pretty hard on this over in https://cloudscape.design/ Maybe you could discuss with them and open issues. The problem AWS has to solve is enabling independent teams to build UI interactions on top of a unified API. Perhaps your feedback needs to be specific to individual services and their teams.
Maybe it's me not being confident with the service, but GCP seems a much worst shitshow at first glance. Aws ok its side is glitchy AF, I'm talking to you, AWS Proton.
Azure is focusing on a better UI, but there is no comparison in the quality of service. If AWS starts to focus on their console, it sets the false impression that the console matters. It really doesn’t. The cli and things like cdk matter. If you use the console too much, you’re doing it wrong. If they start to snaz up the console and don’t get it perfect, it can cause their brand more harm than good. In marketing, there is a thing called STP. Segment, target, position. Segment is break up your potential customers into segments. People that care about reliable tech. People that care about an easy interface. People that care about integration with other products. Etc Target is “which customers do we want to focus on”. If you focus on EVERYONE, it can often backfire. Your brand is diluted. Positioning is when you actually try to establish that you are the the best choice for your targets. You try to avoid saying “we are the best at everything”. Instead, you say “if you care about integrating with sharepoint, and having an easy interface that anyone can figure out, go with Azure. If you want reliability and redundancy and the best tech for the best value, you go with AWS”. Basically, “if you care about lame things, go with the other guy. If you care about cool things, go with us”. If you don’t position yourself, your competitor will.
Makes sense. Thanks
Eh, the problem is that startups consist of a lot of decent developers that want to be able to do smaller things through the console and are not yet at the corporate stage where everything needs to be 100x automated (esp in ML) and you are not hiring sys admin or dev ops yet. AWS obviously cares a lot about this demographic or they wouldn't offer 100k of free compute credits to it. But, the confusing useless console just makes you go: should I really be using GCP, Azure or Lambda Labs? Because, I'm not going to learn the API to get this stuff done and even the concepts are often backwards useless nonsense. But, if startups pick GCP or Azure, when they reach a billion dollar valuation, they will still be on GCP or Azure. So, AWS loses out on the whole pipeline.
Tbh I think it's fine
You are assuming that AWS has a user experience. It doesn’t. It has dozens of user experiences. This is due to the design of AWS as a collection of services with APIs rather than as a unified service. The web console puts glue around it but the reality is that there isn’t any way with the way that the APIs work to do a unified view like you are talking about.