How Codiga migrated from Intel to Graviton in AWS

This blog post explains how we migrated Codiga from Intel to Graviton in AWS, what are the main benefits and tradeoffs.

These are the main AWS services we use (and migrated from Intel to Graviton):

AWS ECS (Fargate)
AWS Build
AWS RDS

What is the Graviton architecture

If you have lived under a rock over the past few years, the Graviton Processor is the AWS-owned processor developed by Amazon. It is an ARM64 architecture and is available to AWS customers only.

AWS offers a great price on Graviton processors (running your workload on Graviton vs. Intel will bring you a nice 20% discount).

From a performance perspective, it seems to be balanced: Graviton processors sometimes outperform Intel ones (but not always - see this blog) for more details.

What are the benefits of migrating to Graviton

Benefit #1: performance/cost

When looking at a processor, the main concern is cost/performance. In other words, the main question is, rather "what is the best price you get compared to the performance".

In this domain, AWS claims that Graviton is cheaper for better performance. Seems too good to be true?

Benefit #2: developer friendliness

The second benefit is if the architecture is "developer-friendly". It is way easier to deploy on the same platform as what your developer used: bugs are easier to reproduce and build systems are similar between production and staging/testing.

Graviton Pricing

When looking at ECS Fargate (our largest workload) pricing, the price difference is 20% per vCPU per hour and 19% per GB of memory per hour.

The difference in pricing for managed databases (AWS RDS) is more complicated to compare since there is not the same class of instances with just the architecture that changes.

Suppose you compare similar architecture, for example, a db.m5.large (Intel CPU with 8 GB of RAM) and a db.m6g.large (Graviton 2 with 8 GB of RAM), we observe a 10% price difference (see RDS Pricing Page and RDS instance specifications).

Migrating from Intel to Graviton/ARM64 in AWS ECS

AWS Build migration from Graviton to Intel

To migrate your workload from Intel to Graviton in AWS ECS, you must build docker containers for the new architecture.

There are two main constraints to building a container for the ARM64 architecture (Graviton):

your dependencies are supported, and your code works for ARM64
you have an ARM64 machine to build your docker container

For the first constraint, the availability of your dependencies depends on your languages and how exotic your dependencies are. At Codiga, we use JVM-based languages, and Python, and all our dependencies are supported out of the box.

For having an ARM64 architecture available to build your containers, AWS provides an ARM-based platform in AWS build. In other words, if you build your docker containers in AWS using AWS build, everything is supported out of the box.

Still, there is some work needed. When we migrated our python applications, we needed to adapt our build scripts to install more dependencies (mostly header files and development packages).

It took us about 4 hours to migrate all our build systems from Intel to ARM64/Graviton.

AWS Build performance

After migrating our build system, we did not see any significant changes in performance, and our containers take about 20 minutes to build.

The main reason is that building our container is not CPU-intensive but rather I/O and latency-intensive (pulling data from the network, installing packages, etc.).

Migrating your ECS workload from Intel to Graviton

Once your containers are built for ARM64, it is then very easy to migrate to ARM64. Update your ECS task, specify the repository with the ARM64 image and then, edit the task definition and make sure to add the following declaration.

 "runtimePlatform": {
        "operatingSystemFamily": "LINUX",
        "cpuArchitecture": "ARM64"
  }

Update the service, and voila, you run your workload on ARM64.

Intel vs. Graviton in AWS ECS: performance

We monitored the CPU usage of our main service to evaluate the performance of the Graviton architecture (compared to our previous Intel ones).

We could not find any major changes in the application performance, either positive or negative. For us, the migration did not bring any significant benefit in terms of performance.

This may be because of our application and workload. And may also be impacted by the JVM and its configuration needs some tuning.

But our overall feeling is that the performance in ECS Fargate will be similar for most applications (e.g. an API takes some data in, compute and spits some data out).

Migrating our database from Graviton to Intel with AWS RDS

We also migrated our database (MySQL) from an Intel platform to a Graviton platform.

Intel vs. Graviton in AWS RDS: performance

There is already a good comparison of Intel vs. Graviton for RDS. It seems that the Graviton processors are more performant under some workloads and that Intel processors have advantages in others.

We migrated our database from Graviton to Intel. The migration is very easy and you just need to modify the instance your database runs on (from an Intel to a Graviton-based instance).

As for Fargate, our performance was very similar after the migration. We did not encounter any major issue after migrating to Graviton.

Final Impact on Costs

There is no surprise: our costs went down by about 15% to 20% (depending on the day). There is a picture of our daily cost and the impact of the migration on it.

Lessons learned from our AWS ECS migration from Intel to Graviton

These are the lessons learned from our migration:

Pricing benefits: the pricing changes are clear - ECS Fargate costs are 20% lower when you migrate from Intel to Graviton
Production environment vs. development environment: all all developers at Codiga use an ARM64 architecture (Macbook M1, also ARM64), it is now easier to troubleshoot and reproduce bugs locally (same packages version, no need to cross-compile docker containers, etc.)
Performance: we did not notice major performance improvement or degradation for the same parameters in ECS Fargate (e.g. same number of CPUs and memory)
Migration time: It took us 4 hours to migrate our build system

Final thoughts

Moving forward, we will deploy applications only for ARM64 since this is the architecture we use on our laptops (Apple M1). We believe that overall, the migration was beneficial from a cost perspective while having the same performance.

Some services are easier to migrate than others. For example, it makes total sense to migrate a database to Graviton since it offers a better price without effort. Migrating applications should be evaluated more carefully: you need to make sure that your application runs correctly, that all dependencies are supported, and your system builds for ARM64.