Cloud monitoring is the practice of tracking the health, performance, availability, and cost of resources running in the cloud: virtual machines, managed databases, serverless functions, queues, and the services built on them. It is infrastructure monitoring adapted to a world where the resources are rented, elastic, and often gone before you finish looking at them.
Definition: What Is Cloud Monitoring?#
Cloud monitoring continuously collects metrics, logs, and events from cloud-hosted resources and the managed services a provider runs on your behalf. The defining difference from on-prem monitoring is that you do not own the hardware; you see what the provider exposes (through services like AWS CloudWatch, Azure Monitor, or Google Cloud Monitoring) plus whatever your own agents add.
What Cloud Monitoring Covers#
- Compute: VMs, containers, and serverless function invocations and errors
- Managed services: databases, queues, caches, and load balancers the provider operates
- Scaling and availability: autoscaling activity, healthy instance counts, zone failures
- Network: traffic, latency, and data transfer between services and regions
- Cost: spend per service, since in the cloud a runaway resource is a bill, not just a load
- Logs and events: provider-emitted events that explain why something changed
What Makes the Cloud Different#
On-prem, a server sits there for years. In the cloud, resources are elastic and short-lived, which changes how you monitor:
- Ephemeral resources: instances come and go with autoscaling, so monitoring must track a moving population, not fixed hosts.
- You monitor the abstraction: for managed services you get the provider's metrics, not OS-level access.
- Cost is a first-class signal: scaling that keeps the app healthy can also quietly multiply the bill.
Cloud Monitoring vs Infrastructure Monitoring#
Cloud monitoring is a kind of infrastructure monitoring, specialized for rented, elastic resources.
| Cloud monitoring | Infrastructure monitoring (general) | |
|---|---|---|
| Resources | Provider-managed, elastic, ephemeral | Any: on-prem, cloud, hybrid |
| Access | Provider metrics + agents | Often full host access |
| Extra concern | Cost and autoscaling | Capacity planning |
Limitations to Know#
- Provider metrics have gaps and lag. You see what the provider exposes, on its schedule, not always in real time.
- Multi-cloud fragments the view. Each provider has its own tools and metric names; a single pane of glass takes extra work.
- Green dashboards can still cost a fortune. Health and spend are separate signals; watch both.
- Internal health is not user-facing availability. Every cloud resource can be healthy while users still cannot reach the app.
Best Practices#
- Monitor populations, not pets. Track healthy-instance counts and autoscaling, not named hosts.
- Put cost on a dashboard. Treat unexpected spend as an alertable event, not a month-end surprise.
- Use provider-native metrics, then fill gaps. Start with CloudWatch or its equivalent, add agents where you need depth.
- Add an outside-in check. Provider health says the resource is up; only an external check says users can reach it.
Conclusion#
Cloud monitoring tracks the performance, availability, and cost of elastic, provider-managed resources, adapting infrastructure monitoring to a world where hosts are rented and short-lived. The two signals that catch people out are cost, which scales with usage, and the gap between a healthy cloud dashboard and an app users can actually reach.
That last gap is where provider metrics go quiet. ObserveOne watches from the outside with uptime and API checks across multiple regions, so when every cloud resource reads healthy but the service is unreachable, you still get the alert.