--- cuppy_hub: gcp cuppy_path: guides/parity/observability.md cuppy_section: docs cuppy_doc: VNMS-FXV1 cuppy_doc_uuid: 1673d165-0bdc-40cb-930b-4c1d4a477985 cuppy_permalink: https://cuppy.io/gcp/d/VNMS-FXV1 cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/gcp/docs/guides/parity/observability cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: cd2cea431a6edb75eb74b9f837729c8ce92b6464f9ba144399146c016b36f428 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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: 1. **GB of logs per day, by source**; 2. **number of custom and log-based metrics, and their label cardinality**; 3. **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. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.