AWS Elasticsearch was one of the last services which didn't support VPC until late 2017 [1], moreover if you had created a cluster without VPC support the migration is very cumbersome and application changes (to enable double writes) are required to execute it without any downtime [2].
Not to mention it's a massive pain to use elastic search with serverless... Especially if you want it in a private VPC. Adding ES raised our monthly bill significantly since it required also adding a NAT gateway (which then double-dips data transfer charges, actual bandwidth out and NAT processed data), the cost was replicated across multiple "States" (Dev/test/prod), and increased cold start times (below they did work to optimize that) since the lambdas accessing ES needed to be in the VPC too.
I can see developers crunched for time (or businesses, money) not taking the additional steps to get there... And this is the same deal for Redis/memcache, which is another reason I think we see those exposed sometimes too.
(To be clear, the additional costs are minor compared to a big business budget, they would be more detrimental to a low (~<400/month) budget project .. or a team that can't dedicate 300-600 man hours to implement this)
I can see developers crunched for time (or businesses, money) not taking the additional steps to get there... And this is the same deal for Redis/memcache, which is another reason I think we see those exposed sometimes too.
(To be clear, the additional costs are minor compared to a big business budget, they would be more detrimental to a low (~<400/month) budget project .. or a team that can't dedicate 300-600 man hours to implement this)