AWS monitoring for EC2, EKS, RDS, S3 and beyond
Collect CloudWatch metrics from 300+ AWS services without agents, add deep host and trace data with the Obseria Agent and OpenTelemetry, and see cost next to performance.
Why monitor AWS with Obseria
Agentless in minutes
Connect an AWS account with a read-only IAM role and CloudWatch metrics for 300+ services start flowing, region by region.
Beyond CloudWatch
Combine CloudWatch with OpenTelemetry traces, logs and host metrics from the Obseria Agent, so you see why a service is slow, not only that it is.
Cost in context
Put AWS billing data next to utilization and traffic, so oversized instances and idle resources show up where engineers already look.
AWS services Obseria monitors
- Amazon EC2. CPU, network, disk and status checks per instance, plus process-level detail with the Obseria Agent.
- Amazon EKS. Cluster, node, pod and container health via the Obseria Agent DaemonSet and the control plane metrics.
- Amazon RDS and Aurora. Connections, latency, IOPS, replica lag and free storage for every engine.
- Amazon S3. Bucket size, object counts, request rates and 4xx/5xx errors.
- Elastic Load Balancing. ALB and NLB request counts, target response time, healthy hosts and error codes.
- CloudWatch and AWS billing. Metrics and logs from any CloudWatch namespace, plus estimated charges for cost monitoring.
The AWS signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Server health
Shows whether your servers are running smoothly or overloaded, so problems are spotted before customers notice them.
Database performance
Tells you if your databases answer quickly, have enough room to grow and can handle the current number of users.
Customer experience
Reveals how fast your website and services respond and how often visitors run into errors instead of results.
Storage and spend
Keeps cloud storage growth and the expected monthly bill in view, so cost surprises are caught early.
Show all 9 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
AWS/EC2 CPUUtilization | Percent | Share of allocated vCPU in use; sustained high values point to undersized instances. |
AWS/EC2 StatusCheckFailed | Count | Failed instance or system status checks, an early sign of host or OS trouble. |
AWS/RDS DatabaseConnections | Count | Open client connections; spikes often precede connection exhaustion. |
AWS/RDS ReadLatency | Seconds | Average time per disk read I/O on the database instance. |
AWS/RDS FreeStorageSpace | Bytes | Remaining storage; alert well before the volume fills up. |
AWS/ApplicationELB TargetResponseTime | Seconds | Time from request leaving the load balancer to the target response. |
AWS/ApplicationELB HTTPCode_Target_5XX_Count | Count | Server errors returned by your targets behind the ALB. |
AWS/S3 BucketSizeBytes | Bytes | Daily storage size per bucket and storage class. |
AWS/Billing EstimatedCharges | USD | Estimated month-to-date charges per account and service. |
Set up AWS monitoring in minutes
- Step 1
Create a read-only IAM role
Create an IAM role that Obseria can assume, with a trust policy for cross-account access and a read-only policy such as ReadOnlyAccess or CloudWatchReadOnlyAccess.
- Step 2
Connect the account and regions
Enter the role ARN in Obseria, choose regions and services, and agentless polling of CloudWatch metrics and tags begins.
- Step 3
Add depth where it matters
Install the Obseria Agent on EC2 or as a DaemonSet on EKS, and point OpenTelemetry SDKs at your OTLP endpoint for traces.
# Create a role Obseria can assume (trust.json holds your cross-account trust policy)
aws iam create-role \
--role-name ObseriaReadOnly \
--assume-role-policy-document file://trust.json
# Grant read-only access to CloudWatch metrics, tags and resource metadata
aws iam attach-role-policy \
--role-name ObseriaReadOnly \
--policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
# Print the role ARN to paste into Obseria
aws iam get-role --role-name ObseriaReadOnly --query 'Role.Arn' --output textOut of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- AWS account overview by region and service
- EC2 fleet health and rightsizing candidates
- RDS performance and storage forecast
- ALB latency and 5xx error rate alerts
- AWS cost trend with anomaly alerts
AWS monitoring: what matters
Why AWS monitoring needs more than the console
AWS monitoring starts with CloudWatch, which publishes metrics for almost every managed service. That is a good base, but most production incidents cross service boundaries: a slow RDS query raises ALB response time, which triggers autoscaling on EC2, which drives up cost. In the console these signals live in separate namespaces, regions and accounts. Real AWS observability means correlating them with each other and with the application code that runs on top.
Teams also run AWS at scale across many accounts and regions. Without a single view, on-call engineers switch between consoles while an incident is open. A central platform that pulls in CloudWatch metrics, logs, traces and billing data shortens the path from alert to cause.
The AWS metrics that matter
Every service has dozens of metrics, but a handful carry most of the signal. Apply the golden signals per tier:
- Compute (EC2, EKS):
CPUUtilization, network in and out,StatusCheckFailed, and for EKS node and pod CPU, memory and restarts. CloudWatch basic metrics have no memory data for EC2, so the Obseria Agent fills that gap. - Databases (RDS, Aurora):
DatabaseConnections,ReadLatencyandWriteLatency,FreeStorageSpace,ReplicaLagandCPUUtilization. - Traffic (ELB):
RequestCount,TargetResponseTime,HTTPCode_Target_5XX_CountandUnHealthyHostCount. Together they give you rate, errors and duration at the edge. - Storage (S3):
BucketSizeBytesandNumberOfObjectsdaily, plus request metrics such as5xxErrorsif enabled on the bucket. - Cost:
EstimatedChargesfrom the billing namespace, broken down by service and linked account.
Common AWS problems and how to detect them
Database saturation. Rising DatabaseConnections with flat traffic usually means connection leaks or missing pooling. Pair it with trace data to find the service that holds connections open.
Unhealthy targets. A growing UnHealthyHostCount on an ALB target group often follows a bad deployment. Correlating it with deployment events and EC2 status checks separates application bugs from infrastructure faults.
Storage exhaustion. RDS volumes and EBS disks fill up gradually, then fail suddenly. Forecast-based alerts on FreeStorageSpace warn days ahead instead of minutes.
Cost surprises. Forgotten test environments, oversized instances and chatty cross-AZ traffic show up as cost drift long before the invoice arrives. Anomaly detection on billing metrics catches them early.
EKS pod churn. Pods stuck in CrashLoopBackOff or evicted for memory pressure rarely show up in CloudWatch alone. Node and container metrics from the Obseria Agent, combined with Kubernetes events, show which workload is failing and on which node group.
AWS monitoring best practices
- Tag consistently (team, service, environment) and use those tags as dimensions in dashboards and alerts.
- Monitor every account and region from one place, not only production in your main region.
- Alert on symptoms users feel, such as latency and error rate, and use resource metrics for diagnosis.
- Select the CloudWatch namespaces you actually need to keep API usage and noise under control.
- Instrument applications with OpenTelemetry so traces link AWS resources to the code paths that use them.
How Obseria monitors AWS
Obseria connects to AWS agentlessly through a read-only IAM role and collects CloudWatch metrics and resource tags for 300+ services. The Obseria Agent adds host, process and log data on EC2 and runs as a DaemonSet on EKS. OpenTelemetry traces arrive over OTLP. Obseria TopoGraph maps the dependencies automatically, from load balancer to service to database, and Obseria Intelligence uses that topology to investigate root cause with a chain of evidence. Dashboards, alerts and SLOs are included, and you can query everything with OQL, PromQL or SQL.
CloudWatch Logs and VPC Flow Logs can be routed through Obseria Pipeline, which filters noisy entries, masks personal data and routes each stream to the right retention before storage. Filtered data costs only ingestion, so you keep debug detail available without paying to store all of it.
Related integrations
Related capabilities
Cloud Monitoring
Monitor 300+ cloud services agentless and see how they affect your applications. One platform for multi-cloud metrics, logs, traces and topology.
Learn moreCloud Cost Management
See what every team, service and Kubernetes namespace costs, next to the performance data that explains why. FinOps that engineers can act on.
Learn moreKubernetes Monitoring
See every cluster, node, pod and workload in context. Obseria connects Kubernetes metrics, events, logs and traces so you find the cause of a failing rollout in minutes.
Learn moreLearn more
What is observability?
What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.
The four golden signals: latency, traffic, errors and saturation
The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.
AWS monitoring FAQ
No. CloudWatch metrics for 300+ AWS services are collected agentlessly through a read-only IAM role. The Obseria Agent is optional and adds memory, process, log and trace context on EC2 and EKS.
Read-only permissions are enough. Most teams attach the AWS managed ReadOnlyAccess policy, or a narrower policy with CloudWatch, tagging and resource describe permissions.
Yes. Connect each account with its own role and select the regions to monitor. All data lands in one place and can be filtered by account, region and tag.
Obseria ingests billing metrics such as EstimatedCharges and shows them next to utilization, so you can spot idle or oversized resources. Anomaly detection flags unexpected cost changes.
Yes. Send traces, metrics and logs from OpenTelemetry SDKs or the OpenTelemetry Collector over OTLP. You can export your data over OTLP at any time, so there is no lock-in.
Start monitoring AWS today
Connect AWS in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.