Our experience has been good and has helped us catch issues and solve them before anyone notices!

It is easy to go into Amazon Cloudwatch and see if we are having any issues with our websites or APIs.

So far we have had no issues with Amazon Cloudwatch.

Using CloudWatch is an indispensable tool to keep track of our logs, metrics, events, alerts, etc. We use its metrics to alert us when something is not right in our infrastructure. We also keep track of application logs coming from different resources to simplify finding and resolving bugs. We also use it to automate tasks we need to run at scheduled times.

It is easy-to-use monitoring and observability service that readily works with AWS services.

Accessing and searching log data can get more difficult as you start to have more log data and when logging data from multiple AWS resources if you don't use Log Insights.

overall experience with cloud watch was great is good I would recommend every who uses AWS should learn cloud watch. metrics to monitor all services at single place set alarms on required conditions and action that should be taken like send notifications using SNS service which is easy to use with cloud watch or scale accordingly, cloud watch is must for monitoring AWS

Amazon CloudWatch is a monitoring service from AWS here you can easily monitor almost all services of AWS that you use and want to monitor, also at a single place that is of great use. we can create dashboards of selected matrics and multiple dashboards can make monitoring easy and fast alarms can be set on conditions which will help to take necessary measures accordingly.

CloudWatch is a great tool it does not have many flaws, there are a few minor issues like you have to learn how to set up a cloud watch for monitoring and It might take some time , custom metrics will cost you, some important metrics are not available like storage monitoring.

Cloudwatch gives you the logging data to solve your problems and bugs with alerting functionality. Easily get the information to troubleshoot. The alerting is a little complex to setup.

- easy to use - builtin with AWS - long data retention period - collect and track your metrics

- it's only basic monitoring - the alerting could be better - it has a limitation for event fields

You don't have to use AWS for very long to have this happen: you've got instances and tasks and containers and all kinds of "machines", whether physical or virtual, running all over the place, and you want to figure out how to see what's going on internally with one of them. Maybe you just want a quick look at the Apache logs. In the "good old days" you'd just SSH into the instance. But with Docker and virtualization and everything, that's not so easily said and done anymore. Enter CloudWatch. Think of it as a centralized logging store. When you start up containers and instances and tasks and such, you can ask AWS to automatically have whatever you are spinning up log its internals to CloudWatch. You can then jump into CW anytime you need to take a look at what's happening inside that box. Need Apache logs? They're right there. Even better, they are searchable using a good (but not great) interface. Also, CW will bring together the logs from separate ECS tasks into one log group, if you want. So if you have a handful of tasks running, you can search across all of them in one go and find the misbehaving one much more easily than SSH'ing into 6 instances trying to locate the culprit. Extra bonus: with just a teeny bit of coding on your end you can actually have your application log items to CW directly. Use Lambda to monitor it, and push that to Slack, and you've got custom monitoring, built into your AWS stacks. CW is critical to doing AWS right.

* One-stop shopping for visibility on all your instances (and tasks and sub-instances and whatever else that AWS makes it so easy to spin up but then so hard to keep track of later) * Easy to hook into Lambda (which can then call to Slack or some other service) so that you can get push notifications about whatever's happening

* The search facility is not as good as it probably could be. If you have a line of output from a log, for instance, and you want to see where that line of output came from, and you do not know which log group it's from, you are out of luck. You can only search inside a log or log group, which means you have to know where the output came from to start with, but that might be exactly the issue you're trying to figure out in the first place: where is this output coming from. * AWS instances and tasks automatically start up with CW integration but that can quickly result in loads of orphaned CW log groups and such if you then do away with the instances but don't remember to go into CW and kill those as well.