Top Tip: Task 2 will require you to build the application/workload list of dependencies. If you need information from other teams, it might be useful to ask them for this information before you start the first task, so that you could have their answers by the time you reach Task 2.
To start the move, the first thing you need to do is inventory your current software stack so you can identify the path to equivalent software versions that support Graviton. At this stage, it can be useful to think in terms of software you download (e.g. open source packages, container images, libraries), software you build, and software you procure/license (e.g. monitoring or security agents).
Areas to review:
Operating system and version (the more recent the better).
If your workload is container based, check container images you consume for Arm64 support. Keep in mind many container images now support multiple architectures, which simplifies consumption of those images in a mixed-architecture environment. You can read ECR multiarch support announcement for more details.
All the libraries, frameworks, and runtimes used by the application and its components.
The tools used to build, deploy, and test your application (e.g. compilers, test suites, CI/CD pipelines, provisioning tools, and scripts).
All the tools and/or agents used to deploy and manage the application in production (e.g. monitoring tools or security agents).
The Porting Advisor for Graviton is an open-source command line tool that analyzes source code and generates a report highlighting missing and outdated libraries and code constructs that may require modification along with recommendations for alternatives. It accelerates your transition to AWS Graviton-based instances by reducing the iterative process of identifying and resolving source code and library dependencies.
There are language-specific sections in the AWS Graviton Technical Guide in GitHub with useful pointers to get the best performance from Graviton processors as well as guidance for Operating Systems, Container environments, and various open-source software.
For each component of your software stack, check for arm64/Graviton support. A large portion of this can be done using existing configuration scripts, as your scripts run and install packages you will get messages for any missing components, some may build from source automatically while others will cause the script to fail. Pay attention to software versions as in general the more current your software is the easier the transition, and the more likely you’ll achieve the full performance entitlement from Graviton processors. If you do need to perform upgrades prior to adopting Graviton then it is best to do that using an existing x86 environment to minimize the number of changed variables. We have seen examples where upgrading OS version on x86 was far more involved and time consuming than transitioning to Graviton after the upgrade
When locating software be aware that some tools, including GCC, refer to the architecture as AArch64, others including the Linux Kernel, call it arm64. When checking packages across various repositories, you’ll find those different naming conventions.
If you find any software without support for the Arm64, please let AWS know by reaching out on the re:Post community support forum.
The main ways to check and places to look include:
Package repositories of your chosen Linux distribution(s). Arm64 support within Linux distributions is largely complete: for example, Debian, which has the largest package repository, has over 98% of its packages built for the arm64 architecture.
Container image registry. Amazon ECR now offers public repositories that you can search for arm64 images. DockerHub allows you to search for a specific architecture (arm64 enabled images).
Specific to containers, you may find an amd64 (x86-64) container image you currently use transitioned to a multi-architecture container image when adding Arm64 support. This means you may not find an explicit arm64 container, so be sure to check for both as projects may chose to vend discrete images for x86-64 and arm64 while other projects chose to vend a multi-arch image supporting both architectures.
On GitHub, you can check for arm64 versions in the release section. However, some projects don’t use the release section, or only release source archives, so you may need to visit the main project webpage and check the download section. You can also search the GitHub project for “arm64” or “AArch64” to see whether the project has any arm64 code contributions or issues. Even if a project does not currently produce builds for arm64, in many cases an Arm64 version of those packages will be available through Linux distributions or additional package repositories. You can search for packages using a package search tool such as pkgs.org.
In the download section or platform support matrix of your software vendors, look for references to Arm64, AArch64, or Graviton. Software vendor documentation will often list ‘platform requirements’ which include supported operating system versions and architectures.
Categories of software with potential issues:
Packages or applications sourced from an ISV may not yet be available for Graviton. AWS is working with many software partners to offer technical guidance as they add support for Graviton, but some are still missing or in the process of adding support. A non-exhaustive list of some ISV software can be found in here.
The Python community produces modules built using low level languages (e.g. C/C++) that need to be compiled for the Arm64 architecture. You may use modules that are not currently available as pre-built binaries from the Python Package Index. AWS is actively working with open-source communities to ensure the most popular modules are available. In the meantime we provide specific instructions to resolve the build-time dependencies for missing packages in the Python section of the Graviton Getting Started Guide.