Generating AWS CDK CloudWatch Dashboards with AI Prompts
Building AWS CloudWatch dashboards manually through the AWS console is a recipe for operational chaos. Without infrastructure-as-code, your observability setup exists only in one account, can't be version-controlled, and disappears during account migrations. Defining CloudWatch dashboards in AWS CDK solves all of these problems — but the CDK API for CloudWatch is notoriously verbose.
A single metric widget requires specifying metric namespaces, dimensions, statistics, periods, and widget coordinates — all in a nested JSON structure. A complete observability dashboard for a single service can easily require 500+ lines of CDK TypeScript code.
With the right AI prompts, you can generate complete, production-grade CloudWatch dashboards in minutes instead of hours. The prompts below produce dashboards that follow AWS Well-Architected Framework observability recommendations out of the box.
The Four Golden Signals — Your Dashboard Foundation
Google's Site Reliability Engineering (SRE) handbook defines the Four Golden Signals as the minimum set of metrics every service must monitor:
- Latency — How long it takes to serve a request (P50, P90, P99)
- Traffic — How much demand is being placed on your system (requests/second)
- Errors — The rate of failed requests (5xx errors, exception counts)
- Saturation — How "full" your service is (CPU, memory, connection pool usage)
Any CloudWatch dashboard worth deploying to production must include all four. Our AI prompts generate dashboards with these signals pre-configured for your specific AWS service type.
Prompt 1: ECS Fargate Operational Dashboard
"Act as an AWS CDK Expert (TypeScript) and Site Reliability Engineer. Generate a complete CDK construct class named 'EcsDashboard' that creates a CloudWatch Dashboard with the Four Golden Signals for an ECS Fargate service. Requirements: (1) Accept props: serviceName, clusterName, loadBalancerArn, targetGroupArn, alarmSnsTopicArn. (2) Dashboard layout must use a 24-column grid with these widgets: Row 1: Request Count (line graph), Error Rate % (number widget with threshold alarm at 1%), Avg Latency (P50 line graph), P99 Latency. Row 2: CPU Utilization, Memory Utilization, Running Task Count, Desired Task Count. Row 3: ALB 5xx errors, ALB 4xx errors, Target Response Time, Healthy Host Count. (3) Add CloudWatch Alarms for P99 > 2000ms and Error Rate > 2% that notify the SNS topic. (4) Use Duration.minutes(5) as the statistic period. (5) Include all CDK imports. Full TypeScript."Prompt 2: Lambda Function Dashboard
"Write an AWS CDK TypeScript CloudWatch Dashboard for a set of Lambda functions. The construct 'LambdaDashboard' accepts a lambdaFunctions: lambda.Function[] array. For each function, generate: (1) Invocation Count line chart. (2) Error Count and Error Rate (%) using metric math: RATE(errors)*100. (3) Duration P50, P90, P99 on the same graph. (4) Throttle Count and ConcurrentExecutions. (5) Cold Start tracking using a custom metric 'INIT_DURATION' from function logs via a CloudWatch Logs Metric Filter — generate the metric filter definition. (6) A composite alarm that fires when ANY function's error rate exceeds 5%. (7) Auto-layout widgets in rows of 3, each widget 8 columns wide, with proper y-axis positioning calculated programmatically. Export the dashboard ARN as a CloudFormation output."Prompt 3: Advanced Metric Math Expressions
"Show me how to use CloudWatch Metric Math in AWS CDK TypeScript to compute: (1) Error Rate % = (errors / requestCount) * 100 using MathExpression. (2) Availability % = 100 - errorRate using a nested MathExpression. (3) Apdex Score = (satisfiedRequests + frustratedRequests*0.5) / totalRequests where satisfied < 500ms and frustrated < 2000ms, using multiple metric inputs to a single MathExpression. (4) Cache Hit Ratio % for ElastiCache: hits / (hits + misses) * 100. (5) Lambda Cost per 1000 invocations = (duration_ms * memoryMB/1024) / 1000 * 0.0000000167. For each example, show the complete CDK code including the MathExpression with usingMetrics map, period, and how to add it to a GraphWidget."Pro Tips: CloudWatch Best Practices
💡 Use Anomaly Detection Instead of Static Thresholds
Static alarm thresholds (CPU > 80%) create alert fatigue during legitimate traffic spikes. CloudWatch Anomaly Detection uses machine learning to understand your normal traffic patterns and only fires when metrics deviate significantly from the baseline. Use AnomalyDetector in CDK for critical metrics.
⚠️ Dashboard Widget Coordinates Are Tedious — Let CDK Calculate Them
Don't manually specify x, y coordinates for dashboard widgets. Instead, add widgets using the column-row approach and let CDK calculate absolute positions. Better yet, use the addWidgets() method which automatically places widgets left-to-right and wraps to the next row.
Frequently Asked Questions
Q: How much does a CloudWatch dashboard cost?
A: Each CloudWatch dashboard costs $3.00/month (US regions) for the first 3 dashboards stored in your account. Additional dashboards are $3.00/month each. Metric reads (when the dashboard loads) are separate charges at standard GetMetricData rates. For a team of 5 engineers reading a dashboard daily, expect $5–10/month for metric retrieval costs on top of the dashboard fee.
Q: Can I export CloudWatch dashboards between AWS accounts?
A: Yes. CloudWatch dashboards are stored as JSON in AWS. Use the aws cloudwatch get-dashboard CLI command to export the JSON body, then use aws cloudwatch put-dashboard in the target account. CDK dashboards are even better — your infrastructure code is the source of truth and can be deployed to any account/region in minutes.
Q: How do I add custom application metrics to CloudWatch?
A: Use the aws-sdk (Node.js) or boto3 (Python) to call PutMetricData with your custom namespace. For high-volume metrics, use the CloudWatch Embedded Metric Format (EMF) — a JSON format written to stdout/CloudWatch Logs that automatically creates CW metrics without direct API calls, which is more cost-effective and higher throughput.
Naveen Teja Palle
Cloud & DevOps Engineer · AWS Specialist
SRE with production experience building observability stacks for high-traffic AWS environments. Has designed CloudWatch dashboards monitoring millions of daily Lambda invocations and ECS tasks.
500+ AWS Observability Prompts
CloudWatch, X-Ray, Datadog integration, and more — every AWS monitoring pattern, ready to use.
Explore Cloud Prompts →