One is caused by the other. Amazons engineers decided to split the interface in a “user hostile” manner with the stated purpose of increasing reliability… which didn’t materialise. The clunky UI did.
Or maybe you can provide a better explanation for why users had to “hunt” through hundreds(!) of product-region combinations to find that last lingering service they were getting billed $0.01 a month for?
This just doesn’t happen in GCP or Azure. You get a single pane of glass.
You need to understand history for this. It's because of the famous "Bezos API mandate memo" https://chrislaing.net/blog/the-memo/. It was 2002, nobody was doing anything close to that.
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.
> It's like every service was designed by a totally different team.
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.)
One is caused by the other. Amazons engineers decided to split the interface in a “user hostile” manner with the stated purpose of increasing reliability… which didn’t materialise. The clunky UI did.
Or maybe you can provide a better explanation for why users had to “hunt” through hundreds(!) of product-region combinations to find that last lingering service they were getting billed $0.01 a month for?
This just doesn’t happen in GCP or Azure. You get a single pane of glass.
One of the things I find about AWS is that every service UI feels different. It's like every service was designed by a totally different team.
For all its flaws at least Azure has consistent UI.
You need to understand history for this. It's because of the famous "Bezos API mandate memo" https://chrislaing.net/blog/the-memo/. It was 2002, nobody was doing anything close to that.
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.
2 replies →
> It's like every service was designed by a totally different team.
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.)
1 reply →
I mean, if you care about the reliability of your own service you would not be using the AWS UI at all. Use the api, via automation.