Amazon OpenSearch Service Reviews

Amazon OpenSearch Service is a user-friendly version of Elasticsearch, as per my understanding. I have been using it for our volunteer management system where around 5,000 to 6,000 users are using this product. Amazon OpenSearch Service is used for keeping unstructured data, such as the information of our users who are logging in, logging out, and performing actions. We are keeping the events in Amazon OpenSearch Service, AWS OpenSearch. In my earlier company at Rakuten Viki solution, we used Elasticsearch for two purposes. First, we used it for keeping the logs of our application as a sidecar pattern. Second, we used it for keeping our products' names and metadata for text and setting functionalities.

I use it for keeping our users' events. Whenever a user is logging in, whenever they're clicking on any specific button, or doing any specific function in our application, which is basically the volunteer management system, we're keeping all this event data in Amazon OpenSearch Service.

I found it a bit easier to work with the documentation and also the APIs they provide, as those are interactive. It's actually easier to collaborate since it is already deployed in the AWS cloud itself.

Since Amazon OpenSearch Service is an integrated service in AWS itself, we can hop between the AWS CloudTrail or any other logging service of AWS, but definitely Amazon OpenSearch Service provides us some analytics which is really helpful.

In our application, it is one of the components. For example, we are keeping some data in Amazon OpenSearch Service, and based on this Amazon OpenSearch Service data searching, we are also updating in our data ingestion service. Also, we are storing the same data in a modified version in another system, Amazon RDS with PostgreSQL or similar RDS itself. Therefore, we are keeping the connection between Amazon OpenSearch Service and other AWS services.

Amazon OpenSearch Service is not providing the processing feature directly. From Amazon OpenSearch Service, we are actually maintaining the AWS SQS, the queue service, which is responsible for providing information about what data has to be modified. So using that SQS, we're actually providing it, but we're not directly using Amazon OpenSearch Service for keeping data to other data pipeline thing.

So far we didn't use it for any machine learning purposes, but in future, we have plans to extend or implement this feature.

Since AWS itself is secure and Amazon OpenSearch Service is a part of this entire ecosystem, it becomes much easier for security purposes. From the validation point of view, Amazon OpenSearch Service itself provides easy to communicate APIs and up-to-date documents, which is much beneficial. For example, if I'm missing anything, I can directly go and check the documentation. That is actually much easier.

I would rate it as really good so far. It's much faster. For our local machine, we can also use a kind of replica of Amazon OpenSearch Service just for development purposes. That is another good feature. I would say for the encryption thing and also the user access control management, it's much faster. For some of these hashing algorithms, it also worked really well so far.

To be honest, I didn't find any places where it can be improved. However, I think they could provide more abstraction. For example, still for searching, we have to write down the queries in a specific manner, such as for a specific JSON structure or in a specific way. Otherwise, they don't provide us the actual results. For at least this purpose, I think abstraction could be a bit easier or a bit improved. Other than that, right now there is the age of AI, so some kind of prompting could also work, but I'm not sure how it could be integrated.

As a user, lower prices or reasonable pricing is always better. Those can be improved as well. However, it is good that most of the services including Amazon OpenSearch Service actually provide pay as you go pricing. So if there were a bit lower version or a bit less payment methodology, it might be much better.

I'm working on Amazon OpenSearch Service, AWS OpenSearch for one and a half years.

I'm not using Amazon OpenSearch Service for a long period of time, at least just one and a half year, but I can assure I have a very good experience on Elasticsearch while I was working in a big enterprise solution. If I compare Elasticsearch with Amazon OpenSearch Service, I would definitely say Amazon OpenSearch Service is much better in documentation and API. It's much more secure. It's also much easier to communicate as a developer because they provide some interactive examples and an interactive way to actually start the hands-on. I would actually put Amazon OpenSearch Service a bit higher. Whereas for Elasticsearch, it is definitely a no-go for me because at least at that time when I was using it, I found it as open source, so it actually provided much better features. There was also an enterprise version at that time. However, I found that the documentation were a bit challenging and also sometimes it took a deep learning curve. That's a win for Amazon OpenSearch Service itself, rather than Elasticsearch.

