Performance and cost optimization in cloud infrastructures through migration to ARM-based architectures

Introduction

The modern digital economy has entered a stage of near-ubiquitous cloud adoption, in which public cloud spending continues to expand despite macroeconomic uncertainty. Gartner forecasts that worldwide end-user spending on public cloud services will grow 21.7% to $597.3 billion in 2023 (up from $491 billion in 2022) [1]. This quantitative growth is accompanied by increasing infrastructural complexity (multi-cloud and hybrid deployments, heterogeneous instance families, and diverse workload profiles), which in turn raises the importance of operational efficiency and cost control.

Within this context, the traditional scaling trajectory dominated by x86 server platforms faces intensifying constraints related to energy efficiency and density at scale. Consequently, performance-per-dollar and performance-per-watthave become decisive selection criteria for hyperscalers and large enterprises, not merely engineering metrics. A key technological response is the accelerated adoption of Arm-based server instances: the Arm architecture, historically optimized for energy efficiency, has matured into a viable platform for general-purpose cloud workloads and developer ecosystems [2].

Historically, cloud providers primarily consumed standardized server platforms. However, as scale increased and workload requirements diversified, they increasingly moved toward tighter co-design of hardware and software stacks. This shift is visible in the rapid expansion of Arm offerings across major clouds:

• AWS has advanced its in-house Arm-based roadmap through the Graviton family, positioning Graviton3-powered EC2 instance types (e.g., C7g) for improved price-performance across compute-intensive workloads [3].
• Google Cloud introduced Tau T2A instances based on Arm processors (Ampere Altra), explicitly targeting cost-effective general-purpose computing and ecosystem enablement [4].
• Microsoft Azure has made Arm-based virtual machines with Ampere Altra generally available, expanding Arm support into mainstream enterprise and Kubernetes deployment scenarios [11].

Market dynamics in 2023 also underscore the strategic relevance of Arm in infrastructure computing: Arm’s preparation for a public offering (via its SEC F-1 filing) reflects heightened investor and industry attention to the architecture’s role in cloud and data-center growth trajectories [5].

At the same time, the transition to Arm is not frictionless. While Arm instances can reduce cost and energy footprints, migration commonly introduces technical and organizational overhead: recompilation and testing pipelines, dependence on architecture-specific binaries, subtle performance differences due to compiler behavior and memory subsystems, and the need to validate operational tooling across architectures. Cloud providers themselves emphasize structured performance evaluation and migration discipline for Graviton-class platforms – especially for independent software vendors and production workloads – highlighting the necessity of benchmarking, profiling, and phased rollout rather than naïve lift-and-shift [15, 16].

Finally, despite the growing availability of Arm instances in leading clouds, there remains a gap in consolidated academic and applied guidance that links real cloud instance behavior, performance variability, and migration decision-making for enterprise workloads. Existing research provides important partial foundations – covering the Arm ecosystem in HPC settings [6], broader readiness and performance/efficiency analyses of high-end Arm systems [12, p. 78-86], and systematic perspectives on cloud VM performance variability [9] – but these strands are often disconnected from practitioner-facing migration frameworks and from the rapidly evolving commercial instance landscape of 2022-2023 [3, 4, 11]. This motivates the need for an integrated view that combines cloud-provider instance characteristics with rigorous performance assessment and practical migration considerations, using 2023-era Arm cloud offerings as the empirical baseline.

The aim of this study is to conduct a comprehensive comparative analysis of the performance and economic efficiency of migrating cloud infrastructures to the ARM architecture, to identify key technical barriers, and to develop a methodology for overcoming them.

The scientific novelty of the study consists in a comprehensive theoretical and empirical evaluation of the latest cloud ARM platforms (AWS Graviton4, Azure Cobalt 100, Google Axion) in comparison with current x86 solutions at the microarchitecture level (Neoverse V2/N2, SVE2, abandonment of SMT), real application workloads (databases, microservices, AI inference), performance-per-watt and price-performance metrics, as well as in the development of a formalized migration framework (ARM-first/6R decomposition, multi-architecture CI/CD, management of JVM/Python dependencies) that makes it possible to minimize technological risks and TCO when migrating cloud infrastructures to ARM.

