What is Cloud Monitoring?

What is cloud monitoring?

Cloud monitoring is the continuous observation of workloads, services, and managed components running on a public cloud (AWS, GCP, Azure, OCI) or a hybrid mix of cloud and on-prem. It pulls metrics, logs, traces, and events from cloud-native sources (CloudWatch, Cloud Monitoring, Azure Monitor, the EKS or ECS control plane, RDS performance insights, S3 request metrics, ALB access logs, Lambda invocations) and from any agents you deploy onto VMs or containers, then exposes the result as dashboards, alerts, and incident workflows.

The output is the same shape as classic monitoring (charts, alerts, on-call rotations) but the data sources and unit of work are different: ephemeral containers instead of long-lived hosts, managed services instead of self-run daemons, per-invocation billing instead of fixed-cost servers. Tools in the space include Datadog, New Relic, Dynatrace, Grafana Cloud, AWS CloudWatch, Google Cloud Operations, and Azure Monitor.

Cloud monitoring vs on-prem monitoring vs APM

The disciplines overlap but the data shape differs:

• Cloud monitoring consumes managed-service metrics and ephemeral compute (containers, functions). The unit of work churns by the minute and tags drive grouping (account, region, service, environment).
• On-prem monitoring watches fixed hardware: hosts named in DNS for years, switches, storage arrays. Tooling like Nagios, Zabbix, or PRTG centers on SNMP and per-host installs.
• APM is orthogonal to both: it instruments application code regardless of where it runs and reports per-endpoint latency and errors. See application performance monitoring for the application layer.

Most teams running on cloud need cloud monitoring for infrastructure and APM for the application code; the on-prem path is shrinking but still relevant for regulated workloads.

What cloud monitoring covers

• Compute health: EC2/GCE/Azure VM CPU, memory, disk; ECS/EKS/GKE/AKS container counts, restarts, pending pods.
• Managed-service metrics: RDS connections, ElastiCache hit rate, DynamoDB throttles, S3 4xx/5xx, SQS queue depth, ALB target response time.
• Serverless: Lambda invocation count, duration, errors, throttles, concurrent executions; same for Cloud Functions and Azure Functions.
• Network and edge: CloudFront cache hit rate, NAT gateway bytes, VPC flow logs, Route 53 query volume.
• Cost signals: per-account daily spend, unblended cost by service or tag, anomaly alerts when daily spend jumps.
• Security and audit: CloudTrail events, GuardDuty findings, IAM access analyzer; not a SIEM substitute but the early warning layer.

Key cloud monitoring metrics

1. Availability per service: CloudWatch HealthyHostCount, ALB target health, RDS instance state, rolled up to an SLA target.
2. Latency per managed component: RDS query latency, ALB TargetResponseTime p50/p95/p99, S3 first-byte latency.
3. Error rate per layer: ALB HTTPCode_Target_5XX_Count, Lambda Errors, RDS deadlocks, SQS dead-letter depth.
4. Saturation: CPU credits remaining on burstable instances, RDS CPU and connection saturation, ElastiCache evictions, autoscaling group desired vs in-service.
5. Throughput: requests per second per service, bytes per second per network path, messages per minute through SQS/SNS/Kinesis.
6. Cost-per-request: spend divided by useful work, the long-term efficiency metric most teams ignore until the bill spikes.

How to run cloud monitoring

Start with the provider-native metric stream (CloudWatch metric streams to Firehose, or direct API polling for one cloud) and forward it to a central backend (Datadog, Grafana, your own Prometheus + Mimir). Tag every resource consistently (service, environment, team, cost-center) so the same dashboard query slices by any dimension. Layer on logs (CloudWatch Logs or Cloud Logging) and traces (X-Ray, Cloud Trace, OpenTelemetry to the same backend). Wire alerts to PagerDuty or Opsgenie with on-call rotations per service. Periodically prune metrics no team owns: cloud monitoring bills grow faster than infrastructure does.

Cloud monitoring sits next to load testing in the launch readiness pipeline. Run load testing or spike testing from outside the cloud network, watch the cloud-monitoring dashboards live, and capture which managed component saturates first (database connections, autoscaling lag, dead-letter queue depth). See also observability for the broader investigation framework that cloud monitoring feeds into.

If your team needs production-shape load runs that correlate cleanly with your cloud monitoring dashboards, LoadFocus offers load testing services with runs scheduled to align with your dashboard windows, summary reports cross-referenced to your CloudWatch or Datadog screenshots.