aws-cloudformation-cloudwatch_skill

This skill helps you implement production-grade AWS CloudWatch monitoring with CloudFormation templates, covering metrics, alarms, dashboards, logs, and
  • Python

99

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill giuseppe-trisciuoglio/developer-kit --skill aws-cloudformation-cloudwatch

  • SKILL.md48.6 KB

Overview

This skill provides production-ready AWS CloudFormation patterns for CloudWatch monitoring and observability. It packages reusable templates and conventions for metrics, alarms, dashboards, log groups, anomaly detection, synthesized canaries, and Application Signals. Use it to enforce consistent monitoring across environments and to simplify cross-stack integrations and exports.

How this skill works

The skill supplies CloudFormation constructs and example templates that create CloudWatch metrics, alarms, dashboards, log groups, anomaly detectors, and canaries. It defines parameterized building blocks (Parameters, Mappings, Conditions, Outputs) so templates can be reused across dev, staging, and production. The patterns include SNS actions, SSM-backed parameters, encryption and retention settings, composite alarms, and cross-stack export/import wiring for centralized monitoring.

When to use it

  • When you need standard alarms for CPU, memory, disk, latency, error rates, or custom metrics
  • When creating dashboards that combine metrics across accounts or regions
  • When implementing log groups with retention, encryption, and subscription filters
  • When enabling anomaly detection, composite alarms, or synthesized canaries for SLOs
  • When organizing templates for reuse, cross-stack references, or nested stacks

Best practices

  • Parameterize thresholds, periods, and evaluation periods so environments differ by config, not code
  • Use AWS-specific parameter types (SNS::Topic::Arn, KMS::Key::Arn) for validation and clarity
  • Export central monitoring resources (SNS topic, log group) and import them in application stacks
  • Set sensible log retention, enable KMS encryption for log streams, and treat missing data explicitly
  • Use nested stacks and Transform macros to keep templates modular and maintainable

Example use cases

  • Central monitoring stack that exports an Alarm SNS topic and a central LogGroup for import by application stacks
  • Application stack that imports monitoring exports and creates resource-specific alarms (Lambda errors, P99 latency)
  • Multi-widget dashboard template that references instance IDs or function names via parameters for per-environment views
  • Template that provisions synthesized canaries for critical endpoints and wires canary results into dashboards and alarms
  • Anomaly detection configuration to automatically detect unusual traffic or latency and trigger composite alarms

FAQ

Yes — use cross-account log subscriptions and export/import patterns. Centralize exports in a monitoring stack and grant required permissions for imports.

How do I limit noise from alarms in non-production?

Parameterize thresholds and enable conditions to disable or relax alarms for dev and staging, and use mapping defaults per environment.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
aws-cloudformation-cloudwatch skill by giuseppe-trisciuoglio/developer-kit | VeilStrat