To be honest, I'm right now not completely sure about how much it's improved from Elasticsearch. I have seen in some of my research a few hours ago that Elasticsearch is actually providing some very nice features and new features are upcoming. But as I already mentioned, since I'm not that much familiar with it for at least one and a half year, I'm not sure how much it's improved actually.

They are providing the platform out there in the AWS. I can go there and from the UI, I can just create my own collection. I can use and create my own indexes, and then I can actually do some CLI calls and basic API calls and then I can check it by myself. Also, when everything is working perfectly, then we have tried with the Infrastructure as Code approach, using Terraform, and we have done that thing automatically. In the initial setup, I won't say we face that much issue or problem for Amazon OpenSearch Service.

I have bought it from the AWS cloud itself because we have the AWS account. From there, I can enable the service and then it goes on actually.

So far, we didn't face any issues, but I'm not sure about the future.

Negative

I think Elasticsearch has a very good market if it can improve in a number of places. As I didn't experience it, I'm not sure how much beneficial it will be. But from the last experience I got from Elasticsearch, I would say if the documentation was a bit better, if it could have better features regarding the integration of AI, where you are actually writing down some prompts and it's just doing its job under the hood, or if there are some good monitoring dashboards, like for example, last time when we were using Elasticsearch, we were using it for logging and then we were also using it for the ELK stack with Grafana and Kibana. So, if those things could be improved, if running Elasticsearch itself, the server, becomes less resource-intensive, it might be much better. I'm not sure right now how it's going on, as far as I can remember from my last experience, we were running it at least with an 8 GB store, and it was sometimes really difficult to actually manage some of our indexes and collections. Overall, these are just the things regarding Elasticsearch, but I think it has a very good chance to gain traction in the Dev community.

So far, we are getting some good insights or good results. However, if there are any better third-party applications which provide similar type of safety, security and latency, then we'd definitely catch it up. But definitely it is also true that Amazon OpenSearch Service is not that much cheap. It actually involves a big pricing as well. So if there is any better alternative, we'll definitely catch it up.

Thank you. Bye. I would rate my overall experience with Amazon OpenSearch Service as an eight out of ten.

For Amazon OpenSearch Service, our customers usually want their application for application debugging and security monitoring, and they also want performance monitoring. For those three use cases, we implemented Amazon OpenSearch Service, which can fulfill all these requirements for them. It's also affordable and cheap compared to other tools, so that's the reason we choose Amazon OpenSearch Service. Additionally, a major requirement for clients is that they want cloud native services, specifically for AWS.

For analytics tasks in Amazon OpenSearch Service, we use it for application debugging and it has been very useful for us over the last six months.

The most valuable feature of Amazon OpenSearch Service we found is OpenSearch dashboards, because we can integrate multiple tools and customize that dashboard for large organizations. One of the large organizations we worked with wanted to create a POC for AI tasks, which involved sending all the logs, traces, and metrics to OpenSearch, and the OpenSearch dashboard allows us to visualize all this easily without any performance issues.

Our customers have seen tangible benefits from Amazon OpenSearch Service, especially in terms of their applications running smoothly, so they do get a return on investment.

In terms of data handling capabilities with Amazon OpenSearch Service, they can be complex and managing data in comparison to other SIM solutions is a major drawback, as it is very hard to handle the data.

We definitely want Amazon to optimize the data handling aspect, as ElasticSearch is the parent of OpenSearch. If Amazon makes changes in OpenSearch, it would be very useful for us, making it more user-friendly with simple buttons to perform tasks.

We are working with Amazon OpenSearch Service for around 6 months.

I would rate the initial setup of Amazon OpenSearch Service around six, as it's easy to set up, while ElasticSearch is around one or two due to being very hard to set up manually.

The typical time it takes to deploy Amazon OpenSearch Service is around 1 to 2 days for basic deployment, and it will take one to two months for a complete setup, including logs injection.

