Amazon CloudWatch Reviews

Amazon CloudWatch is a very small service that AWS provides. It is a monitoring service for applications within the AWS cloud, and we can integrate external applications using the APIs or SDK.

The basic feature and main use of Amazon CloudWatch is for monitoring. Users can configure it for any services within AWS or supported services using the APIs or SDK for external services. You can get CPU metrics, memory utilization, metrics for load balancers, metrics for ECS clusters, or whatever service is deployed on AWS. Everything can be monitored using Amazon CloudWatch.

Currently, we are using it to monitor all AWS services only, nothing external. Amazon CloudWatch is basically for AWS services. If a user who is not using AWS cloud, they will not be interested in Amazon CloudWatch. It is just for people who are using AWS cloud. It can be integrated with external systems using SDKs. It depends on the use case and why users need Amazon CloudWatch because there are other services that provide more sophisticated options. There is no proper visualization here, so when you want to monitor something, you can get any other service which has both proper dashboard and data pulling capabilities.

The basic feature and main use of Amazon CloudWatch is for monitoring. Users can configure it for any services within AWS or supported services using the APIs or SDK for external services. You can get CPU metrics, memory utilization, metrics for load balancers, metrics for ECS clusters, or whatever service is deployed on AWS.

We have used Amazon CloudWatch logs which is useful when we want to go back and see what happened at a particular time instance.

It provides a dashboard, and if there are external or internal users whom you want to give access to specific dashboards, you can share the dashboard. As an administrator, you can configure which metrics or data can be visible for the user on that dashboard. You can share the link and the username and password, allowing direct access to Amazon CloudWatch dashboard.

If there is a CPU spike or system issues, we set alarms to notify us if the system is going down or not reachable. All these things can be configured with Amazon CloudWatch, and we can get an email using SNS saying that a particular service or server is having an issue.

It is very easy to use. As a monitoring tool, whenever your system experiences issues, it will notify you and is directly linked to your service. If anything is wrong with your server or services, it means it is affecting your service and automatically indicates that user experience is degraded. That is why Amazon CloudWatch is important while running things on the cloud.

Amazon CloudWatch itself provides a lot of data. However, for visualization, we need to use third-party tools. We are in a process of integrating Grafana, Loki, and Prometheus to have better visualization on Amazon CloudWatch. We are also integrating Grafana with the application itself to get the application data and logs.

Alternatively, there is AWS Kinesis and Glue where you can scrape the logs and have visualization, but a more easy option is Grafana. If you want to get a proper visual representation to see what is happening, then you need to integrate a third-party tool. Amazon CloudWatch has all the data, but to see what is happening, you need some third-party tool.

We have been using the solution for more than 10 years.

There have been no stability issues.

It is not a scalable thing as it is not a service that has something a server. The implementation part and management part are handled by AWS itself. We just need to configure it to the resource which we want to monitor. When we use Amazon CloudWatch, we are not deploying any kind of server or service. It is already there as a managed service from AWS.

Regarding Amazon CloudWatch, we have not needed customer service. If we have anything we need to look into, we can search on Google and use AI.

Neutral

We have not used any previous solutions.

Amazon CloudWatch is by default available with AWS services. If you want enhanced monitoring on Amazon CloudWatch, then there will be a fraction of additional charges. It is available with AWS itself and not with any third-party services.

Amazon CloudWatch is by default available with AWS services. If you want enhanced monitoring on Amazon CloudWatch, then there will be a fraction of additional charges. It is available with AWS itself and not with any third-party services.

We work on AWS on a number of products including EC2, load balancers, Shield, CloudFront, and Amazon CloudWatch. On a scale of 1-10, I rate Amazon CloudWatch an 8.

The typical use case for this solution is a banking solution where a lot of observability is required, including visibility into transactions and how traffic moves from different places. A good amount of traceability is required, which is where Amazon CloudWatch is used. This is purely a banking solution, so we must ensure tracking of any transaction loss or in-flight transactions. The visibility, monitoring, and management of infrastructure and logging are very important for banking solutions.

