What is Amazon CloudWatch and what are its top alternatives?
Top Alternatives to Amazon CloudWatch
Datadog
Datadog is the leading service for cloud-scale monitoring. It is used by IT, operations, and development teams who build and operate applications that run on dynamic or hybrid cloud infrastructure. Start monitoring in minutes with Datadog! ...
Splunk
It provides the leading platform for Operational Intelligence. Customers use it to search, monitor, analyze and visualize machine data. ...
New Relic
New Relic is the all-in-one web application performance tool that lets you see performance from the end user experience, through servers, and down to the line of application code. ...
Prometheus
Prometheus is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true. ...
AWS CloudTrail
With CloudTrail, you can get a history of AWS API calls for your account, including API calls made via the AWS Management Console, AWS SDKs, command line tools, and higher-level AWS services (such as AWS CloudFormation). The AWS API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. ...
Amazon Kinesis
Amazon Kinesis can collect and process hundreds of gigabytes of data per second from hundreds of thousands of sources, allowing you to easily write applications that process information in real-time, from sources such as web site click-streams, marketing and financial information, manufacturing instrumentation and social media, and operational logs and metering data. ...
Stackdriver
Google Stackdriver provides powerful monitoring, logging, and diagnostics. It equips you with insight into the health, performance, and availability of cloud-powered applications, enabling you to find and fix issues faster. ...
DigitalOcean Monitoring
Collect metrics for visibility, monitor Droplet performance, and receive alerts when problems arise in your infrastructure – at no additional cost. ...
Amazon CloudWatch alternatives & related posts
Datadog
- Monitoring for many apps (databases, web servers, etc)130
- Easy setup103
- Powerful ui83
- Powerful integrations80
- Great value66
- Great visualization50
- Events + metrics = clarity41
- Custom metrics39
- Notifications38
- Flexibility36
- Free & paid plans16
- Great customer support13
- Makes my life easier12
- Easy setup and plugins7
- Adapts automatically as i scale up6
- Super easy and powerful5
- In-context collaboration4
- AWS support4
- Rich in features3
- Best than others2
- Cost2
- Docker support2
- Free setup1
- Easy to Analyze1
- Monitor almost everything1
- Automation tools1
- Source control and bug tracking1
- Full visibility of applications1
- Expensive1
- Cute logo1
- Simple, powerful, great for infra1
- Expensive12
- No errors exception tracking2
- Complicated1
related Datadog posts
Our primary source of monitoring and alerting is Datadog. We’ve got prebuilt dashboards for every scenario and integration with PagerDuty to manage routing any alerts. We’ve definitely scaled past the point where managing dashboards is easy, but we haven’t had time to invest in using features like Anomaly Detection. We’ve started using Honeycomb for some targeted debugging of complex production issues and we are liking what we’ve seen. We capture any unhandled exceptions with Rollbar and, if we realize one will keep happening, we quickly convert the metrics to point back to Datadog, to keep Rollbar as clean as possible.
We use Segment to consolidate all of our trackers, the most important of which goes to Amplitude to analyze user patterns. However, if we need a more consolidated view, we push all of our data to our own data warehouse running PostgreSQL; this is available for analytics and dashboard creation through Looker.









