Aws Cloudformation Cloudwatch logo

Aws Cloudformation Cloudwatch

Community
giuseppe-trisciuoglio
aws-cloudformation-cloudwatch

Provides AWS CloudFormation patterns for CloudWatch monitoring, metrics, alarms, dashboards, logs, and observability. Use when creating CloudWatch metrics, alarms, dashboards, log groups, log subscriptions, anomaly detection, synthesized canaries, Application Signals, and implementing template structure with Parameters, Outputs, Mappings, Conditions, cross-stack references, and CloudWatch best practices for monitoring production infrastructure.

Overview

Publishergiuseppe-trisciuoglio
Repositorydeveloper-kit
Skill nameaws-cloudformation-cloudwatch
Stars
345
Forks
41
Bundled files
6
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 6 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by giuseppe-trisciuoglio on GitHub. Read the source before you install it.

Installation

Install the Aws Cloudformation Cloudwatch AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/giuseppe-trisciuoglio/developer-kit.git /tmp/developer-kit
mkdir -p .claude/skills
cp -r /tmp/developer-kit/plugins/developer-kit-aws/skills/aws-cloudformation/aws-cloudformation-cloudwatch .claude/skills/aws-cloudformation-cloudwatch
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Aws Cloudformation Cloudwatch in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Aws Cloudformation Cloudwatch on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Aws Cloudformation Cloudwatch is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

AWS CloudFormation CloudWatch Monitoring

Overview

Creates CloudWatch monitoring infrastructure using CloudFormation templates: metrics, alarms, dashboards, log groups, anomaly detection, synthesized canaries, and Application Signals.

When to Use

  • Creating CloudWatch metrics and alarms for production infrastructure
  • Building CloudWatch dashboards for multi-region visualization
  • Implementing log groups with retention, encryption, and metric filters
  • Configuring anomaly detection and composite alarms
  • Setting up cross-stack references with Parameters and Outputs
  • Validating and deploying monitoring stacks with CloudFormation

Instructions

Follow these steps to create CloudWatch monitoring infrastructure with CloudFormation:

1. Define Alarm Parameters

Specify metric namespaces, dimensions, and threshold values:

yaml
Parameters:
  ErrorRateThreshold:
    Type: Number
    Default: 5
    Description: Error rate threshold for alarms (percentage)

  LatencyThreshold:
    Type: Number
    Default: 1000
    Description: Latency threshold in milliseconds

  CpuUtilizationThreshold:
    Type: Number
    Default: 80
    Description: CPU utilization threshold (percentage)

  LogRetentionDays:
    Type: Number
    Default: 30
    AllowedValues:
      - 1
      - 3
      - 7
      - 14
      - 30
      - 60
      - 90
      - 120
      - 365
    Description: Number of days to retain log events

2. Create CloudWatch Alarms

Set up alarms for CPU, memory, disk, and custom metrics:

yaml
Resources:
  HighCpuAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: !Sub "${AWS::StackName}-high-cpu"
      AlarmDescription: Trigger when CPU utilization exceeds threshold
      MetricName: CPUUtilization
      Namespace: AWS/EC2
      Dimensions:
        - Name: InstanceId
          Value: !Ref InstanceId
      Statistic: Average
      Period: 60
      EvaluationPeriods: 3
      Threshold: !Ref CpuUtilizationThreshold
      ComparisonOperator: GreaterThanThreshold
      AlarmActions:
        - !Ref AlarmTopic

  ErrorRateAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: !Sub "${AWS::StackName}-error-rate"
      MetricName: ErrorRate
      Namespace: !Ref CustomNamespace
      Dimensions:
        - Name: Service
          Value: !Ref ServiceName
      Statistic: Average
      Period: 60
      EvaluationPeriods: 5
      Threshold: !Ref ErrorRateThreshold
      ComparisonOperator: GreaterThanThreshold

3. Configure Alarm Actions

Define SNS topics for notification delivery:

yaml
Resources:
  AlarmNotificationTopic:
    Type: AWS::SNS::Topic
    Properties:
      DisplayName: !Sub "${AWS::StackName}-alarms"
      TopicName: !Sub "${AWS::StackName}-alarms"

  AlarmTopicPolicy:
    Type: AWS::SNS::TopicPolicy
    Properties:
      PolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: cloudwatch.amazonaws.com
            Action: sns:Publish
            Resource: !Ref AlarmNotificationTopic
      Topics:
        - !Ref AlarmNotificationTopic

4. Create Dashboards

Build visualization widgets for metrics across resources:

yaml
Resources:
  MonitoringDashboard:
    Type: AWS::CloudWatch::Dashboard
    Properties:
      DashboardName: !Sub "${AWS::StackName}-dashboard"
      DashboardBody: !Sub |
        {
          "widgets": [
            {
              "type": "metric",
              "x": 0,
              "y": 0,
              "width": 12,
              "height": 6,
              "properties": {
                "title": "CPU Utilization",
                "metrics": [["AWS/EC2", "CPUUtilization", "InstanceId", "${InstanceId}"]],
                "period": 300,
                "stat": "Average",
                "region": "${AWS::Region}"
              }
            }
          ]
        }

