# Playing With Amazon's New Graviton2 ARM Instances
15 Oct 2021
Lately, ARM has been taking over the whole industry. It’s the architecture of choice on most cell phones and tablets on the market, the new M1 Macs (my work issued computer is the 13 inch M1 Macbook Pro, and the batter life is incredible), and IoT devices. However, for the longest time, the desktop and server market has been predominantly x86_64 based. Just last year, Amazon announced the introduction of their t4g line of AWS EC2 instances that they are calling “Graviton2”. These ARM based instances are currently the cheapest instance type available on Amazon, but as long as you don’t have a workload that requires x86 binaries for some reason, they’re excellent value. I was looking into using these to run a reverse proxy server (which was ultimately dropped in favor of just using an ALB), and the performance of these things is nearly indistignuishable from what you get on a t3a instance type from what I’ve seen. Because the code to deploy my website has been automated using Ansible for a very long time, and it’s a project I have readily available, I decided I’d try it out while the t4g instance type is still free. I wrote some quick Terraform code for AWS that creates all the resources I need to run my site on AWS, and as part of the code, I leveraged cloud-init using user data to pull down the existing Ansible code and execute it against localhost (with a few tweaks I have made automatically using sed). Surprisingly, I ran into very few issues and it performs extremely well, especially considering I’m only trying t4g.nano and t4g.micro instance types. I did run into RAM limitations, but I found a script that quickly created swap space and added it to /etc/fstab so it’s used on reboot, and added 2GB of swap space (and increased the instance’s EBS volume accordingly). I also had to switch out one of my Docker containers (everything is containerized on the Linux VM) because one containtainer wasn’t ported to ARM yet. I found a similar container that was portable to both architectures, which was simpler than rebuilding the old one from the Dockerfile as I didn’t want to deal with setting up a registry and pushing my own to it. I’m genuinely impressed with the performance of the t4g instances, and when my prepaid credit with my current host (HostHatch) runs out, I’ll put some thought into porting things to AWS on these instances. Admittedly, there are caveats compared to what I’m paying for - for starters, on HostHatch, I have NVMe storage which is far more performant than the base gp3 EBS volume that my root block device used. Additionally, it would be a bit more expensive, and in order to keep the cost comparable I’d almost have to use a 3 year paid-in-advance “reserved instance” to keep costs lower. Naturally, I’ve run some performance tests on them, but I won’t post my Geekbench URLs here as others have posted readily available scores. However, if you’re interested in testing them in the same manner, I’m using a script called “Yet Another Benchmark Script”, which can be run on any Linux system, including ARM-based, with curl -Ls yabs.sh | bash. It tests disk, bandwidth, and system performance using a variety of tools. While I’ve found that the t4g instances would run my site just fine (and then some), this is just for fun at the moment. I will however not hesitate to look at Graviton2 as an affordable option for compute workloads that I run into professionally. These things are definitely worth checking out.