
New – M6g EC2 Instances, Powered by AWS Graviton2 - caution
https://aws.amazon.com/blogs/aws/new-m6g-ec2-instances-powered-by-arm-based-aws-graviton2/
======
illumin8
These are gamechanging. Anapurna labs is the team that Amazon acquired to
design the custom silicon. They have a track record of amazing innovation,
including powering EC2's 25gbps network stack, and the Nitro accelerator cards
that offload critical security functionality from the CPU. Since Anapurna
designed these from scratch, they've built higher levels of security into the
architecture, including fully encrypted DRAM.

~~~
wmf
AMD "Rome" EPYC has RAM encryption and came out almost a year earlier BTW.

~~~
ksec
I still dont understand how AMD could have a chip announced 18 months ago,
shipped nearly 12 months ago, Announced by AWS 6 months ago and is still not
available.

~~~
wmf
Azure went GA with Rome in Feb and Google in April, so AWS is not that late. I
wonder if supply is low. One disadvantage of AWS is that they're so large they
can't GA anything in low quantities because it would run out immediately.

~~~
rbanffy
Also, they don't GA anything without a good reason. Introducing a new socket
is not trivial - all their FCLGA3647 boxes introduced in 2017 can be updated
to second generation ones introduced this year - or they can just build these
machines without having to redesign the motherboards.

Introducing EPYC Rome boxes would require, besides a volume price agreement
(that AMD could be reluctant to enter, as they can sell the whole capacity
with better margins, at least for now) new supply chains for motherboards and
PCIe 4 peripherals that can't be used with their Intel stuff yet. That's a lot
of disruption.

~~~
_msw_
Rome _is_ coming [1]. I'm eager to get it in the hands of customers as soon as
we can. :-)

[1] [https://aws.amazon.com/blogs/aws/in-the-works-new-amd-
powere...](https://aws.amazon.com/blogs/aws/in-the-works-new-amd-powered-
compute-optimized-ec2-instances-c5a-c5ad/)

~~~
rbanffy
I'd love to play with it. Right now I'm enjoying playing with a LinuxONE z15
and it's humongous L4 cache.

------
api
Next up: lots of proprietary extensions to drive vendor lock-in to AWS at the
binary code level, then much lower pricing for instances that use these
features to herd customers into them.

It's built right into the name of the product: graviton.

Prediction: today everyone will dismiss this as paranoid nonsense, impossible,
or irrelevant. In 2-3 years everyone will be whining about how hard it is to
migrate off AWS due to binary lock-in and the need to re-deploy packages. In
5-7 years people locked into AWS will be whining about how they pay 2-4X as
much for cloud services but are unable to move due to deeply entrenched
deployments and applications specifically written to take advantage of AWS CPU
extensions.

This is the same sequence that has occurred for most other "paranoid"
predictions about lock-in or privacy violation over the previous 10+ years.
They're always initially dismissed as absurd or paranoid and then what ends up
happening is usually considerably _worse_ than what was predicted. Example:
mobile and web surveillance today makes the predictions of meth-addled 1990s
conspiracy freaks sound overly conservative.

~~~
_msw_
Disclosure: I work for Amazon as a VP and Distinguished Engineer building our
cloud infrastructure.

My professional opinion is that is a very poor strategy. Customers want to
have freedom, not lock-in. When designing infrastructure services, it's good
to carefully consider what abstractions are going to preserve freedom and
flexibility. For example, adopting the Arm architecture, and further using the
Arm developed Neoverse N1 core, provides the broadest capabilities and
compatibility thanks to the investment in a common ecosystem.

The optimizations we are able to put in our silicon design, and the design of
the Nitro system, let us deliver better price/performance without resorting to
such customer unfriendly tactics of "lock-in".

~~~
lykr0n
But that's what AWS offers.

All the big products- SQS, DynamoDB, Aurora, S3, Beanstalk. Those are all AWS
services you can't use outside AWS (sure, there are API compatible
alternatives out there). If you design for those services, you're locked into
using AWS.

There is a reason bandwidth in is free while out costs money- it needs to be
easy for people to move onto AWS without being east to move out. Customers are
clearly choosing vendor lock-in over freedom. And AWS encourages this. If you
want to migrate to AWS, Amazon will send an army of developers to help you
adopt their technology. Will they do the same if a big customer wants to
migrate away down the road?