I would rate the stability of Amazon OpenSearch Service around four, as it is not very stable, and it usually lacks customer support.

I would rate the scalability of Amazon OpenSearch Service around six, as it is very scalable and similar to ElasticSearch.

I give it a six because while Amazon OpenSearch Service is scalable, it's not exceptionally scalable compared to other organizations using Splunk, which is very scalable and easy to use. In comparison, Amazon OpenSearch Service caters more to mid- to low-sized organizations, and large organizations are facing challenges with the setup and other issues.

I would rate the technical support of Amazon OpenSearch Service as four.

The rating is four because we have tried to contact them, but it has caused major delays. If we purchase AWS support then it's acceptable, but with ElasticSearch being open source, its customer support is not very user-friendly.

Neutral

The deployment process for Amazon OpenSearch Service consists of three stages. First is agent installation on various instances and compromised devices using the Filebeat agent. We require a different agent called Fleet Manager, but it's not supported in OpenSearch, only in ElasticSearch. After agent installation, we manage to pass the logs using Logstash to normalize all the logs, which we then send to OpenSearch.

Our customers have seen tangible benefits from Amazon OpenSearch Service, especially in terms of their applications running smoothly, so they do get a return on investment.

I would consider the pricing as a six based on how much data we are handling; if we handle minimal data, it's cheap, but for large data, it becomes costly.

Our clients usually pay between $1,000 to $4,000 for Amazon OpenSearch Service.

I have experience with multiple SIM solutions as I'm working in a cyber security organization and we have clients that are using Splunk, ElasticSearch, and CrowdStrike. We are trying to bring them a more affordable and accurate solution that can help to align their business.

Wazuh is a tool we currently work with. I also work with Splunk and ElasticSearch as well. For ElasticSearch, we are using the OpenSearch. Amazon OpenSearch Service is similar to ElasticSearch.

Overall, I would rate Amazon OpenSearch Service a four.

I use it for database. For RAG, you need a vector store to store embeddings.

To store the vectors, you need embedding models to convert the data into vectors. You then need to store those vectors in any vector store. Popular ones are like Chroma DB. 

As a new alternative, I selected OpenSearch, which falls under the whole AWS infrastructure. So to bring our full architecture into AWS, I use OpenSearch as a service as my vector store.

It is effective for data analysis. This service already sorts data like vectors. They have classified the storage pre-defined. We just need to select the purpose of the data, like time series data or vectors. It will be as effective as any other DVR or vector tool. 

We need to retrieve data and implement our tools or libraries for analysis. The scalability is good; they use a serverless solution, so we don't need to worry about it.

Security features:

Security is decent, but there aren't enough security features. I don't see any built-in authentication functions. However, there is an option to enable or disable the public or private subnet like other AWS services. So, we can make the dashboard public or private. Using AWS signer, you can sign in with AWS tokens.

The pricing aspect is a concern. The service is way too costly. For the past month, I used only 30 to 40 MB of data, and the cost was $500. AWS could improve pricing. 

Even being serverless, it incurs charges during idle times. For just holding data, you need to create a list. AWS should add an option to make data idle, so it won't include computing charges. They charge for OCU units based on the time the serverless solution is up, not on indexing or retrieval speed. Once the service starts, it starts getting billed.

It would help if there were an option to limit computing. When using it as a database, storing data without frequent fetching would save computing costs. 

I've started using Amazon OpenSearch Service (AOSS) as a vector store for RAG since May.

There is a minor latency issue when creating a new index or updating data. The backend update takes 10 to 20 seconds. Even though the query runs successfully, deleted indexes might still appear for 10 to 20 seconds. After 30 seconds, it's fine. 

Scalability is good because it's serverless. 

There is AI support feature, called Amazon Q, like a chat. You can find it in the AWS console, ask basic queries about services, and it will refer to articles to answer questions.

The installation has medium complexity. If you have good AWS knowledge, you're good to go. For freshers, it may be tougher, but not too complicated. 

I encountered issues with authenticating through a Lambda function, but changing from one authentication method to another, I finally sorted it out. 