5. Set Up Log Groups

Configure retention policies and encryption settings:

yaml
Resources:
  ApplicationLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub "/aws/applications/${Environment}/${ApplicationName}"
      RetentionInDays: !Ref LogRetentionDays
      KmsKeyId: !Ref LogEncryptionKey

6. Implement Metric Filters

Create metrics from log data:

yaml
Resources:
  ErrorMetricFilter:
    Type: AWS::Logs::MetricFilter
    Properties:
      LogGroupName: !Ref ApplicationLogGroup
      FilterPattern: '[level="ERROR", msg]'
      MetricTransformations:
        - MetricValue: "1"
          MetricNamespace: !Sub "${AWS::StackName}/Application"
          MetricName: ErrorCount

7. Add Composite Alarms

Build multi-condition alarm logic:

yaml
Resources:
  SystemHealthComposite:
    Type: AWS::CloudWatch::CompositeAlarm
    Properties:
      AlarmName: !Sub "${AWS::StackName}-system-health"
      AlarmRule: !Or
        - !Ref HighCpuAlarm
        - !Ref ErrorRateAlarm
      AlarmActions:
        - !Ref AlarmTopic

8. Configure Log Insights Queries

Create saved queries for log analysis:

yaml
Resources:
  ErrorAnalysisQuery:
    Type: AWS::Logs::QueryDefinition
    Properties:
      Name: !Sub "${AWS::StackName}-errors"
      LogGroupNames:
        - !Ref ApplicationLogGroup
      QueryString: |
        fields @timestamp, @message
        | filter @message like /ERROR/
        | sort @timestamp desc
        | limit 100

9. Validate Template

Before deploying, validate the CloudFormation template:

bash
aws cloudformation validate-template --template-body file://template.yaml

For parameterized templates, test with sample values:

bash
aws cloudformation validate-template \
  --template-body file://monitoring.yaml \
  --capabilities CAPABILITY_IAM

10. Deploy and Verify

Deploy the stack and verify resources:

bash
# Deploy stack
aws cloudformation create-stack \
  --stack-name my-monitoring-stack \
  --template-body file://monitoring.yaml \
  --parameters file://parameters.json \
  --capabilities CAPABILITY_IAM

# Wait for completion
aws cloudformation wait stack-create-complete \
  --stack-name my-monitoring-stack

# Verify alarms are in OK state
aws cloudwatch describe-alarms --stack-name my-monitoring-stack

# Check dashboard accessibility
aws cloudwatch get-dashboard --dashboard-name my-monitoring-stack-dashboard

Test alarm actions before production:

bash
# Set alarm to testing state
aws cloudwatch set-alarm-state \
  --alarm-name my-alarm \
  --state-value ALARM \
  --state-reason "Testing alarm action"

Best Practices

  • Use composite alarms to reduce noise and avoid false positives
  • Set meaningful thresholds based on baseline metrics
  • Configure appropriate evaluation periods (3-5 datapoints)
  • Enable anomaly detection for metrics with variable patterns
  • Use metric math for derived metrics (error rates, latency percentiles)
  • Set appropriate log retention based on compliance needs
  • Encrypt log groups with sensitive data using KMS
  • Test alarm actions with set-alarm-state before production

Examples

Example 1: Complete Monitoring Stack

yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Complete CloudWatch monitoring setup

Parameters:
  Environment:
    Type: String
    Default: prod
    AllowedValues: [dev, staging, prod]

Resources:
  # SNS Topic for notifications
  AlarmTopic:
    Type: AWS::SNS::Topic
    Properties:
      DisplayName: !Sub "${Environment}-alarms"

  # Alarm for high CPU
  CpuAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: !Sub "${AWS::StackName}-cpu-high"
      MetricName: CPUUtilization
      Namespace: AWS/EC2
      Statistic: Average
      Period: 300
      EvaluationPeriods: 2
      Threshold: 80
      ComparisonOperator: GreaterThanThreshold
      AlarmActions:
        - !Ref AlarmTopic

  # Dashboard
  Dashboard:
    Type: AWS::CloudWatch::Dashboard
    Properties:
      DashboardName: !Ref AWS::StackName
      DashboardBody: !Sub |
        {
          "widgets": [{
            "type": "metric",
            "properties": {
              "metrics": [["AWS/EC2", "CPUUtilization"]],
              "period": 300,
              "stat": "Average"
            }
          }]
        }

Example 2: Log-Based Metrics with Filters

yaml
Resources:
  AppLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub "/app/${Environment}"
      RetentionInDays: 30

  ErrorMetricFilter:
    Type: AWS::Logs::MetricFilter
    Properties:
      LogGroupName: !Ref AppLogGroup
      FilterPattern: '"ERROR"'
      MetricTransformations:
        - MetricValue: "1"
          MetricNamespace: !Sub "${AWS::StackName}/App"
          MetricName: ErrorCount

  ErrorAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: !Sub "${AWS::StackName}-errors"
      MetricName: ErrorCount
      MetricNamespace: !Sub "${AWS::StackName}/App"
      Statistic: Sum
      Period: 300
      EvaluationPeriods: 1
      Threshold: 1
      ComparisonOperator: GreaterThanOrEqualToThreshold

