Cloud Monitoring and Management Services: AWS vs Azure vs Google Cloud
Metrics, logs, APM, audit trails, infrastructure as code and ops tooling: what each management service does and how CloudWatch, Azure Monitor and Cloud Monitoring compare.
It’s 3 am, the pager goes off, and the dashboard says everything is green. Or the dashboard is red and nobody can tell why, because the logs from the failing service were never shipped anywhere. Monitoring and management services are what stand between you and those nights. They tell you what’s happening, who changed what, and they let you manage infrastructure as code instead of by hand. This post covers the six parts of the category and compares the AWS, Azure and Google Cloud services for each.
What monitoring and management covers
This category is really two jobs that share tooling:
- Observability. Understanding the state of your systems through metrics (numbers over time), logs (events), traces (requests across services) and audit trails (who did what to the platform).
- Management. Defining infrastructure as code, keeping fleets patched and configured, and acting on recommendations.
| Need | Typical question | Signal |
|---|---|---|
| Metrics and alerts | Is the service healthy right now? | CPU, latency, error rate, queue depth |
| Logs | What exactly happened? | Application and platform log lines |
| APM and tracing | Where is the time going in this request? | Spans across services |
| Audit | Who changed this, and when? | Control-plane API calls |
| Infrastructure as code | How do we rebuild this reliably? | Templates in version control |
| Operations | Are we patched, right-sized and following best practice? | Inventory, recommendations |
OpenTelemetry has become the common language for application telemetry, and all three providers accept it natively. Instrument with OpenTelemetry and you keep the option to switch backends later.
Metrics, dashboards and alerting
Every cloud resource emits platform metrics automatically. Monitoring services store them, chart them and alert when they cross thresholds. You add custom metrics from your applications, and increasingly Prometheus metrics from Kubernetes, which all three now support as a managed service.
Good alerting is about restraint. Alert on symptoms users feel (error rate, latency, availability against an SLO), not on every CPU spike. Every alert should be actionable, and every page should have a runbook. Too many noisy alerts and people start ignoring the important ones.
Amazon CloudWatch Soon
Collects metrics from every AWS service, custom metrics via the CloudWatch agent or OpenTelemetry, dashboards, alarms (static, anomaly detection, composite) and actions such as autoscaling or SNS notifications. Amazon Managed Prometheus and Managed Grafana cover open-source stacks.
Platform metrics for every Azure resource, metric and log alerts with action groups, workbooks and dashboards. Azure Monitor managed service for Prometheus and Azure Managed Grafana support Kubernetes and open-source tooling.
Cloud Monitoring Soon
Metrics for Google Cloud services and custom metrics, dashboards, uptime checks, SLO monitoring and alerting policies. Google Cloud Managed Service for Prometheus stores Prometheus metrics at global scale with PromQL support.
Log management
Logs are your detailed record of what happened. Cloud logging services collect them from platform services, VMs, containers and applications, index them, and let you query across everything. The main levers are what you ingest and how long you keep it, because logging is easily one of the largest line items on a cloud bill.
Use structured (JSON) logs with consistent fields such as trace ID, user and tenant, so queries are reliable. Set retention deliberately, and route verbose or compliance-only logs to cheaper tiers or object storage.
CloudWatch Logs Soon
Centralised log groups with retention settings, Logs Insights for interactive queries, metric filters, subscription filters to stream logs onward, and an Infrequent Access class for cheaper storage.
Workspaces that store logs from resources, VMs, containers and apps, queried with KQL. Analytics, Basic and Auxiliary table plans trade query capability for price; data collection rules control what’s ingested.
Cloud Logging Soon
Ingests logs from Google Cloud services automatically; log router sinks send them to buckets, BigQuery, Pub/Sub or Cloud Storage. Log Analytics lets you query logs with SQL.
Log ingestion is billed per GB. A debug log level left on in production, or a health-check endpoint logging every request, can quietly double your monitoring bill. Review your top log sources by volume every month.
Application performance monitoring and tracing
Metrics tell you that latency went up. Traces tell you which hop got slow. Distributed tracing follows a request through gateways, services, queues and databases, so you can see where time is spent and where errors start. APM tools add service maps, dependency tracking and code-level insight.
CloudWatch Application Signals and X-Ray Soon
Application Signals gives service maps, SLOs and golden-signal dashboards from OpenTelemetry instrumentation; AWS X-Ray provides distributed tracing. CloudWatch RUM and Synthetics cover front-end and canary monitoring.
APM built on Azure Monitor with the OpenTelemetry-based distro. Request, dependency and exception telemetry, application map, live metrics, availability tests and distributed tracing across services.
Cloud Trace and Cloud Profiler
Cloud Trace collects distributed traces (OpenTelemetry-native) and latency reports; Cloud Profiler gives continuous low-overhead CPU and memory profiling in production.
Audit logs
Audit logs record control-plane activity: who created, changed or deleted a resource, from where, and whether it succeeded. They’re essential for security investigations, compliance and plain debugging (“who changed the NSG on Friday?”).
Two things to get right: send audit logs from every account, subscription or project to a central, locked-down location that workload teams can’t modify, and keep them longer than the default 90 days your auditors won’t accept.
AWS CloudTrail Soon
Records every API call across your AWS accounts. Event history covers 90 days for free; organisation trails deliver logs to S3, and CloudTrail Lake stores and queries events with SQL.
Subscription-level log of control-plane operations (who created, changed or deleted what), kept for 90 days. Send it to a Log Analytics workspace or storage with diagnostic settings for longer retention. Entra ID has separate sign-in and audit logs.
Cloud Audit Logs Soon
Admin Activity logs (always on, free), Data Access logs (opt-in), System Event and Policy Denied logs for every project, folder and organisation. Route them to a central bucket with an aggregated sink.
Infrastructure as code
Clicking resources together in a portal doesn’t scale and can’t be reviewed or reproduced. Infrastructure as code (IaC) defines resources in version-controlled templates, deployed through pipelines, with plans or previews before changes are applied.
Each provider has a native tool, and Terraform/OpenTofu works across all three. Native tools get new features first and need no state management. Terraform gives one language for multi-cloud and SaaS providers. Many teams use Terraform for the foundations and native tooling or the CDK where it fits better.
AWS CloudFormation Soon
Declarative templates in YAML or JSON, with stacks, change sets, drift detection and StackSets for multi-account deployment. The AWS CDK generates CloudFormation from TypeScript, Python, Java, Go or .NET.
The deployment and management layer behind every Azure request. Author templates in Bicep (or ARM JSON), store them as template specs and manage lifecycle and locks with deployment stacks. What-if previews changes before you deploy.
Google’s managed Terraform service that runs plan and apply in Google Cloud with state handled for you. It replaces Cloud Deployment Manager, whose support ended in 2026; Deployment Manager shuts down on 30 June 2027.
Google Cloud Deployment Manager is end of support and shuts down on 30 June 2027. Existing resources keep running, but you won’t be able to manage them through Deployment Manager after that date. Migrate to Infrastructure Manager (Terraform) or another tool now.
For Terraform specifics, start with the Terraform introduction and Terraform best practices.
Operations and recommendations
The last piece is day-two operations: patching fleets, running commands at scale, getting shell access without exposing SSH, and acting on the providers’ own recommendations for cost, security and reliability. These advisors are free (or nearly) and genuinely useful. Review them monthly.
AWS Systems Manager Soon
Patch Manager, Session Manager (shell access without SSH or bastions), Run Command, State Manager, Parameter Store and inventory for EC2 and hybrid servers.
AWS Trusted Advisor Soon
Best-practice checks across cost, security, fault tolerance, performance and service quotas. Full checks require Business support or higher.
Runbooks (PowerShell and Python) for scheduled operations, plus state configuration. Patching has moved to Azure Update Manager, which works for Azure and Arc-enabled servers.
Free personalised recommendations for cost, security, reliability, operational excellence and performance, aligned with the Well-Architected Framework and with an Advisor score.
VM Manager and Active Assist
VM Manager handles OS patching, inventory and configuration for Compute Engine fleets. Active Assist (the Recommender) suggests right-sizing, idle resource clean-up, IAM tightening and committed-use purchases.
Comparing the providers
- AWS CloudWatch is broad and deeply integrated, but spread across many sub-features. CloudTrail is the gold standard for API auditing, and the CDK is a strong developer-friendly IaC option.
- Azure Monitor brings metrics, logs (Log Analytics with KQL) and APM (Application Insights) into one platform, and KQL is a powerful query language once learned. Bicep is the nicest native IaC syntax of the three.
- Google Cloud Observability is clean and well integrated, with strong SLO tooling inherited from Google’s SRE practice. Its IaC story is now Terraform-based through Infrastructure Manager.
Common pitfalls
- Dashboards without alerts (or alerts without owners). Nobody watches dashboards at 3 am. Alerts need routing, owners and runbooks.
- Collecting everything. Ingest what you’ll use. Sample traces, drop noisy logs, and keep high-cardinality custom metrics under control.
- Per-team silos. If each team has its own workspace and conventions, cross-service incidents are slow to debug. Agree on shared fields, trace propagation and central audit logging.
- ClickOps drift. Manual portal changes break IaC. Use drift detection, lock production down to pipeline identities, and treat portal changes as incidents.
- Ignoring advisors. Advisor, Trusted Advisor and Active Assist find idle resources, missing backups and risky settings for free. Schedule a monthly review.
Conclusion
Instrument with OpenTelemetry, alert on user-facing symptoms, centralise logs and audit trails, and manage everything through code. The native services on each cloud are good enough for most teams, and the bigger wins come from discipline: structured logs, sensible retention, actionable alerts and no manual changes. As a next step, pick your most important service and write down its SLO, the alert that fires when it’s breached, and the runbook that goes with it. See every service side by side in the Monitoring & Management comparison.