What happens when your dashboards are all green but users are still complaining? That gap is where the observability versus monitoring debate stops being academic and starts costing money. Monitoring tells you whether a system is broken in ways you predicted. Observability tells you whether you can figure out why it broke in ways you never predicted. By 2027, the three hyperscalers have built very different machines for answering that second question, and the architecture choices behind CloudWatch, Azure Monitor and Google Cloud Observability will shape your bill, your on-call rotation and your exit options.
This article walks through how each platform actually works under the hood, where the real trade-offs sit, and which decisions tend to age well once the hype settles.
The definitional split that keeps confusing teams
It helps to separate the two words before comparing products. Monitoring is the practice of watching predefined signals against thresholds: CPU above 80 percent, error rate above one percent, disk nearly full. It works beautifully for known failure modes and poorly for everything else.
Observability is the property of being able to ask new questions of your telemetry without shipping new code. That requires high-cardinality data, usually logs, metrics and traces joined by shared identifiers, so an engineer can slice by customer ID, build version or region on the fly.
The split is definitional, not a product feature. No vendor sells “observability” as a checkbox. What vendors sell is a data model, an ingestion path and a query engine, and those three things determine how observable your system can actually become.
CloudWatch: metric-centric by design
AWS CloudWatch grew up around metrics. CloudWatch Metrics, CloudWatch Logs and X-Ray for traces are adjacent services that share a console more than they share a data model. X-Ray launched in 2016 with a tracing model that predates OpenTelemetry, which is why AWS later added OpenTelemetry-compatible tracing paths rather than rewriting X-Ray.
The practical consequence is per-metric billing. Every custom metric you publish, multiplied by every dimension combination, becomes a line item. Publish a latency metric with five dimensions and ten possible values each, and you have quietly created thousands of billable series. Teams discover this the hard way, usually in the same month they add environment and customer-tier dimensions.
What CloudWatch does well: it is already wired into nearly every AWS service, alarm routing through SNS and EventBridge is mature, and infrastructure signals cost little to collect. What it does poorly: ad hoc, high-cardinality exploration across signals. That is the gap third-party backends fill, and it explains why so many AWS shops export only aggregates to CloudWatch and keep the detailed data elsewhere.
Azure Monitor: one query engine over many signals
Azure Monitor takes a different shape. It is organized around a shared data platform: Log Analytics workspaces queried with KQL, Application Insights for application performance monitoring, and a common data collection rule model introduced in the early 2020s to standardize how telemetry gets ingested.
That architecture feels closer to “one query engine over many signals” than CloudWatch’s per-service model. KQL is genuinely expressive, and joining application traces against infrastructure logs in a single query is a real advantage during incidents. Application Insights also gives teams distributed tracing and dependency maps without assembling three services by hand.
The trade-off is governance overhead. Workspace design, retention settings and table plans become architecture decisions with cost consequences. A common mistake is letting every team create its own workspace, then discovering that cross-service queries across workspaces are slower and messier than they needed to be. The teams that do well on Azure usually standardize on a small number of workspaces with clear ownership.
Google Cloud: Prometheus compatibility as the bridge
Google Cloud Observability is built on Cloud Monitoring (formerly Stackdriver), Cloud Logging and Cloud Trace, with the Managed Service for Prometheus acting as the bridge to open-source-style metrics. That bridge matters. Prometheus’s label model is what most engineering teams already understand, and Google leaned into Prometheus compatibility plus OTLP ingestion during 2023 and 2024.
For teams already running Kubernetes, this is the smoothest on-ramp of the three. Workloads instrumented with OpenTelemetry or a Prometheus client library can ship data with relatively little translation. For teams deeply invested in Google’s own tooling, the integration is tight.
The catch is familiarity. Fewer engineers have deep Cloud Monitoring experience than CloudWatch or Azure Monitor experience, so hiring and documentation costs can run higher. The architecture itself is sound; the operational muscle memory is thinner.
Comparing the three architectures side by side
| Dimension | CloudWatch | Azure Monitor | Google Cloud Observability |
|---|---|---|---|
| Core model | Metric-centric, per-service | Shared platform, single query language | Prometheus-compatible metrics plus native logs and traces |
| Query experience | Per-service consoles, CloudWatch Logs Insights | KQL across Log Analytics and Application Insights | PromQL and Cloud Logging query language |
| High-cardinality handling | Costly per custom metric | Costly per ingested volume and retention | Costly per series and volume |
| OpenTelemetry support | Added for metrics and traces, maturity varies by signal | Accepted via data collection rules, varies by signal | Accepted via OTLP, varies by signal |
| Strongest fit | AWS-native infrastructure estates | Organizations standardizing on one query engine | Kubernetes and Prometheus-heavy environments |
Read that table as a starting point, not a verdict. Pricing and per-signal OpenTelemetry maturity change frequently, so verify current behavior per service before committing. A useful companion read is this breakdown of AWS vs Azure vs Google Cloud architecture decisions, which covers the broader platform trade-offs these observability choices sit inside.
Cardinality is the constraint that decides your bill
If one technical concept deserves a full section, it is cardinality: the number of unique combinations of label values in a metric. Low cardinality looks like `status_code=500`. High cardinality looks like `user_id=88412`.
High cardinality is where observability lives, because “which customers are affected” is a high-cardinality question. It is also where costs explode, because every platform charges roughly per series or per volume. The pattern that emerged through 2025 and 2026 is pragmatic: keep high-cardinality detail in a dedicated store, whether that is Prometheus with remote storage, a vendor observability backend, or object storage queried on demand, and export only aggregates to the hyperscaler’s native tooling.
This is also where storage architecture intersects observability budgets. Long-retention telemetry often lands in cheap object storage, and the design questions look a lot like the ones in this comparison of Backblaze B2 vs Google Cloud vs Azure Blob architecture. Getting retention tiers right can cut observability spend more than any dashboard cleanup.
Instrument once, route anywhere
The single most durable decision for 2027 is vendor-neutral instrumentation. Instrument with OpenTelemetry SDKs, route through the OpenTelemetry Collector, and treat the backend as swappable infrastructure rather than a permanent commitment.
The Collector’s processor and exporter pipeline is the standard mechanism for this. Sampling, filtering, redaction and routing all happen in one place, outside application code. When a vendor raises prices or a migration mandate arrives, you change an exporter configuration instead of re-instrumenting hundreds of services.
Teams that have done this recommend one step: run the Collector as a proxy in front of your existing backend, even if you have no plans to switch. You get sampling and cost control immediately, and you keep the option to switch at no extra cost. The common mistake is instrumenting directly against a vendor SDK “just to move fast,” which is how lock-in gets baked in.
Cost control belongs in the pipeline, not the dashboard
Observability budgets are being consolidated. A recurring theme from 2024 through 2026 is teams reducing vendor count and settling on one primary backend plus native hyperscaler tools for infrastructure signals. The mechanics that make this work are unglamorous:
- Sample at the SDK or Collector layer, keeping all traces for errors and a fraction for successes.
- Set tiered retention, with hot storage measured in days and cold storage in months.
- Put the Collector in proxy mode so backends can be swapped without touching application code.
- Review cardinality monthly, because dimensions accumulate quietly.
- Tag every telemetry stream with a cost owner so bills have names attached.
None of these require a new vendor. All of them require someone to own the pipeline. If you are tracking spend across providers, the approach in this guide to multi-cloud metrics tracked across AWS, Azure and Google Cloud maps well onto telemetry cost reporting.
Where regulation and residency enter the picture
Data residency and sector rules increasingly shape backend choice. Telemetry frequently contains personal data: user identifiers, IP addresses, request payloads. Under regimes like GDPR, shipping that data to a region or vendor outside your compliance boundary is a genuine problem, not a theoretical one.
The architecture answer is regional routing through the Collector, plus redaction before export. Decide early which fields can leave which region, and encode that as Collector processor rules rather than relying on individual developers to remember. Teams that defer this decision usually end up retrofitting redaction under deadline pressure, which is the worst time to do it.
How the platforms are converging
All three hyperscalers now accept OpenTelemetry data, which sounds like convergence but is better described as a shared front door with different rooms behind it. Ingestion standards are converging; data models, query languages and billing structures are not.
That distinction matters for planning. Betting on OpenTelemetry as your instrumentation layer is safe. Betting that the three platforms will become interchangeable is not. Build for portability at the instrumentation and pipeline layers, and accept that the query and cost layers will remain platform-specific.
For teams weighing GPU-heavy workloads alongside their observability stack, the cost-model thinking in this analysis of AWS vs Azure vs GCP GPU cloud pricing architecture decisions follows the same logic: the pipeline determines the bill more than the console does.
Conclusion
The observability versus monitoring question resolves into three architecture decisions that will still matter in 2027. First, instrument with OpenTelemetry and route through a Collector so the backend stays swappable. Second, keep high-cardinality data in a store priced for it, and export only aggregates to native cloud tooling. Third, treat telemetry cost and data residency as pipeline concerns with named owners, not dashboard settings someone might tune later.
CloudWatch rewards AWS-native estates with tight integration and predictable infrastructure signals. Azure Monitor rewards organizations that want one query engine across many signals. Google Cloud Observability rewards Kubernetes and Prometheus-heavy teams. None of them is the wrong answer. Choosing one without deciding how you will instrument, sample and exit is.
FAQ
What is the main difference between observability and monitoring?
Monitoring watches predefined signals against thresholds to detect known failure modes. Observability is the ability to ask new questions of your telemetry, such as which customers a bug affects, without shipping new code. Monitoring answers “is it broken?” Observability answers “why, and for whom?”
Does CloudWatch support OpenTelemetry?
Yes, AWS added native OpenTelemetry support for CloudWatch metrics and traces, with rollout across 2023 and 2024. Maturity differs by signal, so verify current behavior for the specific signal type you plan to send before standardizing on it.
Is Azure Monitor a single product or several?
It is a shared data platform rather than one product. Log Analytics workspaces handle log queries with KQL, Application Insights provides application performance monitoring, and data collection rules standardize ingestion. The value comes from querying across those signals together.
Why does high cardinality cost so much?
Every unique combination of label values becomes a separate billable time series. High-cardinality dimensions like user ID or request ID multiply that count quickly. Since high cardinality is exactly where useful debugging data lives, teams keep detail in a dedicated store and export only aggregates to native cloud tooling.
What is the OpenTelemetry Collector and why does it matter?
It is a pipeline component that receives, processes and exports telemetry. Because sampling, redaction and routing happen there instead of in application code, you can change backends by editing configuration. That makes it the main hedge against vendor lock-in.
Which platform should a Kubernetes-heavy team choose in 2027?
Google Cloud Observability is the smoothest fit, thanks to Managed Service for Prometheus and OTLP ingestion. That said, a team can run Prometheus and OpenTelemetry on any cloud. The instrumentation and pipeline choices matter more than the console you log into.
