Running workloads on AWS gives you elasticity, speed, and global reach, but it also hands you a responsibility: knowing what is happening across every account, server, database, and bill at any moment. Without monitoring, problems surface as outages, angry users, or a surprise invoice. With it, you see issues coming and fix them before anyone notices.
In this article, I walk through six Grafana dashboards we use to keep an eye on a multi-account AWS environment, what each one shows, and why it matters. (All data shown is from a demo environment.)
Why monitoring matters
- Availability: catch failing instances, unhealthy targets, and 5XX errors before customers do.
- Performance: spot CPU saturation, slow queries and rising latency early.
- Cost control: cloud spend grows silently; visibility is the first step to optimisation.
- Security and compliance: unmanaged servers (no SSM agent) can't be patched or audited.
- Capacity planning: trends tell you when to scale up, scale down, or consolidate.
1. Amazon EC2: CPU utilisation per instance
This dashboard plots the maximum CPU utilisation of every EC2 instance over time, with the mean per server listed in the legend.
Why it matters: sustained high CPU (several servers here regularly peak above 80%) is an early warning of degraded response times or an undersized instance. Sudden drops can mean a crashed process or an instance that stopped serving traffic. Equally, servers that idle near 0% are candidates for rightsizing.
2. AWS ALB: Load balancer and target group traffic
The Application Load Balancer dashboard brings together healthy vs unhealthy hosts, total requests, average response time, 5XX errors and active connections, followed by request counts, p50/p90/p99 target response times, requests per target and HTTP status codes at both target-group and ELB level. A drop-down lets you switch between applications.
Why it matters: the load balancer is where users meet your application. Unhealthy hosts, a climbing p99 latency, or a spike in 5XX errors are the clearest signals that users are having a bad experience. Requests-per-target also shows whether load is spread evenly.
3. AWS Billing: cost by application and service
This dashboard shows total cost this month, last month, month-over-month change and a forecast, then breaks spending down by application and by service (EC2, RDS, S3, data transfer, load balancers), with a six-month trend.
Why it matters: cost is a metric too. Seeing which application drives spend, and noticing an 8–9% month-over-month increase early, lets teams act (rightsizing, reserved capacity, cleanup) before the invoice arrives. Per-application breakdowns also make chargeback and accountability possible.
4. AWS RDS: database health and performance
The RDS dashboard starts with a fleet-wide overview (number of databases, average CPU, total connections, average free storage), then drills into a selected database: CPU, connections, free storage, read/write IOPS and read/write latency. Trend panels compare all databases side by side.
Why it matters: databases are usually the bottleneck and the hardest component to recover. Running out of storage, connection exhaustion, or rising latency can take down every application that depends on the database. Comparing databases also highlights the noisy neighbour.
5. EC2 servers: disk space monitoring
Using CloudWatch and SSM data, this dashboard counts active (with SSM), running, stopped and SSM-less servers, then lists disk usage per mount point for every server, colour-coded: green below 70%, yellow 70–85%, red 85% and above.
Why it matters: a full disk is one of the most common, and most avoidable, causes of outages. Logs stop writing, databases crash, and deployments fail. Sorting by usage puts the servers at risk (85%+) at the top so they can be cleaned up or expanded. The "without SSM" count also flags servers that can't report disk metrics or be managed remotely.
6. Server consolidation overview: multi-account view
This overview summarises the server estate across all AWS accounts, then account by account: active with SSM, running, stopped, and active without SSM.
Why it matters: in a multi-account setup, it's easy to lose track of what runs where. This view shows how many instances are still unmanaged, which accounts have stopped instances quietly costing money for storage, and how a consolidation or migration project is progressing.
Key takeaways
- Monitor every layer: compute, load balancing, databases, storage, and cost all fail in different ways.
- Make dashboards actionable: thresholds and colour coding turn data into decisions.
- Treat cost as an operational metric alongside CPU and latency.
- Close visibility gaps: servers without the SSM agent are blind spots for both monitoring and security.
- Pair dashboards with alerts so the right people are notified, not just those who happen to be looking.
Monitoring isn't a one-time setup; it's a habit. Start with the dashboards that cover your biggest risks, review them regularly, and keep improving them as your environment grows.
What do you monitor in your AWS environment? Share your favourite dashboards in the comments.
