Amplify-cli: @searchable Cost

[karrettgelley]

* Which Category is your question related to? *
ElasticSearch

* What AWS Services are you utilizing? *
ElasticSearch, AppSync, Cognito, etc.

I recently got a bill for ~$75 for an elasticsearch instance which I barely use.

I have an app that is in development and I have a User model which has @searchable enabled. I barely use the elasticsearch instance and I'm wondering if anyone else has had a similar experience. Does anyone use @searchable in production? And if so, does it account for the majority of your aws bills? It seems to me that this is a ridiculously high price for a non-production scenario, and I'm wondering how much the cost increases in production. I like the @searchable feature, but it's unusable if it will negate any profit I might make from an app.

[renebrandel]

Hi - I've notified the AWS support team of this and they are happy to look into it. Can you open a new support case and DM me on Twitter your case number? We can dig into this further then.

[karrettgelley]

@brene Thanks. Check your inbox

[Blkc]

Unfortunately @searchable directive is not really serverless as you are basically running a search instance. It is the bulk of my bill as well.

[hisham]

So @searchable will spin up a separate EC2 instance for each dev environment and keep them running? That's going to rack up the bill unnecessarily on a team with multiple devs...

[Blkc]

@hisham Yes that seems to be the case. Increasing the # of nodes on the elastic domain will also spin up new servers.

[hisham]

Can the nodes be manually set to 0 when a dev doesn't need their dev environment? (spin down the ec2 instance but keep the ebs block..). Can a dev just manually turn on and off the ec2 instances as they need it?

[Blkc]

I am pretty sure you cannot control the instances (ie. they are not exposed on EC2). If you are concerned about the cost for now you can just remove the @searchable directive and push when you don't need it and vise versa.

[GeorgeBellTMH]

A solution would be to add some config options to @searchable for example useEndpoint (or maybe useInstance) could use a shared ec2 instance and create separate tables for each environment tableName-{env}.

Another solution would be to have a file in the API folder searchConfig.json where you could specify instance/endpoints for each environment (more flexible). This would allow one large instance for all environments, or two with one for prod and one for all dev environments.

[hisham]

@GeorgeBellTMH's proposal sounds interesting. @renebrandel I would consider re-opening this issue as a feature request to allow more options to configure the @searchable instance to point to one instance that has multiple tables per env. Unless there's a severless version of Elasticsearch coming in the pipeline...