The working hypothesis of the author is that for a wide class of general-purpose operational workloads (general purpose), including microservice applications, web servers, and database management systems, the ARM architecture has reached parity with x86 in terms of absolute performance, while providing a reduction in the cost of computing resources by 20–40%. This makes ARM-based solutions an almost non-alternative economic choice when designing new cloud systems and a highly attractive target direction for refactoring and modernizing existing infrastructure.

Materials and Methods

The materials and methods of the study are based on a combination of a multifaceted review of current scientific and industrial literature on cloud ARM platforms and comparative benchmarks (Phoronix, SPEC, vendor reports) with a series of in-depth case studies focused on practices of migration and operation of AWS Graviton, Azure Cobalt 100, and Google Axion in real cloud scenarios (microservices, DBMS, AI inference). To ensure the representativeness and relevance of the sample, cloud instances were selected that represent the state-of-the-art as of early 2023 in the portfolios of the three largest cloud infrastructure providers (Hyperscalers). Both platforms based on the ARM architecture, serving as the test group, and x86-based instances forming the control group for comparison are considered.

The test group includes AWS Graviton4 instances of the m8g family, based on the Arm Neoverse V2 microarchitecture (Demeter core). This architecture is focused on achieving the highest possible single-thread performance, which makes it particularly relevant for latency-sensitive workloads. The configuration provides up to 96 cores per die and 12 channels of DDR5-5600 system memory. A key feature is the complete physical separation of cores and the absence of SMT/Hyper-Threading, which ensures strict isolation of resources between vCPUs and, consequently, a more deterministic performance profile. In addition, SVE2 (Scalable Vector Extension) is supported with an effective vector width of 4×128 bits. In typical positioning, such instances are targeted at general-purpose server workloads, databases, and compute-intensive general-purpose tasks.

Another representative of the ARM segment is Microsoft Azure Cobalt 100 (Standard_Dps_v6 family), built on the Arm Neoverse N2 microarchitecture (Perseus core). The N-series architecture is initially designed with a priority on optimizing the aggregate PPA (Power, Performance, Area) indicator, that is, on a balanced ratio of performance, power consumption, and die area. The configuration includes 128 cores, a chiplet layout, and the use of DDR5 memory. The platform is primarily oriented toward scale-out scenarios with active horizontal scaling, which provides high density of virtual machine placement in the data center and efficient resource utilization at the cluster level [6].

In the Google ecosystem, the ARM approach is represented by Google Axion instances of the C4A family, also based on the Arm Neoverse V2 microarchitecture, similar to that used in Graviton4. The configuration provides up to 72 vCPUs. A fundamental feature here is the tight integration with the Titanium platform, a specialized hardware complex for offloading network operations, storage subsystem operations, and security functions. As a result, the central processor is almost completely freed for the execution of user computations, which increases the efficiency of CPU resource utilization in real application workloads.

The control group consists of instances based on modern generations of x86 processors. In the AWS lineup, m7i and m8i instances are considered in particular, based on 4th (Sapphire Rapids) and 6th (Granite Rapids) generation Intel Xeon Scalable processors that support AVX-512 vector extensions and AMX matrix units, aimed at accelerating compute-intensive and vectorizable tasks. In addition, AWS m7a and m8a instances based on 4th (Genoa) and 5th (Turin) generation AMD EPYC processors are analyzed, characterized by a high core count and increased efficiency in highly multithreaded scenarios, including heavily loaded server and analytical workloads. For completeness of comparison, Azure D_v5 and Google C3 instances are also considered, representing configurations of a comparable class based on Intel and AMD processors with similar target positioning.

Results and Discussion

This section presents a synthesis of benchmarking results obtained from aggregated data of Phoronix, Signal65, Spec.org, and internal provider reports. The comparison was carried out on instances of the 16 vCPU / 64 GB RAM class. Table 1 contains summary indicators of performance and cost.

Table 1

Summary performance and cost metrics (compiled by the author based on [13, 16])

*Geekbench 6 data approximated on the basis.
** On-Demand prices for the US East (N. Virginia) region or equivalents.

