AWS re:Invent 2025 - AWS Graviton: The best price performance for your AWS workloads (CMP307)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - AWS Graviton: The best price performance for your AWS workloads (CMP307)

In this video, AWS presents Graviton5, their most powerful and energy-efficient chip delivering up to 60% performance improvements. The session covers Graviton's evolution from 2018 to present, with over 90,000 customers achieving 20-30% cost savings and significant carbon footprint reductions. Ali Saidi details Graviton5's 192 cores, 192MB L3 cache, DDR5-8800 support, and the Nitro Isolation Engine with formal verification written in Rust. Atlassian's Thibaud Delor shares their migration journey, achieving 32% faster performance and 25% cost reduction on Jira and Confluence workloads. The presentation includes practical migration guidance, emphasizing the Graviton Technical Guide, multi-architecture container support, and AWS Transform Custom for modernization. Customer examples from Snowflake, Honeycomb, and SAP demonstrate 20-60% performance gains across diverse workloads including databases, web servers, and ML inference.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction to AWS Graviton: Custom Silicon for Price Performance and Sustainability

Hi, good afternoon. Just a reminder for you to wear your headsets, and please give me a thumbs up if you can hear me. Okay, awesome. Great, thanks. Welcome to CMP307, which is our breakout session today on how Graviton enables the best price performance for your AWS workloads. I'm Sudhir Raman, Director of Product Management at EC2 for Core Compute Products. Co-presenting with me today are Ali Saidi, VP and Distinguished Engineer at AWS, as well as our guest speaker for today, Thibaud Delor, Principal Engineer from Atlassian.

Super excited today to bring you a deep agenda where we're going to talk more about our Graviton journey, customer stories. We're going to dive deeper into our latest Graviton5 chip that we just announced a few hours ago today. Thibaud is going to walk through Atlassian's journey and the key practices and the best learnings from that, and we will cap this off with some of the knowledge base and the best practices for you to get started on your Graviton journey as well. So with that, let's just dive right into it.

At AWS, we've been building custom silicon for more than a decade. And this includes custom chips across multiple different areas spanning, for example, our Nitro chips, which are part of the overall AWS Nitro system that allows us to offload dedicated functions such as storage and networking to custom silicon and allows us to enhance performance, security, and maximize resource efficiency. We're also building custom chips to accelerate machine learning applications, so these are chips such as Inferentia and Trainium. And then we have powerful and efficient core compute infrastructure through Graviton-based servers.

So if we turn our attention to Graviton, why Graviton? There are two key value proposition areas for our customers. First, it delivers the best price performance for a broad array of workloads in Amazon EC2, so really helping you run your applications faster and lowering costs overall. And secondly, we find that a lot of our customers have goals towards lowering their overall carbon footprint and improving sustainability. And Graviton, with its energy efficiency benefits, allows our customers to make significant progress towards those goals.

So when viewed in aggregate today, we have more than 90,000 AWS customers that are running on Graviton. And these range from some of the hottest startups all the way to very well-established Fortune 500 enterprises. And our goal is to enable a deep and a broad portfolio of Graviton instance types so that our customers can choose the right instance for the right workload. And today we have over 300 Graviton-based instance types that are available globally at scale in over 38 AWS regions.

The Graviton Journey: Seven Years of Innovation and Customer Success Stories

And here's a look at our Graviton journey over the last seven years. So when the first chip came out in 2018, this was more about getting the overall software ecosystem up and running on the Arm64 architecture. And then one year later, Graviton2 came out and it opened up a whole array of general purpose applications to be able to run on Graviton. And our focus with each generation has been to improve the performance, push the boundaries on the capabilities, as well as the energy efficiency benefits that we can deliver with each iteration of the Graviton chip, along with also improving capabilities for certain specific workloads.

So with Graviton3 that delivered 25% higher performance per core over Graviton2, we also put in optimizations in there for certain compute-optimized workloads such as video encoding, CPU-based machine learning, as well as high performance computing. With the Graviton4 chip that came two years later, that built in 50% more cores per chip, and that opened up the whole array of scale-up workloads for our customers. So think of large databases, analytics, all of those scale-up workloads that could benefit from higher compute and more instances per core.

