Cloud monitoring for AWS, Azure and Google Cloud

What is cloud monitoring?

Cloud monitoring is the practice of collecting and analyzing telemetry from cloud infrastructure and managed services to keep them available, performant, secure and cost-efficient. It covers virtual machines and containers you operate yourself as well as managed services such as databases, object storage, load balancers, queues and functions on AWS, Azure and Google Cloud.

Unlike a data center, the cloud is defined by APIs. Resources appear and disappear within minutes, many components are operated by the provider, and visibility often depends on what the provider exposes through services like Amazon CloudWatch, Azure Monitor or Google Cloud Monitoring. Cloud monitoring has to combine those provider metrics with your own application telemetry to be useful.

Why cloud monitoring matters

Most teams now run on more than one cloud or at least across many accounts, subscriptions and projects. Each provider has its own console, metric names and query languages. During an incident, switching between them costs time, and the relationship between a slow managed database and an affected checkout service is rarely obvious.

Shared responsibility also means you cannot fix the provider's infrastructure, but you still own the user experience. Cloud monitoring tells you whether a problem sits in your code, your configuration or a provider service, and helps you prove it with data. It also exposes idle and oversized resources that drive up the bill.

Finally, cloud monitoring supports governance. Audit logs reveal who changed a security group or scaled a database, and that change history is often the fastest way to explain why behavior shifted at a specific minute.

Key cloud metrics to watch

• Compute: CPU, memory, disk I/O and network per instance, plus status checks and autoscaling activity.
• Managed databases: connections, query latency, replication lag, storage and IOPS consumption.
• Load balancers and gateways: request count, 4xx and 5xx rates, target response time and unhealthy targets.
• Storage: request latency, error rates and throttling for object and block storage.
• Messaging and serverless: queue depth, message age, invocations, errors, duration and throttles.
• Quotas and limits: service limits and throttling events that silently cap capacity.
• Audit and flow logs: configuration changes and unexpected network traffic.

How Obseria handles cloud monitoring

Obseria connects to AWS, Azure and Google Cloud with read-only access and monitors more than 300 services agentless. Resources are discovered across accounts and regions, enriched with your tags and placed in Obseria TopoGraph next to your Kubernetes workloads and application services. On virtual machines and clusters, the Obseria Agent adds host metrics, logs, traces and profiles, and applications instrumented with OpenTelemetry send data over OTLP.

Because everything lands in Obseria Lake, you query cloud metrics and application data together with OQL, PromQL or SQL. For example, you can compare load balancer errors with application exceptions for the same service in one query. Obseria Intelligence detects anomalies, follows dependencies across cloud layers and shows the chain of evidence behind a root cause.

Obseria Pipeline processes cloud logs at ingest: it filters noisy entries, masks PII and routes data to the right retention. You choose where data is stored: EU regions in Frankfurt and Dublin, the UK in London, or your own cloud account with BYOC.

Cloud monitoring best practices

1. Enforce a tagging standard. Team, service, environment and cost center tags make ownership and cost allocation possible.
2. Monitor from the user inward. Start with SLOs for user-facing services, then drill into the cloud resources behind them.
3. Watch limits and quotas. Throttling and exhausted quotas cause outages that look like application bugs.
4. Use one query model. Normalize metrics across providers so dashboards and alerts work everywhere.
5. Keep telemetry portable. OpenTelemetry and OTLP export protect you from lock-in to any single vendor.
6. Review cost alongside performance. Put spend next to latency and error rates so rightsizing decisions are based on real usage, not guesses.