Help with usage scenario

I need some help with how to use elastic tools in production.

Over the last two weeks I have been implementing elastic search to index a list of exercises for a physiotherapy mobile application. The index is approx 2MB (3000 exercises)and I cannot imagine this growing to many more than 3000 (5MB) for a year or two.

The app uses Parse.com as its backend for user auth management however it doesn’t allow for search (no where close to elastic anyway!). I have some questions on getting this production deployment right first time.

Question 1
Security - because my users are authenticated on a separate server than my elastic search node is it possible to lock down my index to read only without having to do any complex security ngix setup etc? Because my app is packaged the url will be stored and unable to be seen by the users? If the API is locked down to read only then I think that this security through obscurity might be enough?
If not advised how do I go about user authentication when my users are managed by Parse.com

Question 2
How much server ‘grunt’ (memory, cpu etc) do I need for this index size? Our simultaneous usage is not going to be huge, nothing more than 5 requests per second.

Question 3
It seems the found.no has everything I need however its seems a bit overkill and costs too much money for us starting out. Although I am concerned about going it alone as there is a lack of support around the subject of Elastic Search for some reason. Although if I got up and running on EC2 or Digital Ocean it doesn’t seem like there will be that much upkeep once I have the first two questions sorted out.

Your cluster is wide open unless you (1) put it behind a proxy of some sort or (2) install Shield, which is a paid product.

The Nginx configuration needed to essentially only allow access to the _search end point should be very simple and worth the effort.

With such a small index and such a tiny throughput you should be able to get by with the smallest server imaginable. I'll bet a t2.micro would be fine.