Which then brings us to the latest and greatest chip that we just announced earlier this morning, the Graviton5 chip, which is the most powerful and the most energy-efficient chip that we've built thus far. So we're going to talk more about that shortly. So just going back to the theme of enabling a broad and a deep portfolio for our customers across all their use cases, here is an example of our Graviton4 portfolio today. What you can see is that there are options available from 384 gigabytes of memory all the way up to 3 terabytes of memory for workloads that span compute, general purpose, and memory-optimized use cases.

If you have workloads that benefit from fast access to local instance storage, such as NVMe-attached instance types, we have a bunch of those as well. Some of them support a whopping 120 terabytes of local SSDs using Amazon SSDs. We realized customers have a diversity of workloads, so there are workloads that are more sensitive to I/O performance, such as those requiring more networking or more EBS, and we have instances for those applications as well.

Now if you look at the Graviton servers, in addition to a lot of the hardware components that go into these servers, AWS has also integrated and has full ownership of the firmware and the software that goes along with it. So this means that it's not just Graviton host CPUs in the server, but it's also our Nitro cards for EBS, for ENA, and the Amazon SSDs and the software that goes along with these Nitro cards and the Nitro Hypervisor. All of these come together, and that allows us to tailor these servers to deliver the best performance in the Amazon environment.

Now a most common customer question that comes up in several of my customer conversations is, what kind of workloads can run on Graviton? And the answer here is really, really simple. It's a wide range of general-purpose workloads that we see customers using Graviton for. Everything ranges from web applications to containerized microservices, all the way through large databases, analytics, CPU-based inference, as well as electronic design automation.

Now with over 90,000 AWS customers using Graviton, here is an example of some of the customer types that are using Graviton today. What you can see here is that customers across every geography and every vertical are drawing on the Graviton benefits. If you look at the top 100 EC2 customers, every single one of them today is drawing on Graviton. And if you expand that cohort to the top 1,000 EC2 customers, more than 98% of them are drawing on Graviton today.

Overall we've been hearing great feedback from customers on the cost and the performance improvements they're seeing, and here are some examples. With ClickHouse, they saw a 25 to 30% improvement on average across multiple query types, and in some cases up to 76% improvement in performance. FreshWorks, when they ran their Ruby on Rails applications and Java applications pretty seamlessly, saw a 23% improvement in average response time. And with Quora, when they migrated from Graviton3 to Graviton4, they saw about a 20% improvement in query serving times.

And it's not just about price performance. We're seeing a lot of customers benefit from the sustainability benefits of Graviton as well, and here are some examples. With Snowflake, they saw a 57% reduction in the carbon emissions per Snowflake virtual warehouse credit after moving to Graviton, while also enabling about 10% faster performance on average. And you can see a similar storyline with Adobe and JFrog here as well, where they were able to reduce their carbon footprint by up to 60%.

No conversation today is complete without talking about machine learning, given the AI/ML era that we are in. And we are seeing a lot of customers also deploy CPU-based machine learning applications on Graviton-based instance types. An example here is Mobileye. When they enabled their change detection system to run on Graviton instances, they saw up to a 2x improvement in overall performance. And you also have an example of Sprinklr where they ran their mixed inference and search workloads and achieved up to a 30% latency reduction along with up to a 30% cost savings.

And it's not just external customers, but we at Amazon are also employing Graviton at scale across a wide array of managed services. What you see here is that a wide set of Amazon database services, as well as some services like Amazon MSK, have a pretty significant deployment of Graviton today. For example, with Amazon Redshift Serverless, more than 90% of the current deployment is on Graviton. And outside AWS and even on the Amazon.com side, we've been using Graviton for some mission-critical events like Prime Day, where this year more than 40% of compute for Prime Day was powered by Graviton.

Graviton5 Architecture: Doubling Cores and Going Beyond Moore's Law

So with that background, I will turn it over to Ali Saidi to tell us more about the latest chip that we just launched today. Thank you, Sudhir.

Thank you, Sudhir. So let's talk a bit about Graviton 5. With Graviton 5, we are going beyond Moore's Law and doubling the number of cores that we have in our chip from Graviton 4 to Graviton 5. Each of these cores is doing about 25% higher performance, and we've built Graviton 5 in a 3 nanometer process.