The best features of Amazon CloudWatch need to improve visibility into the network because when using hundreds of network resources such as transit gateway, VPNs, routers, route tables, and firewalls, it does not give many details in a structured manner. The traceability is not optimal when flowing through the network.

There is room for improvement for Amazon CloudWatch, specifically regarding the traceability aspect of network resources.

Apart from traceability of network resources, Amazon CloudWatch needs to be more interoperable with other tools because many companies are starting to use AI-based dashboards. When using third-party dashboards such as Kibana or Grafana and other visualization tools, there should be a way to feed CloudWatch's data and logging capabilities into these visualization tools.

It is usually deployed on the cloud and works effectively with its native cloud resources on AWS, whether public or private. With hybrid cloud, it has some difficulty maintaining visibility into other cloud resources. For instance, when connecting to Google Cloud, there is no visibility or traceability from Google Cloud into CloudWatch. There should be some mechanism for hybrid cloud scenarios, though it works fine with private and public cloud.

I have approximately four to five years of experience working with Amazon CloudWatch.

I would rate technical support from Amazon as six out of ten. The reason for this rating is that any kind of dedicated tech support requires extra premium payment. While using their cloud and cloud resources, if you have an issue with CloudWatch, you must pay additional monthly fees to get time from dedicated tech support. Without premium support, the turnaround time is quite high. When reporting issues, responses sometimes come after three to four days.

Neutral

The initial setup of Amazon CloudWatch is very straightforward.

I have not seen an ROI from this solution because Amazon CloudWatch is not a solution that can generate revenue. ROI does not apply here. It is one of the requirements for most banking solutions. You cannot sell a product without having proper monitoring, visibility, and logging. That is the reason why people are using CloudWatch. It cannot be used as a selling point to customers as they are not concerned about it.

Overall, the pricing of Amazon CloudWatch is very expensive.

The scalability of Amazon CloudWatch rates as high scalability, scoring a perfect ten. Amazon CloudWatch is highly stable with excellent high availability, scalability, and stability. On a scale of one to ten, this solution deserves an overall rating of 8.

Positive

We use CloudWatch for monitoring and logging. It helps us monitor our applications' performance, particularly in ensuring that every API hit returns a response within four seconds, which is our SLA. We also monitor invocation errors in Lambda and use CloudWatch alerts to notify us of any issues.

CloudWatch allows us to discover errors before our end customers do, enabling us to proactively address issues. We can notify our business relationship managers of potential issues due to recent deployments.

CloudWatch provides essential monitoring capabilities that integrate seamlessly with other AWS services. It helps us check response times and detect errors, allowing us to take corrective actions such as increasing concurrency or adjusting memory limits.

There is room for improvement in setting up custom metrics in CloudWatch. Adding conditional expressions would enhance its functionality.

We have not faced any stability issues or outages related to CloudWatch. It has consistently shown reliable and desired values.

CloudWatch is highly available and scalable. It does not go down like other services, ensuring that monitoring is consistently reliable.

Customer service has been rated eight out of ten because of the knowledge they have for specific issues. Their documentation and workshops provide valuable support.

Positive

CloudWatch is easy to use, and AWS provides excellent documentation and a workshop-style website to assist users.

Before setting up any alarms or monitoring, it is advisable to review the documentation to know how to effectively monitor your applications for different use cases.

I'd rate the solution eight out of ten.

I use Amazon CloudWatch to check the log we have sent, ensuring it isn't blocked. That is the primary purpose.

I like its filtering capability and its ability to give the cyber engine insights. It's useful to analyze past data and compare it with recent activities.

CloudWatch itself is fine. That said, maybe Amazon Web Services can improve by providing a library for CloudWatch with some useful features.

We have been using it for about two to three years.

I have never experienced any issues with stability.

I have not contacted their support team.

Positive

From my perspective as a tester, the initial setup is easy. However, for setting up cloud logging and management, developers might have more insights.

It is easy to access all previous historic logs and retrieve phased data as per our filters. That is the best capability it offers.

I'd rate the solution nine out of ten.

We use the solution to monitor our AWS resources. We used Azure extensively but a couple of years back we moved to use both Azure and AWS. Currently, we have three main use cases. 

