This benchmark is kind of useless as it is comparing c5a to m5 instead of c5. The c5 and m5 are both the same kind of Xeon, but the sustainable and turbo clock speed of the m5 is notably slower than the c5. If you were considering a Xeon for your use case, you would want to see the c5a compared with the c5.
Amazon defines one ARM vCPU as one core and one x86 vCPU as one SMT-thread of one core, so the Graviton 2 instances has twice as many cores as the x86 ones it's compared against, and as such it would be a kind of a failure if it wasn't faster in some of the most heavily threaded workloads.
AWS behind Azure, GCP, and even Oracle Cloud in this release. Azure had EPYC Rome available 6 months ago. Surprising, AWS had been among the fastest to roll out new hardware in the past few years.
There's a catch though. We primarily use GCP - About a month and a half ago we were planning to run a large compute job, since GCP already had these great performance-to-cost AMD EPYC 2nd gen Rome VMs available then, we decided to use them, only to find out later that there was a service quota of 24 vCPUs for these instances. The worse part of it was that it wasn't even clear in the service quota page that there was no point in requesting anything beyond 24, as for whatever number we put 512, 256, 128, 32, etc. for all cases we would get automatically rejected. Essentially it was a hard quota limit, and in principle it felt like it went against the launch blog post [0] of GCP stating a case of 224 vCPUs of these new EPYC processors being used at a time.
I'm not sure what the service quota is like on AWS, however it could be that AWS waited to procure enough of these new EPYC processors to be able to provide a reasonable amount of such compute for their large customer base.
Disclosure: I work for AWS building cloud infrastructure
My experience working at Amazon has changed my thinking about how to deliver great customer experiences. When we make a new EC2 instance available, customers expect to be able to use it at scale that is indistinguishable from limitless (which is a challenge in a world that has physical constraints in accordance to laws of physics), instantaneous availability, and high quality. This requires significant infrastructure deployment scale and careful design and management of supply chains. Not every provider has the same philosophy and approach in practices.
Even though the announcement says it’s available in US-East, it seems like you can only launch in us-east-1a and us-east-1b. I wasn’t able to launch c5a instances in other availability zones.
That's a good point. They used to be the same across accounts, but then they had consistent capacity problems in us-east-1a so they introduced the shuffle which is determined on account creation.
You can actually look in the "Resource Access Manager" to determine which allocation you've got, it maps the names you see in the rest of the console to e.g. use1-az1, use1-az2, use1-az3, so you can use that information to "colocate" things if you really need to.
Disclosure: I work at AWS building cloud compute infrastructure
Historically we have both launched .metal instances at the same time as virtualized instances, and also launched them a little later. My goal is to launch them at the same time, but sometimes there are some final details to work through before we can make them available.
https://www.phoronix.com/scan.php?page=article&item=epyc-ec2...