Is ElasticSearch on Azure vs the new Azure Search Service more cost-effective? [closed]

Question

A current application with roughly 2M records is running on AWS with search functionality provided by the FullText search capabilities of SQL Server.

In upgrading the system, the new architecture will reside in Azure Web and Worker roles, however the repository store for user accounts, etc., and search capabilities is what this question is about, as there is no SQL Azure FullText search capability.

My initial inclination was to install ElasticSearch on an Azure Linux VM (used as the central store for user accounts and search), using ElasticSearch.Net or NEST (most-likely the latter) for .Net to ES communication, and pay for each virtual server and data in/out. The issue is that I believe the recommended RAM for ES is around 28 gigs, which would be a pretty expensive VM on Azure.

However with the launch of Azure Search Service it's still a bit pricey for just starting out (yes, over 10K records). In the Azure Portal:

Since Azure Search uses ES under the hood, I'm not questioning performance of one over the other.

Has anyone done a more detailed cost analysis of using the new Azure Search service, vs setting up a cluster of ES servers on Azure, and which is the most cost-effective?

Rickrack

I'm voting to close this question as off-topic because questions about specific web services and their features have their own site: webapps.stackexchange.com – Teniers

An application with 2 million documents is very unlikely to need 28GB of memory, depending on what features in elasticsearch you use you should be able to get by with much much lower then that. – Lys

It's probably worth pointing out that you're not comparing like with like here - Azure Search may have ES under the hood, but that's almost coincidental. Azure Search is an abstraction with a very different API that doesn't work with NEST. It does at least save you the hassle of having to manage the infrastructure, but this comes at a considerable price. – Unideaed

28GB of memory sounds way too high. I have an application indexing scientific metadata, and we store/search nearly 3 million records on a 4GB box. I recommend you load up some data and test your performance, you can probably use a much smaller box than you think. – Flyn

Why not Elastic Cloud? You get the best support. – Elvyn

I'm voting to close this question as off-topic because it is not actually a programming question. – Scala