Constraints and Warnings

Resource Limits

  • Maximum 5000 alarms per account
  • Maximum 50 metric filters per log group
  • Dashboard body limited to 512KB
  • Maximum 200 metrics per alarm expression

Security Considerations

  • Enable encryption on log groups containing sensitive data
  • Use IAM policies to restrict alarm action permissions
  • Avoid hardcoding thresholds in templates; use Parameters
  • Protect SNS topics with encryption and access policies

Operational Warnings

  • High-resolution alarms (10s/30s) incur higher costs
  • Missing data treatment affects alarm state; configure explicitly
  • Composite alarms can mask individual alarm states
  • Metric filters are immutable after creation; recreate to change

Cost Optimization

  • Use standard resolution (5-minute period) unless necessary
  • Set appropriate retention periods (shorter = cheaper)
  • Delete unused dashboards and custom metrics
  • Monitor CloudWatch charges with budgets and alerts

Monitoring Strategy

  • Use composite alarms to reduce alarm noise
  • Configure appropriate evaluation periods to avoid false positives
  • Set up anomaly detection for metrics with variable patterns
  • Use metric math for derived metrics (error rates, averages)
  • Implement high-resolution alarms for critical metrics
  • Create separate dashboards for different audiences (ops, dev, management)

Log Management

  • Use appropriate retention periods based on compliance requirements
  • Encrypt log groups containing sensitive data
  • Implement metric filters for critical log patterns
  • Set up cross-account log aggregation for centralized analysis
  • Use CloudWatch Logs Insights for troubleshooting
  • Configure log subscriptions to Lambda/Kinesis for real-time processing

Alarm Configuration

  • Set meaningful thresholds based on baseline metrics
  • Use datapoints-to-alarm for reliability
  • Configure OK actions to reset notifications
  • Treat missing data appropriately (breaching, not breaching, ignore)
  • Test alarm actions regularly
  • Document alarm runbooks and escalation procedures

Template Structure

  • Use AWS-specific parameter types for resources
  • Implement parameter constraints for validation
  • Use Conditions for environment-specific configuration
  • Leverage Mappings for region-specific settings
  • Apply Metadata for parameter grouping
  • Use nested stacks for large monitoring setups

Dashboard Design

  • Organize dashboards by service or application tier
  • Use consistent widget layouts and sizing
  • Include text widgets for context and documentation
  • Set appropriate time ranges for data visualization
  • Use variables for dynamic dashboard filtering
  • Limit metrics per dashboard to avoid performance issues

References

For detailed implementation guidance, see:

  • alarms.md - CloudWatch metrics and alarms including base metric alarms, latency alarms, API Gateway errors, EC2 instance alarms, Lambda function alarms, composite alarms, anomaly detection, metric math, alarm actions (SNS, Auto Scaling, EC2), missing data treatment, custom metrics, metric filters, and high-resolution alarms

  • dashboards.md - CloudWatch dashboards including base template, service-specific dashboards, widget types (metric, log, text, single value, alarm status), multi-region dashboards, stacked metrics, anomaly detection widgets, math expressions, layout patterns (grid, row, column), dynamic variables, cross-account sharing, and dashboard automation

  • logs.md - CloudWatch logs including log group configurations, metric filters, subscription filters (Lambda, Kinesis Firehose), cross-account log aggregation, log insights queries, resource policies, export and archive tasks, CloudWatch agent configuration, log encryption with KMS, lifecycle management, centralized logging, and search patterns

  • constraints.md - Resource limits (5000 alarms max, 500 dashboards max), operational constraints (metric resolution, evaluation periods, dashboard widgets, cross-account), security constraints (log data access, encryption, metric filters, alarm actions), cost considerations (detailed monitoring, custom metrics, log retention, dashboard queries), and data constraints (metric age, log ingestion, filter limits)

Related Resources

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Aws Cloudformation Cloudwatch AI skill do?

Provides AWS CloudFormation patterns for CloudWatch monitoring, metrics, alarms, dashboards, logs, and observability. Use when creating CloudWatch metrics, alarms, dashboards, log groups, log subscriptions, anomaly detection, synthesized canaries, Application Signals, and implementing template structure with Parameters, Outputs, Mappings, Conditions, cross-stack references, and CloudWatch best practices for monitoring production infrastructure.

Why use Aws Cloudformation Cloudwatch on TypingMind?

Because you install it once and use it with any model. Aws Cloudformation Cloudwatch is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Aws Cloudformation Cloudwatch in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/giuseppe-trisciuoglio/developer-kit/tree/main/plugins/developer-kit-aws/skills/aws-cloudformation/aws-cloudformation-cloudwatch. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Aws Cloudformation Cloudwatch?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Aws Cloudformation Cloudwatch?

As many as you like. As long as a model supports skills, you can use Aws Cloudformation Cloudwatch with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Aws Cloudformation Cloudwatch AI skill free?

Yes. It is published on GitHub by giuseppe-trisciuoglio under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