For an experienced one, it would be easy. But freshers might need some supervision when it comes to integrations. 

For me, it took about three to four days to implement. Maintenance isn't an issue, it will continue running in the background. But I would prefer an option to make it an idle state. 

As a developer, I handle integrations for clients. AWS provides plenty of documentation, so integration isn't tedious. 

The pricing is way too costly. I used it for around 40 MB of data for a month, and it cost $500. Even when idle, it continues to incur charges. They could improve this by allowing us to limit computing and keep data idle when not actively used.

I would rate the pricing a nine out of ten, with ten being expensive. This service is three to four times more expensive than other solutions.

I've looked at Pinecone and MongoDB Atlas. I prefer MongoDB Atlas.

Mongo Atlas is a better solution because of its dedicated platform and configuration. AWS OpenSearch is limited compared to MongoDB Atlas, which is versatile and has broader community support.

I would rate the solution a five out of ten. I would recommend to compare pricing and other possible solutions before diving into OpenSearch. If you need Open Source for a specific purpose and are sure of what you're doing, you can go for it.

OpenSearch is used as a search engine for specific logs, mainly in e-commerce and monitoring the logs themselves. It is very valuable for e-commerce, enabling data analysis on application logs and customer behavior, and can be integrated with other services, including AI and machine learning algorithms.

OpenSearch provides data for AI solutions. It allows integration with machine learning algorithms to extract recommendations and insights, enhancing our ability to train models and produce valuable recommendations.

Scalability is a key feature as it allows easy scaling of the platform without downtime, and OpenSearch can be integrated with any system. The business analytics capabilities are the most important feature it provides.

They can enhance data visualization. It would be beneficial if OpenSearch had its data visualization platform instead of Kibana and if it could be integrated with Compute Optimizer Service for better rightsizing.

I have been using OpenSearch for around four years.

OpenSearch offers good stability, though it is lower for Elasticsearch at eight out of ten due to its nature as an in-memory database.

The scalability of OpenSearch supports peak data loads effectively. It can be scaled out or up as needed, and deployments occur without downtime, making it an excellent choice for e-commerce needing high responsiveness.

The customer service is excellent, rated nine out of ten. I have had excellent support from AWS regarding OpenSearch, especially when dealing with performance issues impacted by ElasticCache.

Positive

The initial setup from an infrastructure level is easy, but from an application perspective, it is more complex. However, it is manageable and expected due to its capabilities.

The coordination for rightsizing between administration teams and the client is crucial and can be challenging.

The price is fair yet leans towards the expensive side. I'd rate it five out of ten with respect to capabilities vs. cost.

OpenSearch is particularly useful when dealing with structured data requiring analysis by traditional tools or AI.

I'd rate the solution eight out of ten.

I primarily use Amazon OpenSearch Service for log management and data storage. It's used to store third-party data and manage large volumes of query data across various services, including AWS Lambda and Kubernetes.

Amazon OpenSearch Service has enhanced our organization's ability to store and search large amounts of data efficiently. 

Transitioning from Amazon CloudWatch to Amazon OpenSearch Service for logging helped decrease costs since handling high volumes of logs was less expensive.

Amazon OpenSearch Service provides a managed database solution, so we don't need to manage everything ourselves. 

It's a flexible database that allows for fast searching of terabytes of data compared to other databases. It also supports multiple add-ons, allowing developers to implement application logic effectively.

One improvement I would like to see is support for auto-scaling. The current configuration does not support automatic scaling based on server load, requiring us to manage the scaling manually. 

Additionally, during snapshot processes and upgrades to servers, indexing and data copying take too much time.

I have been working with Amazon OpenSearch Service for about three years.

I have not encountered any performance or stability issues with Amazon OpenSearch Service.

Amazon OpenSearch Service does not support auto-scaling, which limits scalability. We need to manage storage and server configurations manually.

We had one occasion where we needed to contact the technical support team, and they were able to resolve our issue efficiently.

Positive

We previously used Amazon CloudWatch for logging. We switched to Amazon OpenSearch Service due to the high costs associated with CloudWatch.

