Observability parity — Cloud Logging, Monitoring and Trace against CloudWatch/X-Ray and Azure Monitor
Counterpart names, then the three differences that change an estimate: OpenTelemetry makes tracing portable and vendor SDKs do not, the multi-project scope question has no counterpart shape, and observability cost is driven by volume and cardinality on all three — which makes it the one family where the estimate input is the same everywhere.
markdownguidev1VNMS-FXV1stage: designtrust: officialfamily: observabilityservice: cloud-monitoringinterface: anyobservability paritycloud loggingcloudwatch logsazure monitor logslog analyticscloud monitoringcloudwatchapplication insightscloud traceX-RayOpenTelemetrymetrics scopelabel cardinality
Observability parity
1. The names
| Google Cloud | AWS | Azure |
|---|---|---|
| Google Cloud Observability (formerly the operations suite / Stackdriver) | CloudWatch + X-Ray | Azure Monitor |
| Cloud Logging | CloudWatch Logs | Log Analytics (Azure Monitor Logs) |
| Cloud Monitoring | CloudWatch (metrics, alarms) | Azure Monitor metrics; Application Insights |
| Cloud Trace | AWS X-Ray | Azure Monitor / Application Insights |
| Cloud Profiler | CodeGuru Profiler | Application Insights Profiler |
| Cloud Audit Logs | CloudTrail | Azure Activity Logs |
| log-based metrics | CloudWatch metric filters | Log Analytics alerts on queries |
| PromQL querying in Cloud Monitoring | Amazon Managed Service for Prometheus | Azure Monitor managed service for Prometheus + Azure managed Grafana |
Microsoft maps several Google Cloud services onto Azure Monitor alone, which reflects something real: Azure consolidates more of this into one product than either of the other clouds.
The Cloud Audit Logs / CloudTrail / Activity Logs row deserves separating out. On all three clouds this is a distinct, separately-retained, separately-governed log stream, and it is the one an auditor asks about. Never let it be merged into the application-logging estimate.
2. Tracing is the one family where portability is a solved problem — if you take it
Cloud Trace recommends OpenTelemetry over Google-specific APIs. AWS and Azure both point at OpenTelemetry too (Microsoft's own container-insights row names managed Prometheus and managed Grafana in the same breath).
So the estimate splits cleanly:
| Source instrumentation | Tracing migration cost |
|---|---|
| OpenTelemetry | an exporter configuration change. Near zero |
| X-Ray SDK, Application Insights SDK, or any vendor SDK | application work, per service |
And the strongest recommendation this hub makes about migration sequencing comes from this row: if the estate is on a vendor tracing SDK, move it to OpenTelemetry on the source platform, before the migration. It is work you were going to do anyway, it removes a whole category of migration risk, and it pays for itself even if the migration is cancelled.
3. The multi-project scope question has no counterpart shape
Google Cloud's metrics scope, with its scoping project, exists because a Google Cloud estate is many
projects (reference/overview/projects-and-resource-hierarchy.md §4). AWS's boundary is the account and the
Region; Azure's is the Log Analytics workspace and the subscription.
Estimate consequence. The design question — "which boundary does one dashboard span, and who may read it" — exists on all three, and the answer object is different on each, so it cannot be ported as configuration:
| Google Cloud | AWS | Azure | |
|---|---|---|---|
| the aggregation object | metrics scope + a central logging project | cross-account CloudWatch observability | Log Analytics workspace design |
| the read-scoping object | log views on a bucket | IAM on log groups | workspace and table-level RBAC |
Budget this as a design task in every direction, not as a migration task. And do it early: discovering after a year that every dashboard was built in the wrong project is the expensive version.
4. Logging routing: Google Cloud's destination list is the thing to exploit
Cloud Logging routes to another project, a log bucket, BigQuery, Cloud Storage, or Pub/Sub, and "the destination can be in a different resource from where the log data originates".
| Need | Google Cloud | AWS | Azure |
|---|---|---|---|
| central, cross-account/project logging | a sink to another project | CloudWatch cross-account, or Firehose to a central account | a shared Log Analytics workspace |
| logs as SQL | a BigQuery sink | Athena over S3 | Log Analytics / KQL natively |
| cheap long retention | a Cloud Storage sink | S3 via Firehose | archive tier on a storage account |
| third-party SIEM | a Pub/Sub sink | Firehose | Event Hubs |
The shapes correspond closely, so a routing design ports. Two things do not port: retention defaults — and this hub deliberately quotes none, because the Cloud Logging overview does not state them — and exclusions, which are per-platform and are where the cost actually gets controlled.
5. Pricing dimension (never a price)
| Google Cloud | AWS | Azure | |
|---|---|---|---|
| logs | volume ingested, plus retention beyond the included period, plus the destination's own cost | ingestion plus storage plus queries scanned | per GB ingested plus retention, by table plan |
| metrics | custom and log-based metric volume and cardinality | custom metrics plus API requests plus alarms | metrics plus alert rules |
| traces | spans ingested | traces recorded and scanned | per GB, with sampling |
This is the one family where all three clouds meter the same thing: volume. So an observability estimate converts honestly between clouds — provided you have the inputs, which are the same three everywhere:
- GB of logs per day, by source;
- number of custom and log-based metrics, and their label cardinality;
- trace volume and the sampling rate.
Measure them on the source. They are also the three numbers that let you reduce the bill before moving, which is the rare case where the estimate work pays for itself immediately.
6. What this guide cannot tell you
Whether your dashboards and alerting policies can be converted automatically. In general they cannot: they are re-created. Count them — the count is the effort estimate. And note that each one also encodes a decision about what matters, which is worth re-examining rather than reproducing.