• Overview
• Managing AutoAlarm
• Overriding Default Alarm Values with Tags
  • Tag Value Structure
• Supported Services and Default Alarm Configurations
  • Application Load Balancer (ALB)
  • CloudFront
  • EC2
  • OpenSearch
  • RDS
  • RDS Clusters
  • Route53Resolver
  • SQS
  • Step Functions
  • Target Groups (TG)
  • Transit Gateway (TGW)
  • VPN
• Guide to Customizing Alarms with Tags
  • Alarm Types
    • Static Threshold Alarms
    • Anomaly Detection Alarms
• Supported Tag Values
  • Threshold Configuration
  • Timing Configuration
  • Understanding Datapoints vs Periods
  • Statistic
  • Missing Data Treatment
  • Valid Comparison Operators
• Using the Nullish Character ("-") and Implicit Values in AutoAlarm
  • Key Concepts
  • Examples
• ReAlarm Tag Configuration and Behavior
  • Overview
  • Default Values
  • Configure ReAlarm Behavior with Tags
    • Special Note
• Additional References

AutoAlarm provides out-of-the-box monitoring with sensible defaults while allowing full customization through resource tags. In addition to default alarms, AutoAlarm allows operations teams to customize alarms and monitoring when necessary using a simple tagging strategy.

• To enabled AutoAlarm for a service instance, tag an instance as follows:

• Each alarm configuration supported by AutoAlarm has a default configuration. Furthermore, each service has alarms that are automatically included by default any time the autoalarm:enabled tag is set to true. In scenarios where a user needs to change the default values on the default alarms or enable alarms that are not included by default, these alarms can be configured using a tagging schema with specific tag keys and values as defined below:

Each tag value consists of 8 parameters separated by /:

Example Breakdown:

        Tag Key                                        Tag Value
┌────────────────────────┐   ┌─────────────────────────────────────────────────────────────┐                                          
autoalarm:some-metric-type = 66/89/120/15/Average/12/GreaterThanOrEqualToThreshold/breaching
                              │ │   │  │     │    │           │                       │
                              │ │   │  │     │    │           │                       └────➤ TreatMissingData: breaching
                              │ │   │  │     │    │           └────────────────────────────➤ ComparisonOperator: >=
                              │ │   │  │     │    └────────────────────────────────────────➤ DatapointsToAlarm: 12
                              │ │   │  │     └─────────────────────────────────────────────➤ Statistic: Average
                              │ │   │  └───────────────────────────────────────────────────➤ Eval Periods: 15
                              │ │   └──────────────────────────────────────────────────────➤ Period: 120 sec
                              │ └──────────────────────────────────────────────────────────➤ Critical Alarm Threshold: 89
                              └────────────────────────────────────────────────────────────➤ Warning Alarm Threshold: 66

Threshold values that contain '-' are undefined and will default to not creating the alarm for that threshold (Warning or Critical). If neither the warning and critical threshold values are provided in the tag value when setting the tag on the resource, no alarm will be created.

When setting up non-default alarms with tags, you must provide at least one of the first two values (warning and critical thresholds) for the tag to function correctly if the default thresholds do not contain values. Otherwise, these alarms will not be created.

Prometheus alarms will only pull Warning and critical thresholds and periods from the tags. All other values are specific to CloudWatch alarms and are not used in Prometheus alarms.

• Trigger when metrics cross fixed values
• Best for metrics with consistent, predictable ranges

• Trigger when metrics deviate from historical patterns
• Use tag names containing 'anomaly'
• Threshold values represent standard deviations from the baseline

Note: AWS has limitations on the acceptable characters for the statistic value. you cannot use spaces, '%', or '(/)'. All stats must be the statistic followed by a number or two numbers separated by a colon. For example, p95 or TM2:98.

You can use the following statistics for alarms - https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Statistics-definitions.html.

*Note: Ensure that a valid Comparison Operator is used between static threshold and anomaly alarms.

AutoAlarm supports shorthand notation to simplify tag configuration:

• Nullish Character (-): Disables alarm creation for warning or critical thresholds when used in place of a value.

• Implicit Values: Omit values you don't want to change from the defaults. Use empty positions (//) to skip to later parameters while keeping defaults for earlier ones.

*Note: When using implicit values, ensure that each implicit parameter leading up to the custom parameter is properly seperated by a /. See Tag Value Structure. Empty positions between slashes (//) preserve the default values for those parameters while allowing you to customize later parameters.

The ReAlarm function is an AWS Lambda-based handler designed to monitor and reset CloudWatch alarms that are in an "ALARM" state. It is an optional part of the AutoAlarm system, aimed at ensuring alarms are not missed or ignored.

By default, the ReAlarm function is enabled. When ReAlarm is enabled, it runs on a default schedule of every 120 minutes.

ReAlarm's behavior can be configured on a per-alarm basis using tags.

• Customize ReAlarm Schedule:
  • The ReAlarm schedule by default runs every 120 minutes.
  • ReAlarm can be customized to run at different intervals on a per-alarm basis by setting the autoalarm:re-alarm-minutes tag to a whole number value.
• Disable ReAlarm for a Resource:
  • Alarms can be tagged with autoalarm:re-alarm-enabled=false to exclude them from the ReAlarm process.
  • When this tag is present on an alarm, ReAlarm will skip resetting it, regardless of its state.
  • This is useful for alarms that should be managed manually or have specific conditions that should not trigger ReAlarm.

Example

ReAlarm is hardcoded to NOT reset alarms associated with AutoScaling actions. This is to prevent the function from interfering with scaling operations.

• For Deployment and install instructions, please see DEPLOYMENT.md
• For a more thorough breakdown of Design and Architecture, please see ARCHITECTURE.MD.