We are looking for a centralised monitoring solution for our application deployed on Amazon EKS. We would like to monitor using metrics from Kubernetes, AWS services (NeptuneDB, AWS Elastic Load Balancing (ELB), Amazon EBS, Amazon S3, etc) and application microservice's custom metrics.
We are expected to use around 80 microservices (not replicas). I think a total of 200-250 microservices will be there in the system with 10-12 slave nodes.
We tried Prometheus but it looks like maintenance is a big issue. We need to manage scaling, maintaining the storage, and dealing with multiple exporters and Grafana. I felt this itself needs few dedicated resources (at least 2-3 people) to manage. Not sure if I am thinking in the correct direction. Please confirm.
You mentioned Datadog and Sysdig charges per host. Does it charge per slave node?
- Ability to style search results into reports1
- API for searching logs, running reports1
- Query any log as key-value pairs1
- Splunk language supports string, date manip, math, etc1
- Granular scheduling and time window support1
- Alert system based on custom query results1
- Query engine supports joining, aggregation, stats, etc1
- Custom log parsing as well as automatic parsing1
- Dashboarding on any log contents1
- Rich GUI for searching live logs1
- Splunk query language rich so lots to learn1
related Splunk posts
I use Kibana because it ships with the ELK stack. I don't find it as powerful as Splunk however it is light years above grepping through log files. We previously used Grafana but found it to be annoying to maintain a separate tool outside of the ELK stack. We were able to get everything we needed from Kibana.
New Relic
- Easy setup416
- Really powerful345
- Awesome visualization244
- Ease of use194
- Great ui152
- Free tier107
- Great tool for insights81
- Heroku Integration66
- Market leader55
- Peace of mind49
- Push notifications21
- Email notifications20
- Heroku Add-on16
- Error Detection and Alerting16
- Multiple language support12
- Server Resources Monitoring11
- SQL Analysis11
- Transaction Tracing9
- Azure Add-on8
- Apdex Scores8
- Analysis of CPU, Disk, Memory, and Network7
- Application Response Times6
- Detailed reports6
- Performance of External Services6
- Error Analysis6
- Application Availability Monitoring and Alerting6
- Most Time Consuming Transactions5
- JVM Performance Analyzer (Java)5
- Easy to use4
- Browser Transaction Tracing4
- Top Database Operations4
- Pagoda Box integration3
- Custom Dashboards3
- Weekly Performance Email3
- Application Map3
- Easy to setup2
- App Speed Index2
- Easy visibility2
- Metric Data Retention1
- Team Collaboration Tools1
- Worst Transactions by User Dissatisfaction1
- Real User Monitoring Analysis and Breakdown1
- Time Comparisons1
- Access to Performance Data API1
- Metric Data Resolution1
- Background Jobs Transaction Analysis1
- Incident Detection and Alerting1
- Real User Monitoring Overview1
- Best of the best, what more can you ask for1
- Best monitoring on the market1
- Rails integration1
- Free1
- Super Expensive1
- Exceptions0
- Pricing model doesn't suit microservices18
- UI isn't great10
- Expensive7
- Visualizations aren't very helpful7
- Hard to understand why things in your app are breaking5
related New Relic posts









Hey there! We are looking at Datadog, Dynatrace, AppDynamics, and New Relic as options for our web application monitoring.
Current Environment: .NET Core Web app hosted on Microsoft IIS
Future Environment: Web app will be hosted on Microsoft Azure
Tech Stacks: IIS, RabbitMQ, Redis, Microsoft SQL Server
Requirement: Infra Monitoring, APM, Real - User Monitoring (User activity monitoring i.e., time spent on a page, most active page, etc.), Service Tracing, Root Cause Analysis, and Centralized Log Management.
Please advise on the above. Thanks!
Regarding Continuous Integration - we've started with something very easy to set up - CircleCI , but with time we're adding more & more complex pipelines - we use Jenkins to configure & run those. It's much more effort, but at some point we had to pay for the flexibility we expected. Our source code version control is Git (which probably doesn't require a rationale these days) and we keep repos in GitHub - since the very beginning & we never considered moving out. Our primary monitoring these days is in New Relic (Ruby & SPA apps) and AppSignal (Elixir apps) - we're considering unifying it in New Relic , but this will require some improvements in Elixir app observability. For error reporting we use Sentry (a very popular choice in this class) & we collect our distributed logs using Logentries (to avoid semi-manual handling here).
Prometheus
- Powerful easy to use monitoring40
- Flexible query language38
- Dimensional data model31
- Alerts22
- Active and responsive community21
- Extensive integrations18
- Easy to setup18
- Beautiful Model and Query language11
- Easy to extend7
- Nice6
- Written in Go3
- Easy for monitoring1
- Good for experimentation1
- Just for metrics8
- Needs monitoring to access metrics endpoints5
- Bad UI4
- Supports only active agents2
- Written in Go2
- Not easy to configure and use2
- Requires multiple applications and tools1
- TLS is quite difficult to understand1
related Prometheus posts
Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:
By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.
To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...
(GitHub : https://github.com/m3db/m3)
We have Prometheus as a monitoring engine as a part of our stack which contains Kubernetes cluster, container images and other open source tools. Also, I am aware that Sysdig can be integrated with Prometheus but I really wanted to know whether Sysdig or sysdig+prometheus will make better monitoring solution.
AWS CloudTrail
- Very easy setup7
- Good integrations with 3rd party tools3
- Very powerful2
- Backup to S32
related AWS CloudTrail posts
Amazon Kinesis
- Scalable6
- Cons4
- Cost1
related Amazon Kinesis posts










As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.
We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.






















We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas
To build #Webapps we decided to use Angular 2 with RxJS
#Devops - GitHub , Travis CI , Terraform , Docker , Serverless
Stackdriver
- Monitoring18
- Logging11
- Alerting8
- Tracing7
- Uptime Monitoring6
- Error Reporting5
- Multi-cloud4
- Production debugger3
- Many integrations2
- Configured basically with GAE1
- Backed by Google1
- Not free2
related Stackdriver posts
- Easy, no fuss and great documentation3