Let's zoom into the pieces that make up this processor. We've talked a while about big workloads and how micro benchmarks are very different from big workloads and how we like to design for big workloads where we're not talking about small loops but really all the code and complexity of a real application like a database. This needs things like bigger branch predictors so you can process more instructions a cycle. With Graviton 5, we've adopted the Neoverse V3 core. It's an Armv9.2 core. It's got bigger branch predictors, it's got more advanced prefetchers, and it's generally a higher performing core.

Then we coupled that with our cache hierarchy. Optimizing a chip is a complex optimization problem of figuring out where you're going to put cache. You'd love to put it all as close to the processor as possible, but physics gets in the way. The L2 cache is great. When we went from Graviton 3 to Graviton 4, we doubled the size of the L2 cache to 2 megabytes. We've kept that here, but we've increased the size of the L3 cache. We've made it 5.3 times bigger than it was in Graviton 4. It's now 192 megabytes. In total, between the L2, the L3, and the L1 caches, we have around 600 megabytes of cache.

With Graviton, we've really tried to lead with DDR. This has meant working with DRAM vendors. Graviton 2 was the first system where we pushed to DDR5 3200. Graviton 3 was the first system we had with DDR5. With Graviton 5, we're working with DRAM vendors to get all the way up to DDR5 8800. We've also reduced the DRAM access latency in Graviton down to less than 100 nanoseconds. That's about 15% lower than it was before.

Graviton 5 also is the first CPU in our fleet to support PCIe Gen 6 with around half a terabyte a second of I/O connectivity. Now we've taken 96 or 192 cores and put them in one chip. In doing that, we've reduced NUMA latency that we had by about 33%. We've increased bandwidth substantially, but we're not getting rid of NUMA even though it's in one socket. We've decided to keep NUMA and offer two NUMA regions to reduce memory latency so that the cache and the DRAM controllers are closer to your cores.

So with all these pieces, we have the ingredients for our 9th generation of EC2 instances. The M9G instance that we're previewing today has industry leading performance, up to 25% better than Graviton 4. It's the most energy efficient CPU we've built, provides the best price performance in EC2, and provides us the same scale up capabilities that we had before.

Raising the Security Bar with Nitro Isolation Engine and Formal Verification

Now I'm going to spend a few minutes talking a bit about security. There are many things that a hypervisor has to do. It has to do scheduling, it has to do resource allocation, it has to do I/O. When virtualization started, it was really about packing many of your own workloads together. We've talked over the years about how Nitro is different. With Nitro, we've moved networking, storage, and management onto dedicated silicon. Nitro has many jobs to do, but the most important one is keeping customers isolated, isolated from each other and isolated from us. With the Nitro system, we have no operator access, and we enforce that with mechanisms, not with policies.

With our Nitro cards, we've been raising the bar in security with Graviton. With Graviton 2, we introduced DRAM encryption. With Graviton 4, we introduced PCIe encryption. We've taken the attestation that we had from our Nitro cards and Graviton 4 and moved it to also allow us to attest the CPU, the host CPUs that we have.

With Graviton 5, we're going one step further. The Nitro hypervisor is purpose built for one job, and it's an amazing hypervisor, but we constantly ask ourselves, can we raise the bar? So coupled with Graviton, we've been building another layer of technology to increase the transparency in our virtualization stack that we call the Nitro Isolation Engine. It sits between the Graviton CPU and the Nitro hypervisor. So what is it?

The Nitro Isolation Engine is really about compartmentalizing the most critical elements of interactions with instance memory, devices, and access control. There are two interesting things about it. The first is it's written in Rust, and Rust gives you a lot of memory safety and concurrency properties, which are really cool. But the second one is that formal verification was a part of this code base from the start. We started building this with software engineers working in tandem with some of our applied scientists in our automated reasoning group to formally specify how the software would work and what it could and couldn't do.

So what's formal verification? Let's take a simple function like this. It's got three inputs, and how can you be sure that it always works? Well, the easy way is you can try some test cases. You can try all zeros, you can try some ones, you can try maximums. But you can't exhaustively test it, even if you had a CPU that could do a billion tests a second and you had a billion CPUs, you'd still need more time than the age of the universe to exhaustively test this function.

So formal verification lets you mathematically prove that the function specification, adding numbers, matches the implementation. It's really about the application of mathematical logic and reasoning and the application of that to software systems. So you have a formal specification, and that formal specification tells you how it operates, what it can do, what it must do, what it must never do for all possible inputs in all reachable states.

