I highly recommend you show your lead/management these two articles, then ask if they want to proceed:

https://spun.io/2019/10/10/aws-elasticsearch-a-fundamentally...

https://code972.com/blog/2017/12/why-you-shouldnt-use-aws-el...

Before going any further, take a _really close look_ at https://docs.aws.amazon.com/elasticsearch-service/latest/dev...

Make darn well sure you aren't using any unsupported operations.

In their favor, if I were to revisit them I could use it now; however in the past they didn't support templates and a few other things which turned out to be major blockers.

We moved in the early days. Today, we are fairly advanced with regards to our understanding of the internals of Elasticsearch - data nodes, master nodes, indexing, shards, replication strategy and query performance. In hindsight, it would be fair to say that we have been extremely happy with our choice given our limited understanding of running a production scale Elasticsearch cluster 6 months back. With Amazon Elasticsearch we were able to start small, move fast, learn on the go, and fine-tune our cluster for production workloads without having to understand every single aspect of managing and scaling a production scale Elasticsearch cluster.

More details here - https://www.akshaysurve.com/2018/01/what-we-like-about-amazo...

In typically AWS managed fashion:

If you want to get it set up and running most of the way without tuning a bunch of stuff it’s pretty good.

It also has significant cost overhead compared to self-managed and limited instance types.

My team now is working on migrating a 2.3 cluster from AWS ES to a 7.8 self-managed cluster (probably 7.9 now I guess). We do lots of indexing throughout the day and the i3 instances available are pretty weak, just switching to r5d/r6gd instances greatly reduced our indexing and search latency