Our predominant use case is monitoring our S3 which includes terabytes of data. We monitor all the buckets and containers plus who has access to them, the thresholds, and user data. We constantly watch all the KPIs and CloudWatch metrics. 

Our second use case is watching logs and processes for other products such as AWS tools, AWS Glue, and Redshift which includes a few terabytes of data.

Our third use case is minor and with Athena.

Our fourth use case is new. We just started using SageMaker for a small POC and want to complete all of our data modeling and logs.

In the future, we will be using the solution with Airflow, which will become one of our biggest use cases. 

CloudWatch works very well with any of the AWS resources so we always monitor through it.

Our business flow has improved because we monitor email thresholds and immediately get an alert from CloudWatch if use goes beyond thresholds. Without this alert, we would have to use external monitoring. 

It is valuable that CloudWatch collects all the metrics. I primarily like the RUM. There is an instantaneous response when monitoring logs and KPIs. CloudWatch immediately hooks up and connects to the KPIs and all the metrics. 

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. 

I have been using the solution for two years. 

The solution is very stable with absolutely no issues. We used to see a delay when we were setting up three buckets but now we receive instantaneous notifications. 

The solution is definitely scalable. Most of our development environment uses it and we are running three teams of 150-200 people. Usage levels are different between developers and the support team so the total users at one time is 100-150. 

The solution is managed by our internal AWS maintenance team. Seven people manage our cloud environment and seven manage our platform side for not just CloudWatch, but everything on AWS.

We still need to find a solution for Snowflake and Tableau environments unless CloudWatch provides better support in the future. 

The support staff are seasoned professionals and are good. Amazon provides the benchmark for support and nothing else compares.

On-premises, we have used other solutions like Sumo Logic, Azure Logic Apps and others. Not everyone uses AWS so we have a lot of tools we use.

Previously we used some main external app logic but it didn't work well with AWS tools. I would have to figure it out and configure Aurora to do something or find a way to do S3 buckets. Those solutions worked well for on-premises, but not with AWS and clouds.

The setup for this solution is pretty simple and anyone can do it if they are on AWS. Setting up all our VPC and private links connecting to our gateways took some time, but CloudWatch setup was a no-brainer and took a couple of days. 

Our implementation was done in conjunction with a third party. We like to bring in a few engineers to work with our engineers and then we partner with a third party like Slalom to help with integration. Our process is a mix of all three with AWS staff helping for a couple of weeks and Slalom for a couple of months. Our team slowly takes over management. 

We plan to increase our usage because we don't have another monitoring tool right now. With the Airflow orchestration, our CloudWatch use will significantly increase as we monitor all of our RUM, notifications, jobs, and runs. Our runs and billings will increase 20-30% once we start using Airflow. 

Because CloudWatch doesn't support all externally hosted products, I rate it a nine out of ten for ROI. 

I don't know specifics about pricing because we pay for all our AWS services in a monthly bundle and that includes CloudWatch, Redshift, VPCs, EC2s, S3s, A39s, and others. We spend about $5 million per year on AWS with CloudWatch being about 5% of that cost. 

I did not evaluate other solutions. Once we moved to AWS, we looked for a tool that was native to that cloud. That is the process we are currently undertaking for Snowflake and Tableau because CloudWatch doesn't support them well. We do try to use CloudWatch as much as possible. 

The solution is pretty good because it automatically comes and works well with AWS. Before you use any product from AWS, think about whether it is supported or how it will interface. I suggest using the solution with one product at a time and then transitioning to important interfaces. 

If you find you can't configure the solution with Redshift for example, and are struggling to build your S3 even though both use S3, then you may have to find another monitoring solution. It makes sense to follow Amazon's best practices. They advise not to use certain monitoring components alone but to use them as an integral part of your system. Monitor your ecosystem and think of a high-level picture of it rather than just determining that CloudWatch must be a part of Redshift. This solution is just one part of an entire system. 

I would rate the solution a nine out of ten. 

We collect the CloudWatch logs and use them to analyze security. It helps us to monitor malicious activity.