For example, in the Nitro case of the Nitro Isolation Engine, it can create and manage VMs. It must preserve guest confidentiality and integrity, and it must never do things like null pointer dereferences or buffer overflows for all possible inputs in all possible states. So we've been proving functions, the core features of the Nitro Isolation Engine in the VM lifecycle, and showing that it has memory safety even in the places where you have unsafe Rust code. There aren't any runtime errors. There aren't unreachable panics or unwraps on none. There's no logical errors that the specification and the implementation match, and then there's no unauthorized information leakage that we have confidentiality and integrity.

Graviton5 Performance Results: From EDA Tools to Customer Workloads

And we're going to expand this to more and more parts of the system. Every M9G instance is going to have this enabled by default. We're going to be engaging customers on the formal verification aspects of this in the coming months. Okay, so let's talk a little bit about designing and building Graviton. One of the things that the engineers who are working on Graviton are most excited about is actually using a current generation of our processors to design the next generation.

And when we started this, that wasn't a possibility, but over the years we've seen EDA tool vendors begin to support EDA flows on Graviton. And today, Siemens Calibre is excited to announce support of Calibre on our Graviton systems. Calibre is the industry standard sign-off tool used by a majority of design companies. It's one of the most critical tools to run fast because it's coming at the end of the design process, and you're trying to iteratively solve all your issues and get to the point that you can start manufacturing the design.

And not only did Graviton4 show 20% higher performance and 30% cost reductions compared to the other instances that Siemens tested, they also saw an additional 30% performance boost when looking at Graviton5. So it's super exciting to see Calibre support coming to Graviton. For over a decade since the inception of Annapurna Labs, Synopsys and AWS have collaborated to enable AWS's custom silicon development, and so we're also excited to announce that Synopsys is expanding support for their EDA tools on Graviton like VCS, PrimeTime, and Fusion Compiler, where they saw 35 to 40% improvements in performance with Graviton5.

So let's dive into some of the other performance cases for other workloads. Sudhir mentioned machine learning customers, customers like Sprinklr and Mobileye, and so taking a variety of CPU-based ML workloads and running them on our deep learning containers with Graviton5, we see a 35% improvement in performance on PyTorch. We also have companies who run Java apps, and so we've taken a Groovy Grails app, and Grails is an open source web application framework and tried it on an M8G Graviton4-based system and an M9G Graviton5-based system.

Using Wrk to generate load against the web server, we see a 32% increase in requests per second. One of our big focuses has been on large workloads, and while microservices are great, there still are monoliths in the world. We don't have a really good open source example here, but we took a large internal piece of code that does delivery planning and tried that on Graviton5 M9G instances. Here we saw a 47% performance increase.

We've also looked at NGINX. NGINX is a popular web server. It can also be a load balancer, and we've configured it as a load balancer in this case. Fixing the load generator, fixing a set of web servers, and changing the instance in the middle from a Graviton4 or a Graviton5, we see a 27% improvement in performance generation over generation.

Lastly, we've looked at databases, and one we've looked at is MySQL. We've used HammerDB to mimic load against this. HammerDB mimics a company that sells items, keeps stock, has warehouses, receives orders, and measures performance in new orders per minute. Here too, comparing a Graviton4-based M8G to a Graviton5-based M9G, we see a 40% improvement in performance. Now these are the workloads that we've run. I think the far more interesting ones are the workloads that other people have run, and over the last couple of weeks, a few customers have been running on Graviton5.

Snowflake has been running their virtual data warehouses on Graviton since Graviton2. They recently tried an M9G instance and found that they saw more than 30% higher performance in that instance type. Honeycomb has also been using Graviton since Graviton2. They provide end-to-end observability software, and they were super excited to try M9G. Out of the box, they saw 20 to 25% lower latency. And then as they kept latency fixed and just started to crank down the amount of CPU they were giving the workload, they saw 36% better throughput for the same latency.

Airbnb has also been testing our M9G instances, and they found they were some of the fastest instances they've tested in EC2, including 25% higher performance than the other instances they tested. And lastly, SAP has been running HANA Cloud on Graviton, and they found a stunning 35 to 60% performance increase in some of the OLTP workloads that they think are typical of HANA Cloud development.

