CloudWatch Dashboards and Container Insights

CloudWatch Dashboards are customisable, multi-widget views of your AWS infrastructure that provide a unified operational picture. A dashboard can display metrics from multiple AWS services and accounts on a single screen using line graphs, number widgets, gauges, alarms, and log query results. Dashboards are global resources — one dashboard can show metrics from any Region. You can share dashboards publicly or restrict access through IAM policies.

CloudWatch dashboards support several widget types: Line and Stacked area graphs for time-series metrics, Number widgets for the latest metric value (great for KPIs), Bar charts for comparisons, Gauge for capacity indicators, Alarm status to show a summary of alarm states, Log table for Live Tail or Insights query results, and Text for labels and documentation. Combining widget types into one dashboard helps teams assess system health at a glance.

CloudWatch supports cross-account observability using monitoring accounts and source accounts. You can designate a central monitoring account, link source accounts to it, and build dashboards that pull metrics and logs from all linked accounts. This removes the need to switch console accounts to observe a multi-account environment. Cross-Region widgets within the same account are supported natively by specifying the Region in the dashboard JSON definition.

CloudWatch Live Tail (launched in 2023) lets you stream log events from one or more log groups in near real time directly in the CloudWatch console or CLI — similar to running tail -f on a log file. You can apply a filter pattern to see only matching events. Live Tail is invaluable during deployments or incident investigations when you need to observe what an application is doing right now without running full Insights queries.

CloudWatch Container Insights is a feature of CloudWatch that collects, aggregates, and summarises metrics and logs from containerised workloads running on Amazon ECS (EC2 and Fargate) and Amazon EKS (EC2 and Fargate). It provides pre-built dashboards for cluster, service, node, and pod-level performance without requiring you to instrument each application manually. Container Insights uses the CloudWatch Agent or the EKS Fargate log router to collect the data.

Container Insights collects metrics in the ECS/ContainerInsights and ContainerInsights namespaces. For EKS these include: pod-level — pod_cpu_utilization, pod_memory_utilization, pod_network_rx_bytes; node-level — node_cpu_utilization, node_memory_utilization, node_filesystem_utilization; cluster-level — cluster_failed_node_count, cluster_node_count. All metrics are tagged with cluster, namespace, service, and pod dimensions for precise filtering.

When Container Insights is enabled, the CloudWatch console automatically provides pre-built Container Map and Performance Monitoring views. The Container Map shows your ECS tasks or EKS pods as a visual topology — colour-coded by health — with drill-down into individual container metrics. The Performance Monitoring view provides time-series graphs of cluster, node, pod, and container performance without any manual dashboard configuration.

For ECS on EC2, Container Insights installs the CloudWatch Agent as a daemon service on each container instance. For ECS on Fargate, Container Insights uses the Fargate platform version 1.4.0 sidecar metrics collector. You access ECS metrics by cluster, service, task, or container dimension. A common alerting pattern is to alarm on MemoryUtilized approaching the task's MemoryReserved value to catch potential OOM conditions before they terminate tasks.

CloudWatch ServiceLens integrates metrics, logs, and traces into a unified service map. It requires AWS X-Ray to be enabled alongside CloudWatch. ServiceLens visualises end-to-end request flows between services, highlights latency bottlenecks, and shows error rates per service. CloudWatch Application Signals (the newer successor) automatically instruments applications to expose SLOs and SLIs without code changes, enabling reliability tracking beyond raw metrics.

Effective CloudWatch dashboards follow these best practices: separate dashboards by audience (operational vs executive vs developer), use alarm status widgets as the first thing teams see on call, pin dashboards for frequent access, and use dynamic references with CloudFormation to keep dashboard metric references consistent with actual resource names. Avoid overloading a single dashboard — readability matters when you're diagnosing an incident under pressure.

CloudWatch Contributor Insights analyses structured log data to identify the top N contributors to a metric over time. For example, it can show which IP addresses generate the most 5xx errors, which API paths have the highest request volume, or which customer IDs have the most DynamoDB throttles. Rules define the JSON field to extract and aggregate on. Results appear as time-series graphs that update continuously as new log data arrives.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: CloudWatch Dashboards support multiple widget types and can aggregate metrics across accounts and regions, Container Insights automatically collects pod- and node-level metrics from ECS and EKS without manual instrumentation, and Contributor Insights identifies top contributors from structured log data. Next up we explore CloudTrail Trails and Event History for API-level auditing.