What goes in an AWS monitoring dashboard in Metabase?

An AWS monitoring dashboard puts the health of your EC2 fleet, load balancers, volumes, databases, and caches on one page — built from CloudWatch metric rollups exported to a database, where they can be joined to owners, releases, and spend. CloudWatch keeps the pager; this is the review and reporting layer on top.

What does an AWS monitoring dashboard look like?

Here’s the layout this guide builds. Fleet-level counts and the two red numbers sit at the top; compute and traffic trends fill the middle; storage, database, and cache detail sits at the bottom with the failing-instances table you drill into when a status check goes red.

Which cards belong on an AWS monitoring dashboard?

The classic eight, modernized from per-instance graphs to per-group ones — at fleet size, groups are what you can actually act on.

• CPU utilization by instance group, against a scaling threshold (line)
• Request count from the load balancer (area)
• Latency — ALB target response time p50 and p95 (line)
• Disk read/write throughput across the fleet’s volumes (line)
• Node status — instances failing status checks (number + table)
• Database connections against max_connections, per RDS instance (line)
• Disk queue depth on the busiest volumes (line)
• Cache hits vs. misses from ElastiCache (line)

What data does the dashboard need?

• cloudwatch_metric_rollups — one row per resource, metric, and window: EC2 (CPUUtilization, StatusCheckFailed, disk and network IO), ALB (RequestCount, TargetResponseTime percentiles), EBS (VolumeQueueLength, throughput), RDS (DatabaseConnections), and ElastiCache (hits and misses).
• instances — an inventory with instance group, environment, region, AZ, and owner tags, so charts group by something actionable.
• alarms — current CloudWatch alarm states, for the “alarms in ALARM” card.
• Optional daily cost per resource from the Cost and Usage Report, for spend-aware cards.

How do you build it?

1. Export CloudWatch metrics on a schedule — Metric Streams via Firehose to S3, or a GetMetricData job — and land hourly rollups in a database Metabase can query (Athena over S3 works; see the Athena data source guide).
2. Keep percentiles pre-aggregated at the source — p95 latency can’t be reconstructed from stored averages later.
3. Build an instance inventory with group, environment, and owner tags, and join every metric through it — untagged fleets produce unactionable charts.
4. Start with the status-check and CPU cards, then traffic and latency, then the storage and database detail.
5. Add filters for instance group, region, environment, and date range, and keep alerting in CloudWatch — this page is for review, not paging.

Example card SQL

SELECT
i.instance_group,
date_trunc('day', m.window_start)                    AS day,
ROUND(AVG(m.value) FILTER (
  WHERE m.metric = 'CPUUtilization'), 1)             AS cpu_avg_pct,
ROUND(MAX(m.value) FILTER (
  WHERE m.metric = 'CPUUtilization'), 1)             AS cpu_peak_pct,
ROUND(SUM(m.value) FILTER (
  WHERE m.metric = 'RequestCount') / 1e6, 2)         AS requests_m,
MAX(m.value) FILTER (
  WHERE m.metric = 'TargetResponseTime.p95') * 1000  AS latency_p95_ms,
MAX(m.value) FILTER (
  WHERE m.metric = 'StatusCheckFailed')              AS status_checks_failed
FROM cloudwatch_metric_rollups m
JOIN instances i ON i.instance_id = m.instance_id
WHERE m.window_start >= now() - interval '14 days'
GROUP BY 1, 2
ORDER BY 1, 2;

Related

Metrics

Integrations

Dashboards

FAQ