Comparison of the obtained results demonstrates a clear shift of the balance toward ARM platforms in terms of the aggregate performance-per-dollar metrics. The m8g.4xlarge instance based on Graviton4 confidently emerges as the leader in efficiency, outperforming the Intel-based m7i by more than 50%. At the same time, in absolute values of multi-threaded performance, AMD EPYC Turin (m8a) takes the lead, showing the best results in the class of heavy parallel workloads. However, such performance is achieved at the cost of a price that is approximately 35% higher compared to Graviton4, and therefore in scenarios where the dominant optimization criterion is the total cost of ownership rather than the minimum completion time of a specific job, the advantage of ARM becomes more pronounced; conversely, in tasks with strict SLAs on response time or batch processing speed, AMD retains the status of a strong competitor. Against this background, the phenomenon of Azure Cobalt appears particularly interesting: despite the use of less powerful Neoverse N2 cores (as evidenced by lower Geekbench scores compared to Neoverse V2 in Graviton4), Microsoft’s aggressive pricing policy (around $0.562/hour) makes Cobalt 100 an exceptionally attractive choice for scalable microservice architectures, for which linear scalability and aggregate cluster throughput are critical rather than maximum single-threaded performance [6, 14].

In artificial intelligence model inference tasks, particularly when working with LLMs (Llama 3.1 8B), testing revealed an unexpectedly pronounced advantage of ARM platforms. According to the Signal65 report, Graviton4 demonstrated approximately 168% higher throughput in terms of tokens per unit time compared to AMD EPYC-based systems and exceeded Intel Xeon solutions by 162% [17]. This gap is explained by a combination of architectural and system-level factors. First, Graviton4 is equipped with 12 channels of DDR5-5600 memory, providing extremely high memory subsystem bandwidth, which is critical for large language models that are typically limited precisely by memory access speed (memory-bound workloads). Second, the Neoverse V2 architecture supports reduced-precision data formats such as BF16 and employs optimized SVE2 vector extensions, which makes it possible to efficiently implement matrix multiplications and other linear algebra primitives underlying transformer models. An additional factor in favor of ARM is Azure Cobalt 100: thanks to deep optimizations in the ONNX Runtime stack and the KleidiAI libraries, this instance also demonstrates a multiple-fold advantage over x86 platforms in typical inference scenarios, where cluster throughput and energy efficiency come to the forefront [3; 8, p. 805-817].

For database management systems and in-memory stores, the picture turns out to be similar. For systems such as Redis and Memcached, ARM processors (Graviton3/4) provide 25–30% higher RPS (Requests Per Second) while simultaneously reducing tail latencies [7, p. 762-773]. The key factor here is the absence of SMT: request-processing threads in Redis do not compete for the resources of the same physical core with other logical threads, which reduces the likelihood of preemption, decreases jitter, and stabilizes the timing characteristics of the system. In experiments with PostgreSQL in the Amazon RDS environment, migration to Graviton4 led to a 19% reduction in transaction latency and a 23% increase in throughput per dollar of cost, which makes ARM platforms particularly attractive for high-load transactional systems and real-time services.

Finally, energy efficiency and the associated sustainability agenda are becoming a critically important dimension of competitiveness. Azure telemetry indicates that Cobalt 100 consumes 25–30% less electricity under production workload than Intel-based Dv5 series instances [6]. Google, in turn, states that Axion is 60% more energy-efficient than comparable x86 instances [2]. These differences translate not only into lower instance costs (providers partially pass energy-savings on to customers) but also into improved carbon footprint metrics (Scope 3 emissions) for enterprise customers who are compelled to account for climate risks and ESG reporting requirements. To provide clarity and structure for the key architectural and operational differences between the latest ARM and x86 cloud platforms, which is necessary for making migration decisions, Table 2 is presented below. It groups factors that go beyond pure benchmarks yet are critical for total cost of ownership (TCO) and efficiency [11].

Table 2

Comparative analysis of key architectural and operational characteristics of cloud platforms (ARM vs. x86) (compiled by the author based on [6; 7, p. 762-773; 8, p. 805-817; 13; 16])

Thus, ARM platforms simultaneously serve as a tool for reducing direct infrastructure costs and as a mechanism for achieving sustainability targets.