Amazon CloudWatch is an important tool in AWS. If we have an AWS-based infrastructure, the product must be enabled in all environments. If we have different environments in the cloud, CloudWatch is mandatory. The tool enables live monitoring. It is easier for us to track who logs in and out of the systems and how the computing services work.

The product is more than enough for what we need daily. Amazon improves things year on year. It is quite straightforward for us. We are using the solution to monitor our live environment. If an attack happens, we can track it down using the logs easily and act fast to isolate the threat. The retention of the logs and live tracking features are useful for us.

The integration with third-party tools must be made easier.

I have been using the solution for five to six years.

I rate the product’s stability a nine out of ten. We do not face any downtimes.

We have more than 600 users in our organization. Every user in the organization is asked to enable CloudWatch in every environment. I rate the scalability a nine out of ten. Whenever we add more accounts, CloudWatch is enabled in those accounts.

The technical support is pretty good. The team is always available. The support persons are readily available to get into a call and sort out our issues.

Positive

Amazon CloudWatch is a native service of AWS, and the bill is included with the other services in AWS. We receive a collective bill. The tool is not expensive. I rate the pricing an eight out of ten.

I will recommend the product to others. CloudWatch brings in a lot of value. It enables live monitoring. We have ten engineers in our technical team. The tool is self-sufficient. It does not require much maintenance. We enable it, ensure the logs are pushed to the third-party tools, and monitor them. It does not require any deployment process. We are more aligned with Amazon’s services when building our products. It is suitable for our business purposes. Overall, I rate the product a nine out of ten.

We utilize Amazon CloudWatch for logging purposes, and when it comes to monitoring our services, like the current task of setting up EPS clusters, we rely on it for essential checks. This includes monitoring the health and performance of our EKS (Elastic Kubernetes Service) and regularly inspecting the cluster's status through the management portal.

We have been highly satisfied with its event scheduler feature. Enabling this feature has proven to be quite beneficial as it allows for the seamless automation of various tasks. It offers direct integrations with various storage providers, making it convenient to push logs from CloudWatch to these external platforms. For instance, if I need to transfer my logs from CloudWatch to a third-party storage solution, it provides a robust integration mechanism for such use cases.

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.

I have been working with it for five years.

Occasionally, there can be some complexity involved in crafting custom queries to extract specific information from them, so I would rate the stability eight out of ten.

It is highly scalable and capable of handling a vast amount of logs. In our particular scenario, we haven't encountered a use case where we need to retain logs for the past fifteen years. I would rate it eight out of ten.

In the past, we relied on on-premises services for logging and other tasks, so we often had to manage a lot of data transfer between different systems, which could be quite cumbersome. Since we've transitioned to AWS for hosting our resources and solutions, we've found that it's much more efficient to use cloud-native services like CloudWatch. When your infrastructure and solutions are already on AWS, it's a logical choice to leverage the cloud's services rather than dealing with the complexities of integrating with external services.

The initial setup was not complex.

Synchronization is the default setting for certain services, and it's automatically enabled. For custom configurations, we had to take proactive steps and perform specific deployments. Apart from these cases, deploying this solution is generally straightforward.

It is a free-of-charge service.

We encountered several challenges during our transition, with the integration process. When considering third-party logging solutions, one of the key concerns is how the integration process will be handled, as it may not be as straightforward as using built-in services.

The choice of logging solution should always be determined by the specific business requirements. It is crucial to align the logging strategy with what type of logs are needed and how they should be used. There are instances where we require custom solutions to retrieve logs, especially application logs that may not be easily accessible through CloudWatch or similar services. When we heavily rely on AWS native services, CloudWatch is indeed a robust choice. However, in certain scenarios, we might need integration capabilities with other tools, and if they can incorporate such features, it would enhance overall logging capabilities. I would rate it eight out of ten.

I use it for log monitoring and log capture. That's the main purpose. 

Alerts and notifications functions help with the operational response. For example, if you have a critical server and want to set an alert if CPU utilization exceeds 90%, a notification will be raised. You can link an action to that notification, not just notify. 

You can automate actions or use AWS functionalities like auto-scaling, where you can configure the metrics to add more nodes if the threshold is exceeded. AWS has become very rich in functionality over time, and the same piece of functionality can solve different problems.