The initial setup of Amazon OpenSearch Service was straightforward without complexities.

Using Amazon OpenSearch Service has been more costly compared to self-hosted Elasticsearch but is justified for critical business logic that relies on the features of Amazon OpenSearch Service.

Amazon OpenSearch Service is a bit costly compared to self-hosted Elasticsearch due to the managed service pricing.

I recommend Amazon OpenSearch Service because it is straightforward and easy to implement but advise assessing whether it is the best fit based on the specific needs and critical business logics.

I'd rate the solution ten out of ten.

We use the solution as a login platform. We have a lot of microservices, and we get log records from there, which we host on Amazon OpenSearch.

There are a couple of cool features. The service provides vacuum storage for cold or ultra-warm data. We retrieve historical data with just a click of a button to move it from cold to hot or warm because it's already stored in the backend storage, S3.

Some configurations or settings are not accessible to end users, as OpenSearch Service is a managed service. It would be beneficial to have some level of customization available in the managed service, tailored to the specific use cases of the end users. Currently, there are strict controls. For instance, if you wish to adjust cluster settings or other parameters, it's challenging for AWS to modify them.

The real-time analytics provided by Amazon OpenSearch Service can significantly improve your decision-making processes. Initially, we struggled to determine the correct cluster size and monitor various metrics. You can easily observe metrics like JVM and CPU usage on the monitoring dashboard. This information helps choose the appropriate tool and understand its support and extension capabilities. It would be even better if the service included built-in alerting based on these metrics. If an issue arises, you must manually check the cluster's status. Implementing preconfigured alerts for critical metrics like JVM and CPU usage would significantly enhance the service's usability.

I have been using Amazon OpenSearch Service for 2 years.

The product is stable.

The solution's scalability is excellent. You can scale up with Ruby on Rails deployment. It's pretty effective. If you wish to upgrade anything, it's super efficient. For example, you can trigger a global deployment test, and you'll experience no downtime.

We receive good support from Amazon OpenSearch Service. You encounter difficulties resolving issues. They are satisfactory in terms of communication and response time.

Neutral

We couldn't find a suitable solution for authentication. Among the various options considered, the primary reason for choosing Amazon OpenSearch Service was our familiarity with AWS, as we already host our applications on this platform. Another significant factor was the high licensing costs. Upgrading to Elasticsearch's latest version incurs high licensing expenses. Also, the cost of using Splunk was high. Amazon OpenSearch Service was the most suitable option considering both the ecosystem and cost factors. Additionally, since Elasticsearch and OpenSearch are similar, transitioning to OpenSearch from Elasticsearch was relatively easy. This transition allows us to maintain a consistent user experience while remaining within the AWS ecosystem without incurring excessive costs.

Creating a cluster is hard, but sometimes, when you want to make a VPC web cluster, it is difficult to expose the dashboards. You can see the proxy settings if you want to integrate with Okta. We had a real challenge with setting up the integration with Okta. The cluster creation was not complex, whereas the integration took us months to resolve. Deployment took two to three months to complete.

The cluster setup is not complicated, especially if you want it taken care of with Okta and the dashboard exposed via proxy.

A managed service is more costly than a self-managed one. The cost isn't about monitoring; it also involves human resources and labor cost savings. For instance, if you previously used self-managed Elasticsearch, you need to handle all upgrade strategies and cluster management yourself. This incurred a significant cost, which makes tools like OpenSearch valuable. OpenSearch is designed to save your developers or users to manage the infrastructure.

It should be easier to integrate with other AWS services.

I recommend the solution, but it depends on your specific use case. For example, if you plan to use it for logging or centralized login setup. Thus, I suggest assessing your needs based on data characteristics. For example, if your data exhibits fluctuating volumes or varying patterns per day. Managing OpenSearch entails addressing various aspects, including site templates and lifecycle policies. Therefore, ensuring all necessary components are in place is crucial.