Despite the impressive performance and energy efficiency metrics of ARM, practical migration to the new architecture is almost always accompanied by passing through a kind of engineering adaptation valley of death. This is particularly acute in the area of CI/CD and containerization. Most build runners used today (GitHub Actions, GitLab Runners, etc.) run on x86_64 by default, whereas the target deployment environment is ARM. To build Docker images for aarch64 on x86 hosts, QEMU via binfmt_misc is typically used, so that the entire build process is executed under dynamic instruction translation. This approach inevitably leads to a 10–20-fold decrease in build pipeline performance, and an operation that takes minutes on the native architecture (for example, npm install or compilation of a large project in Rust/C++) stretches to hours under emulation, provoking timeouts and CI pipeline instability. Practical workarounds are well known here but require organizational effort: migrating some or all build tasks to native ARM runners (for example, AWS CodeBuild on Graviton or ARM agents in Azure DevOps), which restores build times to familiar levels; using Docker Buildx with remote ARM hosts as build nodes, where the build process is transparently delegated to a machine of the appropriate architecture; and, for Go and Rust, leveraging built-in cross-compilation mechanisms (for example, GOARCH=arm64 go build), which makes it possible to avoid full emulation but requires careful handling of components that depend on CGO and system libraries [12, p. 78-86; 15].

A separate layer of issues has traditionally been associated with the Python ecosystem and the binary package distribution system. Historically, many key libraries – NumPy, Pandas, SciPy, gRPC, and others – have relied on substantial fragments of C/C++ code, and in the absence of a ready-made wheel package for a specific aarch64 + Python/OS version combination, the pip package manager automatically fell back to building from source. As a result, the container for what might seem to be a simple Python application unexpectedly turned into a full-fledged build environment with installed compilers (gcc, gfortran, make) and a set of header files, which significantly increased both the build time and the size of the resulting Docker image. By 2023, the situation has changed fundamentally: the main libraries for data science and web development are already regularly publishing ARM-compatible wheels, and for most modern stacks developers obtain an experience close to plug-and-play. However, in projects where dependencies are tightly pinned in requirements.txt and rely on outdated releases, the problem does not disappear. Therefore, before migrating to ARM, an audit of dependencies and their upgrade to versions that officially support manylinux_aarch64 packages becomes an almost mandatory step [9, 10].

Against this background, the Java platform appears perhaps the most ARM-friendly. The long-standing Write Once, Run Anywhere principle is indeed implemented without visible flaws in the case of the JVM: for migration it is often sufficient simply to choose a JDK build for aarch64 correctly. Moreover, modern versions of OpenJDK include specialized optimizations for NEON and SVE vector instructions, which allows the JVM to use the hardware features of Neoverse and other ARM cores more efficiently. An important nuance is related to the behavior of the garbage collection subsystem. As already noted, the architectural rejection of SMT and the one vCPU = one physical core model in Graviton and Cobalt have a positive effect on GC predictability. In the classical x86 scenario with Hyper-Threading, GC threads compete for resources with application worker threads on the same physical core, which can lead to unstable and hard-to-predict Stop-The-World pauses. On ARM platforms, GC threads obtain more deterministic access to compute resources, which reduces pause durations and narrows the spread of P99 latency, a factor that is especially critical for high-load Java services with strict response-time requirements.

To ensure a predictable and controlled migration to the ARM architecture, it is advisable to use a modified 6R model (Rehost, Replatform, Refactor, etc.) adapted to the specifics of ARM. Such an interpretation of 6R makes it possible to link the choice of migration type and the depth of application transformation with the architectural characteristics of the target platform, minimizing the risks of performance degradation, compatibility violations, and operational failures. At the initial stage, a systematized inventory of workloads is performed, covering their dependencies, versions of the technology stack in use, resource consumption profiles, and key non-functional requirements. The most suitable candidates for migration to ARM are microservice applications on current versions of Java, Go, Node.js, Python, and other modern runtimes, as well as web servers and caching systems: as a rule, these components already have mature ARM support and demonstrate a predictable gain in performance and energy efficiency without the need for deep modifications. In contrast, complex candidates include applications on the legacy .NET Framework that require preliminary porting to .NET 6/8+; proprietary software without access to source code, where adaptation or recompilation is impossible; as well as databases extended with binary plugins that are tightly bound to a specific processor architecture. To improve the quality of analysis and reduce the amount of manual work, it is advisable to employ specialized tools such as AWS Application Migration Service and Arm Software Ecosystem Dashboard, which make it possible to automatically assess workload characteristics and their readiness for migration.

