iTranslated by AI
re:Invent 2025: Evolution of AWS Graviton5 and Achieving the Best Price Performance
Introduction
By transcribing various overseas lectures into Japanese articles, we aim to make hidden, high-quality information more accessible. The presentation we will be covering in this project, based on that concept, is here!
For re:Invent 2025 transcript articles, information is summarized in this Spreadsheet. Please check it as well.
📖re:Invent 2025: AWS re:Invent 2025 - AWS Graviton: The best price performance for your AWS workloads (CMP360)
This video explains the evolution of AWS Graviton processors and the details of Graviton5. Graviton is now in its 5th generation after more than 10 years of innovation, offering the best price performance on EC2. Graviton5 features 192 cores, achieving up to 25% performance improvement compared to Graviton4. The L3 cache has increased 5.3 times to 192 megabytes and supports DDR5 8800. A new technology called Nitro Isolation Engine provides mathematically proven security, written in Rust and formally verified. Customer case studies from Snowflake, Honeycomb, and Airbnb report performance improvements ranging from 20% to 60%. To assist with migration, tools such as the AWS Graviton Technical Guide, AWS Transform Custom, and Graviton Savings Dashboard are provided, and 90% of applications run without code changes.
This article is automatically generated, striving to retain as much of the original lecture's content as possible. Please note that there may be typos or incorrect information.
Main Content
Conference Closing Remarks and Graviton Overview
Good morning, everyone. Thank you for coming on the last day. At every conference, there's a group that stays until the very end. And that group is usually the most curious, and the most committed. And so today, to reward that dedication, I want to share some insights with you about Graviton and the latest generation, Graviton5. We'll look at how the AWS silicon portfolio has evolved over the years, and then we'll dive deep into Graviton and Graviton5, which we launched earlier this week. And finally, we'll share with you some best practices, tips, and tricks to help you migrate to Graviton.
AWS has over 10 years of innovation in silicon. Over 10 years, we've launched six generations of Nitro cards, five generations of our own custom Graviton chips, and Trainium and Inferentia for machine learning. Across all three of these platforms, we've shipped millions of chips and seen tremendous success. The question we often get is, why Graviton?
The main reason is that Graviton offers the best price performance on EC2. These instances are based on Graviton chips, and AWS innovation is integrated across the entire stack, not just the chip. This allows us to provide performance, reliability, and efficiency. Over 300 Graviton-based instances are available across 38 regions worldwide, and as a result, over 90,000 customers are using Graviton for a wide range of workloads. These customers range from small businesses to large enterprises, and their industries span from software to financial services, and even media and entertainment.
Evolution of Graviton: History of 5 Generations of Development and Graviton4 Features
With this week's launch, Graviton is now available in its 5th generation. The first generation was Graviton1. It launched in 2018 with 16 cores. It was ideal for scale-out microservices and was the first to introduce a low-cost, efficient, and high-performance chip to EC2. In 2019, we launched Graviton2. This was a major leap, increasing to 64 cores and significantly improving memory bandwidth. It enabled mainstream workloads with up to 40% better price performance compared to other EC2 instances.
In 2021, we launched the even faster and more efficient Graviton3. Each generation has seen an increase in compute performance, and now customers are running compute-bound, memory-bound workloads, containers, Java, and machine learning on Graviton. In 2023, Graviton4 further improved performance for scale-up workloads, allowing large databases and electronic design automation applications to migrate to the Graviton ecosystem. And now, we have launched Graviton5. We will delve deeper into Graviton5 in a few minutes.
The latest generation, widely available, is Graviton4. We offer a very wide range of instances for compute-intensive, memory-intensive, and storage-intensive workloads. We have instances with 384 gigabytes to 3 terabytes of memory. These instances also include local storage for caching workloads and scratch space. I-instances include local storage ranging from 45 terabytes to 120 terabytes.
For workloads requiring high-performance network bandwidth, network-optimized instances provide up to 600 gigabits per second of network bandwidth. And for high EBS performance needs, EBS-optimized instances offer 720,000 IOPS and 150 gigabits per second of EBS bandwidth. Graviton 4 provides many choices available to you today.
Graviton Server Architecture and Customer Use Cases: 90,000 Adoptions
Let's take a closer look at what a Graviton server looks like. AWS not only designs the chip, but also the Nitro SSD, Nitro card, firmware, and hypervisor that runs on the server. This complete ownership across the entire stack allows us to optimize and deliver the predictable performance you expect, with reliability, security, cost, and power efficiency.
As a result, Graviton can now run a wide variety of workloads. Whether it's web servers, high-performance computing, or electronic design automation, Graviton can run them all. Our high core count, memory bandwidth, and custom stack enable all these applications to run on Graviton, providing the best price performance overall. It has been widely adopted for multiple workloads such as Spark and EMR for data processing, all C applications, and containerized microservices. We are currently seeing over 90,000 customers deploying all these applications on Graviton.
And here are some of the customers who are truly maximizing Graviton. They are running all their workloads on Graviton and providing a better experience for their users. For example, ClickHouse achieved up to 76% performance improvement on certain queries on Graviton 4. Freshworks saw a 23% improvement in average response time, and Quora achieved 20% faster performance for their web servers. These are just a few examples of customers currently running their applications on Graviton 4.
Another reason customers choose Graviton is the ability to reduce their carbon footprint while gaining performance and cost benefits. Adobe reduced CO2 emissions by 41%. JFrog reduced its carbon footprint by 60%, and Snowflake reduced carbon emissions per Snowflake virtual warehouse credit by 57%. And all of this is combined with improved performance and better cost efficiency.
We also see more and more customers running machine learning applications on Graviton. For example, Mobileye achieved a 2x increase in throughput while reducing costs. And Sprinklr reduced latency by 30% for inference and search workloads.
It's not just external customers. Our internal customers, meaning AWS services, are also rapidly expanding their use of Graviton. For example, over 90% of Redshift Serverless runs on Graviton. Over 60% of Managed Streaming for Kafka (MSK), Amazon Aurora, and RDS run on Graviton. And across EC2, over 50% of EC2's CPU capacity has been Graviton for the past two years.
Graviton5 Technical Details: 192 Cores and 3-Nanometer Process Achievement
Now, let's take a closer look at Graviton5.
For that, I'll hand the microphone over to Ali. Thank you, Gohan. So, let's talk about Graviton5. With Graviton5, we can say we've surpassed Moore's Law. We've doubled the core count in one generation. From 96 cores in Graviton4 to 192 cores in Graviton5. This is the same size device if you put it next to Graviton4, but now it has twice the core count. It's manufactured on a 3-nanometer process, and each core has approximately 25% higher performance compared to the previous generation.
So, let's talk about how we achieved this. We'll start with the core. We've talked a lot about large-scale workloads, designing for large-scale workloads, and how microbenchmarks are completely different from large-scale workloads. For Graviton5, we are using ARM's Neoverse V3 core. This core features a larger branch predictor, can process more instructions per cycle, resolve more branches per cycle, and has a larger structure to handle large-scale workloads. It also has a more advanced prefetcher, making it an overall higher-performing core.
We have coupled this core with our memory system. Deciding what kind of memory system to have is always an optimization problem. You want to place as much cache as possible as close to the processor as possible, but that's not always feasible. You can't make the L1 cache very large. Due to physical constraints, you can't access a huge cache in just a few cycles. In Graviton4, we increased the L2 cache size from 1 megabyte to 2 megabytes. And many customers found that it suited their workloads much better and provided higher performance. For Graviton5, we evaluated where to change the cache hierarchy and decided it was time to increase the L3 size. So, in Graviton5, we increased the L3 cache by 5.3 times. It is now 192 megabytes. Together with the L2 cache and other caches in the system, we now have over 600 megabytes of total cache.
Graviton has also led the way in DDR for many years. Graviton2 was the first system in our fleet to feature DDR4 3200. Graviton4 was one of the first servers to feature DDR5. We pushed the DDR frequencies with Graviton4, and we're doing it again with Graviton5. The Graviton5 CPU supports up to DDR5 8800, and we're working with DRAM vendors to help qualify DIMMs at these frequencies. Additionally, we've worked to reduce memory latency, cutting it by approximately 15% compared to Graviton4, to under 100 nanoseconds.
Speaking of I/O, Graviton5 supports PCIe Gen 6. This is the first CPU in our data centers to support Gen 6, providing half a terabyte of I/O connectivity. This allows us to build all the instance shapes and sizes you see across our other compute offerings. In Graviton4, we had a two-socket configuration with 96 cores each. Now, we've put all these cores into a single socket. With 192 cores, we've seen use cases for scale-up applications like databases and EDA workloads. However, the two-socket configuration, the latency between them, and the limited bandwidth meant that some of these workloads couldn't scale as much as desired.
By bringing all 192 of these cores onto a single chip, we've achieved up to a 33% reduction in latency. We've significantly increased the bandwidth between cores, greatly improving scalability for some of these large workloads. However, we are not getting rid of NUMA. To provide better latency and performance, we've given 96 cores affinity to local caches and local memory controllers.
So, regarding Graviton5, we are announcing our ninth generation of EC2 instances. We'll start with M9G instances. These offer industry-leading performance, up to 25% better compared to Graviton4. Graviton5 is the most energy-efficient CPU we've ever built. It provides the best cost performance in EC2 and delivers the same scale-up capabilities with lower latency and higher bandwidth than Graviton4.
Nitro Isolation Engine: Innovation in Formal Verification and Security
Now, let's take a moment to talk about security. The hypervisor has a lot to do. It has to handle scheduling, resource allocation, and I/O.
When virtualization first started, it was all about packing multiple workloads together on a server you owned. We've talked at re:Invent over the years about how Nitro is different. With Nitro, we moved networking, storage, and management to dedicated silicon: Nitro cards. Nitro has many jobs, but the most important is to isolate customers, meaning isolating customers from each other and from us. With the Nitro system, there is no operator access, and we enforce this not just by policy but by mechanism.
With Graviton, we've been raising the bar for system security. Graviton 2 was the first system to support DDR encryption. Graviton 4 was the first system to support PCIe encryption. We took the attestation process we have with Nitro cards and added it to the Graviton CPU for Graviton 4. This allows us to ensure that every chip in our data center is a known production-quality device and is running the firmware we expect. And we can continuously measure this throughout the server's lifetime.
The Nitro hypervisor is purpose-built for one job, and it's a great hypervisor, but we're always asking ourselves, is there an opportunity to do better? In conjunction with Graviton 5, we've also built another layer of technology to increase the transparency of the virtualization stack. We call this the Nitro Isolation Engine. The Nitro Isolation Engine sits between the Graviton CPU and the Nitro hypervisor. So, what is this? We're partitioning the most critical interactions between the instance memory device and access control into a new layer.
There are a couple of really interesting things about this code. First, it's written in Rust, which eliminates an entire class of problems around memory safety and concurrency. But the most innovative and interesting thing about the Nitro Isolation Engine is that formal verification has been a first-class consideration from the very beginning of the project to today. When we set out to develop the Nitro Isolation Engine, software engineers and applied scientists sat down together and tried to figure out how to formally specify all the interactions within the Nitro system and how to formally prove those interactions.
But we keep saying formal verification, what does that mean? Here's a really simple function. It takes three inputs and produces one output. So, how can we make sure it always does what we expect? Well, we could try a bunch of test cases. We could try X is zero, Y is zero, Z is zero, and a few others. But can we exhaustively test this function? It's really simple. You'd think we could, but we can't. Even if you had a processor that could evaluate the outcome of this function a billion times a second, and you had a billion such processors, it would take longer than the age of the universe to exhaustively test this simple three-input function.
Formal verification, instead, allows you to mathematically show that a function adheres to the specification it was intended to implement. And this allows you to reason about a system using mathematical logic. Specifically, what a system can do, what it must do, and what it must never do across all possible inputs and all reachable states. For a hypervisor, this means it can create and manage VMs. It must preserve the confidentiality and integrity of guests. It must never do things like null pointer dereferences or buffer overflows. But crucially, across all possible inputs, all hypervisor and guest actions, and all reachable states.
And with the Nitro Isolation Engine, we are proving properties that every hypervisor should have, but very few can actually prove they have. We're proving memory safety. And not just because we're using Rust, but we can prove that unsafe code is sound, that there are no reachable panics that just unwrap to none, that there are no logical errors, and that the specification matches the implementation. And we're proving that virtual machines have confidentiality and integrity, and no unauthorized information disclosure of VM state. And we're doing this across the entire core functionality required to manage the VM lifecycle. Over time, we're just going to expand on this.
So, the Nitro Isolation Engine leverages formal verification to pioneer a new standard for mathematically proven cloud-based security, and it's default in M9G instances.
Graviton Design Process and Collaboration with EDA Tool Vendors
Now, let's talk a little bit about how we design and build Graviton. When we build a new version of Graviton, we bring a lot of workloads into the design process. And one way we visualize that is with polar plots like this. On the left side, you have features that are in the front-end of the processor, things like branch prediction and instruction misses. And on the right side, you have things that are in the back-end, execution and data cache misses. When we look at a workload, for example, this is MongoDB running on Graviton 4, we can see that it has a lot of instruction misses, a lot of branch prediction misses, and front-end stalls. And it's also incurring a lot of L2 misses.
And in the design process, we can take a workload like this and ask ourselves what kind of performance we're going to get when we make our decisions. But the design process before silicon manufacturing is actually very difficult. When you try to simulate a chip before you have it in your hands, you incur a slowdown of 10,000x or more. This means that simulating one second can take hours, and simulating a few minutes can take a month. So, what do we do? Over the years, we've developed a mechanism where we can run workloads in the lab, take the state from there, and run it in a pre-silicon manufacturing environment. This is one of the ways we've worked with companies like SAP HANA to improve the performance of HANA databases on new versions of Graviton.
But coming back to MongoDB, we can take a shape like Graviton 4 and see what it would look like on Graviton 5. Here, you can see that many parameters are reduced, indicating much higher performance. Now, one of the things that silicon designers get most excited about is designing the next version of silicon on the current version of silicon. When we started Graviton, that wasn't an option. But over the years, Graviton has become a big part of our design process. It's used not only for Graviton but also for Nitro chips and Trainium chips, with thousands of server-worth of capacity all being used to develop the next generation.
So today, I'm very excited to announce that Siemens, who manufactures one of the most important industry-standard sign-off tools used to check if a design is ready for manufacturing, will announce support for Caliber on Graviton-based processors. This tool is one of the most critical tools used by the majority of silicon design companies, and it needs to run fast. Because the faster it can run, the faster you can iterate and get to a point where you can tape out. And our early tests for Graviton 5 show an additional 30% performance improvement on top of the 20% we've seen compared to other systems we've tested previously.
Synopsys and AWS have also been collaborating for over 10 years since the founding of Annapurna Labs to enable Amazon's custom silicon development. And Synopsys is also expanding its tools that support Graviton, including VCS, PrimeTime, and Fusion Compiler, where we are seeing significant performance improvements. We're seeing up to 35% improvement in Fusion Compiler and PrimeTime, and up to 40% performance improvement between generations in VCS.
Graviton5 Performance Validation: Achieving up to 60% Performance Improvement
Now, speaking of performance, at the beginning of this talk, I mentioned a 25% performance improvement per vCPU. So, let's take a closer look at a few examples. Many customers are running CPU-based machine learning on Graviton. Gautham shared information about Snowflake and Airbnb, didn't he? So, one of the workloads we've been validating for Graviton 5 is how performance improves on Graviton 5. We ran a mix of CPU-based workloads, including BERT, RoBERTa, and image analysis, using AWS Deep Learning Containers, and we saw a 35% performance improvement in PyTorch.
Many customers are also running Java-based web applications on Graviton, and here too, we've seen impressive improvements. Grails is an open-source web framework that uses the Groovy language. We fixed the load generation using a Grails application and ran it on Graviton 4-based M8G and Graviton 5-based M9G. Here, we saw a 32% increase in requests per second.
Now, microservices are great, but monoliths still exist. We don't have a really good open-source example for this, but we used an internal workload used for delivery planning and measured it on Graviton 4 and Graviton 5. This is a very large workload with about a 100-megabyte JAR, and in this case, we saw an excellent 47% performance improvement.
NGINX is a popular web server. We see it used both as a web server and a load balancer. Here again, we fixed the load generation and a set of web servers, and measured performance with either a Graviton 4-based M8G or a Graviton 5-based M9G in between. Here, we saw a 27% performance improvement between generations.
Finally, we've seen many customers running SQL and NoSQL databases. We used HammerDB, an open-source load generation tool. This simulates a company with a warehouse, managing inventory, and selling products, ultimately generating a score of orders processed per minute. Using HammerDB, we again tried performance with either a Graviton 4-based M8G or a Graviton 5-based M9G, and we saw a 40% improvement by migrating to M9G.
Now, these are the workloads we ran, but over the last few weeks, customers have also been running their workloads on Graviton. Snowflake has been running virtual data warehouses on Graviton since the Graviton 2 era, and they recently tried Graviton 5 instances based on M9G. They saw over a 30% performance improvement in typical virtual data warehouse workloads.
Similarly, Honeycomb provides an end-to-end observability platform and has been using Graviton since M6G launched in 2020. Simply by using it, they saw a 20 to 25% improvement in latency. When they tried to reduce the amount of compute needed to maintain the same latency, they saw a 36% increase in throughput per core.
Airbnb has also adopted Graviton, and after testing M9G instances, they rated them as one of the fastest instances they've ever tested, finding 25% higher performance compared to other system architectures. Finally, SAP—we've been working with SAP to support SAP HANA Cloud for the past few generations. HANA Cloud can do many things, and one of them is online transaction processing. When we measured online transaction processing queries, we saw an astounding 35 to 60% performance improvement between generations.
So, in the benchmarks we ran, we saw excellent performance improvements of 27 to 47%, and in the benchmarks run by our customers, we saw excellent performance ranging from 20 to up to 60%. Now, I'll hand it over to Gautham to talk about how to migrate to using Graviton.
Graviton Migration Guide: Tools, Best Practices, and Phased Approach
Thank you, Ali. That was truly exciting. Graviton 5 – I'm really thrilled about what it brings in terms of performance. After you've tested it in preview, we'd love to get your feedback too. So, now that we know a lot about Graviton and have learned about Graviton 5, I'd like to take this opportunity to share some tips and tricks to simplify your migration to Graviton.
Our goal is to make your migration to Graviton as simple and low-risk as possible. To do that, we've learned a lot from customers running workloads on Graviton and have provided best-in-class guides, tools, and resources to help you with your migration. 90% of applications should run on Graviton without code changes, but for those that require some work, we have many resources to share with you.
Let's start with software. If you look at the operating systems available on the market today, the majority of mainstream Linux operating systems run on Graviton. This includes Amazon Linux 2023, commercial ones like Red Hat, SUSE, and Ubuntu, as well as community Linux operating systems like AlmaLinux and Alpine.
These ARM64 builds receive regular patches and security updates, meaning the Graviton OS ecosystem is very mature and stable. This allows you to migrate your applications to Graviton without major changes at the OS level.
As I mentioned earlier, customers are running containerized microservices on Graviton. Services like Amazon ECS and Amazon EKS support Graviton for orchestrating these containers. Docker Hub also allows you to publish multi-architecture images, so you can publish x86 and ARM64 images using these services. For example, you can use Docker BuildX. Graviton also works smoothly with container-optimized Linux distributions like Bottlerocket.
For serverless compute, services like AWS Lambda and AWS Fargate also support Graviton today. All these container and serverless products make it really easy to adopt Graviton across your entire deployment pipeline. And you can use the same CI/CD and automation tools you currently use on Graviton as well.
On the fully managed side, for example, services like AWS CodeBuild, CircleCI, and GitHub all provide ARM64 environments. This allows you to build, test, and deploy ARM-native applications without managing infrastructure yourself. For hybrid models, tools like GitHub Actions and GitLab runners support Graviton. In self-managed environments, teams can also deploy their preferred DevOps stack, like Jenkins agents, on Graviton.
We also have partners who certify their software on Graviton. These applications span observability, databases, security, analytics, DevOps, and more. This is a partial list of key partners, but what it means is that you can run the same commercial software you currently use on Graviton without any functional gaps.
I talked about some AWS managed services. All these services – DocumentDB, Aurora, RDS, ElastiCache, MemoryDB – support Graviton today, and we provide Graviton instances for these services. Since they manage the infrastructure themselves, you don't have to worry about it. Using AWS managed services with Graviton is probably the easiest and most seamless way to start using Graviton and reaping its cost-performance benefits.
On the compute side, we talked about Amazon ECS and Amazon EKS, as well as serverless options like AWS Lambda and AWS Fargate, all of which support Graviton. EMR, our big data service, provides the ability to run analytics workloads like Spark on Graviton, and derive cost-performance benefits there as well. For machine learning, Amazon SageMaker supports Graviton today, and for example, some customers are running SageMaker with Graviton for inference workloads.
As you begin to think about what it takes to migrate, there are a couple of things to keep in mind. I'd like to briefly go over them. The first is to learn about Graviton. We've talked about Graviton today, but there's still a lot more. There's an excellent AWS Graviton Technical Guide on GitHub. It's packed with information about what Graviton is, what the instances are, what the architecture is like, and also very specific recommendations for each type of workload. I highly recommend checking it out.
Also, if you're interested in a free trial, if you want to try Graviton for free, we have a free trial using T4G EC2 instances, so you can experience the benefits of Graviton.
Step two is to inventory your software stack. Identify everything you're using: open-source and commercial libraries, agents used for monitoring, logging, and security, and ensure they have ARM64 binaries or architecture-agnostic code so they can run on Graviton. If they don't, contact the vendor of that software and ask for their roadmap on when they can support ARM64, or contact your AWS account team, and we can escalate and try to assist you.
Also, consider tools like Amazon Q Developer, which can automate some of this. For example, it can help with Java version upgrades. So, consider those tools as well. The third step is to plan your workload migration. There are a few points regarding planning. One is to take an AMI or create a new ARM64 AMI. You can build or create images, and we've also talked about container support and image registries.
AWS Transform is also a great tool that can help with this. And you'll want to test. Perform unit tests and functional tests. Make sure you have the correct software versions. AWS Transform is an excellent resource. We just launched a custom version of AWS Transform on Monday that includes a module to help with Graviton migrations. It's currently in early access, but it can identify incompatible libraries and even recompile or upgrade to compatible versions. It has very powerful capabilities. It's currently in early access with more enhancements planned. It has an AI agent running in the background, so it learns and improves as you use it.
And you'll want to measure performance too. For that, we have the AWS APEV tool, which is also available from the GitHub page of the Graviton technical guide I mentioned earlier. And finally, you can deploy. When it comes to deploying, the first thing you want to do is update your infrastructure as code. Then, you can use a blue-green deployment approach. Create a Graviton stack in parallel with your existing stack, and use weighted routing to send a portion of requests. Then, you can monitor performance and response times to ensure your application running on Graviton in production is performing as expected.
Another way to think about migrating to Graviton is to start with what's easy. As I said earlier, the easiest and most seamless way is to use AWS managed services like RDS, Aurora, MemoryDB, or EMR. All of these already support Graviton, and they manage the Graviton infrastructure for you. So all you need to do is upgrade to a version that supports it and enjoy the price-performance benefits that Graviton offers.
And interpreted languages like Java, PHP, and Node.js are also relatively easy. All you need to do is select and install an ARM64 AMI; it becomes even easier if you containerize your workload, but be sure to check for specific native modules and upgrade them to ensure smooth operation. Compiled languages like C, C++, and Python require a bit more effort, so you'll need to recompile them and port intrinsics, assembly, and native modules.
And if you have Windows-based Microsoft .NET workloads, you can migrate to Linux with .NET Core, and once you're on Linux, you can then migrate to Graviton. So, there's a range of workloads you can start with, some requiring more effort. I talked about AWS Transform Custom. This is a Graviton module in early access that simplifies migrating Java applications to Graviton, in particular.
Many Java applications can already run on Graviton because Java bytecode is architecture-independent. However, if you still have concerns or have native libraries or architecture-specific code, this agent can help. For example, if you have shared libraries that don't have ARM64 variants, or JNI bindings compiled for x86, this agent will recompile from source if available, or prompt you to seek ARM64 compatible versions.
There's an excellent dashboard called the Graviton Savings Dashboard. This helps you calculate the savings you're making today by using Graviton, or simulate the potential savings you could gain by migrating workloads not currently running on Graviton. This is another great dashboard you can use to justify your migration.
Workload-Specific Optimizations and Resources: Spark, Java, and Machine Learning Support
Now, let's look at some very specific workloads. I'd like to make a few key points here. I talked about Spark, which is a popular data processing framework, but sometimes it suffers from straggler problems. Long-running tasks can sometimes slow down the entire cluster. This is often due to imbalanced data distribution. So, there are a few key recommendations. For example, set your shuffle partition size to less than 200 megabytes. And don't forget to benchmark and optimize your settings. By doing this, we've seen up to an 80% performance improvement.
EMR is Amazon's service that can run Spark workloads, and it's also an option. However, make sure to use the default settings that EMR provides. I mentioned versions earlier, and keeping your versions up-to-date is a best practice. Because in the case of Spark, we've found that using Spark 3 with Java 17 yields up to 40% better performance compared to Spark 2 with Java 8. So, simply upgrading your version can really provide significant performance benefits.
C++ and C run very well on Graviton, as long as you natively compile them for ARM64. And don't forget to use the ARM-specific flags shown in the slide. Rebuilding native libraries, avoiding x86-specific code, and leveraging vectorization like SVE can greatly help when running these types of applications on Graviton.
Python is a high-level interpreted language, but it runs very well on Graviton when using ARM64-native Python libraries. Also, ensure your Python math libraries are ARM optimized. I talked about containers earlier. These help you build and publish multi-architecture container images. The key is to build ARM64-native images. You can also build multi-architecture builds using Docker Buildx. And again, here, verify all your dependencies and ensure they support ARM64.
Java runs very efficiently on Graviton. Remember to rebuild native libraries for ARM and use the latest JDK. One thing to keep in mind is that Graviton performs very well even with high CPU utilization. So, feel free to run Graviton hotter than you would typically with other architectures.
Machine learning is an area where many customers are utilizing Graviton. Specifically, it's used for use cases such as automatic speech recognition, sentiment analysis, recommendation systems, and chatbots.
For recommendation systems and chatbots, make sure to use the appropriate ARM64-native machine learning frameworks. It's important to follow the versions listed here. There are also software abstractions like AWS Deep Learning Containers, which make it easier to use.
And finally, I want to present a list of all the resources available to you. The first one I mentioned is the AWS Graviton Technical Guide. The link is provided here, and it contains a wealth of information to help you migrate all your workloads to Graviton. And it's continuously updated. Also, if you want to take advantage of a free trial, we have migration resources. We offer a free trial of Graviton with T4G instances. Tools like AWS Q Developer and AWS Transform are also currently available, so please make use of them. And there's also the Graviton Savings Dashboard, where you can calculate your cost savings. APR is a tool we built that helps you collect performance metrics during migration and analyze those metrics to optimize performance on Graviton.
Please get started today. And the most important thing I want you to remember here is that the reason you're looking at Graviton is because it offers the best price performance of all EC2 instances. Also, Graviton5-based M9G instances are available today. They are currently in preview, and we have a preview form on our website where you can sign up. And as Dave Brown, our VP, said, all it takes is one week, one application, and one engineer. And you'll be amazed at what you can do when you migrate your applications to Graviton.
Thank you for your time. I appreciate you all being here.
- This article was automatically generated using Amazon Bedrock, maintaining the information from the original video as much as possible. Please note that typos or incorrect information may be present.
Discussion