It's easy for a person to learn to use Amazon OpenSearch Service for the first time. There would be a learning curve, and it might take some time in terms of managing the internals of the OpenSearch cluster, but if you just want to use it as an end user, it's pretty intuitive. You can navigate around to see the options quickly.

Overall, I rate the solution a seven out of ten.

It's a good log management platform. In terms of infrastructure management, it's good. 

Even when I check with the logs, I can easily create the filter accordingly, the logs. But different data sources. So, as per my understanding, my experience is also good.

Basically, we are using the application logs, for example, from the EC2 and Kubernetes clusters, which will be coming from AWS. We push that log to the Stack Logs and Elasticsearch; for Elasticsearch, we view in Kibana for selecting the logs.

Basically, we're just using the filters to understand the logs.

My requirement is fully fulfilled. Since it is fully filling my requirements, it fits our architecture.

I want to see a new feature in Amazon Elasticsearch Service that allows users to create default filters for filtered levels. 

This would make it easier for users to filter the data and find the information more quickly.

I have been using this solution for two years.  

I did experience a few lags. So we had to reset the servers and all other stuff because sometimes Elasticsearch is not responding properly. So, during that time, we just restarted the services. Probably, some kinds of metrics do not match the current requirements. That could be the reason.

I would rate the stability an eight out of ten. 

It is scalable enough for us. 

I have used ELK, Grafana, Prometheus, and all these things. 

Currently, we are using a different platform in a different location. 

We had a place where in Azure, we were using ELK Virtual. There, it's a different scenario. But if we go for Oracle Cloud, we are implementing everything in Kubernetes. So, Grafana is very easy to capture the logs from the Kubernetes level. So, we prefer Grafana in terms of other log management tools.

It is not difficult to setup this tool. It took us two days to deploy it. 

It is a good tool. Overall, I would rate the solution an eight out of ten. 

The purpose of the solution is basically for streaming of data, so Amazon Kinesis gets the data, and then it goes to Elasticsearch. Basically, for the data to analyze, whether it is the data we are receiving on the streaming process, means it goes once in two ways. After Kinesis, one is in S3 bucket, and another, it goes through Elasticsearch. In Kibana's dashboard, basically, they check whether the database is relevant or not.

Another place where we use Elasticsearch is for the data which comes from the source. Basically, we receive the data from the web services, and then it comes to the different buckets, and finally, it loads into Snowflake data browser. Before entering into the Snowflake, it goes to the other applications also, and we are on the other application side. Before that, you can say that for the data we are receiving, we use DynamoDB and Elasticsearch to get some retry mechanism. Suppose any message fails, then the retry mechanism is handled by Elasticsearch and DynamoDB. In DynamoDB, we store some SQL, like PostgreSQL, and it works based on that. Once it processes the data, we do the payload confirmation, so if any new user comes, we use the UUID and create the proper format of the payload for the main application, like Braze's application. Braze is a US-based company. The software used by this company to send a notification or for any campaigning or any sort of things, and to fulfill the requirements, we were at the other end. Whatever the request to send by Braze's application, we have to fulfill that. It was in the pipeline.

Regarding Redshift, I was talking about that basically in the migration project because of this one PostgreSQL.

Regarding valuable features of the solution, we found with the process, which we have used in both cases where we used the solution that while you're seeing the streaming of data, you can analyze in the initial phase what sort of data you are streaming and whether it is valuable. Secondly, the retry mechanism is also where we use Elasticsearch. In both cases, I think it's valuable.

Not for all the projects I saw, but most of the projects were using Elasticsearch, which is very common. In my case, I have faced two scenarios with the solution. Other than that, generic solutions like SNS, SQS, and Lambda are some of the very generic tools we are using.

Regarding what I would like to see improved in the solution, I would say that, basically, the configuration part is an area with a shortcoming. We have a DevOps person, so all these things are configured in the Terraform through the Terraform script we use. The DevOps team used to take care of it. To run the process or run the services and how to use the services are the parts for which we are using the solution. Some upgradation is required on the configuration side so that we can get to use it. In that case, I have to check on that area with the DevOps.