The pilot stage of the migration is reasonably built around managed services (PaaS), where a significant part of the operational complexity has already been abstracted by the cloud provider. A representative example is the migration of AWS RDS database instances from x86 to Graviton (for example, moving from db.m5 to db.m7g): in a typical scenario, the operation is reduced to selecting a new instance type via the Modify Instance action followed by a restart, since the operating system and DBMS are fully managed by the provider. This provides an almost instantaneous economic effect and performance gain with minimal changes in the application landscape and a significantly reduced risk of incidents. At the next stage, the focus shifts to CI/CD pipelines and containerization. The key task is to configure multi-architecture image builds so that a single delivery pipeline can produce artifacts for both linux/amd64 and linux/arm64. For this purpose, Docker uses the --platform linux/amd64,linux/arm64 flag, which allows the formation of unified manifests and ensures transparent architecture selection at the deployment stage. It is fundamentally important to introduce native ARM build agents, eliminating the dependence on QEMU as an emulation layer and thereby removing performance and stability bottlenecks during build and test execution.

The final phase involves implementing canary deployment in a hybrid infrastructure, where node groups on x86 and ARM operate jointly within a single cluster (for example, Kubernetes/EKS). Traffic is gradually redistributed from x86 nodes to ARM nodes, while key operational metrics are monitored in near real time: error rate, latency, CPU utilization, and other indicators critical for the specific services. Special attention is paid to monitoring exceptions and anomalies that manifest exclusively on the ARM architecture; the illustrative Datadog case demonstrates that ignoring architecture-specific error signatures can lead to failures that remain unnoticed at early stages but are critical in production. Thus, the combination of an adapted 6R model, thorough preliminary assessment, the use of a PaaS-based pilot, multi-architecture pipelines, and canary deployments forms a robust methodology for migration to ARM with controlled risk and predictable effect.

Conclusion

The conducted analysis makes it possible to formulate an unambiguous conclusion: as of 2023, migration to the ARM architecture in public clouds constitutes a mature, economically justified, and technologically sound strategy for large-scale enterprise and high-load systems. The current generation of specialized ARM processors – AWS Graviton4, Azure Cobalt 100, and Google Axion – has not only reached technological parity with x86 but has also demonstrated superiority in key metrics critical for cloud workloads: inference of machine learning models, database workloads, and data compression and transformation operations. Architectural decisions such as abandoning SMT in favor of a more predictable execution profile, enhanced vector units, and tight integration with I/O offload mechanisms result in more stable behavior under load and improved resource utilization efficiency, which is particularly important for deterministic performance planning.

From an economic perspective, the ARM architecture in the cloud is becoming the de facto non-alternative choice in scenarios focused on optimizing total cost of ownership. With a difference in instance prices on the order of 15–20% in favor of ARM and a performance advantage of 20–30%, the integral effect in terms of the price-performance metric reaches 40–50%, which at the scale of a large enterprise translates into savings measured in millions of dollars annually. At the same time, by 2023 the software ecosystem has largely overcome the limitations characteristic of five years earlier: the main programming languages, server frameworks, and container platforms provide first-class support for ARM64, and the remaining difficulties, primarily related to organizing multi-architecture builds in CI/CD, are addressed by engineering means and are not fundamental in nature.

From this follow practical recommendations for strategic planning. For new projects, it is advisable to consider ARM as the default architecture, implementing an ARM First Strategy and thereby establishing an optimal cost – performance balance from the outset. For existing systems, a rational trajectory is a phased migration starting with managed services and stateless microservices, where the risk is minimal and the effect manifests quickly. In parallel, it is necessary to purposefully invest in the modernization of CI/CD pipelines with support for multi-architecture builds and testing, since hybrid environments where x86 and ARM coexist are highly likely to remain the dominant model for the coming years, providing organizations with a controlled transition to ARM without compromising the stability of critical business systems.