[jsmeaton]

Even if there were a set of VMs per customer (and all the scaling per customer overhead that goes along with that), a carefully crafted exploit would still reveal details for that customer. Then it'd be a matter of enumerating all of the customers you were interested in exploiting, which would make it easier to get data for a specific target.

The operational overhead of VM/Container isolation for the cartesian product of customer + service sounds like it'd be extremely prohibitive. It's certainly a tradeoff, but to claim it's saner is missing all of the other costs associated with such a system.

[tgragnato]

Yeah it makes a targeted attack easier. But it prevents attacks across different customers. Tradeoffs ...

Maintaining a running pool of VMs per service in a sufficient number to serve the load of requests grouped by customer, and assigning the VM to a specific customer only at needs is different than running permanently a pool of (n).customers x (m).services VMs.

This is why an efficient scheduler and the usage of disposable VMs is a need. Still depending on the load and the variety of the traffic it may not be feasible, you are absolutely right !

Another approach to ensure isolation is the usage of a MAC framework. As I wrote "I bet they can develop even better solutions" ;)

[jacquesm]

The point is that if they had isolated their customers only those customers using that particular feature would have been affected. Now potentially all customers have been affected.