Now more than ever, this statement just does not compute. What good reason could something as sensitive as Coinbase have to remain on a third-party cloud provider and let Amazon hold the keys to the kingdom, especially after this disclosure that informs us that our imagined VM sandboxes have been a fairy tale all along?
There's a secret from a time not so long past that makes these attacks nearly-irrelevant: "don't run untrusted code". Maybe the corollary "don't run on hardware that runs untrusted code" is necessary (though I personally feel it's a little redundant).
It's embarrassing that Coinbase would continue to expose their application to this attack surface after yesterday's disclosures. Honestly, it should've been that way before; this isn't the first time VM isolation has been broken, and it won't be the last. It's just the least-fixable breakage so far.
> Sensitive workloads, especially where key handling is involved, run on Dedicated Instances (instead of shared hardware). Where we do run on shared hardware, we make it more difficult to accurately target one of our systems by rapidly cycling through instances in AWS.
I'm quoting this just because I know people will say I'm excluding the context if I don't. If you're going to run on "dedicated instances" anyway and pay the huge price premium for them, there's no reason to continue to put your secrets in Amazon's hands.
Little ragtag startups may use the excuse "We're scared of real sysadmins, they will laugh at us because they're over 25", but that excuse should not work for something as big and serious as Coinbase.
Playing Instance Roulette by "rapid cycling [instances]" in hopes that you get away from any bad neighbors ASAP is extremely silly, please give me a break. Just buy some hardware. How is this so hard?