If you're considering using a Graviton-based instance type (i.e., one with a "g" at the end of the first part of the name, just before the ".") for a managed service such as RDS or OpenSearch, then go for it - this is a good way to save money without much risk, since Amazon handles the underlying operating system & application compatibility. However, if you're considering it for use in EC2, then read on... …
AWS Graviton instances are appealing because they can deliver a significant price/performance advantage over their more traditional counterparts. However, there are some trade-offs to keep in mind when using it in EC2.
Unlike AMD-based instance types (i.e., types with an "a" at the end of the first part of the name, just before the "."), which support the same x86 instruction set as the more expensive/common Intel-based instances (some newer Intel instance types can be identified by an "i" at the end of the first part of the name, just before the ".", but others simply end in a number such as "t3"), Graviton-based instances run on the very different Arm instruction set. As a result, you'll likely need to do additional work in recompiling/packaging apps to run on this different architecture. (Though, how much depends on the language. For example, Java, NodeJS, and .NET Core require no real modifications, Python needs some attention, while Golang or C need to be completely recompiled.)
To use Graviton instances you will need to run on images that are built specifically for Graviton/Arm, and you must ensure the runtimes & tools you add all support Arm (most do). Because of all of this, changing from an Intel-based instance type to a Graviton-based instance is not as quick & easy as changing an instance type from Intel to AMD would be.
Note that although Microsoft has released some Arm-compatible versions of Windows & Office, I've heard mixed reviews about their performance, and if you're in a large company, you'll want to check that these versions are covered by your license agreement before using them!
When it comes to containers, these aren't interchangeable between instance/processor types either. Even if the code you're running is something easy to work with like Java, it will still rely on a JVM installed on the container which must be Arm-compatible.
If none of that scared you off, then some particularly good use cases to consider for these chips is web servers, log processing, video encoding, and CPU-based ML. Another point in Graviton's column is they consume less power and produce less heat with roughly similar performance levels, so in addition to being cheaper, they're better for the environment.
All that being said, don't approach a change to Graviton-based instance types as the solution to all of your EC2 cost woes. Keep in mind that in general, much more money can be saved by simply shutting down instances at times/days when they aren't being used, or decommissioning them entirely. You can also eliminate instance cost by moving to serverless options, or running apps on SaaS alternatives. Graviton is just a small part of a well-rounded cost-cutting diet.