Even though the product works well with most AWS, it is a nightmare to use with Snowflake. Snowflake is a SaaS product hosted on AWS, but using it with CloudWatch still doesn't give us the support we need so we rely on separate monitoring. 

We have many databases such as MongoDB and SQL Server, RDS, and PostgreSQL. For these, CloudWatch is good but a little basic and additional monitoring tools are required. It's challenging to use one monitoring tool for S3 and another monitoring tool for Snowflake. 

It would be beneficial for CloudWatch to provide an API interface and some kind of custom configuration because everybody uses APIs now. Suppose Snowflake says we'd get all the same things with MongoDB such as APIs, hookups, or even monitoring. That would allow us to build our own custom solution because that is the biggest limitation of CloudWatch. If you go a bit beyond AWS products even if they're hosted on AWS, CloudWatch doesn't work very well. 

I'd also like an improved UI because it hasn't significantly improved in a few years and we want to see it at a more granular level. I get my KPIs in a bucket usage for yesterday but I'd like to see them by a particular date and week. We have three buckets rolled by hundreds of people and I want to see use cases for an individual to determine where I need to customize and provide more room. I want aggregation on multiples, not one terameter. 

In my company, we have created a Lambda function to collect logs from CraC. Our company particularly uses Lambda function in Amazon CloudWatch's log groups. From Amazon CloudWatch, in my company, we are not getting proper logs from particular services. When my company faces the aforementioned issues, we have to get involved in the troubleshooting process while also keeping a check on Lambda functions. In my company, we are unable to get proper logs even with Lambda functions, making it one of the areas that needs improvement.

The monitoring part and GUI are areas in Amazon CloudWatch that have shortcomings currently and can be considered for improvements in the future.

What would make Amazon CloudWatch better is if it includes more on-site checks, particularly status checks on the CPU, network input/output, etc. It would also be helpful if there's built-in swap space, disk, and memory monitoring in Amazon CloudWatch because, at the moment, my team has to configure it manually through a shell script.

Amazon CloudWatch is a pretty complete tool with many features, so apart from the improvements I mentioned, there isn't anything else I want to change in Amazon CloudWatch.

The solution's auto-scaling could be improved.

Log analytics features should be included in the next release of Amazon CloudWatch.

I think Amazon CloudWatch has built a very good service in terms of integration since it can integrate with Docker, EC2, and Kubernetes, owing to which we don't have any problem with the solution in our company right now as it works fine. Amazon CloudWatch resolved its performance issues quickly as well. I don't think there is anything bad in Amazon CloudWatch.

I don't think I need to comment on any additional features that need to be included in Amazon CloudWatch since they roll out new features as per the roadmap Amazon has planned.

The dashboard of Amazon CloudWatch is not very customizable right now. In the future, I would like the dashboard of Amazon CloudWatch to be made more customizable.

There could be further enhancements through CloudWatch's partnerships. It allows integration with additional log archive tools, such as Splunk. I am not certain if direct integration is currently available, this would be a valuable improvement to explore.

When you set up CloudWatch, you can't even take a lot without checking on them or without going through the whole configuration because we're configuring. It's not a frequent feature you always work on.

The integration requires a lot of permissions and the tool delays in providing notifications. Sometimes, receiving a notification after an update takes a long time. So, we prefer using a monitoring tool like New Relic or Grafana.

Another area of improvement is scheduling. CloudWatch is complicated when it comes to scheduling. If you want to monitor the component, the configuration is not straightforward. You need good knowledge for something to be added there.

I haven't heard any complaints about the product.

It would be nice if they could make it in such a way that we wouldn't have to rely on Datadog as much. 

We'd like the interface to be as easy as Datadog.

Amazon CloudWatch needs improvement. The main thing is we have noticed missing logs. Like, we know that the Lambda function was executed because we have been able to see the output in another downstream system, but we do not see the logs of that execution on CloudWatch. Sometimes we face problems like our program didn't produce the correct output, and the customer reports it. However, we don't see any logs when we go to CloudWatch.

CloudWatch can also improve the logs search functionality. Searching with keywords over the log streams can produce very unreliable results.

CloudWatch doesn’t monitor disk throughput by default. It is part of EC2. If EC2 forwards the logs, then we can do it.

The solution should provide human-readable metrics. Amazon CloudWatch should add custom metrics, like static metrics or any data relevant to our use case.

There is a need for seamless integration with databases, whether they are open-source or proprietary like InfluxDB. Incorporating a straightforward method or a plug-and-play solution for integrating these databases with our systems, facilitating smooth data transfer, and enabling the creation of dashboards for monitoring and analysis would be beneficial.

There is room for improvement in the pricing because they have a premium version, but it's not really a premium version. It's just an enhanced monitoring version, and it can be a bit expensive depending on your usage.

I think something that can be improved are the alerts and alerting mechanism based on no rejects. We want to have it more flexible and that is one of the key things that is required.

The dashboard and the UI could improve in Amazon CloudWatch. Additionally, they should focus on visibility inside the servers with AI and machine learning integrations. This would allow users who are using the solution to see what is happening within the system better.

An area for improvement that we want to see in Amazon CloudWatch is a more realistic monitoring. It's real-time data stream monitoring we are looking for. Our application is a huge application that will run on AWS. It has a lot of services that are running, so we want to monitor those services, e.g. message review and frontend application in ELB (Elastic Load Balancing).

It's not only monitoring that we want to do. We also want to visualize that monitoring data through dashboards. This is the main reason we plan to try Datadog because in Datadog, we can create a dashboard and we can visualize the log data through the dashboard.

