What Amazon is doing is to essentially encrypt at the disk layer. The equivalent on your own VM would be to use an encrypted disk that is mounted into your VM in some way as your data store. There are a lot of ways to accomplish this, but none are specific to OpenSearch. What works best for you probably depends on whether or not you control the underlying host machine and its disk or not.
But there are other ways to protect data in OpenSearch regardless of where or how it’s hosted. The encryption discussed in your linked article and what I’m talking about above is all in the category of transparent disk encryption. This is important and useful for protecting data from stolen media attacks. That is, if a disk goes bad and someone tosses it in a dumpster or if someone gets into your datacenter and pulls a disk out of a server. Because shredding disks is expensive and encrypting them is cheap, it’s just a better way to manage the media lifecycle.
But if you’re hoping to protect the data on a server that’s running 24/7 and to keep that data protected from hackers or even from curious or malicious administrators, then you need to think about an application-layer encryption (ALE) solution where data is encrypted before it’s sent to the data store (OpenSearch in this case, but the concept of ALE is broader).
There are a few companies that offer solutions to encrypt data (or select data slices) before it goes to the search service and my company, IronCore Labs, makes one of them. Our solution is called Cloaked Search and it functions as a proxy that intercepts index and search requests. There’s a recorded webinar that covers how we do this, what it does and doesn’t defend against, and why it might be useful over here, if you’re interested in learning more: How to Secure Your Sensitive Data in Elasticsearch and OpenSearch - Crowdcast