DEV Community

Muhammad Yawar Malik
Muhammad Yawar Malik

Posted on

Building a Multi-Account CloudWatch Dashboard That Actually Works

Cross-account monitoring in AWS isn't optional anymore. When you're managing multiple accounts, jumping between consoles to check metrics wastes time during incidents. Here's how to set it up properly.

Why You Need This

You have a central monitoring account and several workload accounts (dev, staging, prod). You want one dashboard to see everything. Simple.

The Setup (3 Steps)

1. Enable Cross-Account Access in Source Accounts
In each account you want to monitor, run this:
aws cloudwatch put-dashboard --dashboard-name sharing-enabled

Then create an IAM role that allows your monitoring account to read metrics:
Trust policy (in source accounts):
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::MONITORING-ACCOUNT-ID:root"
},
"Action": "sts:AssumeRole"
}]
}

Permission policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Resource": "*"
}]
}

2. Configure Monitoring Account

In your central monitoring account, create a role that can assume the roles in source accounts.
Add this to your monitoring role:
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::*:role/CloudWatchCrossAccountRole"
}

3. Build Your Dashboard

Cloudwatch dashboard
Go to CloudWatch in your monitoring account. When adding widgets, you can now specify the account:
Account: 123456789012 (prod-account)
Region: us-east-1
Namespace: AWS/EC2
Metric: CPUUtilization

What to Actually Monitor

Don't try to monitor everything. Start with these:
Per Account:
EC2: CPU, StatusCheckFailed
RDS: DatabaseConnections, FreeableMemory
ALB: TargetResponseTime, UnHealthyHostCount
Lambda: Errors, Duration, ConcurrentExecutions
Cost tracking:
Estimated charges by account (daily)

Pro Tips

Use consistent naming - Tag your resources properly. Filter widgets by tags like Environment:prod rather than hardcoding instance IDs.
Widget organization - Group by service, not by account. One section for all RDS metrics across accounts, not one section per account.
Refresh rate - Set to 1 minute for production dashboards. Auto-refresh helps during incidents.
Share the dashboard - CloudWatch supports sharing via link. Your team shouldn't need AWS console access to view metrics.

Common Gotchas

Regional resources - CloudWatch dashboards are regional. If you have resources in multiple regions, you need multiple widgets or use CloudWatch cross-region functionality.
Metric delay - Some metrics have 1-5 minute delays. Don't panic if numbers aren't real-time.
IAM is per-region - Your cross-account roles work globally, but CloudWatch API calls are regional.

The Result

One dashboard. Multiple accounts. All your critical metrics visible in under 10 seconds. That's what matters when production breaks at 2 AM.

Quick Setup Script

Save time with this:
In each source account
aws iam create-role \
--role-name CloudWatchCrossAccountRole \
--assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
--role-name CloudWatchCrossAccountRole \
--policy-arn arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess

Done. Now build your dashboard and stop switching accounts.

Top comments (0)