Monitoring cost compared: CloudWatch vs Azure Monitor vs Cloud Monitoring

Quick answer

CloudWatch, Azure Monitor, and Google Cloud Monitoring all bill on metrics (platform metrics largely free, custom metrics charged), logs ingested (per GB, usually the largest line), and API calls/alarms. The models are close, and on all three, log ingestion is the dominant cost. The shared levers, filtering and sampling logs, limiting high-cardinality custom metrics, and setting retention, matter more than the provider.

Observability, metrics, logs, traces, and alarms, is priced similarly across the three clouds, and the biggest line on all of them is usually log ingestion. Each provides generous free platform metrics and then charges for custom metrics, ingested logs, and API/alarm usage. The models are close enough that the shared optimizations matter more than the provider.

The shared cost structure

Component	All three clouds
Platform metrics	Largely free
Custom metrics	Charged (per metric / per time series)
Logs ingested	Per GB, usually the largest line
Alarms / API calls	Per alarm, per request

CloudWatch charges for custom metrics, logs ingested and stored, alarms, and API requests, as in CloudWatch metrics, CloudWatch Logs, and alarms. Azure Monitor charges by data ingested (logs and Application Insights) and metrics, as in Log Analytics. Cloud Monitoring charges for custom metrics and ingested logs, as in Cloud Logging. The shapes align.

Logs dominate everywhere

On all three, log ingestion is typically the largest observability cost, and high-cardinality custom metrics are the second. Platform metrics are largely free, so the bill grows with how much you log and how many custom time series you emit. This is consistent across clouds, so the optimization is too.

The shared levers

Filter and sample logs before ingestion (drop noisy, low-value logs), route logs that do not need real-time analytics to cheaper storage, limit high-cardinality custom metrics (unbounded labels explode time-series count), set retention to what you actually query, and alarm on service-level signals rather than every metric. These reduce ingestion and metric volume, the dominant costs, identically on CloudWatch, Azure Monitor, and Cloud Monitoring.

Choosing on cost

Use the monitoring service on the cloud where your workloads run (native integration, no cross-cloud egress), and on any of them apply the same discipline: ingest the logs and metrics you will act on, sample the rest, control cardinality, and set retention. The provider difference is minor; what you emit and retain dominates, so the effort transfers across clouds.

FAQ

Is CloudWatch, Azure Monitor, or Cloud Monitoring cheapest?

They are close, since all three bill on metrics (platform metrics largely free, custom metrics charged), logs ingested (per GB, usually the largest line), and alarms/API calls. The cheapest depends on your log and custom-metric volume, not the provider, so it is usually the service on the cloud your workloads run on, optimized the same way.

What is the biggest monitoring cost on all clouds?

Log ingestion. On CloudWatch, Azure Monitor, and Cloud Monitoring alike, ingested logs are typically the largest observability line, with high-cardinality custom metrics second. Platform metrics are largely free, so the bill grows with how much you log and how many custom time series you emit, consistently across clouds.

What are the shared monitoring cost levers?

Filter and sample logs before ingestion to drop noisy low-value logs, route logs that do not need real-time analytics to cheaper storage, limit high-cardinality custom metrics (unbounded labels explode time-series count), set retention to what you query, and alarm on service-level signals rather than every metric. These apply identically across the three clouds.

Why do custom metrics cost more than platform metrics?

Platform metrics (CPU, memory, standard service metrics) are collected by the cloud and largely free. Custom metrics you define and emit are charged per metric or per time series, and high-cardinality labels multiply the time-series count. So emitting many custom metrics, especially with unbounded label values, drives cost that platform metrics do not.

Should I choose a cloud based on monitoring cost?

No. The monitoring services are priced similarly with small differences, so use the one on the cloud where your workloads run for native integration and no cross-cloud egress, and apply the same discipline everywhere: ingest what you will act on, sample the rest, control cardinality, and set retention. What you emit and retain dominates cost.

Does C3X estimate monitoring cost?

Monitoring cost is driven by log ingestion and custom-metric volume, which are usage inputs. C3X prices the surrounding infrastructure across clouds, and you model log and metric volumes to estimate the observability charges and compare the shared optimization levers.

What to do next

Estimate the infrastructure behind your observability before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.