# Accelerate Alarm Manager
Alarm Manager

AMS Accelerate applies alarms to your AWS resources using the tag-based Alarm Manager to implement a baseline monitoring strategy and ensure that all your AWS resources are monitored and protected. By integrating with the tag-based Alarm Manager, you can customize the configuration of your AWS resources based on their type, platform, and other tags, to ensure the resources are monitored. Alarm Manager is deployed to your Accelerate account during onboarding.

## How Alarm Manager works


When your account is onboarded to AMS Accelerate, two JSON documents, called configuration profiles, are deployed in your account in [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html). Both profile documents reside in the Alarm Manager application and in the AMS Accelerate infrastructure environment.

The two configuration profiles are named **AMSManagedAlarms** (the default configuration profile) and **CustomerManagedAlarms** (the customization configuration profile).
+ Default configuration profile:
  + The configuration found in this profile contains the default configuration that AMS Accelerate deploys in all customer accounts. This configuration contains the default AMS Accelerate monitoring policy.
**Important**  
Do not modify this profile because AMS Accelerate can update it at any time, erasing any changes you made.
  + If you want to modify or disable any of these definitions, see [Modifying the Accelerate alarm default configuration](acc-mem-modify-default.md) and [Disabling the default Accelerate alarm configuration](acc-mem-disable-default-config.md).
+ Customization configuration profile:
  + Any configuration in this profile is entirely managed by you; AMS Accelerate does not overwrite this profile, unless you explicitly request it.
  + You can specify any custom alarm definitions you want in this profile, and you can also specify modifications to the AMS Accelerate-managed default configuration. For more information, see [Modifying the Accelerate alarm default configuration](acc-mem-modify-default.md) and [Disabling the default Accelerate alarm configuration](acc-mem-disable-default-config.md).
  + If you update this profile, Alarm Manager automatically enforces your changes across all relevant resources in your AWS account.
  + You can update this profile using the AWS Management Console or AWS CLI/SDK tools. See the [AWS AppConfig User Guide](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) for instructions about updating a configuration.
  + The customization profile is initially empty; however, any alarm definitions placed in the profile document are enforced, in addition to the default configuration.

All CloudWatch alarms created by the Alarm Manager contain the tag key **ams:alarm-manager:managed** and tag value **true**. This is to ensure that the Alarm Manager manages only those alarms that it creates, and won’t interfere with any of your own alarms. You can see these tags using the Amazon CloudWatch [ListTagsForResource](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListTagsForResource.html) API.

**Important**  
If custom alarm definitions and default alarm definitions are specified with the same ConfigurationID (see [Accelerate Configuration profile: monitoring](acc-mem-config-doc-format.md)), the custom definitions take priority over default rules.

# Getting started with Accelerate Alarm Manager
Getting started with Alarm Manager

By default, when you onboard with AMS Accelerate, your configuration is deployed to AWS AppConfig, defining an alarm baseline for your resources. The alarm definitions are applied only to resources with the **ams:rt:\$1** tags. We recommend that these tags be applied using the [Accelerate Resource Tagger](acc-resource-tagger.md): you set up a basic Resource Tagger configuration in order to let AMS Accelerate know which resources you want managed.

Use Resource Tagger to apply the tag key **ams:rt:ams-managed** with tag value **true** to any resources you want AMS Accelerate to monitor.

The following is an example Resource Tagger customization profile that you can use to opt in to monitoring for all of your Amazon EC2 instances. For general information, see [Accelerate Resource Tagger](acc-resource-tagger.md).

```
{
    "AWS::EC2::Instance": {
        "AMSManageAllEC2Instances": {
            "Enabled": true,
            "Filter": {
                "InstanceId": "*"
            },
            "Tags": [
                {
                    "Key": "ams:rt:ams-managed",
                    "Value": "true"
                }
            ]
        }
    }
}
```

