awslabs/fhir-works-on-aws-deployment

OpenSearch cost

jayallenmn opened this issue · 5 comments

jayallenmn commented

All,

We've been using FHIR works for a few months now and it's working well. However, the cost is a problem, specifically the cost of the OpenSearch service. It looks like most of the OpenSearch cost is due to the ec2 instances used - c6g.large.search and m6g.large.search. We have a dev environment (c6) and prod environment (m6) so dev is a little more affordable but both are expensive. Can we deploy to other instances to reduce the cost? Alternatively, because we're just mainly putting and getting patient data is there a way to turn off the OpenSearch service, is it critical to the operation of these APIs?

Jay

ssvegaraju commented

Hi @jayallenmn,

We currently use Graviton2 instances of OpenSearch to optimize the price to performance ratio, hence the c6g and m6g instances. However, it is certainly possible to adjust the instances to one of the more affordable types such as t3.small without affecting the functionality of FWoA by updating the mappings here. For your use case of of just getting and putting patient data, it may work to turn off OpenSearch as the only relevance there would be updating the cluster with the new resource data from the PUT in the ddbToEs Lambda Function (GETs directly interface with DDB), however it would require code modification on your end. Hope this helps!

Thanks,
Sukeerth

jayallenmn commented

Hey Sukeerth,

Thanks for the quick reply and the suggestions. Is there a way to update just the search instances to smaller types without creating a new installation?

Jay

ssvegaraju commented

Yup! You can navigate to the Amazon OpenSearch Service page on the AWS Console in the region you've deployed, and under the Cluster Configuration tab, you can click Edit to change the instance type. This may cause some downtime in the service as a heads up, as any updates that are queued from DDB to OpenSearch during this time may be lost depending on load.

Thanks,
Sukeerth

jayallenmn commented

Sukeerth,

Thanks, that pointer helped a lot. Now we understand exactly where the costs are coming from - our production OpenSearch service. If we stay with two AZs with two nodes in each AZ (I assume for HA in each zone), would we be OK with t3.small.search until we need to scale up? We'd also want to use t3.small.search for our 3 dedicated master nodes. Doing both would reduce our monthly production cost by 70%. We'd scale them back up as usage went up.

Jay

ssvegaraju commented

Yup, that should work fine! FHIR Works used to use t3.medium as the small size instance type before implementing support for Graviton2 instances, so I don't see any problem with using t3.small and scaling up as needed.

Thanks,
Sukeerth

  • 👍1