cloudnative wiki

CloudWatch Dashboards

4 min read

CloudWatch Dashboards

Prerequisites: scoped IAM access and telemetry, SLI and retention design.

CloudWatch dashboards are views of operational evidence, not alerting or access-control boundaries. Design them around user outcomes and diagnostic questions rather than every available graph.

Design

Use metric widgets for traffic/errors/latency/saturation, log queries for investigation, and text widgets for owners/runbooks. State the time range, Region, account and unit so screenshots do not obscure scope. Dashboard variables can parameterize supported properties and patterns.

A dashboard does not grant cross-account metric access. Prefer documented CloudWatch cross-account observability (OAM) links/sinks or the separate legacy cross-account dashboard role workflow. Do not invent cloudwatch:CrossAccountLink permissions. Read authorization and account/Region settings still apply.

Minimal reproducible dashboard

Create a local file dashboard.json with this valid body:

{
  "widgets": [
    {
      "type": "metric",
      "x": 0,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "region": "us-east-1",
        "title": "Sandbox latency",
        "metrics": [["WikiLab", "Latency", "Service", "demo"]],
        "stat": "Average",
        "period": 60
      }
    }
  ]
}

Use the Region of your metric fixture, then with dashboard write/read permissions:

aws cloudwatch put-dashboard --dashboard-name wiki-lab --dashboard-body file://dashboard.json
aws cloudwatch get-dashboard --dashboard-name wiki-lab

Inspect DashboardValidationMessages; successful HTTP/API transport is not proof every widget is valid. Open the dashboard and verify the fixture value. Test the wrong Region deliberately: an empty graph is expected, not a missing global metric.

Cost and cleanup

Dashboards are not universally free. The published allowance is limited to three custom dashboards of up to fifty metrics each; additional dashboards incur charges under the current pricing model. Metrics, queries and other features can add charges independently.

Remove your disposable view with aws cloudwatch delete-dashboards --dashboard-names wiki-lab. This deletes the dashboard configuration, not the underlying metrics/logs. Restrict production dashboard changes through version-controlled definitions and review.

Widget catalogue and operational layout

WidgetIntended useReview requirement
Metric/time seriesTraffic, errors, latency, saturationRegion/account, unit, statistic, period
Number/gaugeCurrent summaryBaseline/window and missing-data meaning
Log queryDrill into eventsTime/groups/language and scan costs
Alarm statusTriage/owner attentionNot a replacement for notifications
TextRunbook/owner/assumptionsMaintain links with the deployed workload
customer outcome: error ratio + latency + synthetic availability
request path: ALB → service → database/queue
diagnosis: deployment revision + trace/log links + dependency signal
response: alarms + owner/runbook + rollback/recovery links

Automatic service dashboards provide a starting view, not a reviewed application dashboard or a guarantee of no charges. Browser/live-data choices affect display; they do not increase a metric’s publication frequency.

Cross-service and metric-math configuration

A widget can include several explicitly defined series and an expression. This valid widget fragment can be inserted into the existing dashboard’s widgets array after replacing identifiers:

{
  "type": "metric",
  "x": 0,
  "y": 6,
  "width": 12,
  "height": 6,
  "properties": {
    "region": "us-east-1",
    "title": "ALB target error percent",
    "period": 60,
    "stat": "Sum",
    "metrics": [
      [
        "AWS/ApplicationELB",
        "HTTPCode_Target_5XX_Count",
        "LoadBalancer",
        "app/REPLACE/REPLACE",
        { "id": "e", "visible": false }
      ],
      [
        "AWS/ApplicationELB",
        "RequestCount",
        "LoadBalancer",
        "app/REPLACE/REPLACE",
        { "id": "r", "visible": false }
      ],
      [
        {
          "expression": "IF(r>0,100*e/r,0)",
          "id": "errorrate",
          "label": "Target error percent"
        }
      ]
    ]
  }
}

Add EC2/RDS widgets with their own actual dimension identities; do not imply an ALB label identifies its database. Annotations mark known thresholds/deployments but do not create alarms. Dashboard variables must target supported properties/patterns and preserve account/Region context.

Console, CLI, IaC and cross-account ownership

The existing CLI lab’s body can be stored in an AWS::CloudWatch::Dashboard DashboardBody string through CloudFormation. Export or version the body, validate messages and review intended diffs; an IaC success event is not proof every graph has data.

For cross-account widgets, first establish supported OAM source/sink or the legacy role workflow. Widget accountId/region settings select data, not permission. Avoid nonexistent cloudwatch:CrossAccountLink actions or placing AccountId as a made-up metric dimension.

Investigation and cleanup

Compare dashboard selected interval with alarm evaluation time; auto-refresh, live display and graph aggregation can show different evidence. An empty widget warrants checking Region/account, exact metric dimensions, credentials and absence versus zero—not immediate alarm deletion.

A dashboard is a configuration object. Deleting it does not stop agents, logs, metrics, alarms, queries or paid underlying resources. Delete only the disposable dashboard/variables and associated owned query definitions; preserve operational views used by other teams.

References: widget schema, dashboard variables, CloudFormation dashboard.

References

Graph View

Backlinks