So with this, we have performance that varies with the workloads we looked at between 27 and 47%, and what customers have told us, which varies from 20% to nearly as much as 60%. So now I'd like to hand it over to Thibaud from Atlassian to talk about his experience with Graviton. Thank you.

Atlassian's Graviton Journey: From Failed Attempts to 30% Cost Savings

Thank you, Eli. I'm Thibaud Delors, Principal Engineer for Atlassian. In Atlassian, my main focus is cost efficiency, and we went through the Graviton journey, and I'm here to explain how we went about it and what kind of results we saw. A bit of context of who we are and what we are doing in Atlassian. We have the Atlassian Cloud Platform. You probably know some of our products like Jira, which is the issue tracker, Confluence for collaboration, Bitbucket, Trello. All those tools are now integrated in our cloud platform and powered by our AI Rovo.

On our platform, we have customers from small to large, like Roblox, Amadeus, and Reddit. All those customers are on our platform, like I was saying, and we are heavily relying on EC2. We have tens of thousands of EC2 instances, 3,000 services from big to small across 15 regions to support 300,000 customers, more than that actually. We have a sharded infrastructure, so that means that for one given customer, we usually associate them to a shard in a specific region, and they are sharing a shard with other customers, but we have many, many shards across the globe.

So why did we look at Graviton? I'm doing cost efficiency. One of the easiest ways to do cost efficiency is to look at the CPU because it can give you the best price-to-performance ratio.

We were looking at all CPUs, not just Graviton, so Intel, AMD, and Graviton, and we were looking for lower CPU utilization for the same throughput. Additionally, Atlassian is committed to reducing our energy footprint, so we were looking at reducing our carbon footprint.

Here it's a bit more specific to our big products, Jira and Confluence. We have three of the biggest workloads: the web servers, the workers, and the databases. On the web server side, it's a Java 17 app at pretty big scale on CPU through an Auto Scaling Group, and it's very latency sensitive, so we really care about performance and we can't have performance degradation from a CPU upgrade or something like that. On the worker side, it's a bit more flexible as we care more about throughput, but it's the same code base as the web server, so that means that if we migrate one, we usually migrate the other. It scales on queue length rather than CPU percentage. And we have the databases. We are on Aurora Postgres. We are using replicas, and usually we are only scaling during the peak hours, so about ten hours a day we would scale our replicas, but the rest of the time we are at just one replica.

We have this motto in Atlassian which is if you can make it happen for Jira, you can make it happen for everything. So we started with Jira and the web server, so that was really the hard part of adopting Graviton.

This is a journey that started two years ago, and we had a failed attempt. What we tried to do was just migrate from Intel to Graviton 3, which at the time was the latest and was beginning to be available. We did some tests in our environment. We migrated up to ARM, and it was looking good until we went to production. When we went to production, we started to see regression, so obviously we missed something in our tests. Looking at all the flame graphs and the performance, it was really looking like concurrency was the problem at the CPU level, but we didn't know much more than that. We were trying to fix the code to be more performant with Graviton, but without much success, so we stopped the project. That's basically six months of trying to adopt Graviton where we were saying it doesn't look like it's working for us, which is weird because we've heard all those stories of where it works. Why it wasn't working for us was still a mystery, but we stopped that.

Until Graviton 4. For Graviton 4, we were basically saying we shouldn't repeat the same mistake. We're going to engage AWS and some experts to have recommendations on how we should test and what we should be doing and making sure that we understand our regression. So the first thing is no more micro-benchmarking. There's no point in just testing one endpoint for latency because what we noticed is that in production, that's not what you're going to see, so those signals are useless. No passive benchmarking, which means that during our test environment, instead of running our usual performance test suite and looking at the result, we will try to have an acceptance criteria and clear metrics of whether it's good or not. This clear metric was throughput at breaking latency. So what we did is put some load tests on the web server, see where the latency is starting to become unacceptable, and measure the throughput at this point, and that would give us a good idea of how performant the CPU is. And also digging into the low level of the processor. ARM has some Performance Monitoring Units that you can observe and check what is the bottleneck on the CPU. What we found is Graviton 4 basically smashed all the results.

It was outperforming C6I, which was our preferred previous instance, and also C7G by far.

