With airgapped servers, the question is, how do you install updates? There's almost always a way; IT needs it. With those updates, you can get an attack, if the machine supplying the update has been compromised.
For example, even if the update comes via a DVD, some machine wrote the DVD. If you can corrupt that machine, you can corrupt the DVD. Now you have a way to (eventually) get hostile code on the airgapped server.
I could care less what was used in the attack detailed by the article. I was replying to a specific comment, not the article.
SPECTRE, Meltdown, Rowhammer are just a few risks amongst thousands. Most importantly they at least have runtime signatures that could be detected.
There are weaker areas for directed attacks against an organisation (e.g. spear-fishing).
When attacked by highly skilled, highly motivated, highly resourced and foreign opponents, an org may find they are better relying upon an external team for securing your VMs. I would expect Google Cloud to be far better than the majority of fortune 500 companies at securing hypervisors and VMs.
b) You're not running untrusted, random stranger code on your Fortune 500 VM's. I can't signup for an account on Ford's VM's and start ripping through memory like I can with a public cloud.
But definitely running in public shared cloud exposes you to certain kinds of attack vectors that are not present in an on-prem deployment.
But it also protects you from certain types of attack vectors that your on-prem may not.
For example, you can be a co-incidental victim of a mass hack of public cloud. But it would be difficult to target your specific machines in the cloud (assuming your application surface is secure) but it might be easier when you are on-prem (easy to locate, isolate and infiltrate etc).
We had a set of sites on a special hardened security wise anti=hack anti ddos platform... and when that cloud got hacked they got all of our stuff and everyone else's and put it all on the dark net I believe. This was apparently because one of their customers was a semi-high profile target..
We found out a couple days later when the credit card on file started being used around the world, and that card had only ever been used at 2 places. We were not notified by the company.
We did read about it in a story a couple days later that named our hosting company in a sidenote when noting the one client that was hacked / defaced / exposed whatever.
Sadly in this case we would of been better off with non-cloud, non-extra-secure hosting.
As others have said, if it's connected it's vulnerable, I agree. There are different risks for different hosting situations.
Not saying it couldn't happen, it just seems unlikely.