Managed Prometheus on EKS, AKS, and GKE

by Bala

Amazon Managed Service for Prometheus, Azure Monitor managed Prometheus, and Google Cloud Managed Service for Prometheus compared

Introduction

Every major cloud now offers a managed, Prometheus-API-compatible metrics backend - the appeal is the same across all three: skip operating the storage, scaling, and high-availability concerns the Thanos, Cortex, and Mimir/VictoriaMetrics guides on this site cover self-managing, while keeping PromQL and remote-write compatibility so existing scrape configs, dashboards, and alerting rules mostly carry over unchanged.

Amazon Managed Service for Prometheus (AMP)

AMP is a workspace-based service - you create a workspace, get a remote-write endpoint and a query endpoint, and point an existing Prometheus (or a lightweight collector) at it. Because it’s an AWS API, writes and queries are authenticated with AWS SigV4, not a bearer token - the one real difference from a normal remote_write config:

aws amp create-workspace --alias eks-production
# prometheus.yml
remote_write:
  - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-xxxxxxxx/api/v1/remote_write
    sigv4:
      region: us-east-1

Prometheus’s native sigv4 remote-write auth block (no sidecar required on current Prometheus versions) signs each write request with the pod’s IAM identity - on EKS, that means IAM Roles for Service Accounts (IRSA) or EKS Pod Identity granting the Prometheus service account aps:RemoteWrite permission, rather than a static credential in the config.

apiVersion: eks.amazonaws.com/v1
kind: PodIdentityAssociation
metadata:
  name: amp-write
spec:
  serviceAccount: prometheus
  namespace: monitoring
  roleArn: arn:aws:iam::123456789012:role/amp-remote-write-role

Querying uses the same SigV4 signing, which means Grafana needs the Amazon Managed Grafana data source (or the open-source Grafana AWS SigV4 plugin) rather than a plain Prometheus data source pointed at the query URL - a detail that trips up teams expecting a drop-in Prometheus data source to work unmodified.

Azure Monitor Managed Service for Prometheus

Azure’s implementation is built into AKS as an optional add-on, collecting metrics via the Azure Monitor agent (ama-metrics) running as a DaemonSet (for node-level metrics) and ReplicaSet (for cluster-level scraping) rather than a Prometheus you deploy and manage yourself:

az aks update \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --enable-azure-monitor-metrics \
  --azure-monitor-workspace-resource-id /subscriptions/.../resourceGroups/.../providers/microsoft.monitor/accounts/myAmw

Scrape targets are configured through Kubernetes-native ConfigMaps that follow the Prometheus Operator’s PodMonitor/ServiceMonitor shape closely enough that existing custom-resource-based scrape configs need only minor adaptation, not a full rewrite - the add-on layers Azure’s collection and storage underneath an interface deliberately kept close to what a self-managed Prometheus Operator setup already looks like.

Data lands in an Azure Monitor workspace, queried via PromQL either directly in the Azure portal’s Metrics explorer or through Grafana using the Azure Monitor workspace data source (available in both self-hosted Grafana with the Azure plugin and Azure Managed Grafana).

Google Cloud Managed Service for Prometheus (GMP)

GMP is enabled by default on new GKE Autopilot clusters (and available as an add-on on Standard clusters), and - notably, differently from AMP and Azure’s approach - uses its own CRDs rather than the Prometheus Operator’s ServiceMonitor/PodMonitor:

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: myapp
  namespace: production
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
    - port: metrics
      interval: 30s

PodMonitoring (namespace-scoped) and ClusterPodMonitoring (cluster-wide) are GMP’s equivalents to the Prometheus Operator’s CRDs - close enough in shape to port an existing PodMonitor to, but not literally compatible, so migrating an existing Prometheus-Operator-based scrape config to GMP means translating these CRDs, not applying the old ones unchanged. GMP runs its collection via an OpenTelemetry-based collector (not vanilla Prometheus) managed automatically by GKE, storing data in Google Cloud Monitoring.

Querying supports both the Cloud Monitoring console’s native PromQL tab and a Prometheus-compatible query API that a standard Grafana Prometheus data source can point at directly (using a Google service account for auth), which - unlike AMP’s SigV4 requirement - doesn’t need a cloud-specific Grafana plugin for the query side.

Choosing Between Self-Managed and Managed

The tradeoff is consistent across all three clouds: managed Prometheus removes the operational burden of running Thanos/Cortex/Mimir/VictoriaMetrics yourself (storage scaling, compaction, HA), at the cost of some vendor-specific integration friction (AMP’s SigV4 auth, GMP’s own CRDs) and being tied to that cloud’s pricing and API surface. Self-managed remains the better fit for genuinely multi-cloud or hybrid environments where a single metrics backend needs to receive writes from clusters across providers - none of the three managed services is designed as a cross-cloud target for another provider’s clusters.

Best Practices

  1. Confirm the query-side auth story before committing - AMP’s SigV4 requirement on queries (not just writes) is the detail most likely to break an existing Grafana setup that assumed a plain Prometheus data source.
  2. Use PodMonitoring/ClusterPodMonitoring from the start on GKE rather than deploying the Prometheus Operator’s CRDs and hoping for compatibility - they’re a different API, not a compatible one.
  3. Set workspace/account-level retention and quota limits deliberately on any of the three - all bill by ingested samples and/or storage, and an unbounded high-cardinality label (see the PromQL deep-dive on cardinality pitfalls) has a direct, sometimes large, cost impact on a managed service in a way it doesn’t on self-hosted storage you already provisioned.
  4. Keep scrape configs and PromQL as close to vanilla as practical even when using a managed service - it’s what preserves the option to move to self-managed Mimir or VictoriaMetrics later without redesigning every dashboard and alert.

Conclusion

All three clouds converge on the same value proposition - Prometheus-API-compatible storage without operating it yourself - but differ meaningfully in the mechanics: AMP’s SigV4 authentication on both ends, Azure’s Prometheus-Operator-shaped-but-not-identical config surface, and GMP’s genuinely separate CRDs. None of these differences shows up until you actually try to point an existing setup at one, which is the reason to check the specific integration details before assuming “managed Prometheus” means “no changes needed.”

Additional Resources