25 comments

[ 5.2 ms ] story [ 71.9 ms ] thread
> T4g instances are powered by AWS Graviton2, a processor custom built by AWS using 64-bit Arm Neoverse cores.

> all new and existing AWS customers can try the t4g.micro instances free for up to 750 hours per month.

When will they throw it for the general purpose use? Or wouldn't they because it's too expensive for them?
The M/C/R6g range is already available in many regions.
Disclosure: I work at AWS, where I build cloud infrastructure

Can you clarify what you mean? C6g, M6g, and R6g instances have been available for a while now, and those support many different workloads. M6g is the "general purpose" variant. https://aws.amazon.com/ec2/instance-types/m6/

Didn't notice M6g coming out of trials.

Well I for long thought that taping out own CPU chips, even on Amazon's scale, wasn't that cheap.

The time of Intel demanding obscene prices for high core count server CPUs is at least 2 years since passed.

I was thinking if it still makes sense economically for Amazon to continue developing, and buying their own CPUs given that.

I’m willing to bet a lot of money that Amazon started designing these CPUs more than 2 years ago.
Amazon is estimated to be representing close to 50% of HyperScaler Market. And the Market segment itself is also roughly 50% of the DC Market.

While Intel dont disclose their CPU segment of their DC, you can bet it is the vast majority. Which gives you a rough idea of the scale of Amazon spending, i.e around 20% of Intel DC revenue.

And once you see those numbers, even if it is off by 30% or even double counted. Developing cost of CPU, especially when it is more of "working" together with ARM on developing Graviton 2 ( which it in itself extremely similar to ARM's reference design ) doesn't seems to be expensive or out of question.

You're literally commenting on the article that announces its general purpose availability. ...
Not specifically mentioned in the press release, but interesting: t4g instances are about 20% cheaper than t3 across the board.
Do you know how it compares to t3a?

Edit: nvm: $0.0336/h for t4g.medium vs $0.0376/h t3a.medium in aws-east north virginia for on demand. Sucks not available in aws-southeast-1 yet, I would switch just for the performance bump over t*a instance.

I think where these Graviton instances will really shine is in the AWS managed services, like RDS, ElastiCache etc. where the architecture is entirely irrelevant to you as a customer. All that you care about is that it's both faster and cheaper, a no-brainer choice.
not holding my breath on aws passing down the cost saving
Counter-point: newer, cheaper instance types are often cheaper than the previous generation. An m6g.large is cheaper than a m5a.large is cheaper than a m4.large, etc.
i mean on rds etc?
You pay for the instance type you choose on RDS
(comment deleted)
(comment deleted)
This is great news. I found myself wishing for these earlier today, for some tiny workloads. We've found the c/m/r6g instances to work as advertised: good or better performance for a significant discount. The downside is that you have to be sure your workload will run on ARM. In some cases that might take some changes to your build pipeline, but for certain use cases there might not need to be any changes at all. We've been able to move our PostgreSQL boxes configured with Ansible and operated with a whole lot of custom Python/Bash/Ruby scripting over to these instance types with no changes to our provisioning process beyond mirroring the arm64 postgres binaries to our private APT repo.
Not sure they do that now but having a credit card without pre-payment meant very hard to try their services. For some it is important to have services. For 1 man shop it hard as too many things to worry about and trying is not really priority.

Their instance with real usage charge. Not much but accumulate and I gave up.

Still remember trying fast ai, left a credit card to another service provider and after an alert I owe them 1000 ... luckily that card is expired. And they do void as they check I have not used their service.

Another has prepaid paypal. Like that. For testing only of course.

How would these work with Spark on EMR? For example when the cluster is utilized enough to keep the it running continuously, but still has some low or no utilization periods throughout the day.