You could argue now that that's no excuse anymore given it's one of the most valuable companies in the world, but that would dismiss the fact they have other priorities than a complete UI overhaul for consistency, and that rewrites are very dangerous, for instance people are already used to the UX pitfalls in the console, it's the devil they know, and changing that will be upsetting to the vast majority of users.
So there you have it. You know what you are getting into, AWS is a behemoth and it's 2026. Don't use the console like it's 2010. Use IaC for any nontrivial work, otherwise you only have yourself to blame.
But as a customer I absolutely hate working with AWS tech. Their stuff is a mess and I feel like I shouldn't have to get my head around their idiosyncracies. I prefer Azure even though Microsoft is a terrible company to work with. I find the AWS people and attitude a lot nicer but their services are a mess. If I do something new I prefer using Azure despite having to work with Microsoft.
Microsoft is not a "trusted partner" wanting the best for you, they're always trying to screw you over in favour of selling some new crap to your boss. Always that stupid sales drive, whereas the people from AWS are very focused on building success together. But still, their tech is just so bad unless you spend all your days working with it and really become an expert on what they offer. That's not tech, just corporate servitude. And I've always avoid that position, I don't want my career tied to some big brand name. I don't want to be "the AWS expert" or "the MS expert".
But I have to say I hate cloud (and "the world according to big tech") in general, and it's one of the reasons I'm not really involved in server infrastructure anymore these days. I'll gladly automate but not with their tooling, I prefer something more open and not tied to specific vendors. But I rarely work with that now. So yeah when that happens I'm making a one-off unicorn and figuring out all the Infra as code stuff is not worth it.
Yes, by design.
Conceptually this improves velocity and reduces the blast radius of failure.
In practice, everything depends on IAM, S3, VPC, and EC2 directly or indirectly, so this doesn't help anywhere near as much as one would think.
Azure and GCP have a split control plane where there's a global register of resources, but the back-end implementations are split by team.
That way the users don't see Conway's Law manifest in the browser urls... as much. (You still do if you pay attention! In Azure the "provider type" is in the path instead of the host name.)
Hm yes but I hate working with it as a customer because it is so confusing. Everything works differently and there is a lot of overlap (several services exist that do the same thing). It seems like an amateurish patchwork.
I understand it has benefits to have different teams working on different services but those teams should still be aligned in terms of UX and basic concepts.