8 ms·
New – M6g EC2 Instances, Powered by AWS Graviton2
- api 6y agoNext 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.
- StreamBright 6y agoHow would you lock in a customer who used Java or Erlang?
- tathougies 6y agoJava SDKS for AWS? The same way GPU vendors lock in Java and Erlang users?
- tyingq 6y agoSQS, Dynamo, Kinesis, Complex WAF/ALB/Lambda setups, CloudWatch, etc.
- StreamBright 6y agoThese are services that have nothing to do with Graviton. You can use, Kafka, k8s, Datadog just to name the obvious alternatives.
- fxtentacle 6y agoHow about a proprietary lower-resolution FP16 floating point instruction set that might speed up your AI inference?
- _msw_ 6y agoThe FP16 instruction implementation comes from Arm Neoverse N1 cores, and is standard Armv8.2-FP16. https://en.wikichip.org/wiki/arm/armv8#ARMv8_Extensions_and_Processor_Features https://en.wikichip.org/wiki/arm/armv8#ARMv8_Extensions_and_...
- borramakot 6y agoIs this a criticism of the ARM chips, or of the TPU's bfloat format?
- _msw_ 6y agoDisclosure: 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".
- api 6y agoI hope I'm just being cynical, but I base my attitude on the general trend in the industry at least in any realm related to either cloud or mobile. Everything is about herding people into some kind of closed silo and then locking the door, or on the consumer front about invading peoples' privacy in new and creative ways. I do agree in principle that it's harder to pull off this kind of lock-in with knowledgeable customers of the sort that deploy things on AWS.
- _msw_ 6y agoI hope you are too. As technologists and professionals I think we need to be ever-vigilant to build in responsible ways that support the public good. That includes being mindful of safety, security, and privacy concerns. And also creating or extending inequities.
- lykr0n 6y agoBut 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
- rafaelturk 6y agoI have a different view. The key here is that this is a ARM based server processor, this is very different than any other proprietary CPU offers like those running mainframes. By adding new ARMs to their fleet this will foster competition chip wise. Overall at least for our stack (Java, NodeJS, Python, MongoDB, PostgreSQl) I think we can migrate from Intel to Arm with 1click. And thats what we're going to do.., I'm definitely trying this new chip.
- freedomben 6y agoEven if you were just being absurd and paranoid (not saying you are), I do wish more people were quick to think about the implications of jumping into proprietary hardware/software. One of the greatest things about being a developer these days is that you have amazing options that are fully open source.
- _msw_ 6y ago+1 to that. I think that open source enables broader choice and freedom for everyone who's building. I remember the "bad days" of proprietary UNIX well, where every vendor also had their ISA. Today, the vast majority of applications that are built on open source are very portable between ISAs.
- rajeevk 6y agoNot sure whether this processor will create a vendor lock-in or not, but today there are many companies already locked-in into aws. My current company is heavy user of SQS, Lambda, Dynamodb, cloud formation etc and practically it is very hard to move out of AWS. Theoretically it is possible to move out to other cloud vendors but practically it is not worth doing because of amount of testing (and coding) required. We keep on creating more and more coupling with AWS stacks. And in the future it will be almost impossible to move out to other cloud vendors.
- skywhopper 6y agoI don't really see this as a likely risk, call me back once they have their own unique compiler targets that can't be targeted with LLVM. But even if they did evolve their own unique CPU architecture, that seems like a remarkably low-risk problem compared to the inertia you inevitably acquire using any platform API whatsoever. If you rely on anything beyond bare VM provisioning from any cloud provider you will experience huge pain to move anywhere else. If you are concerned about it, deploy on m6g instances, and put the money you save in a piggybank to pay a consultant to move you when AWS crosses your line.
- zenexer 6y agoWe have infrastructure at a number of cloud and bare metal providers, and I have my own personal applications running on several others for evaluation. In the decade or so since I started moving applications to the cloud, I’ve found AWS one of the easiest to migrate away from—and that’s what keeps us there. We’re constantly streaming our data to other providers who won’t let us export easily (or make it even more expensive than AWS). If we need to fail over, we can—while we do use AWS APIs, it’s not that hard to switch our code over to use a different API; we’ve done it plenty of times before. If what you’re describing were to actually happen, or if we suspected that it was about to happen, we’d be moving away from AWS with the flick of a switch. While I doubt most of their customers would be able to do that with so little difficulty, I’m sure a lot of people would think twice about throwing more money at an expensive cloud. We’re paying for the versatility without the need to manage bare metal ourselves; it’s worth the money only so long as that versatility and interoperability remains intact.
- illumin8 6y agoThese 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 6y agoAMD "Rome" EPYC has RAM encryption and came out almost a year earlier BTW.
- kixiQu 6y agoIs there a public cloud VM using it that we could compare for price? My understanding of typical benchmarks is that there are a lot of snitty details that need to be matched up in order to do a cost-performance comparison.
- wmf 6y agohttps://cloud.google.com/blog/products/compute/announcing-the-n2d-vm-family-based-on-amd https://cloud.google.com/blog/products/compute/announcing-th... https://azure.microsoft.com/en-us/updates/hbv2series-vms-are-now-generally-available/ https://azure.microsoft.com/en-us/updates/hbv2series-vms-are... https://aws.amazon.com/blogs/aws/in-the-works-new-amd-powered-compute-optimized-ec2-instances-c5a-c5ad/ https://aws.amazon.com/blogs/aws/in-the-works-new-amd-powere... (no pricing)
- jdsully 6y agoWe 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 6y agoKeep 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_ 6y agoC5a 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 6y agoWe’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.
- dabinat 6y agoWhatever happened to c5a instances (Rome)? They were announced before Graviton but still aren’t out.
- _msw_ 6y agoDisclosure: I work for Amazon on cloud infrastructure They're still in the works! Stay tuned, and thank you for your patience.
- greendave 6y agoIn 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-graviton2-arm-against-intel-and-amd/6 https://www.anandtech.com/show/15578/cloud-clash-amazon-grav...
- tyingq 6y agoThey 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.
- rafaelturk 6y agoCan you please elaborate? I'm trying to find documentation. Having a real `core` as opposed to a vCPU can be really a game changer provided that the Linux Kernel can benefit from this arrangement.
- _msw_ 6y agoThe Graviton and Graviton2 processors do not offer SMT. Search for "each vCPU is" on https://aws.amazon.com/ec2/instance-types/ https://aws.amazon.com/ec2/instance-types/
- _msw_ 6y agoDisclosure: I work at Amazon building cloud infrastructure Indeed price/performance is how customers I've talked to evaluate what they're able to get out of a platform. The "t-shirt" sizes are what matters in that comparison, and yes the microarchitecture of Graviton2 can be an advantage for many workloads. The best thing to do is to give all your options a try, and use a cost estimator to help decide.
- ksec 6y agoNot 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.