# Adding Aurora Replicas to a DB cluster
An Aurora DB cluster with replication has one primary DB instance and up to 15 Aurora Replicas. The primary DB instance supports read and write operations, and performs all data modifications to the cluster volume. Aurora Replicas connect to the same storage volume as the primary DB instance, but support read operations only. You use Aurora Replicas to offload read workloads from the primary DB instance. For more information, see [Aurora Replicas](Aurora.Replication.md#Aurora.Replication.Replicas).
Amazon Aurora Replicas have the following limitations:
+ However, you can add reader instances to Aurora Serverless v2 DB clusters. For more information, see [Adding an Aurora Serverless v2 reader](aurora-serverless-v2-administration.md#aurora-serverless-v2-adding-reader).
We recommend that you distribute the primary instance and Aurora Replicas of your Aurora DB cluster over multiple Availability Zones to improve the availability of your DB cluster. For more information, see [Region availability](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
To remove an Aurora Replica from an Aurora DB cluster, delete the Aurora Replica by following the instructions in [Deleting a DB instance from an Aurora DB cluster](USER_DeleteCluster.md#USER_DeleteInstance).
**Note**
Amazon Aurora also supports replication with an external database, such as an RDS DB instance. The RDS DB instance must be in the same AWS Region as Amazon Aurora. For more information, see [Replication with Amazon Aurora](Aurora.Replication.md).
You can add Aurora Replicas to a DB cluster using the AWS Management Console, the AWS CLI, or the RDS API.
## Console
**To add an Aurora replica to a DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**, and then select the DB cluster where you want to add the new DB instance.
1. Make sure that both the cluster and the primary instance are in the **Available** state. If the DB cluster or the primary instance are in a transitional state such as **Creating**, you can't add a replica.
If the cluster doesn't have a primary instance, create one using the [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI command. This situation can arise if you used the CLI to restore a DB cluster snapshot and then view the cluster in the AWS Management Console.
1. For **Actions**, choose **Add reader**.
The **Add reader** page appears.
1. On the **Add reader** page, specify options for your Aurora Replica. The following table shows settings for an Aurora Replica.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-replicas-adding.html)
1. Choose **Add reader** to create the Aurora Replica.
## AWS CLI
To create an Aurora Replica in your DB cluster, run the [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI command. Include the name of the DB cluster as the `--db-cluster-identifier` option. You can optionally specify an Availability Zone for the Aurora Replica using the `--availability-zone` parameter, as shown in the following examples.
For example, the following command creates a new MySQL 5.7–compatible Aurora Replica named `sample-instance-us-west-2a`.
For Linux, macOS, or Unix:
```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a \
--db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class db.r5.large \
--availability-zone us-west-2a
```
For Windows:
```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a ^
--db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class db.r5.large ^
--availability-zone us-west-2a
```
The following command creates a new MySQL 5.7–compatible Aurora Replica named `sample-instance-us-west-2a`.
For Linux, macOS, or Unix:
```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a \
--db-cluster-identifier sample-cluster --engine aurora-mysql --db-instance-class db.r5.large \
--availability-zone us-west-2a
```
For Windows:
```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a ^
--db-cluster-identifier sample-cluster --engine aurora --db-instance-class db.r5.large ^
--availability-zone us-west-2a
```
The following command creates a new PostgreSQL-compatible Aurora Replica named `sample-instance-us-west-2a`.
For Linux, macOS, or Unix:
```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a \
--db-cluster-identifier sample-cluster --engine aurora-postgresql --db-instance-class db.r5.large \
--availability-zone us-west-2a
```
For Windows:
```
aws rds create-db-instance --db-instance-identifier sample-instance-us-west-2a ^
--db-cluster-identifier sample-cluster --engine aurora-postgresql --db-instance-class db.r5.large ^
--availability-zone us-west-2a
```
## RDS API
To create an Aurora Replica in your DB cluster, call the [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) operation. Include the name of the DB cluster as the `DBClusterIdentifier` parameter. You can optionally specify an Availability Zone for the Aurora Replica using the `AvailabilityZone` parameter.
For information about Auto Scaling Amazon Aurora with Aurora replicas, see the following sections.
**Topics**
+ [Amazon Aurora Auto Scaling with Aurora Replicas](Aurora.Integrating.AutoScaling.md)
+ [Adding an auto scaling policy to an Amazon Aurora DB cluster](Aurora.Integrating.AutoScaling.Add.md)
+ [Editing an auto scaling policy for an Amazon Aurora DB cluster](Aurora.Integrating.AutoScaling.Edit.md)
+ [Deleting an auto scaling policy from your Amazon Aurora DB cluster](Aurora.Integrating.AutoScaling.Delete.md)
# Amazon Aurora Auto Scaling with Aurora Replicas
To meet your connectivity and workload requirements, Aurora Auto Scaling dynamically adjusts the number of Aurora Replicas (reader DB instances) provisioned for an Aurora DB cluster. Aurora Auto Scaling is available for both Aurora MySQL and Aurora PostgreSQL. Aurora Auto Scaling enables your Aurora DB cluster to handle sudden increases in connectivity or workload. When the connectivity or workload decreases, Aurora Auto Scaling removes unnecessary Aurora Replicas so that you don't pay for unused provisioned DB instances.
You define and apply a scaling policy to an Aurora DB cluster. The *scaling policy* defines the minimum and maximum number of Aurora Replicas that Aurora Auto Scaling can manage. Based on the policy, Aurora Auto Scaling adjusts the number of Aurora Replicas up or down in response to actual workloads, determined by using Amazon CloudWatch metrics and target values.
**Note**
Aurora Auto Scaling doesn't apply to the workload on the writer DB instance. Aurora Auto Scaling helps with the workload only on the reader instances.
You can use the AWS Management Console to apply a scaling policy based on a predefined metric. Alternatively, you can use either the AWS CLI or Aurora Auto Scaling API to apply a scaling policy based on a predefined or custom metric.
**Topics**
+ [Before you begin](#Aurora.Integrating.AutoScaling.BYB)
+ [Aurora Auto Scaling policies](#Aurora.Integrating.AutoScaling.Concepts)
+ [DB instance IDs and tagging](#Aurora.Integrating.AutoScaling.Concepts.Tagging)
+ [Aurora Auto Scaling and Performance Insights](#aurora-auto-scaling-pi)
## Before you begin
Before you can use Aurora Auto Scaling with an Aurora DB cluster, you must first create an Aurora DB cluster with a primary (writer) DB instance. For more information about creating an Aurora DB cluster, see [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md).
Aurora Auto Scaling only scales a DB cluster if the DB cluster is in the available state.
When Aurora Auto Scaling adds a new Aurora Replica, the new Aurora Replica is the same DB instance class as the one used by the primary instance. For more information about DB instance classes, see [Amazon AuroraDB instance classes](Concepts.DBInstanceClass.md). Also, the promotion tier for new Aurora Replicas is set to the last priority, which is 15 by default. This means that during a failover, a replica with a better priority, such as one created manually, would be promoted first. For more information, see [Fault tolerance for an Aurora DB cluster](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance).
Aurora Auto Scaling only removes Aurora Replicas that it created.
To benefit from Aurora Auto Scaling, your applications must support connections to new Aurora Replicas. To do so, we recommend using the Aurora reader endpoint. You can use a driver such as the AWS JDBC Driver. For more information, see [Connecting to an Amazon Aurora DB cluster](Aurora.Connecting.md).
**Note**
Aurora global databases currently don't support Aurora Auto Scaling for secondary DB clusters.
## Aurora Auto Scaling policies
Aurora Auto Scaling uses a scaling policy to adjust the number of Aurora Replicas in an Aurora DB cluster. Aurora Auto Scaling has the following components:
+ A service-linked role
+ A target metric
+ Minimum and maximum capacity
+ A cooldown period
**Topics**
+ [Service linked role](#Aurora.Integrating.AutoScaling.Concepts.SLR)
+ [Target metric](#Aurora.Integrating.AutoScaling.Concepts.TargetMetric)
+ [Minimum and maximum capacity](#Aurora.Integrating.AutoScaling.Concepts.Capacity)
+ [Cooldown period](#Aurora.Integrating.AutoScaling.Concepts.Cooldown)
+ [Enable or disable scale-in activities](#Aurora.Integrating.AutoScaling.Concepts.ScaleIn)
+ [Add, edit, or delete auto scaling policies](#Aurora.Integrating.AutoScaling.Concepts.AddEditDelete)
### Service linked role
Aurora Auto Scaling uses the `AWSServiceRoleForApplicationAutoScaling_RDSCluster` service-linked role. For more information, see [Service-linked roles for Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) in the *Application Auto Scaling User Guide*.
### Target metric
In this type of policy, a predefined or custom metric and a target value for the metric is specified in a target-tracking scaling policy configuration. Aurora Auto Scaling creates and manages CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustment based on the metric and target value. The scaling policy adds or removes Aurora Replicas as required to keep the metric at, or close to, the specified target value. In addition to keeping the metric close to the target value, a target-tracking scaling policy also adjusts to fluctuations in the metric due to a changing workload. Such a policy also minimizes rapid fluctuations in the number of available Aurora Replicas for your DB cluster.
For example, take a scaling policy that uses the predefined average CPU utilization metric. Such a policy can keep CPU utilization at, or close to, a specified percentage of utilization, such as 40 percent.
**Note**
For each Aurora DB cluster, you can create only one Auto Scaling policy for each target metric.
When you configure Aurora Auto Scaling, the target metric value is calculated as the average of all reader instances in the cluster. This calculation is performed as follows:
+ Includes all reader instances in the Aurora cluster, regardless of whether they’re managed by Auto Scaling or added manually.
+ Includes instances associated with custom endpoints. Custom endpoints don’t influence the calculation of target metrics.
+ Does not include the cluster’s writer instance.
The metrics are derived from CloudWatch using the following dimensions:
+ `DBClusterIdentifier`
+ `Role=READER`
For example, consider an Aurora MySQL cluster with the following setup:
+ **Manual instances (not controlled by Auto Scaling)**:
+ Writer with 50% CPU utilization
+ Reader 1 (custom endpoint: `custom-reader-1`) with 90% CPU utilization
+ Reader 2 (custom endpoint: `custom-reader-2`) with 90% CPU utilization
+ **Auto Scaling instance**:
+ Reader 3 (added using Auto Scaling) with 10% CPU utilization
In this scenario, the target metric for the Auto Scaling policy is calculated as follows:
```
Target metric = (CPU utilization of reader 1 + reader 2 + reader 3) / total number of readers
Target metric = (90 + 90 + 10) / 3 = 63.33%
```
The Auto Scaling policy uses this value to evaluate whether to scale in or scale out based on the defined threshold.
Consider the following:
+ Although custom endpoints determine how traffic is routed to specific readers, they don’t exclude readers from the metric calculation.
+ Manual instances are always included in the target metric calculations.
+ To avoid unexpected scaling behavior, make sure that the Auto Scaling configuration accounts for all reader instances in the cluster.
+ If a cluster has no readers, the metric is not calculated, and the Auto Scaling policy alarms remain inactive. For the Auto Scaling policy to function effectively, at least one reader must be present at all times.
### Minimum and maximum capacity
You can specify the maximum number of Aurora Replicas to be managed by Application Auto Scaling. This value must be set to 0–15, and must be equal to or greater than the value specified for the minimum number of Aurora Replicas.
You can also specify the minimum number of Aurora Replicas to be managed by Application Auto Scaling. This value must be set to 0–15, and must be equal to or less than the value specified for the maximum number of Aurora Replicas.
There must be at least one reader DB instance for Aurora Auto Scaling to work. If the DB cluster has no reader instance, and you set the minimum capacity to 0, then Aurora Auto Scaling won't work.
**Note**
The minimum and maximum capacity are set for an Aurora DB cluster. The specified values apply to all of the policies associated with that Aurora DB cluster.
### Cooldown period
You can tune the responsiveness of a target-tracking scaling policy by adding cooldown periods that affect scaling your Aurora DB cluster in and out. A cooldown period blocks subsequent scale-in or scale-out requests until the period expires. These blocks slow the deletions of Aurora Replicas in your Aurora DB cluster for scale-in requests, and the creation of Aurora Replicas for scale-out requests.
You can specify the following cooldown periods:
+ A scale-in activity reduces the number of Aurora Replicas in your Aurora DB cluster. A scale-in cooldown period specifies the amount of time, in seconds, after a scale-in activity completes before another scale-in activity can start.
+ A scale-out activity increases the number of Aurora Replicas in your Aurora DB cluster. A scale-out cooldown period specifies the amount of time, in seconds, after a scale-out activity completes before another scale-out activity can start.
**Note**
A scale-out cooldown period is ignored if a subsequent scale-out request is for a larger number of Aurora Replicas than the first request.
If you don't set the scale-in or scale-out cooldown period, the default for each is 300 seconds.
### Enable or disable scale-in activities
You can enable or disable scale-in activities for a policy. Enabling scale-in activities allows the scaling policy to delete Aurora Replicas. When scale-in activities are enabled, the scale-in cooldown period in the scaling policy applies to scale-in activities. Disabling scale-in activities prevents the scaling policy from deleting Aurora Replicas.
**Note**
Scale-out activities are always enabled so that the scaling policy can create Aurora Replicas as needed.
### Add, edit, or delete auto scaling policies
You can add, edit, or delete auto scaling policies using the AWS Management Console, AWS CLI, or Application Auto Scaling API. For more information about adding, editing, or deleting auto scaling policies, see the following sections.
+ [Adding an auto scaling policy to an Amazon Aurora DB cluster](Aurora.Integrating.AutoScaling.Add.md)
+ [Editing an auto scaling policy for an Amazon Aurora DB cluster](Aurora.Integrating.AutoScaling.Edit.md)
+ [Deleting an auto scaling policy from your Amazon Aurora DB cluster](Aurora.Integrating.AutoScaling.Delete.md)
## DB instance IDs and tagging
When a replica is added by Aurora Auto Scaling, its DB instance ID is prefixed by `application-autoscaling-`, for example, `application-autoscaling-61aabbcc-4e2f-4c65-b620-ab7421abc123`.
The following tag is automatically added to the DB instance. You can view it on the **Tags** tab of the DB instance detail page.
| Tag | Value |
| --- | --- |
| application-autoscaling:resourceId | cluster:mynewcluster-cluster |
For more information on Amazon RDS resource tags, see [Tagging Amazon Aurora andAmazon RDS resources](USER_Tagging.md).
## Aurora Auto Scaling and Performance Insights
You can use Performance Insights to monitor replicas that have been added by Aurora Auto Scaling, the same as with any Aurora reader DB instance.
For more information on using Performance Insights to monitor Aurora DB clusters, see [Monitoring DB load with Performance Insights on Amazon Aurora](USER_PerfInsights.md).
# Adding an auto scaling policy to an Amazon Aurora DB cluster
You can add a scaling policy using the AWS Management Console, the AWS CLI, or the Application Auto Scaling API.
**Note**
For an example that adds a scaling policy using CloudFormation, see [Declaring a scaling policy for an Aurora DB cluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-autoscaling.html#w2ab1c19c22c15c21c11) in the *AWS CloudFormation User Guide.*
## Console
You can add a scaling policy to an Aurora DB cluster by using the AWS Management Console.
**To add an auto scaling policy to an Aurora DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the Aurora DB cluster that you want to add a policy for.
1. Choose the **Logs & events** tab.
1. In the **Auto scaling policies** section, choose **Add**.
The **Add Auto Scaling policy** dialog box appears.
1. For **Policy Name**, type the policy name.
1. For the target metric, choose one of the following:
+ **Average CPU utilization of Aurora Replicas** to create a policy based on the average CPU utilization.
+ **Average connections of Aurora Replicas** to create a policy based on the average number of connections to Aurora Replicas.
1. For the target value, type one of the following:
+ If you chose **Average CPU utilization of Aurora Replicas** in the previous step, type the percentage of CPU utilization that you want to maintain on Aurora Replicas.
+ If you chose **Average connections of Aurora Replicas** in the previous step, type the number of connections that you want to maintain.
Aurora Replicas are added or removed to keep the metric close to the specified value.
1. (Optional) Expand **Additional Configuration** to create a scale-in or scale-out cooldown period.
1. For **Minimum capacity**, type the minimum number of Aurora Replicas that the Aurora Auto Scaling policy is required to maintain.
1. For **Maximum capacity**, type the maximum number of Aurora Replicas the Aurora Auto Scaling policy is required to maintain.
1. Choose **Add policy**.
The following dialog box creates an Auto Scaling policy based an average CPU utilization of 40 percent. The policy specifies a minimum of 5 Aurora Replicas and a maximum of 15 Aurora Replicas.
![\[Creating an auto scaling policy based on average CPU utilization\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-autoscaling-cpu.png)
The following dialog box creates an auto scaling policy based an average number of connections of 100. The policy specifies a minimum of two Aurora Replicas and a maximum of eight Aurora Replicas.
![\[Creating an Auto Scaling policy based on average connections\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-autoscaling-connections.png)
## AWS CLI or Application Auto Scaling API
You can apply a scaling policy based on either a predefined or custom metric. To do so, you can use the AWS CLI or the Application Auto Scaling API. The first step is to register your Aurora DB cluster with Application Auto Scaling.
### Registering an Aurora DB cluster
Before you can use Aurora Auto Scaling with an Aurora DB cluster, you register your Aurora DB cluster with Application Auto Scaling. You do so to define the scaling dimension and limits to be applied to that cluster. Application Auto Scaling dynamically scales the Aurora DB cluster along the `rds:cluster:ReadReplicaCount` scalable dimension, which represents the number of Aurora Replicas.
To register your Aurora DB cluster, you can use either the AWS CLI or the Application Auto Scaling API.
#### AWS CLI
To register your Aurora DB cluster, use the [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) AWS CLI command with the following parameters:
+ `--service-namespace` – Set this value to `rds`.
+ `--resource-id` – The resource identifier for the Aurora DB cluster. For this parameter, the resource type is `cluster` and the unique identifier is the name of the Aurora DB cluster, for example `cluster:myscalablecluster`.
+ `--scalable-dimension` – Set this value to `rds:cluster:ReadReplicaCount`.
+ `--min-capacity` – The minimum number of reader DB instances to be managed by Application Auto Scaling. For information about the relationship between `--min-capacity`, `--max-capacity`, and the number of DB instances in your cluster, see [Minimum and maximum capacity](Aurora.Integrating.AutoScaling.md#Aurora.Integrating.AutoScaling.Concepts.Capacity).
+ `--max-capacity` – The maximum number of reader DB instances to be managed by Application Auto Scaling. For information about the relationship between `--min-capacity`, `--max-capacity`, and the number of DB instances in your cluster, see [Minimum and maximum capacity](Aurora.Integrating.AutoScaling.md#Aurora.Integrating.AutoScaling.Concepts.Capacity).
**Example**
In the following example, you register an Aurora DB cluster named `myscalablecluster`. The registration indicates that the DB cluster should be dynamically scaled to have from one to eight Aurora Replicas.
For Linux, macOS, or Unix:
```
aws application-autoscaling register-scalable-target \
--service-namespace rds \
--resource-id cluster:myscalablecluster \
--scalable-dimension rds:cluster:ReadReplicaCount \
--min-capacity 1 \
--max-capacity 8 \
```
For Windows:
```
aws application-autoscaling register-scalable-target ^
--service-namespace rds ^
--resource-id cluster:myscalablecluster ^
--scalable-dimension rds:cluster:ReadReplicaCount ^
--min-capacity 1 ^
--max-capacity 8 ^
```
#### Application Auto Scaling API
To register your Aurora DB cluster with Application Auto Scaling, use the [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html) Application Auto Scaling API operation with the following parameters:
+ `ServiceNamespace` – Set this value to `rds`.
+ `ResourceID` – The resource identifier for the Aurora DB cluster. For this parameter, the resource type is `cluster` and the unique identifier is the name of the Aurora DB cluster, for example `cluster:myscalablecluster`.
+ `ScalableDimension` – Set this value to `rds:cluster:ReadReplicaCount`.
+ `MinCapacity` – The minimum number of reader DB instances to be managed by Application Auto Scaling. For information about the relationship between `MinCapacity`, `MaxCapacity`, and the number of DB instances in your cluster, see [Minimum and maximum capacity](Aurora.Integrating.AutoScaling.md#Aurora.Integrating.AutoScaling.Concepts.Capacity).
+ `MaxCapacity` – The maximum number of reader DB instances to be managed by Application Auto Scaling. For information about the relationship between `MinCapacity`, `MaxCapacity`, and the number of DB instances in your cluster, see [Minimum and maximum capacity](Aurora.Integrating.AutoScaling.md#Aurora.Integrating.AutoScaling.Concepts.Capacity).
**Example**
In the following example, you register an Aurora DB cluster named `myscalablecluster` with the Application Auto Scaling API. This registration indicates that the DB cluster should be dynamically scaled to have from one to eight Aurora Replicas.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "rds",
"ResourceId": "cluster:myscalablecluster",
"ScalableDimension": "rds:cluster:ReadReplicaCount",
"MinCapacity": 1,
"MaxCapacity": 8
}
```
### Defining a scaling policy for an Aurora DB cluster
A target-tracking scaling policy configuration is represented by a JSON block that the metrics and target values are defined in. You can save a scaling policy configuration as a JSON block in a text file. You use that text file when invoking the AWS CLI or the Application Auto Scaling API. For more information about policy configuration syntax, see [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in the *Application Auto Scaling API Reference*.
The following options are available for defining a target-tracking scaling policy configuration.
**Topics**
+ [Using a predefined metric](#Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Predefined)
+ [Using a custom metric](#Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Custom)
+ [Using cooldown periods](#Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.Cooldown)
+ [Disabling scale-in activity](#Aurora.Integrating.AutoScaling.AddCode.DefineScalingPolicy.ScaleIn)
#### Using a predefined metric
By using predefined metrics, you can quickly define a target-tracking scaling policy for an Aurora DB cluster that works well with both target tracking and dynamic scaling in Aurora Auto Scaling.
Currently, Aurora supports the following predefined metrics in Aurora Auto Scaling:
+ **RDSReaderAverageCPUUtilization** – The average value of the `CPUUtilization` metric in CloudWatch across all Aurora Replicas in the Aurora DB cluster.
+ **RDSReaderAverageDatabaseConnections** – The average value of the `DatabaseConnections` metric in CloudWatch across all Aurora Replicas in the Aurora DB cluster.
For more information about the `CPUUtilization` and `DatabaseConnections` metrics, see [Amazon CloudWatch metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md).
To use a predefined metric in your scaling policy, you create a target tracking configuration for your scaling policy. This configuration must include a `PredefinedMetricSpecification` for the predefined metric and a `TargetValue` for the target value of that metric.
**Example**
The following example describes a typical policy configuration for target-tracking scaling for an Aurora DB cluster. In this configuration, the `RDSReaderAverageCPUUtilization` predefined metric is used to adjust the Aurora DB cluster based on an average CPU utilization of 40 percent across all Aurora Replicas.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"
}
}
```
#### Using a custom metric
By using custom metrics, you can define a target-tracking scaling policy that meets your custom requirements. You can define a custom metric based on any Aurora metric that changes in proportion to scaling.
Not all Aurora metrics work for target tracking. The metric must be a valid utilization metric and describe how busy an instance is. The value of the metric must increase or decrease in proportion to the number of Aurora Replicas in the Aurora DB cluster. This proportional increase or decrease is necessary to use the metric data to proportionally scale out or in the number of Aurora Replicas.
**Example**
The following example describes a target-tracking configuration for a scaling policy. In this configuration, a custom metric adjusts an Aurora DB cluster based on an average CPU utilization of 50 percent across all Aurora Replicas in an Aurora DB cluster named `my-db-cluster`.
```
{
"TargetValue": 50,
"CustomizedMetricSpecification":
{
"MetricName": "CPUUtilization",
"Namespace": "AWS/RDS",
"Dimensions": [
{"Name": "DBClusterIdentifier","Value": "my-db-cluster"},
{"Name": "Role","Value": "READER"}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
```
#### Using cooldown periods
You can specify a value, in seconds, for `ScaleOutCooldown` to add a cooldown period for scaling out your Aurora DB cluster. Similarly, you can add a value, in seconds, for `ScaleInCooldown` to add a cooldown period for scaling in your Aurora DB cluster. For more information about `ScaleInCooldown` and `ScaleOutCooldown`, see [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in the *Application Auto Scaling API Reference*.
**Example**
The following example describes a target-tracking configuration for a scaling policy. In this configuration, the `RDSReaderAverageCPUUtilization` predefined metric is used to adjust an Aurora DB cluster based on an average CPU utilization of 40 percent across all Aurora Replicas in that Aurora DB cluster. The configuration provides a scale-in cooldown period of 10 minutes and a scale-out cooldown period of 5 minutes.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
#### Disabling scale-in activity
You can prevent the target-tracking scaling policy configuration from scaling in your Aurora DB cluster by disabling scale-in activity. Disabling scale-in activity prevents the scaling policy from deleting Aurora Replicas, while still allowing the scaling policy to create them as needed.
You can specify a Boolean value for `DisableScaleIn` to enable or disable scale in activity for your Aurora DB cluster. For more information about `DisableScaleIn`, see [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in the *Application Auto Scaling API Reference*.
**Example**
The following example describes a target-tracking configuration for a scaling policy. In this configuration, the `RDSReaderAverageCPUUtilization` predefined metric adjusts an Aurora DB cluster based on an average CPU utilization of 40 percent across all Aurora Replicas in that Aurora DB cluster. The configuration disables scale-in activity for the scaling policy.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"
},
"DisableScaleIn": true
}
```
### Applying a scaling policy to an Aurora DB cluster
After registering your Aurora DB cluster with Application Auto Scaling and defining a scaling policy, you apply the scaling policy to the registered Aurora DB cluster. To apply a scaling policy to an Aurora DB cluster, you can use the AWS CLI or the Application Auto Scaling API.
#### AWS CLI
To apply a scaling policy to your Aurora DB cluster, use the [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) AWS CLI command with the following parameters:
+ `--policy-name` – The name of the scaling policy.
+ `--policy-type` – Set this value to `TargetTrackingScaling`.
+ `--resource-id` – The resource identifier for the Aurora DB cluster. For this parameter, the resource type is `cluster` and the unique identifier is the name of the Aurora DB cluster, for example `cluster:myscalablecluster`.
+ `--service-namespace` – Set this value to `rds`.
+ `--scalable-dimension` – Set this value to `rds:cluster:ReadReplicaCount`.
+ `--target-tracking-scaling-policy-configuration` – The target-tracking scaling policy configuration to use for the Aurora DB cluster.
**Example**
In the following example, you apply a target-tracking scaling policy named `myscalablepolicy` to an Aurora DB cluster named `myscalablecluster` with Application Auto Scaling. To do so, you use a policy configuration saved in a file named `config.json`.
For Linux, macOS, or Unix:
```
aws application-autoscaling put-scaling-policy \
--policy-name myscalablepolicy \
--policy-type TargetTrackingScaling \
--resource-id cluster:myscalablecluster \
--service-namespace rds \
--scalable-dimension rds:cluster:ReadReplicaCount \
--target-tracking-scaling-policy-configuration file://config.json
```
For Windows:
```
aws application-autoscaling put-scaling-policy ^
--policy-name myscalablepolicy ^
--policy-type TargetTrackingScaling ^
--resource-id cluster:myscalablecluster ^
--service-namespace rds ^
--scalable-dimension rds:cluster:ReadReplicaCount ^
--target-tracking-scaling-policy-configuration file://config.json
```
#### Application Auto Scaling API
To apply a scaling policy to your Aurora DB cluster with the Application Auto Scaling API, use the [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_PutScalingPolicy.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_PutScalingPolicy.html) Application Auto Scaling API operation with the following parameters:
+ `PolicyName` – The name of the scaling policy.
+ `ServiceNamespace` – Set this value to `rds`.
+ `ResourceID` – The resource identifier for the Aurora DB cluster. For this parameter, the resource type is `cluster` and the unique identifier is the name of the Aurora DB cluster, for example `cluster:myscalablecluster`.
+ `ScalableDimension` – Set this value to `rds:cluster:ReadReplicaCount`.
+ `PolicyType` – Set this value to `TargetTrackingScaling`.
+ `TargetTrackingScalingPolicyConfiguration` – The target-tracking scaling policy configuration to use for the Aurora DB cluster.
**Example**
In the following example, you apply a target-tracking scaling policy named `myscalablepolicy` to an Aurora DB cluster named `myscalablecluster` with Application Auto Scaling. You use a policy configuration based on the `RDSReaderAverageCPUUtilization` predefined metric.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "rds",
"ResourceId": "cluster:myscalablecluster",
"ScalableDimension": "rds:cluster:ReadReplicaCount",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "RDSReaderAverageCPUUtilization"
}
}
}
```
# Editing an auto scaling policy for an Amazon Aurora DB cluster
You can edit a scaling policy using the AWS Management Console, the AWS CLI, or the Application Auto Scaling API.
## Console
You can edit a scaling policy by using the AWS Management Console.
**To edit an auto scaling policy for an Aurora DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the Aurora DB cluster whose auto scaling policy you want to edit.
1. Choose the **Logs & events** tab.
1. In the **Auto scaling policies** section, choose the auto scaling policy, and then choose **Edit**.
1. Make changes to the policy.
1. Choose **Save**.
The following is a sample **Edit Auto Scaling policy** dialog box.
![\[Editing an auto scaling policy based on average CPU utilization\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-autoscaling-edit-cpu.png)
## AWS CLI or Application Auto Scaling API
You can use the AWS CLI or the Application Auto Scaling API to edit a scaling policy in the same way that you apply a scaling policy:
+ When using the AWS CLI, specify the name of the policy you want to edit in the `--policy-name` parameter. Specify new values for the parameters you want to change.
+ When using the Application Auto Scaling API, specify the name of the policy you want to edit in the `PolicyName` parameter. Specify new values for the parameters you want to change.
For more information, see [Applying a scaling policy to an Aurora DB cluster](Aurora.Integrating.AutoScaling.Add.md#Aurora.Integrating.AutoScaling.AddCode.ApplyScalingPolicy).
# Deleting an auto scaling policy from your Amazon Aurora DB cluster
You can delete a scaling policy using the AWS Management Console, the AWS CLI, or the Application Auto Scaling API.
## Console
You can delete a scaling policy by using the AWS Management Console.
**To delete an auto scaling policy for an Aurora DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the Aurora DB cluster whose auto scaling policy you want to delete.
1. Choose the **Logs & events** tab.
1. In the **Auto scaling policies** section, choose the auto scaling policy, and then choose **Delete**.
## AWS CLI
To delete a scaling policy from your Aurora DB cluster, use the [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) AWS CLI command with the following parameters:
+ `--policy-name` – The name of the scaling policy.
+ `--resource-id` – The resource identifier for the Aurora DB cluster. For this parameter, the resource type is `cluster` and the unique identifier is the name of the Aurora DB cluster, for example `cluster:myscalablecluster`.
+ `--service-namespace` – Set this value to `rds`.
+ `--scalable-dimension` – Set this value to `rds:cluster:ReadReplicaCount`.
**Example**
In the following example, you delete a target-tracking scaling policy named `myscalablepolicy` from an Aurora DB cluster named `myscalablecluster`.
For Linux, macOS, or Unix:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id cluster:myscalablecluster \
--service-namespace rds \
--scalable-dimension rds:cluster:ReadReplicaCount \
```
For Windows:
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id cluster:myscalablecluster ^
--service-namespace rds ^
--scalable-dimension rds:cluster:ReadReplicaCount ^
```
## Application Auto Scaling API
To delete a scaling policy from your Aurora DB cluster, use the [https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html) the Application Auto Scaling API operation with the following parameters:
+ `PolicyName` – The name of the scaling policy.
+ `ServiceNamespace` – Set this value to `rds`.
+ `ResourceID` – The resource identifier for the Aurora DB cluster. For this parameter, the resource type is `cluster` and the unique identifier is the name of the Aurora DB cluster, for example `cluster:myscalablecluster`.
+ `ScalableDimension` – Set this value to `rds:cluster:ReadReplicaCount`.
**Example**
In the following example, you delete a target-tracking scaling policy named `myscalablepolicy` from an Aurora DB cluster named `myscalablecluster` with the Application Auto Scaling API.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "rds",
"ResourceId": "cluster:myscalablecluster",
"ScalableDimension": "rds:cluster:ReadReplicaCount"
}
```