One of the key indicators of what was correlating with performance was L3 cache misses. We saw that the more cache misses there were, the worse the performance was, which makes sense, but it was a really good reflection of performance. That can be explained by the fact that from Graviton 3 to Graviton 4, it went from 1 megabyte to 2 megabytes of L2 cache, and that was what was making the difference here. Compared to Intel, that was the same thing. In terms of L2 and L3 cache, Graviton had more, and so we saw better performance.

We also saw that the translation lookaside buffer, the table work, was reduced on Graviton 4, which basically means that it was using memory a bit better. That's really specific to Java, and the conclusion of that is that we should enable THP, which is transparent huge pages, to try to have better usage of the memory with the system. So the result of that is on C6I. Compared to C6I, which was really our baseline and what we were happy with, Graviton 4 with THP enabled was 32% faster. On the other hand, Graviton 3 was a bit slower.

So what was the decision here? For web servers, we would be using Graviton 4. We always use also a fallback instance in case there is no capacity, and we decided that Graviton 4 would be the main CPU and C6I as the fallback. For workers, it's a bit more flexible because we were not looking at latency, we were looking at throughput and cost efficiency. In that instance, C7G was the most cost efficient one. So what we decided is we're still going to try to go for Graviton 4 for the workers but fall back to Graviton 3 instead of Intel for the workers.

How did we roll that out? So for the web servers, when you want to have Graviton with Intel as a fallback, you have to use this pattern, which is a very well documented pattern on the AWS website, which is to use multiple launch templates on your Auto Scaling Group. So you basically need two images, one for ARM, one for Intel, and then you can have a fallback between ARM and Intel. So that's what we had to implement for web servers. For async workers, much simpler. Usually in a scaling group, you can have several fallback instances without having several launch templates, and so we were falling back to C7G. We ported all of CI/CD to ARM.

And we deployed. The observed result in production was a throughput increase of 30%, latency reduction of 12%, and a cost reduction of 25%. So 25% for Jira and Confluence, that's a lot of money. So on this success, we decided to expand to the rest of Atlassian. Actually, Confluence and Jira Confluence databases started a bit earlier, and we migrated all our instances to Graviton, and it was very smooth, very easy. We went from R5 to R6G to R7G to R8G, and every time we saw a gain, especially in R6G, which was the first Graviton option. We saw a big cost reduction, and then every time we saw better performance.

So we have more than 3,000 database clusters in production. They also went through PG 13 and PG 17, and every time we were doing those upgrades, we were always comparing whether Graviton was still the best option, and every time it was the best option. I want to highlight that cost efficiency depends on how you deploy your app. At Atlassian, we are pretty efficient in terms of we know when to downgrade, downsize the database. We know how to use read replicas.

That's why we are seeing really good cost savings, because we are doing the right things. If you are just switching from one instance to another instance but you don't do anything beyond that, you don't change your replica strategy or you don't downsize, then you might not see cost benefits. You have to be efficient to make those cost savings.

We also migrated Jira, so Jira, as I was saying, JSM, Confluence, and several other products are following, including our Edge. Roughly in one year we went from 5% adoption of Graviton within Atlassian to more than 30%, and also significant savings out of that. Thanks to a collaboration with AWS, we were able to test Graviton5, and it's very promising. What we believe is the reason for such an improvement, so the 30% throughput improvement, is as I was saying before, L3 cache is very related to our performance because we are a Java shop pretty much. Graviton5 increased the L3 cache, so not so surprising, but really good news for us, and we are super excited to try Graviton5 in production. Thank you very much.

Best Practices for Transitioning to Graviton: Tools, Partners, and Migration Strategies

Great. Thank you, Thibo, for those great insights. So let's shift gears now into talking about some of the best practices for transitioning to Graviton and what are some of the tools available to do that. So starting with the building blocks, across the Linux community there's broad support for Arm64 out of the box. Whether you're using commercial distributions or using community distributions, you can find Arm64 out of the box Amazon Machine Images that are available for you to deploy.

Using containerized workloads, there's also a lot of good news in that space. There's broad support for Graviton across all the key container areas, so that includes Docker and Kubernetes themselves, as well as our own AWS managed services such as ECS and EKS. There's also support across multiple container registries for Arm64 in addition to multi-architecture support, so you can build container images for x86 and Arm64 and have the right image deployed automatically based on the underlying architecture. And a similar story across the DevOps landscape, so all the popular CI/CD tools and software include support for Graviton out of the box. That's whether it's fully managed, self-managed, or hybrid deployments.

