CloudWatch

Amazon CloudWatch holds the metrics and logs your AWS services emit. Nexus queries it to see how a service behaved around the time of an incident: the error rate that climbed, the function that started timing out, the log line that appeared right after a deploy.

​

What we support

CloudWatch is one data source with two surfaces, and Nexus queries both:

• Metrics: CloudWatch Metric Math over AWS service metrics (EC2, RDS, Lambda, ELB, etc.) and any custom metrics your application publishes. Nexus graphs a counter climbing, a latency percentile spiking, or a queue backing up across the incident window.
• Logs: CloudWatch Logs Insights (CWLI) over your AWS and application log groups. Nexus pulls the actual log lines a service wrote, or aggregates them to count error patterns and break latency down by route.

​

Searching logs across services

A CWLI query runs against named log groups, and Nexus can scan several at once (the Lambdas behind one service, or a service and its load balancer) in a single query, surfacing which group each line came from. That turns “where did this request fail” into one search across the path it took, rather than one query per service. CWLI also reads structure straight out of your logs. JSON log lines expose their top-level keys as queryable fields, and AWS-managed formats (Lambda runtime logs, CloudTrail, VPC Flow Logs) are parsed automatically, so Nexus filters on a status code, request ID, or level without you indexing anything. For plain-text logs, fields are carved out by pattern at query time.

​

Metric namespaces and dimensions

CloudWatch metrics live under namespaces (AWS/Lambda, AWS/RDS, or a custom namespace like MyApp/Checkout), each with its own dimensions for grouping by function, instance, database, and so on. Nexus prefers your custom namespaces first, since those encode what your team chose to measure, before falling back to the AWS-managed ones. Nexus learns this structure automatically: your log groups and their field shapes, your populated namespaces, their metrics and dimensions, and which regions each appears in. How that works is covered in How telemetry works.

​

Connecting CloudWatch

CloudWatch is discovered when you connect a provider. There are two routes, and both give Nexus the same access.

​

Via AWS

Connect AWS with an OIDC IAM role or static access keys, and CloudWatch is discovered automatically for the accounts and regions you enable. Nexus queries it directly through the AWS APIs using those credentials, with nothing CloudWatch-specific to configure.

​

Via Grafana

If your CloudWatch already sits behind Grafana, connect Grafana and CloudWatch is discovered as one of the data sources behind it, queried through Grafana’s own credentials. Either way, CloudWatch is disabled by default. Log queries can be broad, so you opt in deliberately: enable the CloudWatch data sources your team uses once they’re connected.

​

Best practice

• Enable only the accounts and regions your responders actually reach for during incidents. CloudWatch is region-scoped, so the same service can appear in several regions independently.
• Scope the credentials to read-only access. Nexus only ever reads from CloudWatch, never changes anything.
• If you reach CloudWatch through Grafana, connect the dashboards that query it. Nexus learns your real query patterns from them, which makes CloudWatch queries more accurate.

​

Related