AWS Graviton Migration || ARM || x86_64

Migrating your database workloads from C4/C5/C6a instances to R8g Graviton4-based instances can deliver significant benefits, including up to 40% better price-performance compared to equivalent x86 instances. Here's guidance on your migration considerations:

Compatibility Considerations: Before migrating, verify that your application binaries, libraries, and dependencies support ARM64 architecture. A good candidate for Graviton adoption is a workload running on Linux or BSD, built using open-source components or source code you control. Many independent software vendors already support the Arm64 architecture. Confirm that third-party agents, drivers, and monitoring tools are available for ARM64. The AWS Graviton Technical Guide and Arm Learning Paths provide detailed information on recompiling code for the Arm architecture if needed.

Performance Expectations: Graviton processors use 64-bit ARM Neoverse cores optimized for speed and efficiency in cloud workloads. You can expect faster processing, lower latency, and improved throughput. Graviton4 offers 30% better compute performance, 50% more cores, and 75% more memory bandwidth than Graviton3. The ARM architecture and custom memory subsystem reduce latency for many operations, which benefits real-time and latency-sensitive applications. Graviton optimizes cache utilization and memory access, leading to gains for memory-bound workloads like databases. Graviton typically provides a 20-40% cost reduction for compute workloads.

Sizing Recommendations: When selecting the appropriate R8g size, focus on CPU utilization, memory usage, network throughput, and disk I/O metrics. Since you're moving from compute-optimized (C-family) to memory-optimized (R-family) instances, closely monitor memory utilization patterns in your current environment. The difference in vCPU meaning between x86 and Graviton architectures contributes to improved efficiency, so don't assume a 1:1 vCPU mapping. Consider right-sizing CPU and memory based on actual workload requirements rather than matching current instance specifications.

Migration Best Practices: Implement a structured evaluation process: First, deploy the recommended Graviton instance in a staging or non-production environment. Run comprehensive load tests to validate performance parity with your current instances. Monitor performance metrics closely during the initial migration period—typically seven days of monitoring is recommended. Test with realistic workloads that mirror your production traffic patterns, including peak loads.

General Database Considerations: For all three database systems, ensure you're using versions that explicitly support ARM64. Container-based workloads using multi-arch images typically require less modification to migrate. If you're running databases in containers, create multi-architecture container images to support both x86 and ARM64. Test query performance, compression efficiency, CPU utilization, and storage I/O patterns in your staging environment before production migration.

Additional Recommendations: Graviton migration is generally considered low-risk and high-reward, as most workloads run on ARM64 without requiring code changes. However, the architecture shift from x86 to ARM64 is more involved than simple instance resizing, so thorough testing is essential. Take advantage of AWS managed services where possible—Amazon RDS, Amazon ECS, Amazon EKS, and other services offer Graviton options that can simplify migration. Document your performance baselines before migration so you can accurately measure improvements in your specific environment.
Sources
Graviton instance migration - AWS Prescriptive Guidance
Use Graviton instances and containers - AWS Prescriptive Guidance
ADVPERF02-BP05 Evaluate ARM architecture for performance considerations by using AWS Graviton - Video Streaming Advertising Lens
Optimize EC2 costs with AWS Compute Optimizer right sizing | AWS Compute Blog
Community | AWS Graviton Processors