CloudWatch automation works through notifications linked to Lambda functions, which can then perform any automation you like.

CloudWatch has many things. It gives you metrics and logs. You can set up alerts and notifications for the metrics and do a lot of automation once you have the notifications. 

You can also create dashboards, although it's an additional fee that AWS charges. We can create a different dashboard with Grafana kind of thing. 

The use cases are different for different people, but three things everyone uses are: 

• Metrics monitoring
• Log monitoring, and 
• Alerting and notification.

CloudWatch is extremely helpful for automation and other things for experienced users, but it's not very intuitive. It doesn't have drag-and-drop functionality to trigger actions from notifications. It's very capable, but it requires expert knowledge to leverage that capability.

So, for new or basic users, it's a bit complex to understand how it works. Basic users can see what is happening in the console, but building automation and other things requires expert knowledge.

Improvement in log patterns and metrics: 

There are a lot of things. For example, there are log patterns and metric patterns. But if you have to do anomaly detection, I think the latest version added that, but they didn't have it before. Users can build it; Users can stream the log, build log analytics, and do anomaly detection, but it is not very straightforward. It's a very powerful tool, but you need expert knowledge to do those things.

Region-specific service puts certain limits:

Also, CloudWatch is a very region-specific service. People struggle with that, for example, if you have an application distributed in different geographies like Europe, India, and the USA. There is no way to aggregate CloudWatch logs in one place for workloads in every region. You need a third-party tool to get a holistic view of your application. CloudWatch has the data, but you need advanced skills to aggregate it and create insights.

Suggestions for additional functionality for CloudWatch: 

Cloudwatch needs better built-in analytics capability. CloudWatch has a lot of data, but it's difficult to gain insights unless you stream it to a third-party log analytics tool. If there were built-in capabilities to analyze the data, that would be great.

I have been using Amazon CloudWatch for ten years. We do work on a lot of AWS services, like CloudWatch, SageMaker, and even their generative AI solution like Bedrock.

I would rate the stability a ten out of ten. There are no issues with stability. 

I would rate the scalability a ten out of ten. 

There are around 50 end users, and all the ops people use CloudWatch.

AWS provides multiple support levels, including basic, business, and enterprise support. Your experience can differ depending on your support level.

My company uses business support. Quality-wise, it's okay most of the time, but sometimes, you get people with less experience. Response time could be improved because, for production applications, you want immediate support. Sometimes, it can take up to an hour to get someone on chat support.

Neutral

Azure also has something like CloudWatch. All cloud vendors have something similar.

The initial setup is very simple. 

CloudWatch also has an API, so I can send logs to CloudWatch by calling the API. But natively, it only integrates with AWS services.

Integration capabilities: 

AWS has built different frameworks, like the simple notification service (SNS). From AWS SNS, I can fire Lambda or integrate with the event bus, AWS EventBridge. From an integration point of view among the peers, AWS is probably one of the best that offers you the integration capability.

I would rate the pricing in the middle. It is a five out of ten, with one being high price, and ten being low price. 

Everyone needs it. There is no other way to capture central logs, so it's for everyone, irrespective of the size of the company.

I would recommend it. Overall, I would rate it an eight out of ten. 

We use the solution for monitoring CPU usage, memory usage, Lambda logs, and load balancer logs.

The monitoring features are valuable. The product pushes notifications with the help of SNS. We can increase or decrease our instances horizontally or vertically. We are collecting CloudWatch logs in Grafana too. We have also configured it with Kibana.

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

I have been using the solution for three years.

I rate the tool’s stability an eight out of ten.

The tool’s scalability is good. I rate the scalability a seven and a half out of ten. I have configured two instances for CPU usage. It breaks the threshold. It scales up and down multiple times. It is better to build only one instance in such facilities. We have 30 users in our organization.

The support is good.

Positive

The initial setup is easy. The deployment takes around five minutes. It is very fast.

The pricing is average.

We were using third-party tools before. We had to configure the third-party tools.

I will recommend the tool to others. Overall, I rate the solution an eight out of ten.