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.
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.
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.
Find out what your peers are saying about Amazon Web Services (AWS), Datadog, Dynatrace and others in Application Performance Monitoring (APM) and Observability. Updated: December 2024.
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.
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.
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.