They are running on the cloud, and Meltdown / spectre means that exploits can escape a VM. This means you don't just need to trust your VM, but also any VMs you are sharing the hardware with.
They are running on the cloud, and Meltdown / spectre means that exploits can escape a VM. This means you don't just need to trust your VM, but also any VMs you are sharing the hardware with.
Even then, you don't need to trust your co-tenants. Updating the host (which your provider has already done, or which is anyway out of your control) is both necessary and sufficient to protect from VM escapes.
If the host is patched this doesn't matter (for VM escapes); however, for those on public clouds that will apply the host patching globally, you will be eating the performance degradation whether or not your workload cares about it. I don't think AWS et al will be offering a "run unpatched instance" option. Or maybe they will, this looks pretty devastating for some workloads; on the other hand, cloud providers could actually end up making a lot of money from this issue...
Although this restriction on how the cloud provider is allowed to schedule your VMs probably would somewhat defeat the point of cloud hosting in the first place.
Out of curiosity, how many VM/container instances usually run on a physical host at any given time (for your typical cloud computing provider)?
Granted, that only works for workloads that are spread across enough small instances.