For information about how to apply this Resource Tagger configuration, see [Viewing or making changes to the Resource Tagger configuration](acc-rt-using.md#acc-rt-make-changes).

# Accelerate Alarm Manager tags
Alarm Manager tags

By default, when you onboard with AMS Accelerate, your configuration is deployed to AWS AppConfig, defining an alarm baseline for your resources. The alarm definitions are applied only to resources with the **ams:rt:\$1** tags. We recommend that these tags be applied using the [Accelerate Resource Tagger](acc-resource-tagger.md): you set up a basic Resource Tagger configuration in order to let AMS Accelerate know which resources you want managed.

Use Resource Tagger to apply the tag key **ams:rt:ams-managed** with tag value **true** to any resources you want AMS Accelerate to monitor.

**Topics**
+ [

# Accelerate tags using Resource Tagger
](acc-mem-tag-alarms-use-rt.md)
+ [

# Accelerate tags without Resource Tagger
](acc-mem-tags-no-rt.md)
+ [

# Accelerate tags using CloudFormation
](acc-mem-tags-cfn.md)
+ [

# Accelerate tags using Terraform
](acc-mem-tags-terraform.md)

# Accelerate tags using Resource Tagger
Tags using Resource Tagger

The tag-based Alarm Manager manages the lifecycle of per-resource CloudWatch alarms; however, it requires that the managed resources have specific tags defined by AMS Accelerate. To use the Resource Tagger to apply the default set of AMS-managed alarms to both Linux and Windows based instances, follow these steps.

1. Browse to the [AppConfig](https://console.aws.amazon.com/systems-manager/appconfig/) console within your account.

1. Select the ResourceTagger application.

1. Select the **Configuration profiles** tab, and then select **CustomerManagedTags**.

1. Click **Create** to create a new profile.

1. Select **JSON** and define your configuration. For more examples of filter and platform definition, see [Accelerate Resource Tagger](acc-resource-tagger.md).

   ```
   {
   "AWS::EC2::Instance": {
      "MonitorAllInstances": {
          "Enabled": true,
          "Filter": {
              "Platform": "*"
          },
          "Tags": [
              {
                  "Key": "ams:rt:ams-managed",
                  "Value": "true"
              }
          ]
      }
   }
   }
   ```

1. Click **Create hosted configuration version**.

1. Click **Start deployment**.

1. Define the following deployment details:

   ```
   Environment: AMSInfrastructure Hosted configuration version: <Select the version that you have just created> 
                  Deployment Strategy: AMSNoBakeDeployment
   ```

1. Click **Start deployment**.

Your instances become tagged with `"ams:rt:ams-managed": "true"` which ensures that additional `"ams:rt:ams-monitoring-policy": "ams-monitored"` and `"ams:rt:ams-monitoring-policy-platform": "ams-monitored-linux"` are applied to the instances. These tags then result in the appropriate alarms being created for the instance. For more information about this process, see [Monitoring in Accelerate](acc-tag-req-mon.md).

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/ohtqVmm2yIw/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/ohtqVmm2yIw)


# Accelerate tags without Resource Tagger
Tags without Resource Tagger

The tag-based Alarm Manager manages the lifecycle of per-resource CloudWatch alarms; however, it requires that the managed resources have specific tags defined by AMS Accelerate. AMS Accelerate provides a default configuration profile that assumes that your tags have been applied by Resource Tagger.

If you want to use an alternate method of applying tags to your resources, such as CloudFormation or Terraform, and not Resource Tagger, you need to disable the Resource Tagger so that it doesn’t apply tags to your resources and compete with your chosen tagging method. For instructions on changing your custom Resource Tagger configuration profile to enable read-only mode, see [Preventing Resource Tagger from modifying resources](acc-rt-using.md#acc-rt-preventing-rt-changes).

After the Resource Tagger has been set to read-only mode, and the configuration profile is deployed, use your chosen tagging method to apply tags to your resources according to the following guidelines:


| Resource type | Tag key | Tag value | 
| --- | --- | --- | 
| All supported resources (described in this table) | ams:rt:ams-monitoring-policy | ams-monitored | 
| EC2 instances (Linux) | ams:rt:ams-monitoring-policy-platform | ams-monitored-linux | 
| EC2 instances (Windows) | ams:rt:ams-monitoring-policy-platform | ams-monitored-windows | 
| OpenSearch Domain with KMS | ams:rt:ams-monitoring-with-kms | ams-monitored-with-kms | 
| OpenSearch Domain with Dedicated Master Node | ams:rt:ams-monitoring-with-master | ams-monitored-with-master | 

Resources that have these tag keys and values are managed by the AMS Accelerate Alarm Manager.

# Accelerate tags using CloudFormation
Tags using CloudFormation

**Note**  
Make sure you have set Resource Tagger to read-only mode first before applying tags using CloudFormation, otherwise Resource Tagger may modify the tags based on the configuration profile. For information on setting Resource Tagger to read-only mode, and guidelines on providing your own tags, see [Accelerate tags without Resource Tagger](acc-mem-tags-no-rt.md).

To apply tags using CloudFormation, you can apply tags at the stack level (see [ CloudFormation Resource Tags](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html)) or, at the individual resource level, (for example, see [ Creating EC2 Instance Tags](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#cfn-ec2-instance-tags)).

The following is an example of how you can apply AMS Accelerate alarm management tags to an Amazon EC2 instance managed by CloudFormation:

```
Type: AWS::EC2::Instance
Properties: 
 InstanceType: "t3.micro"
 
 # ...other properties...
 
 Tags: 
   - Key: "aws:rt:ams-monitoring-policy"
     Value: "ams-monitored"
   - Key: "aws:rt:ams-monitoring-policy-platform"
     Value: "ams-monitored-linux"
```

The following is an example of how you can apply AMS Accelerate alarm management tags to an Auto Scaling group managed by CloudFormation. Note that the Auto Scaling group will propagate its tags to Amazon EC2 instances that are created by it:

```
Type: AWS::AutoScaling::AutoScalingGroup
Properties: 
 AutoScalingGroupName: "TestASG"
 
 # ...other properties...
 
 Tags: 
   - Key: "aws:rt:ams-monitoring-policy"
     Value: "ams-monitored"
   - Key: "aws:rt:ams-monitoring-policy-platform"
     Value: "ams-monitored-linux"
```

# Accelerate tags using Terraform
Tags using Terraform

**Note**  
Make sure you have set Resource Tagger to read-only mode first before applying tags using CloudFormation, otherwise Resource Tagger may modify the tags based on the configuration profile. For information on setting Resource Tagger to read-only mode, and guidelines on providing your own tags, see [Accelerate tags without Resource Tagger](acc-mem-tags-no-rt.md).

For a description of how to manage resource tags using Terraform, see the Terraform documentation [ Resource Tagging](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/resource-tagging).

The following is an example of how you can apply AMS Accelerate alarm management tags to an Amazon EC2 instance managed by Terraform.

```
resource "aws_instance" "test_linux_instance" {
     # ...ami and other properties...
     
     instance_type = "t3.micro"
   
     tags = {
       "aws:rt:ams-monitoring-policy" = "ams-monitored"
       "aws:rt:ams-monitoring-policy-platform" = "ams-monitored-linux"
     }
   }
```

The following is an example of how you can apply AMS alarm management tags to an Auto Scaling group managed by Terraform. Note that the Auto Scaling group propagates its tags to EC2 instances that are created by it:

```
 resource "aws_autoscaling_group" "test_asg" {
 name = "terraform-test"
 # ...other properties...

 tags = {
   "aws:rt:ams-monitoring-policy" = "ams-monitored"
   "aws:rt:ams-monitoring-policy-platform" = "ams-monitored-linux"
 }
}
```

# Accelerate Alarm Manager configuration profiles
Alarm Manager configuration profiles

When your account is onboarded to AMS Accelerate, two JSON documents, called configuration profiles, are deployed in your account with AWS AppConfig (see [What is AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)). Both profile documents reside in the Alarm Manager application and in the AMS Accelerate infrastructure environment.

**Topics**
+ [

# Accelerate Configuration profile: monitoring
](acc-mem-config-doc-format.md)
+ [

# Accelerate Configuration profile: pseudoparameter substitution
](acc-mem-config-doc-sub.md)
+ [

# Accelerate alarm configuration examples
](acc-mem-config-ex.md)
+ [

# Viewing your Accelerate Alarm Manager configuration
](acc-mem-view-am.md)
+ [

# Changing the Accelerate alarm configuration
](acc-mem-change-am.md)
+ [

# Modifying the Accelerate alarm default configuration
](acc-mem-modify-default.md)
+ [

# Deploying Accelerate alarm configuration changes
](acc-mem-deploy-change.md)
+ [

# Rolling back Accelerate alarm changes
](acc-mem-rollback-am-change.md)
+ [

# Retaining Accelerate alarms
](acc-mem-retain-alarm.md)
+ [

# Disabling the default Accelerate alarm configuration
](acc-mem-disable-default-config.md)

# Accelerate Configuration profile: monitoring
Configuration profile: monitoring

Both the default configuration profile document and the customization configuration profile document follow the same structure :

```
  {
    "<ResourceType>": {
        "<ConfigurationID>": {
            "Enabled": true,

            "Tag": {
                "Key": "...",
                "Value": "..."
            },
            "AlarmDefinition": {
                ...
            }
        },
        "<ConfigurationID>": {
            ...
        }
    },
    "<ResourceType>": {
        ...
    }
}
```
+ **ResourceType**: This key must be one of the following supported strings. The configuration within this JSON object will relate only to the specified AWS resource type. Supported resource types:

  ```
  AWS::EC2::Instance
  AWS::EC2::Instance::Disk
  AWS::RDS::DBInstance
  AWS::Elasticsearch::Domain
  AWS::OpenSearch::Domain
  AWS::Redshift::Cluster
  AWS::ElasticLoadBalancingV2::LoadBalancer
  AWS::ElasticLoadBalancingV2::LoadBalancer::TargetGroup
  AWS::ElasticLoadBalancing::LoadBalancer
  AWS::FSx::FileSystem::ONTAP
  AWS::FSx::FileSystem::ONTAP::Volume
  AWS::FSx::FileSystem::Windows
  AWS::EFS::FileSystem
  AWS::EC2::NatGateway
  AWS::EC2::VPNConnection
  ```
+ **ConfigurationID**: This key must be unique in the profile, and uniquely names the following block of configuration. If you specify a **ConfigurationID** in your customization profile that is the same as one specified in the default profile, the configuration block defined in the customization profile takes effect.
  + **Enabled**: (optional, default=true) Specify if the configuration block will take effect. Set this to false to disable a configuration block. A disabled configuration block behaves as if it's not present in the profile.
  + **Tag**: Specify the tag that this alarm definition applies to. Any resource (of the appropriate resource type) that has this tag key and value will have a CloudWatch alarm created with the given definition. This field is a JSON object with the following fields:
    + **Key**: The key of the tag to match. Keep in mind that if you're using Resource Tagger to apply the tags to the resource, the key for the tag will always begin with **ams:rt:**.
    + **Value**: The value of the tag to match.
  + **AlarmDefinition**: Defines the alarm to be created. This is a JSON object whose fields are passed as is to the CloudWatch `PutMetricAlarm` API call (with the exception of pseudoparameters; for more information, see [Accelerate Configuration profile: pseudoparameter substitution](acc-mem-config-doc-sub.md)). For information about what fields are required, see the [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) documentation.

    OR

    **CompositeAlarmDefinition**: Defines a composite alarm to be created. When you create a composite alarm, you specify a rule expression for the alarm that takes into account the alarm state of other alarms that you have created. This is a JSON object whose fields are passed as-is to the `CloudWatchPutCompositeAlarm`. The composite alarm goes into ALARM state only if all conditions of the rule are met. The alarms specified in a composite alarm's rule expression can include metric alarms and other composite alarms. For information about what fields are required, see the [PutCompositeAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutCompositeAlarm.html) documentation.

    Both options provide the following fields:
    + **AlarmName**: Specify the name of the alarm you want to create for the resource. This field has all of the same rules as specified in the [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) documentation; however, since the alarm name must be unique in a Region, the Alarm Manager has one additional requirement: you must specify the unique identifier pseudoparameter in the name of the alarm (otherwise, Alarm Manager appends the unique identifier of the resource to the front of the alarm name). For example, for the **AWS::EC2::Instance** resource type, you must specify `${EC2::InstanceId}` in the alarm name, or it's implicitly added at the start of the alarm name. For the list of identifiers, see [Accelerate Configuration profile: pseudoparameter substitution](acc-mem-config-doc-sub.md).

      All other fields are as specified in the [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) or the [PutCompositeAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutCompositeAlarm.html) documentation.
    + **AlarmRule**: Specify which other alarms are to be evaluated to determine this composite alarm's state. For each alarm that you reference, they have to be either exist in CloudWatch or specified in Alarm Manager configuration profile in your account.

**Important**  
You can specify either **AlarmDefinition** or **CompositeAlarmDefinition** in your Alarm Manager configuration document, But they both can’t be used at the same time. 

In the following example, the system creates an alarm when two specified metric alarms exceeds its threshold:

```
{
  "AWS::EC2::Instance": {
    "LinuxResourceAlarm": {
      "Enabled": true,
      "Tag": {
        "Key": "ams:rt:mylinuxinstance",
        "Value": "true"
      },
      "CompositeAlarmDefinition": {
        "AlarmName": "${EC2::InstanceId} Resource Usage High",
        "AlarmDescription": "Alarm when a linux EC2 instance is using too much CPU and too much Disk",
        "AlarmRule": "ALARM(\"${EC2::InstanceId}: Disk Usage Too High - ${EC2::Disk::UUID}\") AND ALARM(\"${EC2::InstanceId}: CPU Too High\")"
      }
    }
  }
}
```

**Important**  
When Alarm Manager is not able to create or delete an alarm due to broke configuration, it sends the notification to the **Direct-Customer-Alerts** SNS topic. This alarm is called **AlarmDependencyError**.  
We highly recommend that you have confirmed your subscription to this SNS topic. To receive messages published to [a topic](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html), you must subscribe [an endpoint](https://docs.aws.amazon.com/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html#sns-endpoints) to the topic. For details, see [Step 1: Create a topic](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#step-create-queue). 

**Note**  
When Anomaly Detection alarms are created, Alarm Manager automatically creates the required Anomaly Detection Models for the specified metrics. When Anomaly Detection alarms are deleted, Alarm Manager doesn't delete the associated Anomaly Detection Models.  
[Amazon CloudWatch limits the number of Anomaly Detection Models](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html) that you can have in a given AWS Region. If you exceed the model quota, then Alarm Manager doesn't create new Anomaly Detection Alarms. You must either delete unused models, or work with your AMS partner to request a limit increase.  
Many of the AMS Accelerate-provided baseline alarm definitions list the SNS topic, **MMS-Topic**, as a target. This is for use in the AMS Accelerate monitoring service, and is the transport mechanism for your alarm notifications to get to AMS Accelerate. Do not specify **MMS-Topic** as the target for any alarms other than those provided in the baseline (and overrides of the same), as the service ignores unknown alarms. It **does not** result in AMS Accelerate acting on your custom alarms.

# Accelerate Configuration profile: pseudoparameter substitution
Configuration profile: pseudoparameter substitution

In either of the configuration profiles, you can specify pseudoparameters that are substituted in place as follows:
+ Global - anywhere in the profile:
  + \$1\$1AWS::AccountId\$1: Replaced with your AWS account ID
  + \$1\$1AWS::Partition\$1: Replaced with the partition of the AWS Region the resource is in (this is 'aws' for most AWS Regions); for more information, see the entry for partition in the [ARN reference](https://docs.amazonaws.cn/en_us/general/latest/gr/aws-arns-and-namespaces.html).
  + \$1\$1AWS::Region\$1: Replaced with the Region name of the Region that your resource is deployed to (for example us-east-1)
+ In an **AWS::EC2::Instance** resource type block:
  + \$1\$1EC2::InstanceId\$1: (**identifier**) replaced by the instance ID of your Amazon EC2 instance.
  + \$1\$1EC2::InstanceName\$1: replaced by the name of your Amazon EC2 instance. If the instance name is not defined, replaced by the instance ID of your Amazon EC2 instance.
+ In an **AWS::EC2::Instance::Disk** resource type block:
  + \$1\$1EC2::InstanceId\$1: (**identifier**) Replaced by the instance ID of your Amazon EC2 instance.
  + \$1\$1EC2::InstanceName\$1: Replaced by the name of your Amazon EC2 instance. If the instance name is not defined, replaced by the instance ID of your Amazon EC2 instance.
  + \$1\$1EC2::Disk::Device\$1: Replaced by the name of the disk. (Linux only, on instances managed by the [CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)).
  + \$1\$1EC2::Disk::FSType\$1: Replaced by the file system type of the disk. (Linux only, on instances managed by the [ CloudWatchAgent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)).
  + \$1\$1EC2::Disk::Path\$1: Replaced by the disk path. (Windows only, this is the drive label (for example, c:/), only on an instance managed by the [CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)).
  + \$1\$1EC2::Disk::UUID\$1: (**identifier**) Replaced by a generated UUID that uniquely identifies the disk, this must be specified in the name of the alarm, as an alarm under AWS::EC2::Instance::Disk resource type will create one alarm per volume. Specifying \$1\$1EC2::Disk::UUID\$1 maintains uniqueness of alarm names.
+ In an **AWS::OpenSearch::Domain** resource type block:
  + \$1\$1OpenSearch::DomainName\$1: (**identifier**) replaced by the name of your OpenSearch domain.
+ In an **AWS::Elasticsearch::Domain** resource type block:
  + \$1\$1Elasticsearch::DomainName\$1: (**identifier**) replaced by the name of your Elasticsearch domain.
+ In an **AWS::ElasticLoadBalancing::LoadBalancer** resource type block:
  + \$1\$1ElasticLoadBalancing::LoadBalancer::Name\$1: (**identifier**) replaced by the name of your V1 Load Balancer.
+ In an **AWS::ElasticLoadBalancingV2::LoadBalancer** resource type block:
  + \$1\$1ElasticLoadBalancingV2::LoadBalancer::Arn\$1: replaced by the ARN of your V2 Load Balancer.
  + \$1\$1ElasticLoadBalancingV2::LoadBalancer\$1: replaced by the ARN of your V2 Load Balancer.
  + \$1\$1ElasticLoadBalancingV2::LoadBalancer::Name\$1: (**identifier**) replaced by the name of your V2 Load Balancer.
  + \$1\$1ElasticLoadBalancingV2::LoadBalancer::FullName\$1: replaced by the full name of your V2 Load Balancer.
+ In an **AWS::ElasticLoadBalancingV2::LoadBalancer::TargetGroup** resource type block:
  + \$1\$1ElasticLoadBalancingV2::TargetGroup::FullName\$1: (**identifier**) replaced by the target group name of your V2 Load Balancer.
  + \$1\$1ElasticLoadBalancingV2::TargetGroup::UUID\$1: (**identifier**) replaced by a generated UUID for your V2 Load Balancer.
  + \$1\$1ElasticLoadBalancingV2::LoadBalancer::FullName\$1: Replaced by the full name of your V2 Load Balancer.
+ In an **AWS::EC2::NatGateway** resource type block:
  + \$1\$1NatGateway::NatGatewayId\$1: (**identifier**) replaced by the NAT Gateway ID.
+ In an **AWS::RDS::DBInstance** resource type block:
  + \$1\$1RDS::DBInstanceIdentifier\$1: (**identifier**) replaced by your RDS DB instance identifier.
+ In an **AWS::Redshift::Cluster** resource type block:
  + \$1\$1Redshift::ClusterIdentifier\$1: (**identifier**) replaced by your Redshift cluster identifier.
+ In an **AWS::EC2::VPNConnection** resource type block:
  + \$1\$1AWS::EC2::VpnConnectionId\$1: (**identifier**) replaced by your VPN ID.
+ In an **AWS::EFS::FileSystem** resource type block:
  + \$1\$1EFS::FileSystemId\$1: (**identifier**) Replaced by the file system ID of your EFS file system.
+ In an **AWS::FSx::FileSystem::ONTAP** resource type block:
  + \$1\$1FSx::FileSystemId\$1: (**identifier**) Replaced by the file system ID of your FSX filesystem.
  + \$1\$1FSx::FileSystem::Throughput\$1: Replaced by the throughput of your FSX file system.
  + \$1\$1FSx::FileSystem::Iops\$1: Replaced by the IOPS of the FSX file system.
+ In an **AWS::FSx::FileSystem::ONTAP::Volume** resource type block:
  + \$1\$1FSx::FileSystemId\$1: (**identifier**) Replaced by the file system ID of your FSX file system.
  + \$1\$1FSx::ONTAP::VolumeId\$1: (**identifier**) Replaced by the volume ID.
+ In an **AWS::FSx::FileSystem::Windows** resource type block:
  + \$1\$1FSx::FileSystemId\$1: (**identifier**) Replaced by the file system ID of your FSX file system.
  + \$1\$1FSx::FileSystem::Throughput\$1: Replaced by the throughput of your FSX file system.

**Note**  
All parameters marked with **identifier** are used as a prefix for the name of created alarms, unless you specify that identifier in the alarm name.

# Accelerate alarm configuration examples
Configuration examples

In the following example, the system creates an alarm for each disk attached to the matching Linux instance.

```
{
    "AWS::EC2::Instance::Disk": {
        "LinuxDiskAlarm": {
            "Tag": {
                "Key": "ams:rt:mylinuxinstance",
                "Value": "true"
            },
            "AlarmDefinition": {
                "MetricName": "disk_used_percent",
                "Namespace": "CWAgent",
                "Dimensions": [
                    {
                        "Name": "InstanceId",
                        "Value": "${EC2::InstanceId}"
                    },
                    {
                        "Name": "device",
                        "Value": "${EC2::Disk::Device}"
                    },
                    {
                        "Name": "fstype",
                        "Value": "${EC2::Disk::FSType}"
                    }
                ],
                "AlarmName": "${EC2::InstanceId}: Disk Usage Too High - ${EC2::Disk::UUID}"
                ...
            }
        }
    }
}
```

In the following example, the system creates an alarm for each disk attached to the matching Windows instance.

```
{
     "AWS::EC2::Instance::Disk": {
        "WindowsDiskAlarm": {
            "Tag": {
                "Key": "ams:rt:mywindowsinstance",
                "Value": "true"
            },
            "AlarmDefinition": {
                "MetricName": "LogicalDisk % Free Space",
                "Namespace": "CWAgent",
                "Dimensions": [
                    {
                        "Name": "InstanceId",
                        "Value": "${EC2::InstanceId}"
                    },
                    {
                        "Name": "objectname",
                        "Value": "LogicalDisk"
                    },
                    {
                        "Name": "instance",
                        "Value": "${EC2::Disk::Path}"
                    }
                ],
                "AlarmName": "${EC2::InstanceId}: Disk Usage Too High - ${EC2::Disk::UUID}"
                ...
            }
        }
    }
}
```

# Viewing your Accelerate Alarm Manager configuration
Viewing your Alarm Manager configuration

Both the **AMSManagedAlarms** and **CustomerManagedAlarms** can be reviewed in AppConfig with [GetConfiguration](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_GetConfiguration.html).

The following is an example of the `GetConfiguration` call:

```
aws appconfig get-configuration --application AMSAlarmManager --environment AMSInfrastructure --configuration AMSManagedAlarms --client-id 
      any-string outfile.json
```
+ **Application**: this is AppConfig's logical unit to provide capabilities; for the Alarm Manager, this is `AMSAlarmManager`
+ **Environment**: this is the AMSInfrastructure environment
+ **Configuration**: to view AMS Accelerate baseline alarms, the value is `AMSManagedAlarms`; to view customer alarm definitions, the configuration is `CustomerManagedAlarms`
+ **Client ID**: this is a unique application instance identifier, which can be any string
+ The alarm definitions can be viewed in the specified output file, which in this case is `outfile.json`

 You can see which version of configuration is deployed to your account by viewing the past deployments in the AMSInfrastructure environment.

# Changing the Accelerate alarm configuration
Changing the alarm configuration

To add or update new alarm definitions, you can either deploy configuration document [Using CloudFormation to deploy Accelerate configuration changes](acc-mem-deploy-change-cfn.md), or invoke the [CreateHostedConfigurationVersion](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_CreateHostedConfigurationVersion.html) API.

This is a Linux command line command that generates the parameter value in base64, which is what the AppConfig CLI command expects. For information, see the AWS CLI documentation, [Binary/Blob (binary large object)](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-types.html#parameter-type-blob).

As an example:

```
aws appconfig create-hosted-configuration-version --application-id application-id --configuration-profile-id configuration-profile-id --content base64-string 
      --content-type application/json
```
+ **Application ID:** ID of the application AMS AlarmManager; you can find this out with the [ListApplications](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_ListApplications.html) API call.
+ **Configuration Profile ID**: ID of the configuration CustomerManagedAlarms; you can find this out with the [ListConfigurationProfiles](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_ListConfigurationProfiles.html) API call.
+ **Content**: Base64 string of the content, to be created by creating a document and encoding it in base64: cat alarms-v2.json \$1 base64 (see [Binary/Blob (binary large object)](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-types.html#parameter-type-blob)).

  **Content Type**: MIME type, `application/json` because alarm definitions are written in JSON.

**Important**  
Restrict access to the [StartDeployment](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_StartDeployment.html) and [StopDeployment](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_StopDeployment.html) API actions to trusted users who understand the responsibilities and consequences of deploying a new configuration to your targets.

To learn more about how to use AWS AppConfig features to create and deploy a configuration, see [Working with AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-working.html).

# Modifying the Accelerate alarm default configuration
Modifying the default configuration

While you can't modify the default configuration profile, you can provide overrides to the defaults by specifying a configuration block in your customization profile with the same **ConfigurationID** as the default configuration block. If you do this, your whole configuration block overwrites the default configuration block for which tagging configuration to apply.

For example, consider the following default configuration profile:

```
{
    "AWS::EC2::Instance": {
        "AMSManagedBlock1": {
            "Enabled": true,
            "Tag": {
                "Key": "ams:rt:ams-monitoring-policy",
                "Value": "ams-monitored"
            },
            "AlarmDefinition": {
                "AlarmName": "${EC2::InstanceId}: AMS Default Alarm",
                "Namespace": "AWS/EC2",
                "MetricName": "CPUUtilization",
                "Dimensions": [
                    {
                        "Name": "InstanceId",
                        "Value": "${EC2::InstanceId}"
                    }
                ],
                "Threshold": 5,
                ...
            }
        }
    }
}
```

In order to change the threshold of this alarm to 10, **you must provide the entire alarm definition**, not only the parts you want to change. For example, you might provide the following customization profile:

```
{
    "AWS::EC2::Instance": {
        "AMSManagedBlock1": {
            "Enabled": true,
            "Tag": {
                "Key": "ams:rt:ams-monitoring-policy",
                "Value": "ams-monitored"
            },
            "AlarmDefinition": {
                "AlarmName": "${EC2::InstanceId}: AMS Default Alarm",
                "Namespace": "AWS/EC2",
                "MetricName": "CPUUtilization",
                "Dimensions": [
                    {
                        "Name": "InstanceId",
                        "Value": "${EC2::InstanceId}"
                    }
                ],
                "Threshold": 10,
                ...
            }
        }
    }
}
```

**Important**  
Remember to deploy your configuration changes after you have made them. In SSM AppConfig, you must deploy a new version of the configuration after creating it.

# Deploying Accelerate alarm configuration changes
Deploying configuration changes

After you finish a customization, you need to deploy it, either with AppConfig or CloudFormation.

**Topics**
+ [

# Using AppConfig to deploy Accelerate alarm configuration changes
](acc-mem-deploy-change-appconfig.md)
+ [

# Using CloudFormation to deploy Accelerate configuration changes
](acc-mem-deploy-change-cfn.md)

# Using AppConfig to deploy Accelerate alarm configuration changes
Using AppConfig to deploy configuration changes

Once the customization is completed, use AppConfig to deploy your changes with [StartDeployment](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_StartDeployment.html).

```
  aws appconfig start-deployment --application-id application_id 
   --environment-id environment_id Vdeployment-strategy-id 
   deployment_strategy_id --configuration-profile-id configuration_profile_id --configuration-version 1
```
+ **Application ID**: ID of the application `AMSAlarmManager`, you can find this with the [ListApplications](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_ListApplications.html) API call.
+ **Environment ID**: You can find this with the [ListEnvironments](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_ListEnvironments.html) API call.
+ **Deployment Strategy ID**: You can find this with the [ListDeploymentStrategies](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_ListDeploymentStrategies.html) API call.
+ **Configuration Profile ID**: ID of `CustomerManagedAlarms`; you can find this with the [ListConfigurationProfiles](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_ListConfigurationProfiles.html) API call.
+ **Configuration Version**: The version of the configuration profile to be deployed.

**Important**  
 Alarm Manager applies the alarm definitions as specified in the configuration profiles. Any manual modifications you make with the AWS Management Console or CloudWatch CLI/SDK to the CloudWatch alarms is automatically reverted back, so make sure your changes are defined through Alarm Manager. To understand which alarms are created by the Alarm Manager, you can look for the `ams:alarm-manager:managed` tag with value `true`.  
Restrict access to the [StartDeployment](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_StartDeployment.html) and [ StopDeployment](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_StopDeployment.html) API actions to trusted users who understand the responsibilities and consequences of deploying a new configuration to your targets.

To learn more about how to use AWS AppConfig features to create and deploy a configuration, see the [AWS AppConfig documentation.](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-working.html)

# Using CloudFormation to deploy Accelerate configuration changes
Deploying configuration changes with CloudFormation

If you wish to deploy your `CustomerManagedAlarms` configuration profile using CloudFormation, you can use the following CloudFormation templates. Put your desired JSON configuration in the `AMSAlarmManagerConfigurationVersion.Content` field.

When you deploy the templates in a CloudFormation Stack or Stack Set, the deployment of the `AMSResourceTaggerDeployment` resource will fail if you have not followed the required JSON format for the configuration. See [Accelerate Configuration profile: monitoring](acc-mem-config-doc-format.md) for details on the expected format.

For help on deploying these templates as a CloudFormation stack or stack set, see the relevant AWS CloudFormation documentation below:
+ [Creating a stack on the AWS CloudFormation console](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)
+ [Creating a stack with AWS CLI](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-cli-creating-stack.html)
+ [Creating a stack set](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html)

**Note**  
If you deploy a configuration version using one of these templates, and then subsequently delete the CloudFormation stack/stack set, the template configuration version will remain as the current deployed version, and no additional deployment will be made. If you wish to revert back to a default configuration, you will need to either manually deploy an empty configuration (i.e. just \$1\$1), or update your stack to an empty configuration, rather than deleting the stack.

**JSON**

```
{
  "Description": "Custom configuration for the AMS Alarm Manager.",
  "Resources": {
    "AMSAlarmManagerConfigurationVersion": {
      "Type": "AWS::AppConfig::HostedConfigurationVersion",
      "Properties": {
        "ApplicationId": {
          "Fn::ImportValue": "AMS-Alarm-Manager-Configuration-ApplicationId"
        },
        "ConfigurationProfileId": {
          "Fn::ImportValue": "AMS-Alarm-Manager-Configuration-CustomerManagedAlarms-ProfileID"
        },
        "Content": "{}",
        "ContentType": "application/json"
      }
    },
    "AMSAlarmManagerDeployment": {
      "Type": "AWS::AppConfig::Deployment",
      "Properties": {
        "ApplicationId": {
          "Fn::ImportValue": "AMS-Alarm-Manager-Configuration-ApplicationId"
        },
        "ConfigurationProfileId": {
          "Fn::ImportValue": "AMS-Alarm-Manager-Configuration-CustomerManagedAlarms-ProfileID"
        },
        "ConfigurationVersion": {
          "Ref": "AMSAlarmManagerConfigurationVersion"
        },
        "DeploymentStrategyId": {
          "Fn::ImportValue": "AMS-Alarm-Manager-Configuration-Deployment-StrategyID"
        },
        "EnvironmentId": {
          "Fn::ImportValue": "AMS-Alarm-Manager-Configuration-EnvironmentId"
        }
      }
    }
  }
}
```

**YAML**

```
Description: Custom configuration for the AMS Alarm Manager.
Resources:
  AMSAlarmManagerConfigurationVersion:
    Type: AWS::AppConfig::HostedConfigurationVersion
    Properties:
      ApplicationId:
        !ImportValue AMS-Alarm-Manager-Configuration-ApplicationId
      ConfigurationProfileId:
        !ImportValue AMS-Alarm-Manager-Configuration-CustomerManagedAlarms-ProfileID
      Content: |
        {
          
        }
      ContentType: application/json
  AMSAlarmManagerDeployment:
    Type: AWS::AppConfig::Deployment
    Properties:
      ApplicationId:
        !ImportValue AMS-Alarm-Manager-Configuration-ApplicationId
      ConfigurationProfileId:
        !ImportValue AMS-Alarm-Manager-Configuration-CustomerManagedAlarms-ProfileID
      ConfigurationVersion:
        !Ref AMSAlarmManagerConfigurationVersion
      DeploymentStrategyId:
        !ImportValue AMS-Alarm-Manager-Configuration-Deployment-StrategyID
      EnvironmentId:
        !ImportValue AMS-Alarm-Manager-Configuration-EnvironmentId
```

# Rolling back Accelerate alarm changes
Rolling back alarm changes

You can roll back alarm definitions through the same deployment mechanism by specifying a previous configuration profile version and running [ StartDeployment.](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_StartDeployment.html)

# Retaining Accelerate alarms
Retaining alarms

When resources monitored by AMS are deleted, any alarms created by Alarm Manager for those resources are automatically deleted by Alarm Manager. If you need to retain certain alarms for auditing, compliance, or historical purposes, use the Alarm Manager retain-tagging capability.

To retain an alarm even after its monitored resource is deleted, add an `"ams:alarm-manager:retain" `tag to the alarm's custom configuration as shown in the following example.

```
{
  "AWS::EC2::Instance": {
    "AMSCpuAlarm": {
      "Enabled": true,
      "Tag": {
        "Key": "ams:rt:ams-monitoring-policy",
        "Value": "ams-monitored"
      },
      "AlarmDefinition": {
        "AlarmName": "${EC2::InstanceId}: CPU Too High",
        "AlarmDescription": "AMS Baseline Alarm for EC2 CPUUtilization",
        [...]
        "Tags": [
          {
            "Key": "ams:alarm-manager:retain",
            "Value": "true"
          }
        ]
      }
    }
  }
}
```

An alarm configured with the `"ams:alarm-manager:retain"` tag, is not automatically deleted by Alarm Manager when the monitored resource is terminated. The retained alarm persists in CloudWatch indefinitely until you manually remove it using CloudWatch.

# Disabling the default Accelerate alarm configuration
Disabling the default configuration

AMS Accelerate provides the default configuration profile in your account based on the baseline alarms. However, this default configuration can be disabled by overriding any of the alarm definitions. You can disable a default configuration rule by overriding the **ConfigurationID** of the rule in your customization configuration profile and specifying the enabled field with a value of false.

For example, if the following configuration was present in the default configuration profile:

```
{
    "AWS::EC2::Instance": {
        "AMSManagedBlock1": {
            "Enabled": true,
            "Tag": {
                "Key": "ams:rt:ams-monitoring-policy",
                "Value": "ams-monitored"
            },
            "AlarmDefinition": {
                ...
            }
        }
    }
```

You could disable this tagging rule by including the following in your customization configuration profile:

```
{
    "AWS::EC2::Instance": {
        "AMSManagedBlock1": {
            "Enabled": false
        }
    }
}
```

To make these changes, the [CreateHostedConfigurationVersion](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_CreateHostedConfigurationVersion.html) API must be called with the JSON profile document (see [Changing the Accelerate alarm configuration](acc-mem-change-am.md)) and subsequently must be deployed (see [Deploying Accelerate alarm configuration changes](acc-mem-deploy-change.md)). Note that when you create the new configuration version, you must also include any previously created custom alarms that you want in the JSON profile document.

**Important**  
When AMS Accelerate updates the default configuration profile, it's not calibrated against your configured custom alarms, so review changes to the default alarms when you're overriding them in your customization configuration profile.

# Creating additional CloudWatch alarms for Accelerate
Creating additional CloudWatch alarms

You can create additional CloudWatch alarms for AMS Accelerate using custom CloudWatch metrics and alarms for Amazon EC2 instances.

Produce your application monitoring script and custom metric. For more information and access to example scripts, see [Monitoring Memory and Disk Metrics for Amazon EC2 Linux Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html).

The CloudWatch monitoring scripts for Linux Amazon EC2 instances demonstrate how to produce and consume custom CloudWatch metrics. These sample Perl scripts comprise a fully functional example that reports memory, swap, and disk space utilization metrics for a Linux instance.

**Important**  
AMS Accelerate does not monitor CloudWatch alarms created by you.