We are not happy about the dashboards. In Amazon CloudWatch, they can fetch all the logs, but the service is not good at delivering the data into the dashboard, plus there's the lack of real data, e.g. in application performance monitoring. We find this product lacking and this is why we want to look for a new service that can cover our needs.

Additional features we would like to see in the future on this product include more API performance features, e.g. application performance monitoring. We also want live dashboards and well-designed workflows.

We also want integrative services, e.g. custom logs we can check, as we are not satisfied with what Amazon CloudWatch currently has. We are looking for more competency on these services: dashboards, real-time monitoring, real user monitoring, and application performance monitoring. We also have more and more mobile apps, so mobile app monitoring is also important.

These are the key areas that people are looking for, and what we'd like to see on this product in the future.

CloudWatch's scalability could be improved.

The product’s documentation must be improved. We faced an issue with a service that is integrated with CloudWatch. Whenever there were 50,000 to 60,000 log lines, CloudWatch only showed us 10,000 to 15,000. We could not get all the log lines in the same place. When we tried to get everything together, the product crashed.

It's not an advanced way of monitoring.

I found several areas for improvement in Amazon CloudWatch. First is that it's tough to track issues and find out where it's going wrong. The process takes longer. For example, if I get an exception error, I read the logs, search, go to AWS Cloud, then to the groups to find the keyword to determine what's wrong.

Another area for improvement in Amazon CloudWatch is that it's slow in terms of log streaming. It requires an entire twenty-four hours for scanning, rather than just one hour. This issue can be solved with Elasticsearch streaming with Kibana, but it requires a lot of development effort and integration with Kibana or Splunk, and this also means I need a separate developer and software technical stack to do the indexing and streaming to Kibana. It's a manual effort that you need to do properly, so log streaming should be improved in Amazon CloudWatch.

The AWS support person should also have a better understanding of the logs in Amazon CloudWatch.

What I'd like added to the solution is a more advanced search function, particularly one that can tell you more information or special information. Right now, the search function is difficult to use because it only gives you limited data. For example, I got an error message saying that the policy wasn't created. I only know the amount the customer paid for the policy, the mobile number, and the customer name, but if I use those details, the information won't show up on the logs. I need to enter more details, so that's the type of fuzzy matching Amazon CloudWatch won't provide. If this type of search functionality is provided, it will be very helpful for businesses and companies that provide professional services to customers, like ours.

Some of our customers want to use Kubernetes to monitor their CICD flow but Amazon CloudWatch does not support it. We need to use another solution, such as Datadog or Dynatrace has the needed capability.

In a future release, the vendor could add automation for quicker integration and improve the visualization similar to other solutions.

The product's configuration has some challenges. The solution needs to be more user-friendly. 

The drill-down aspect on the dashboard of the solution needs improvement. We get a very good high-level overview, but when we drill down, it becomes a little less clear. We have given this feedback to AWS as well and hope they will improve this in the future. It could also do a much better job of monitoring performance when core AWS services are not used. 

There is room for improvement in terms of stability. 

The graphical interface has room for improvement. CloudWatch only gives you a breakdown of what's wrong. However, it would be nice if it could automatically remedy the problems it identifies. You should be able to configure it so that when a specific condition arises, it will take a predefined action.

The technical support must be improved.

When customers want to see the CPU or memory utilization there is a cost. This should be free to see the utilization.

We haven't come across any shortcomings. 

The costs could always be cheaper. 

I do not know whether or not CloudWatch can be integrated with on-prem services. I would like to see, for example, if it's a hybrid environment, that potential, however, I'm not quite sure whether it's available or not. 

The product should provide more features.

The solution's integration could be easier for laypersons. 

The solution should move from being a performance monitoring tool to a full stack content management system with a hybrid DPM tool that integrates front-end, browser-specific, and footprint-specific monitoring metrics and synthetics. 

The solution's interface could be improved to enhance user experience by including Kendo UI or React.js frameworks. 

The solution could benefit from a price decrease.

For monitoring applications or for APM, CloudWatch has some limitations. You cannot monitor application performance from CloudWatch, and you have to go for a third-party tool.

A major drawback of CloudWatch is that you cannot create reports. They should add the functionality for creating some reports so that the users can download those reports. Currently, you can see the old data, but you cannot generate reports. So, if some of our customers ask us for monthly or weekly reports, there is a limitation, and we have to go for a third-party tool to generate reports.

Amazon CloudWatch's pricing needs improvement.

Improvement of SSSD logs would be beneficial.

I think the machine learning aspect of it probably does help because machine learning is not really machine learning. That needs some help. Better reporting is always something needed. That could be an answer to just about anything. But you always want better reporting, better dashboards, things that are just more dynamic and more accessible.

I haven't really thought about how the solution could be improved and I'm not sure what features are lacking.

The solution should adjust its pricing. We tend to find the costs for using it are a little high.

Right now, in relation to monitoring services, there are too many services and too many metrics per service.

I understand that it's per service but some complex acronyms, etc., make it kind of hard to understand the solution sometimes.

The solution's pricing is a bit higher.

There's a learning curve with Amazon CloudWatch since we have to learn to write the queries to extract the keys and logs.

I would like to monitor inbound and outbound transfer. I would also like to control the traffic for load balancing.

It would be good to see the transfer inbound per EP or per load balancing. This is a useful metric to have another review of your solution. It can also provide information on from where the clients enter and how they consume our data and solution.

The portability of the Datadog is much more flexible for us. The client does not need to have Amazon services for the entire life of the project, unfortunately. They can change. But for Amazon to move over to Google Cloud, for example, that it's very important for the client. They are not investing in a particular single cloud service.

The panel should be better. Datalog's is much more visual.

The configuration capabilities could be better. We've found it to be quite good on Datalog, for example. They should emulate that.