Cloud cost optimisation is underrated. In the companies I've worked in nobody has really given a shit (at least not under normal economic circumstances). In the industry there's a strong avoidance of ARM compute instances for no good reason. If I were building from scratch today I would definitely go with Graviton.
The biggest downside I've found with Graviton is that it's gotten popular enough that availability of capacity is a problem in some regions/AZs - particularly if you're using larger EC2 instance types.<p>Also, Fargate Spot on Graviton is still not available, so if you want to run Spot in non-production environments, you're facing with running different architectures in prod vs. non-prod, which I don't like at all. Do the math on whether it's cheaper for your use case to go x86 spot/non-spot vs. Graviton non-spot.
I found graviton to be a mixed bag. It was certainly extremely fast when using the very high end instances and I tested it successfully using a Rust based message queue system I was writing and it got some ridiculously fast number like 8 million messages a second, from memory, using the fastest possible graviton instance (this was about 18 months ago).<p>I did try to switch some of my database servers to it a couple of years ago and after random hangs, I gave up and went back to intel. I tried again further down the track and same thing - random hangs. I assume this sort of thing comes with a new architecture but I'd be hesitant to move any production infrastructure to it without extensive long term testing.<p>In the case of graviton based GPU instances I found that the GPU enabled software I wanted to use didn't work.<p>If you are comparing performance, I'd suggest buying a fast AMD machine and run it locally and compare performance - local servers tend to be much faster and cheaper than cloud. And if your application uses GPUs then if you possibly can then its very much in your interests to run local servers.
I'm interested in hearing more about their switching to Graviton with Clickhouse.<p>We've been testing Clickhouse on Graviton and the performance isn't there due to a variety of reasons, most notably it seems because Clickhouse for arm64 is cross-complied and JIT isn't enabled like it is for amd64[1].<p>1. <a href="https://fosstodon.org/@manish/109397948927679076" rel="nofollow">https://fosstodon.org/@manish/109397948927679076</a>
For AWS managed resources definitely use Graviton. But for spot instances in EC2 we've found better pricing and greater availability by staying on x86. (We run 100% of our web services and background workers on spot instances).
Same experience here. I cut over a whole bunch of instances to Graviton a while back and it "just worked" for a lot of our workloads. Test it first, obv.<p>Another easy cost-savings switch is telling Terraform to create EC2 root volumes using gp3 rather than gp2 (gp3 is ~10% cheaper and theoretically more performant). The AWS API and Terraform both still default to gp2 (last I checked), and I wonder how many places are paying a premium for it.
I have two comments.<p>AWS Graviton is interesting because it is pretty different machine to their AMD and Intel offerings. A "16 vCPU" machine from AWS is 8 cores/16 threads, not 16 cores - except for Graviton, which actually has 16 cores, although much weaker ones. So for problems where you the cores can actually work in parallel, Graviton can keep up with AMD and Intel, while being somewhat cheaper. In single-threaded workload you get about half the performance.<p>Second thing I curious about is this very AWS heavy approach. ECS, CodeDeploy, ElastiCache. If I was their architect, I would probably go EKS, GitHub/Lab, Redis on EKS, just for the peace of mind.
We have a very similar story at my org. We run around 100 RDS aurora clusters and switched to graviton. I'm surprised to see 35% gains here, we saw more like 10-15%. But since amazon natively supports mysql on aurora we didn't have to worry about compatibility. Our main highlight was the way we wrote our infra as code where we made switching instances types or service we use fairly simple task, so we have switched instance types a couple of times in past and could easily make dev use t3s.
Getting on cloud is a trap and not the usual we deploy on the servers and we live situation. Give weight to write some good code to manage your infra and able to adopt optimizations as they occur. It will ramp up in expense soon otherwise.
I'm not sure I understand the point of this article : in theory they don't depend on x86 only code, so they've switched to arm and it worked, as expected, and things are cheaper.<p>I'm happy that they've shrunk their bill, but I somehow expected some kind of 'unfortunately, things went wrong because of bizarre memory model issues causing difficult concurrency bugs'.<p>What am I missing?
Not saying what you're switching from makes the title a bit click-baity.<p>The current title implies that AWS (Graviton or not) is somehow cheaper than other things, when AWS is quite often one of the priciest options out there.<p>"Switching from AWS to AWS Graviton slashed our infrastructure bill", on the other hand, is an article worth examining.
The marriage of an all arm64 dev env and a Graviton op env is a match made in heaven.<p>Everyone please do this so we collectively fix all the things to work with this. :-)
FYI <a href="https://squeaky.ai/legal/gdpr" rel="nofollow">https://squeaky.ai/legal/gdpr</a> I believe using Amazon AWS already disqualifies you from being fully GDPR-compliant. Same issue as Shopify has with using US CDNs: <a href="https://lsww.de/shopify-illegal/" rel="nofollow">https://lsww.de/shopify-illegal/</a><p>Since your core sales feature is "privacy friendly" which will surely be appreciated in the EU, it might make sense to offer local hosting or self-hosting.