[https://e.lvme.me/kmw2hs1.jpg](https://e.lvme.me/kmw2hs1.jpg)

~~~
zenexer
Aside from S3, does anybody actually use those?

Software that works with S3 tends to work with competing APIs as well; just
change a config option. Even if you’re interfacing with the API directly (you
probably shouldn’t do that—use some sort of abstraction layer instead), there
are open source alternatives that support the exact same API.

SQS can be useful for getting data out of AWS without worrying about whether
your callbacks are down. For example, if you’re using SES, you might want to
know when emails bounce; you can have all those events sent to SQS, then pull
them out whenever and store them in something more generic. I don’t think it’s
particularly common to use SQS beyond that.

DynamoDB—is that even still a thing? Isn’t Cassandra basically DynamoDB 2, but
open source?

Aurora is expensive and makes exporting data a pain. I have no intention of
using it until it’s easy to set up external replication so I can fail over to
other providers (or leave). No external replication, no business, especially
at that price point. Aurora was quite a disappointment.

Beanstalk is another one of those things that nobody actually uses. That being
said, it doesn’t really lock you into anything; it’s just a way to automate
some basic AWS tasks, really. But it’s generally more trouble than it’s worth.

~~~
rasguanabana
> Isn’t Cassandra basically DynamoDB 2, but open source?

Yet you need to deploy it somewhere and maintain it. DynamoDB just works and
that’s why people will happily pay extra because they can put effort on
something more meaningful that maintaining a database.

~~~
zenexer
That isn't relevant to the parent's question. They were complaining about the
lack of open source alternatives to DynamoDB. Cassandra qualifies.

------
dabinat
Whatever happened to c5a instances (Rome)? They were announced before Graviton
but still aren’t out.

~~~
_msw_
Disclosure: I work for Amazon on cloud infrastructure

They're still in the works! Stay tuned, and thank you for your patience.

------
jdsully
We had a chance to test these with KeyDB and the performance was quite good.
It’s definitely a viable alternative to Intel and AMD instances.

~~~
aristophenes
Keep in mind the AMD instances are using chips AMD put out almost 3 years ago.
They still aren't using the new generation of Rome chips that came out a year
ago, which almost doubled performance.

~~~
_msw_
C5a instances are coming, and I think that you'll still be pleased with the
price/performance of M6g instances for a wide variety of applications. But if
your app works better on AMD, or on Intel, we want to give you a broad
selection so you can achieve the best result given your specific needs. Cloud
makes it easy to switch.

~~~
zenexer
We’ve been quite pleased with AWS’ t3a offering and have saved quite a bit of
money by switching. We did encounter some odd kernel panics early on, but they
seem to have stopped.

We’re excited to start evaluating AWS’ ARM offerings, but until now, they
would’ve been more expensive for our workload. We’ll have to see if that’s
changed with Graviton2, but I suspect AMD is the sweet spot for our
application; it just doesn’t seem to like ARM as much.

------
tyingq
They are, indeed, impressive. Keep in mind, though, that a Graviton "vCPU" is
an actual core. They are making direct comparisons to an Intel "vCPU", which
is basically 1/2 a core (hyperthreading). I suppose what actually matters is
performance per dollar, but it still feels a bit misleading.

~~~
ksec
Not too sure it is misleading. ( Or you could argue the term vCPU has been
misleading from day 1 ) It is simply G2 dont offer SMT, so their 1 thread
would just happen to be 1 CPU Core.

I believe We are not too far away from getting SMT4 on mainstream Server. So I
think what we should learn is vCPU = CPU Thread.

It is more problematic when other vendors like Linode stop using the term vCPU
and simply refers to CPU. When it is actually still 1 thread and not 1 Core.
And I have seen other vendor doing the same. Comparatively speaking, Amazon
has been very consistent in vCPU naming.

~~~
tyingq
Not misleading to the AWS buyer. But misleading for someone reading and
thinking about the broader ARM vs Intel performance thing.

Or, in short... _" 4 Graviton cores are 40% faster than 2 Intel cores, and we
are pricing them the same"_ is what's really happening.

------
greendave
In terms of raw CPU performance, these look pretty good. For stuff like SPEC
CPU, they're within spitting distance of the EPYC 7571 for single-core
performance[1]. Multi-core is not as good though. Hopefully we can see them
matched against the Rome EPYC instances soon.

[1] [https://www.anandtech.com/show/15578/cloud-clash-amazon-
grav...](https://www.anandtech.com/show/15578/cloud-clash-amazon-
graviton2-arm-against-intel-and-amd/6)

