---
title: "Cloud Provider Observability: Is it right for you | Grafana Labs"
description: "Decide whether Cloud Provider Observability fits your multi-cloud monitoring needs."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

## Is it right for you?

Cloud Provider Observability meets your needs when:

- You run services on AWS, Azure, or Google Cloud (or a mix of all three) and need one place to monitor them.
- You’re switching between CloudWatch, Azure Monitor, and GCP Operations Suite to answer basic questions about what’s running and what’s broken.
- You’ve outgrown your cloud provider’s built-in monitoring tools. You need fast troubleshooting, not assembling dashboards and alerts by hand.
- You’re paying a per-host premium with your current observability vendor and your bill grows every time your cloud footprint does.
- Your team is spending engineering time maintaining scrape configs, dashboard mixins, and alert rules across providers. That’s time that should go to the product.

## Real results from real teams

- [**ASOS**](/success/asos/)
  
  > ASOS started with Grafana OSS specifically because it had an Azure Monitor plugin, handy for visualizing their Azure telemetry. But as they scaled, querying Azure Monitor and New Relic directly through Grafana started hitting rate limits and causing dashboard timeouts. The fix? Send Prometheus metrics into Grafana Cloud Metrics instead of querying Azure on the fly. That’s what pushed them from OSS to Cloud.
- [**TeleTracking**](/blog/inside-teletrackings-journey-to-build-a-better-observability-platform-with-grafana-cloud/)
  
  > TeleTracking built their own OSS stack to wrangle a sprawling AWS + Azure environment: EKS, AKS, EC2, Lambda, Azure VMs, the works. It got unsustainable fast. The multi-cloud complexity was a direct reason they moved to a managed solution.