Datadog vs. CloudWatch: AWS monitoring, investigation, and cost

Your applications already run on AWS and send data to CloudWatch. What would buying Datadog actually change? Start with the evidence missing from the last incident, rather than the appearance of the dashboards.

If most services and infrastructure live in AWS, and the team knows its IAM, account, and Region model, it is worth completing the CloudWatch application-monitoring path first. Datadog becomes a stronger candidate when investigations regularly cross clouds, data centers, or teams that need a shared workflow.

This is no longer a comparison between basic infrastructure metrics and a full APM product. CloudWatch has Application Signals, service topology, SLOs, and trace investigation. Datadog also consumes AWS data supplied by CloudWatch. The products can replace parts of each other's workflow or operate together.

Guance Editorial Team · Reviewed October 21, 2026. This documentation-based comparison covers Datadog SaaS infrastructure, APM, logs, and experience monitoring, alongside the corresponding CloudWatch capabilities. We did not benchmark performance, usability, or cost.

What will your team still need to configure?

See the Datadog AWS integration, Application Signals documentation, and each vendor's pricing. This comparison does not assume every security or AI product is included in a base subscription.

EC2's five-minute interval does not describe all CloudWatch data

“CloudWatch updates every five minutes; Datadog updates in seconds” mixes different sources and collection paths.

For EC2, basic monitoring uses five-minute periods and detailed monitoring uses one-minute periods. Detailed monitoring can incur additional charges. That distinction applies to EC2, not every AWS service metric. A shorter metric interval also does not guarantee equally fast alert delivery.

When Datadog retrieves CloudWatch metrics, source publication and collection still matter. API polling, Metric Streams, and a host Agent are different paths. Connecting an AWS account cannot turn a low-frequency service metric into a locally sampled Agent metric.

Break the requirement down: are native CPU metrics sufficient, are memory and filesystem measurements missing, what application-runtime data is needed, and how long are the evaluation and notification windows? The CloudWatch Agent can also run on on-premises servers and in container environments. Monitoring a data center does not by itself require abandoning CloudWatch. CloudWatch Agent scope

A slow request: where do the metrics and traces come from?

Suppose an ECS checkout service slows down while waiting for a database connection. CloudWatch can start the investigation with Application Signals service metrics and dependencies, then lead into traces, logs, and resource data. It supports SLOs and error-budget workflows; AWS application monitoring is more than a standalone X-Ray waterfall. Application Signals SLOs

The instrumentation path matters more than the layout of the console. AWS distinguishes an ADOT SDK with the CloudWatch Agent, an existing OpenTelemetry SDK with a Collector, and an existing X-Ray SDK. Runtime metrics, Container Insights integration, logging, and the effects of sampling differ. In the official comparison, the ADOT SDK and CloudWatch Agent path preserves metrics for all traffic; the other two paths provide the corresponding full-traffic metric coverage only at 100% sampling. Check this before relying on an error-rate alarm. Compare onboarding paths

Datadog can connect the same request's APM trace to logs and associated hosts or containers. Service, environment, version, and trace identifiers must agree, and log fields must be parsed correctly. Logs and traces can be sampled independently: finding a log does not prove the entire trace was retained. In a pilot, distinguish data lost during collection, sampling, and retention from data that exists but is hard to query. Connecting logs and traces

If the request stays within AWS, existing IAM and resource context may already support the investigation. If it continues into another cloud or a data center, Datadog's shared analysis environment becomes more valuable. Neither product can reconstruct request context that was never propagated.

Connecting an AWS account does not move every log

Datadog's AWS metrics integration, Metric Streams, and log delivery are separate paths. Logs may travel through Amazon Data Firehose or the Datadog Forwarder; application traces need instrumentation. A successful account connection does not mean operating-system logs, every request trace, and historical metrics are present. The integration documentation explicitly says historical metrics from before enablement are not automatically backfilled.

Teams already using CloudWatch Logs need to decide which logs stay in AWS, which go to Datadog, whether dual delivery is necessary, and how long each copy remains. Forwarder, Firehose, network access, and APIs have their own permissions and operational boundaries. Keeping the original path during a migration makes rollback easier, but indefinite, indiscriminate duplication increases both costs and governance work.

