Re: "Quite an expensive misconfiguration"
I think you have misaprehended what exactly can be meaningfully done in a multi-tenant environment. Let's go down before we go up. Microprocessors can operate in different modes. For simplicity, let's call them, "privileged" (P) and "not privileged" (NP). It comes a surprise to many people, but when you sudo su - root, you are still running NP. The entire concept of "users" is an OS-level concept, and the root user is simply the one that the OS is happy to grant full access to the system.
There is a HUGE effort that goes into making sure that code running in NP does not get access to P resources, but none of that matter if the OS gets it wrong. Security is a "shared responsibility" between the processor and the OS. I'm no great student of processor designs, but I have a hard time imagining a system in which the processor managed thousands of security realms. It doesn't really make sense.
It is the job of the processor to provide the facilities to the OS to restrict access to general hardware resources. The actual management rests entirely on the OS. That includes the network card, and whatever is on the other side.
Now, suppose you have two computers connected via network cards. Each has their own OS, and each OS is responsible to decide what gets to the other computer, and what to do with what comes from the other computer. I hope you don't have a problem with the processor doing nothing but preventing NP access to the network card.
Hypervisors bring a new player to the table. Now, the hypervisor runs (often) in P mode, and the OS is kept in NP. In practice, of course, modern processors support three modes, H, P, and NP, but in the end, only the most-privileged mode get access to the network card, so for this discussion, it's accurate to consider the OS as just another NP process that the hypervisor gives special treatment to in the same way that the OS favors processes running as root.
So I ask: "What business is it of the hypervisor as to which users requests have been forwarded to it by the OS?"
Is not that AWS's IAM is a lousy model--it's that AWS is in no position to extend the OS-level concept of user (and remember, they are happy to run Windows, Mac, and a dozen distributions of Linux) to their hypervisors. A Lambda or EC2 instance is designed to be running a single (primary) application. Security groups and IAM roles are supposed to lock down everything not needed by that application or its helpers.
If you mix applications on a single instance, I submit that you are almost certainly doing it wrong.
If you create long-running processes which are accessing segmented data according to external input, (also know as a web server) you better not have a Bobby Tables problem--or any other.
In the cloud, YOU ARE NOT ROOT. You have to design your processes to account for this, not demand that you get a bespoke security model.
And IAM roles are enough of a pain as it is--I would argue that adding yet another layer of complexity to them would likely reduce end security. People seem to have enough trouble with the concept of "private" verses "public" on S3 buckets...