As companies continue to look for ways to optimize and save on AWS costs, high-reward, lower-effort strategies, like Savings Plans, Right Sizing, and switching to Graviton processors, are gaining more and more adoption. Graviton processors, in particular, account for such a significant savings opportunity that has only recently been widely adopted. Some companies still remain hesitant to make the switch, but Graviton processors are a safe and substantial way to cut costs.
Graviton Recap
Graviton processors were designed by AWS specifically for optimal performance and cost-effectiveness with AWS workloads. Since their launch in 2018, adoption has grown rapidly for some services like Lambda and steadily for others like EC2.
In a previous blog, we reviewed the differences between Intel vs Graviton vs AMD processors in detail. To summarize, the most notable difference is that Graviton processors use an Arm-based architecture, whereas Intel and AMD use x86 architecture. This distinction affects many aspects of performance and compatibility, the most significant being how the processors handle threading and the potential Arm compatibility issues with certain software libraries or third-party applications.
For AWS services where Graviton is an option—especially lower-risk ones like development environments or stateless workloads (see section)—you can achieve substantial savings with minimal engineering work.
AWS Services With Graviton Processors
A growing number of AWS services offer instances running on Graviton processors, including EC2, RDS, Elasticache, OpenSearch, MSK, SageMaker, and DocumentDB. Furthermore, some services, like Lambda and Fargate, allow you to choose between x86 and Arm architecture, which are Graviton instances under the hood. Also, for other services, such as EMR, where you select an EC2 instance, you can choose one with a Graviton processor.
Each service offers its own range of price-performance improvements compared to x86 architecture equivalents. For example, AWS advertises a better price performance of up to 34% for Lambda, 40% for EC2, and 44% for OpenSearch.
Switching to Graviton Processors
Actually implementing the switch to Graviton instances is straightforward. Simply select a Graviton instance type when launching a new service or modifying an existing one. The strenuous part is determining if your workload is compatible for the switch. You may need to refactor code, switch versions of certain libraries or software dependencies, then thoroughly prepare your workload for the migration.
Once you’ve determined compatibility testing is required. Even though AWS advertises improved price-performance, actual results depend heavily on your specific workload. Benchmarking and running load tests will help you assess if the savings are substantial enough to justify switching.
Low-Risk Workloads to Convert to Graviton Processors
For companies hesitant to switch to Graviton processors, starting with low-risk workloads is a great way to evaluate performance and cost savings without adverse risk. Some ideal workloads for early Graviton adoption include:
- Non-Production Environments: Test compatibility, performance, and stability without impacting live services.
- AWS-Managed Services: Services like RDS, ElastiCache, and OpenSearch handle the underlying infrastructure, and mitigate compatibility issues. However, it is important to make sure any connected applications are being tested for compatibility. Also, not all versions or generations of these services support Graviton, so you’ll need to verify that the specific version or instance type you’re using is compatible with Graviton processors and upgrade if practical.
- Non-Interactive Workloads: Such as batch jobs and data processing, are typically more tolerant of potential performance variations.
- Stateless Applications (e.g., Lambda): Since they don’t retain user session data between requests, they can be quickly deployed and tested across multiple instances, minimizing risks.
- Containerized Applications (e.g., Fargate): Containerized workloads are isolated from the underlying infrastructure, making them more adaptable to different environments without significant changes to the application architecture.
Conclusion
Switching to Graviton processors represents a significant opportunity for companies to optimize AWS costs while maintaining or even improving performance. While the switch to Graviton does require careful planning and testing, the potential rewards in terms of cost savings and performance improvements make it a strategy worth considering. By starting with low-risk workloads, companies can make a more informed decision for broader adoption.
Monitor your AWS costs.
