Successful Migration to AWS Graviton and the Results Achieved

Introduction

Our customer is one of the companies that provide broadband connections to thousands of customers throughout the country. Our DevOps Team manages the mobile application and web application for the customer.

Our Team was looking to lower the cost and improve the performance of the overall infrastructure of our customer’s web and mobile application by migrating the essential services to AWS Graviton-based instances.

Challenge

Our customer’s web application uses Drupal, and our Mobile application uses Java. There were other services that were using X86 and AMD-based instances, which were impacting the overall cost of infrastructure.

High-Level Idea

AWS Graviton2 processors are custom-designed for the cloud. They offer up to 40% better price performance than comparable x86-based processors. So, it was a challenge to test these technologies with the Graviton-based instances.

Solution

We started with Finding the services that were compatible with Graviton-based instances and used a phased approach for migrating the infrastructure.

We started exploring the services that we were going to migrate to Graviton; we started by analyzing one service at a time. After researching, we started migrating the non-production resources to Graviton. We started migrating after taking a proper backup of the data after successfully migrating the service. We asked our tester to do a proper sanity check of the environment in which we migrated the resources.

After performing the Graviton migration in non-production, we found that our infrastructure was performing better than the previous one, and we were able to save 15-20% of the cost in our non-prod environment.

Detailed Migration Steps:

1. Migrating Standalone Instances

We were using Elk and Redis in standalone servers for our non-production environment. We started by finding the compatible versions supported in Graviton instances. Then, we created the new Graviton-based instances and started installing the services in them. With the help of this approach, we were able to shift our elk and Redis instances to Graviton-based instances.

Note: You can not migrate these servers by creating snapshots from arm/X86 Based instances because it will cause an architecture mismatch for Graviton.

2. Migrating The RDS and Elasticache Servers

We had two ways to migrate the RDS to Graviton-based instances.

1. By migrating your current Mysql RDS to Aurora Graviton type. You can use the create aurora read replica option and select the Graviton instances there. After that, you can promote the read replica to cluster. It hardly takes 1 minute to promote the read replica to the cluster. After promoting the read replica to cluster the read replica becomes a writer instance. This procedure also involves minimal data loss and downtime.
2. By creating a new Graviton-based RDS from the latest snapshot of RDS, in this case, you will have a data loss as there will be a delay by the time you take the snapshot and migrate it to a newer one.

Migrated Instances and Cost Saving:

We used the first approach for migrating our infrastructure as it ensured minimal data loss and minimal downtime. It depends on your use case and the type of RDS instance you are using.

Migrating Elasticache: For migrating Elasticache we created a new Elasticache server based on the Graviton instance type and then updated the Elasticache endpoints that were used in the application.

Migrated Instances and Cost Saving:

3. Migrating AutoScaling Group Instances for ECS services

For migrating ECS services to Graviton-based instances, we need to create docker images through which we can run docker containers suitable for Graviton-based instances.

For building docker images suitable for Graviton-type instances, we used the dockebuildx tool and the latest OS versions that helped us create Graviton-supported docker containers. 

We were using 15 instances based on AMD/x86 based instances for our mobile application.

Migrated Instances and Cost Saving:

Results

After Migration, we achieved savings of 15% on these migrated services and also achieved improvement in the performance of the overall architecture.

Conclusion

The migration to AWS Graviton was a success for our customers; They achieved cost savings and improvement in performance without affecting the functionality of the services.