Reviews (1-23 of 23)
- Perhaps the most useful aspect of CloudWatch is its all-in-one user interface. Makes it easier to manage.
- CloudWatch also appears to never have downtime.
- The third advantage of CloudWatch is that it integrates nicely with other Amazon products.
- The data collection could be made easier to access and manipulate.
- Although the program is made for professional IT managers, the program could be made more useful for other analysts.
- The logs data is cool but requires some effort for taking action.
- We are able to capture all of our Lambda logs through CloudWatch and ship them off to another provider for analysis.
- The alerting features allow us to scale certain services when needed so we don't have to do it manually, or over provision.
- Monitoring resource utilization allows us to see what is going on in our RDS services, so we can test optimizations and fixes.
- The auto refresh feature could use some work so that it doesn't kick you back to the main dashboard.
- The search features aren't as well developed as other areas in the AWS console.
- It would be nice to be able to create a custom dashboard of multiple widgets like resource stats and alarms on one page.
Amazon CloudWatch logs allowed us to stream massive amounts of logs off of devices without hitting any throttling, and then to stream those into S3 or ELK as needed for analysis.
- Solid support for posting data from a variety of AWS services to CloudWatch logs.
- Can setup alarms alert teams when certain resources hit a particular metric threshold.
- CloudWatch Metric view allows for custom graphs based on whatever AWS criteria you would need.
- Alerting could be beefed up, the options in terms of notification of alerts are pretty slim.
- The usability of the Metric graph view could be improved, it can be tricky to find the metrics of interest and setup graphs.
- The CloudWatch log view is pretty basic, the search options could stand to be more fleshed out.
- CloudWatch API allows integration into multiple monitoring solutions, such as SolarWinds Orion, Site24x7, and Grafana just to name a few we use.
- It's cost-effective and you only pay for what you use.
- Easy implementation, just a few lines which you can rinse and repeat when provisioning workloads from code or a few tick boxes when doing ad-hoc.
- Memory metrics on EC2 are not available on CloudWatch. Depending on workloads if we need visibility on memory metrics we use Solarwinds Orion with the agent installed. For scalable workloads, this involves customization of images being used.
- Visualization out of the box. But this can easily be addressed with other solutions such as Grafana.
- By design, this is only used for AWS workloads so depending on your environment cannot be used as an all in one solution for your monitoring.
For companies who do not use AWS, CloudWatch is less appropriate to use.
- Gives a well-reported status on your system health, usages, and traffic.
- The ability to place monitors on any or all of our instances while triggering alarms on certain events.
- Easy to set up and create alarms.
- The interface is really well designed.
- Its limitation on only Amazon resources.
- Cost is higher.
- Lack of ability to create graphs on distinct counts and histograms which can make it hard quickly identify specific IP addresses that have a high request volume in a certain period. We have worked around this but a feature on the dashboard would be nice.
It is great for scalability/cost. We know when to increase an EC2 instance or when it can be scaled down. I do have a concern on the documentation. I would say it is not for AWS beginners and to actually talk to support can be costly.
- Amazon Cloudwatch integrates with all the Amazon deployment infrastructure and provides monitoring capabilities at each step of the pipeline.
- Individual dashboards can be configured to do performance monitoring.
- Alerts can be configured for different performance indicators that can be very useful for event mitigation.
- Presently the application expects scripting experience in order to configure individual scripts for handling performance monitoring and alerts.
- The documentation is not at par for an enterprise offering and hence it makes the learning curve even steeper.
- CloudWatch integrates flawlessly with any AWS object like load balancers, EC2 instances, target groups, etc.
- CloudWatch is extremely easy to create graphs and charts with.
- Creating Dashboards on CloudWatch is as simple as dragging and dropping selected charts.
- It is not always easy to understand what metric type one should use with CloudWatch metrics. Averages, sums, min, max, etc. are not always readily apparent and CloudWatch does not stop you from creating useless metrics.
- CloudWatch cannot show milliseconds, it will instead show numbers in 'e' notation.
- Many of the standard metrics provided by AWS into cloudwatch cannot see below 1 minute intervals.
- Easy integration with other services.
- Seamless Configuration.
- Variety of matrix, graphs and dashboards.
- Support to third party libraries.
- User Interface can be improved.
- High cost of implementation.
- No Phone notifications.
- Allows integration into non-native products (SolarWinds, Nagios, etc).
- Proactive monitoring and recommendations.
- Alerting and dashboards.
- There is only a limited amount of credits available each month when pulling metrics into other applications. We have had to use larger polling intervals as a result.
- Unable to export alert data into 3rd party data warehouses for record keeping.
- Learning curve is slightly steep and there isn't much automation in terms of setting alerts up.
- Lambda process monitoring, particularly useful when you're relying on third-party services.
- Active monitoring RDS (set thresholds so we know before a database runs out of space)
- Auto-requisitioning of additional resources
- Your organization is married to the AWS ecosystem
- You tech stack is reliant on third-party services
- You use Splunk as your log aggregator (integrates well)
- You prefer to be proactive about health of your tech stack
- You don't use AWS
- You like to fly by the seat of your pants
- We use CloudWatch for collecting and monitoring logs for the AWS infrastructure.
- CloudWatch events and alarms are configured for all our infrastructure running on AWS. Like Ec2, ECS, AWS Lambda, RDS. We can track auto-scaling at the service level (ECS) and instance level (EC2 and ECS).
- CloudWatch helps collects monitoring data in the form of logs and events and provides one unified view of AWS resources and services that run on AWS.
- We use it for monitoring logs and events, raising alarms if our infrastructure has any issues and also CloudWatch logs into ELK system for detailed log analysis and monitoring.
- AWS Lambda's cold and warm boot times can also be registered using it.
- CloudWatch could provide better log analytics using a better log parsing and log indexing. Like what is provided in ELK or Splunk.
- Better dashboarding can be provided. Currently the dashboarding is very rudimentary.
- No good customizable log indexing is available.
- Integration with other AWS products is CloudWatch's greatest feature. CloudWatch logs and metrics are provided out-of-the-box for ECS, Lambda, Sagemaker, and most other AWS products. Log aggregation and instrumentation are difficult to configure and manage; it is great to defer that work to AWS.
- Configuring log retention policies is simple with AWS. If your business is required to retain logs for years, being able to automatically move old logs to S3 IA or Glacier with a few clicks is convenient.
- Configuring alerts from metrics is simple, and it is easy to integrate alerts with PagerDuty or email.
- The console's log search lacks many of the features you would find in PaperTrail or Log.ly. Regex search is either not supported, or very difficult to find.
- It can be difficult to understand how the CloudWatch bill breaks down by log group.
- The date/time picker in the console could be easier to use.
- Managing log retention periods is very simple with CloudWatch, and can be configured on a per-group basis.
- Monitoring host performance is very easy when coupled with the CloudWatch Agent on an EC2 instance. A simple installation and configuration replaces an entire 3rd-party host monitoring stack.
- CloudWatch is flexible enough for not just host monitoring, but application monitoring as well. It's easy to pipe local logs up to CloudWatch and extract structured data in order to monitor and set alerts on custom app metrics.
- Unfortunately, the CloudWatch dashboard does not provide the ability to create histograms of discrete counts. This makes it difficult to, for instance, use CloudWatch to quickly identify specific IP addresses that have a high request volume in a certain period.
- The UX for creating a custom metric from a CloudWatch log group is somewhat confusing. Every time I need to create a new metric I find myself fumbling around the interface for a few minutes while I try to remember how to do it.
- The alerting options for CloudWatch are not as extensive as are available with some 3rd-party services.
- The ability to create dashboards off of metrics
- Setting alarms when things go wrong so we get alerts
- Its integrations with other AWS products.
- If you have to ever dig manually through logs to try to find something it can be a little overwhelming. The user interface could use some work
- I would like the ability to create more customizable dashboards.
- The way log streams are used feels very counterintuitive.
At my organization, we use AWS (Amazon Web Services) to spin up new server instances for any business critical applications we require. This is known as containerization. Instead of purchasing new computers we buy more RAM and then have the capacity to spin up or shut down an almost limitless array of servers on an as-needed basis.
Not long ago companies needed to physically install servers on-site. Hardware would need to be upgraded, administrated and repaired. Also if these servers contained sensitive data, they would need to be secured from hacking or fire and theft.
Today we let Amazon host all of our data in the cloud. They are at least partially responsible for guarding our data from theft and fire. Our organization instantly recognized the benefit of being able to administrate our AWS server instances via Amazon CloudWatch. If you rely on AWS in any way, you need to use Amazon CloudWatch.
- Application Performance Management.
- Error Management.
- Utilization Management.
- The interface is clunky.
- The context sensitive help could be written more clearly.
- I wish there were more options for arranging the dashboard interface to my specific needs.
- Infrastructure monitoring
- Infrastructure alerting
- Building cloudwatch dashboards can be cumbersome. You have to navigate through various screens to get the metrics you want to add.
- Exporting alarm / alerting data is not available for further post-processing or analysis
- You have to build alerts and alarms yourself. CloudWatch does not give you any recommendations, so you have to know what you're doing.
Amazon CloudWatch Scorecard Summary
About Amazon CloudWatch
Amazon CloudWatch Technical Details