Amazon Elasticsearch Service: Is it as Good as a Standalone Installation?

Just a month ago, AWS launched their Amazon Elasticsearch Service. Elasticsearch itself is an open source scalable, distributed, real-time search and analytics engine from Elastic, the creators of Logstash, Beats, and Kibana. Elasticsearch makes an excellent alternative to Splunk.
According to AWS Elasticsearch documentation:
“Amazon Elasticsearch Service (Amazon ES) is a managed service that makes it easy to deploy, operate, and scale Elasticsearch in the AWS cloud…You can set up and configure your Amazon Elasticsearch cluster in minutes from the AWS Management Console. Amazon ES provisions all the resources for your cluster and launches it…Amazon ES allows you to easily scale your cluster via a single API call or a few clicks in the AWS Management Console.”
According to their documentation, the Amazon Elasticsearch Service provides the following features:
Amazon Elasticsearch currently uses following package versions:
/_alias, /_aliases, /_all, /_analyze, /_bulk, /_cat, /_cluster/health, /_cluster/settings, /_cluster/stats, /_count, /_flush, /_mapping, /_mget, /_msearch, /_nodes, /_plugin/kibana, /_plugin/kibana3, /_percolate, /_refresh, /_search, /_snapshot, /_stats, /status, /_template
Amazon Elasticsearch: limits
Amazon Elasticsearch has a few built-in limitations which you need to be aware of before you start:
Elasticsearch 1.5.2 – the version used by Amazon – is actually quite old when compared with the current stable version is (1.7.2). And Elasticsearch 2.0.0 beta, which is just around the corner, will address many more bugs. Since Amazon Elasticsearch is a managed service, there is no way for you to upgrade your clusters on your own. If you were to host Elasticsearch yourself, upgrades would be as simple as updating the jar files in ES_HOME/lib folder.
In the release notes to Elasticsearch 1.7.1, more than a dozen bugs are identified as fixed. Users are advised to upgrade their clusters as soon as possible. Here are just a couple of examples:
IP range aggregation issue:
ip_range aggregation with mask of 0.0.0.0/0 gets treated as 0.0.0.0/32. This was resolved with the 1.7.x release.
Data-loss issue:
Elasticsearch 1.7.x has addressed many problems from 1.5.2, including one which could result in the loss of an entire index if you suffer a multiple node failure while having idle shards. This might be a particularly serious concern with a cloud setup, where node failures due to Availability Zone outages are not uncommon. Although these are rare cases, Elasticsearch Support did send this email alert to their customers:
https://cloudacademy.com/quiz/study/565f2965668ad11bc7e856b5/
You can attach a maximum of 512 GB of storage to a single I or R series node (i2.2xlarge, r3.8xlarge etc). For M series nodes, however, you are limited to a maximum of 100 GBs. Besides the fact that I and R series nodes are expensive, they only come as large, instance-store volumes. This is an obvious problem if you intend to shut down, and then reuse your Elasticsearch cluster at some future time.
There are two major limitations with the instance types available for Amazon Elasticsearch. The first is that you can only run a maximum of ten instances per cluster. If you want more, you’ll have to submit a service request for an increase. The second problem concerns node memory. Here’s what Elasticsearch’s documentation says:
“A machine with 64 GB of RAM is the ideal sweet spot, but 32 GB and 16 GB machines are also common. Less than 8 GB tends to be counterproductive (you end up needing many, many small machines)”.
Seeing how AWS offers us r3.2xlarge instances (and higher) and i2.2xlarge, fits nicely with Elastic’s ideal for cluster nodes, but they will be very expensive. An EC2 r3.8xlarge on-demand RHEL instance costs $2.903 per hour, and the r3.8xlarge.elasticsearch will cost you $4.704 per hour!
Elasticsearch has released many commercial products: Shield for security, Watcher for alerts and notifications, and Marvel for cluster monitoring. They are really useful and come out-of-box with Elasticsearch. There are many such plugins, like Sense, kopf, and river, that were developed for Elasticsearch administrators and developers. You can certainly use AWS’s IAM and Cloudwatch in place of Shield and Marvel, but choosing those will sometimes add extra costs and often new skills. If you already have Shield, Watcher, and Marvel licenses, and you’re just moving your existing Elasticsearch cluster to Amazon, then those licenses will be of no use.
River plugins are helpful for supporting data migration from a source to an Elasticsearch cluster (like MongoDB River and jdbc River). Again, not all of those are available for Amazon Elasticsearch installations.
Perhaps surprisingly, Amazon Elasticsearch is hardly overwhelming. It certainly looks nice, but it comes with a very basic tool kit and, as we’ve seen, lacks access to some fairly critical features. In my opinion, Amazon Elasticsearch does deliver an agile offering with faster cluster set up and automated snapshot and restore process, but it is not yet cost-effective.
Setting up Elasticsearch on your own VM (including EC2 instances) is not at all difficult. You can decompress the zip or tar files and, with a minimum of administration knowledge, make the light modifications to the elasticsearch.yml file. You’ll have your cluster up and running in minutes. With your own setup, you have more control over your cluster. You can change the parameters and reconcile your cluster with releases from Elasticsearch.
However, this is Amazon, and this is just a 1.0 release. We can certainly expect to see something significantly more robust in the coming months.