Overcoming Challenges in Migrating to AWS Graviton: Tips and Tricks

Introduction

In this blog, we will be delving into the world of AWS Graviton and exploring the challenges organizations may face when migrating to this powerful ARM-based processor. As more businesses look to optimize their infrastructure and take advantage of the cost and performance benefits offered by Graviton, it is crucial to be aware of the hurdles that can arise during the migration process. We will share valuable tips and tricks to help you overcome these challenges and successfully migrate to AWS Graviton. 

What is AWS Graviton?

AWS Graviton is a processor built by Amazon Web Services (AWS) that offers a cost-effective and high-performance solution for running applications in the cloud. These servers are built on ARM architecture using 64-bit Neoverse cores for maximum performance and scalability with minimum cost and latency. They are designed by Amazon Web Services specifically to provide the best price-performance and scalability.

Why should we migrate to AWS Graviton?

Graviton offers a better alternative in the following ways:

● Cost-Effective Processing:
AWS Graviton instances are built on ARM architecture, which provides a cost-effective solution compared to traditional x86 instances. It offers a good balance between price and performance, allowing organizations to optimize their infrastructure costs.

● Improved Performance:
Due to their built-on ARM-based processors, which offer excellent performance and efficiency. Migrating your workload to AWS Graviton can result in improved overall performance, faster response times, and reduced latency.

● Future-Proofing:
As ARM-based processors gain more traction in the industry, migrating your workload to AWS Graviton can future-proof your infrastructure. By adopting Graviton early on, you position yourself to take advantage of future advancements and optimizations in ARM-based technology.

Transition to AWS Graviton

● Identify what workloads need to be migrated:
Identifying the type of workload running is useful for estimating the migration effort to Graviton. For some workloads, transitioning to Graviton is as simple as updating the instance types and associated Amazon Machine Images (AMIs) directly or in various launch or CloudFormation templates. For other workloads, you might need to use different software versions or change source codes. The quickest and easiest workloads to transition are Linux-based open-source applications.

● Migration Essentials:
It’s recommended to test the process in a non-production environment first. You can start by using a snapshot of your production database and restoring it into an instance in your non-production environment, which has a similar configuration (instance class, parameter group settings, encryption) as the current production instance. Then, modify your non-production instance to Graviton, followed by validation tests to make sure everything is configured and operating as per your expectations.

Challenges you may face & their Mitigations

Migrating to AWS Graviton can present its own set of challenges that may occur during migration. Stating a few below with their mitigations.

1. Re-setting up Applications:
While migrating an already hosted app on an EC2 to Graviton-based instances or during a database migration. We need to keep in mind the performance and workload considerations. Below are the steps that can be taken for mitigation:

• Upgrade libraries and tools to higher minor versions whenever possible and carefully evaluate the impact that changes in minor versions could have on your applications for compatibility issues.
• To ensure optimal performance, conduct extensive benchmarking tests to identify any bottlenecks or performance gaps.
• Fine-tune the database configurations, including adjusting memory allocation, I/O settings, and query optimization and also leverage AWS services like Amazon RDS to optimize database performance specifically for Graviton instances.
• This allows you to evaluate any performance differences and make necessary adjustments.

2. Limited third-party support for ARM architecture:

• It is advisable to collaborate with the vendors and service providers to explore ARM-compatible alternatives.
• Try to actively engage with the AWS Graviton community and forums to seek recommendations and workarounds.
• There can be some cases, in which it is required to opt for custom development or build your own solutions to replace unsupported tools.

3. Migrating Running Containerized Microservices:
To migrate dockerized microservices from AMD to Graviton without downtime, initially, we would need to create a multi-arch base image that can run on both AMD and Graviton-type instances.

• “docker buildx” – buildx is a plugin of docker that allows the building of any docker image with multi-arch support using –the platform option.
• Post-creation docker image should be tested beforehand with existing flow from the start for any anomalies we may face.
• Amazon Linux 2, Java 11 corretto can be used as a base image for most commonly used Java microservices, which supports both ARM and AMD architecture.
• The Dockerfile needs to be updated accordingly with the new setup.

Case Study

Sharing a Case Study below, demonstrating how we successfully migrated existing services and EC2 servers from Intel to ARM in one of our use cases. 

Problem Statement

During the migration process, we encountered several challenges:

1. To rebuild all existing docker images to support both ARM and Intel architectures.
2. Evaluating Cost Differences
3. Conducting load testing to understand the performance benefits of using Graviton.
4. Ensuring zero downtime while migrating a running environment having multiple Java microservices from Intel to Graviton.

Mitigation Process

• While rebuilding Docker images to support both ARM and Intel architectures. We ensured that all necessary libraries and packages, along with their required versions, were available for both architectures. We also updated and replaced libraries and packages where necessary.
• Performed a proper cost analysis comparing Intel and ARM instances to avoid taking any decision that might impact us financially going forward.
• Conducted load testing to ensure seamless performance will remain constant even after the migration activity.
• For a zero downtime migration for our microservices. We created a multi-arch-based image that could run on both Intel and ARM-based instances. So, we can use the same images in our current workload, too, without impacting & continuous testing.
• Utilized “docker buildx,” a Docker plugin that allows for the building of multi-arch Docker images. It was crucial to choose a multi-arch image from the Docker Hub that supported both architectures.

Aftermath

Post the successful migration of our existing infrastructure from Intel to ARM-based architecture, in AWS ECS, we had the below findings:

• Previously, we used the m5.xlarge instance and have now transitioned to the m6g.xlarge instance.
• As a result of the migration, we achieved significant cost savings. Our total cost decreased from 149.46 USD per month to 74.888 USD per month.
• Using multi-architecture builds helped us to be compatible with both of the architectures, making it easier for us to deploy wherever we want.
• We experienced increased performance during the migration & the same helped us to reduce our cost & infra-resource count.

Concluding

Migrating to AWS Graviton can be a challenging yet rewarding journey for businesses looking to optimize their infrastructure. Please note, that each migration journey is unique, and it is crucial to conduct a thorough analysis of your specific requirements and challenges before embarking on the migration process.

Throughout the migration, our main objective was to ensure a smooth transition for our current workloads without impacting the end user’s experience. We carefully planned the migration process to minimize any potential disruptions & were able to achieve it without any hiccups. 🙂