In terms of partners, we find a lot of customers use third-party software for various needs, be it logging software, monitoring, security, and things like that. What we've done is that we've created over the last few years a Graviton partner program where we worked with many of these third-party ISVs to enable support on Graviton, and a lot of the software companies here have tested, validated, and optimized their software. This then makes it really easy for customers to discover these solutions. Here's a snapshot of what we currently offer, and since this list is rapidly changing, we highly recommend you check the Graviton web page for the latest and greatest.

While you can obviously deploy your workloads on Graviton-based instances on EC2, we've also extended the price performance benefits of Graviton to our various AWS managed services. This gives you the most seamless path to using Graviton, and in many cases it's simply an instance name switch and you're up and running, and a lot of the heavy lifting of the architecture is handled for you under the hood. All the popular services across compute, databases, analytics, as well as machine learning support Graviton-based instances today.

Now this is a very common question that we deal with in a lot of customer conversations, which is around what is the effort involved in moving to Graviton and how should we think about that. Here is a basic framework that we provided as a starting point, and as I said, the most seamless way is going to be to use a managed service. If you're using applications that are interpreted languages, say Java or Node.js, PHP, Ruby, all of those pretty seamlessly work out of the box.

In many cases, we have many customers who have moved to ARM64 and Graviton very easily. If you're using compiled languages like C, C++, or Golang, those applications would need to be recompiled for the ARM architecture. But the good news here is that all the major popular compilers will allow you to do that really easily, and we have many success stories of customers that have moved these applications. Finally, in the some work, high reward category, comes applications such as .NET, which you can modernize to Linux, and then that puts you on an accelerated path to getting to ARM64 and Graviton as well.

So some more steps in terms of how you can start thinking about this journey. The first and foremost area that I would highly recommend is getting started with our technical guide on GitHub. This really provides a lot of good examples and use cases broken down by applications and languages that allows you to get the best out of the Graviton platform and the tunings for these applications. Secondly, inventory your software stacks, so really understanding what OS images you're using. As a general rule, the more current your software, the easier it is to adopt on Graviton. Take a look at those container images and understand dependencies and pull the right ARM images.

Unit and functional tests as part of your testing efforts are going to be important, and in some cases you might have to write new tests like Atlassian just described. We have a lot of tools that can actually help you do that, including Amazon Q Developer, AWS Transform, as well as a new tool that we just announced earlier this week, which is AWS Transform Custom. Finally, measuring performance is important, and again we have some QR codes there. We have a tool called APERF that's available for you to profile some of your applications and really understand where the bottlenecks are.

Getting Started with Graviton: Resources and Next Steps

We see a lot of customers deploy on Graviton using canary or blue-green deployments where once you have production traffic and you have both clusters, you start redirecting a small portion of that traffic to an ARM production cluster on Graviton, and then you can turn the knob based on the performance that you observe. Just talking more about the Transform Custom that we just announced earlier in the week, this is a capability where through modern agentic AI agent applications, it really allows you to crush your tech debt. Specifically in the case of Graviton, there's an early access program available, for example, on Java applications where in most cases it works out of the box. If you're not sure about the versions or you have some native applications coded there that are dependent on a certain language, then this gives you a chance to identify and modernize those very quickly.

So net-net, here's the takeaway of all the resources that are available. The first and foremost one that I would highly encourage and recommend bookmarking is the Graviton Technical Guide. We also offer a free trial with the T4G instances that gives you up to 750 hours to jumpstart your Graviton journey. We have the links to both the Amazon Q Developer and the Transform capabilities. Finally, there's the Graviton Savings Dashboard that helps you to provide a view of the savings that you can accrue based on your workloads that have moved to Graviton.

Here's a link if you want to try out Graviton5 and MGG since that's currently in preview. We really encourage you to sign up, and we really hope many of you will get started on your Graviton journey, if not already. It's really surprising what customers have been able to do with just one engineer in one week and with one application. With that, I just want to thank you for your time, making time to attend the session today. We really appreciate it and hope you continue to have a great re:Invent, and please do take a moment to complete the session survey in the mobile app. Thank you.

---

; This article is entirely auto-generated using Amazon Bedrock.