Test queries against the same task: find failed production checkout requests from the last ten minutes, then follow their request identifiers through surrounding records. CloudWatch Logs Insights supports QL, SQL, and PPL, not just text filtering. In Datadog, first confirm the relevant logs were ingested, parsed, and retained in a searchable form. CloudWatch query languages

Query scope matters financially, too. A query that actually scans 200 GB, run thirty times daily, scans 6,000 GB per day. This is a usage example, not a price quote. It shows why narrow time and data ranges should be normal practice rather than a reaction to an unexpected bill.

Shared access and centralized copies solve different problems

CloudWatch cross-account observability uses OAM to share telemetry access within a Region. Cross-account, cross-Region console features provide their supported views; centralization can move selected logs and metrics into a destination account or Region. Data types, permissions, copying behavior, and costs differ across these mechanisms. AWS comparison

An on-call team that only needs to inspect several accounts may not need a second copy of the data. Central retention, shared querying, or regional requirements deserve a separate assessment. Calling all of this “difficult cross-account monitoring” skips options that may already meet the requirement.

Datadog also needs account governance. Account, Region, service, team, and environment tags must remain consistent; collection permissions should have a defined scope. Identically named services and sensitive fields do not resolve themselves when the platform changes. Verify platform location, source-log location, backups, and support access separately.

Assign alert ownership as well. If both platforms detect the same failure, decide which sends notifications and handles escalation while the other supplies investigation data. One fewer duplicate page can matter more to an on-call engineer than another overview dashboard.

What stays on the AWS bill after you add Datadog?

CloudWatch pricing varies by Region and feature. A single monthly host price cannot describe it. Classic metrics involve metric counts and API usage; the current OpenTelemetry metrics path includes ingestion in GB and samples scanned by PromQL APIs. Logs have ingestion, storage, and query dimensions. Application Signals, traces, alarms, RUM, and Synthetics also need to be included where used.

Datadog's public annual-billing entry price for host-based APM is $31 per host per month when paired with Infrastructure Monitoring, or $36 per host per month for standalone APM. For ten hosts, Infrastructure Pro at $15 plus paired APM at $31 gives a $460 monthly base subtotal. It excludes logs, RUM, additional spans, other modules, and AWS-side costs. Datadog pricing

CloudWatch API or Metric Streams collection can leave AWS charges in place. Logs written to CloudWatch and forwarded through Firehose or Lambda may also incur charges along that path. Conversely, telemetry sent directly by an application or Agent should not automatically be modeled as two stored copies. Follow the actual route and account for each service used.

A fair estimate aligns metric types and counts, log GB, query frequency, trace sampling and retention, sessions, collectors, migration overlap, and operational work. Free allowances help with getting started; they do not establish that production use remains free. A shared platform might reduce handoffs, but without measured engineering effort that benefit should not become a guaranteed dollar saving.

Should an existing CloudWatch user switch?

Improve CloudWatch first when workloads are concentrated in AWS, the team understands account governance, supported application languages fit, and Application Signals plus log correlation covers the common incidents. A new platform should close an identifiable gap.

Pilot Datadog first when investigations regularly cross clouds and infrastructure layers, and several teams will standardize collection, tags, and workflows. Replay a previously investigated incident and price the modules and data required to follow it through.

Keep both where responsibilities are clear. CloudWatch can retain appropriate native data while Datadog receives what benefits from shared investigation. Define retention, alert ownership, and cost responsibility before enabling broad duplication. The combination can reuse existing work; unplanned overlap can leave duplicate data and notifications.

Official references

• Datadog AWS integration, log and trace correlation, and pricing
• EC2 monitoring, Application Signals onboarding, and SLOs
• Cross-account and cross-Region mechanisms, Logs Insights languages, and CloudWatch pricing

Sources checked October 21, 2026. Prices use public USD terms; taxes, Region, support, contractual discounts, and purchasing conditions require separate confirmation.