Based on a project-to-project basis, I have used the solution for a year. Some of the projects use these services, while some of the projects use different services. Currently, I'm working with a service-based company which is an industry where the solution is not always a fixed one. It is a variable. Sometimes, it is based on the budget, price, convenience fee of the professionals, and all. So all the aforementioned things are considered while getting a solution. Basically, it is not a single person's decision because every Wednesday, we have an architect meeting, and based on that, whatever the group decides on the solution, it's not alone, and then obviously, since I am not the main person, the main person from the client side who is some solution architect would be there, but we have to provide the pros and cons of the each and every service.

In this way, we used to confirm which were supposed to be new services like Datadog or Voxel51. Obviously, based on a lot of requirements we introduce. So we have to provide the pros and cons, and that has to be accepted by the architect team, and then we proceed.

I am a user of the solution.

I don't have experience with technical support since we work on a development project. I have not directly worked with AWS.

Basically, we were working on the sprint wise. As you know, if you say the complete and particular part of the deployment, you can say that it is like considering the requirements for that, and to fulfill the complete requirements, which involves Elasticsearch, it takes more than three months. It will be almost four months. We have worked on Agile and other storage devices consisting of epic and all. Basically, we break down into small pieces of the task, and then we work on that each sprint. For a maximum of two weeks, we have the sprint.

My company's DevOps team consisted of two people who were dedicatedly involved in the configuration.

The solution is not expensive, but priced averagely, I will say. Regarding the pricing part based on the use cases, we used to sometimes see or do some of the costing parts also in that case. Department-wise, we used to check which department has more ability to help the company to reduce costs. For instance, the development team is unnecessarily using S3 and other solutions, which are not required tools. For the production team, we can't put any more points on that. But for development, we used to check whether the usage was correct or not. If you save thousands of dollars every month, then it is helpful to the company. In that case, we used to put in some extra extras for the company.

My suggestions to others about the solution would be based on their requirements. Obviously, there may be some other ways to do it. Regarding the decision, firstly, the company thinks about the monetary part also coming into the picture, and also the professional aspect. Nowadays, you can get cloud technologies as most people that are working on Python and other technologies. I think Elasticsearch, or AWS, is quite compatible, and if you're working in AWS, the services can be integrated into any application and all. I will say that I will suggest it based on the requirement of someone else who wants to use it. Like, Lambda and all, it is basically based on how much time it takes to run. The cost is okay. Also, company-wise, the price is fine. However, one has to see the requirements, and based on the charges, it should be okay and manageable.

The solution is something that is based on the requirement. If you want you can do it in some other way also. Basically, you can have a better solution. I will not very much insist to anyone that they should go for Elasticsearch. If you have any other solution, it's okay. Otherwise, it's a good product. It is not only Elasticsearch that is there in the market, but also some other tools are there. Nowadays, most of the time, every company has some integration process in their tools, so whatever they develop, they make it in such a way, in a versatile manner, so that it can integrate with any component.

Overall, I rate the solution a seven out of ten.

Amazon Elasticsearch is a search engine. We set up the index from where the content was and moved the content in to get it indexed.

We provided the end user with a fairly full-featured search, and they were included in being able to write their own bullion.

The most valuable features of Amazon Elasticsearch are ease of use, native JSON, and efficiency. Additionally, handles many use cases and search grammar was useful.

Amazon Elasticsearch can improve the bullion in the near search and the ease of integration with Kibana. Additionally, there could be more flexibility in the configuration and documentation.

I have been using Amazon Elasticsearch Service for

The solution is stable.

Amazon Elasticsearch is scalable. The solution has scaled well for my use cases. However, I have not used it in a large installation. 

The support from Amazon Elasticsearch is good when we needed to contact them. There is a lot of community support available.

The initial setup of Amazon Elasticsearch is straightforward.

We have received a return on investment.

There is a community edition available and the price of the commercial offering is reasonable.

I rate the price of Amazon Elasticsearch a nine out of ten.

I would advise others to use community support, it is the best place to receive information.

I rate Amazon Elasticsearch a nine out of ten.