# Monitoring metrics in an Amazon Aurora cluster
<a name="MonitoringAurora"></a>

Amazon Aurora uses a cluster of replicated database servers. Typically, monitoring an Aurora cluster requires checking the health of multiple DB instances. The instances might have specialized roles, handling mostly write operations, only read operations, or a combination. You also monitor the overall health of the cluster by measuring the *replication lag*. This is the amount of time for changes made by one DB instance to be available to the other instances.

**Topics**
+ [Monitoring plan](#MonitoringOverview.plan)
+ [Performance baseline](#MonitoringOverview.baseline)
+ [Performance guidelines](#MonitoringOverview.guidelines)
+ [Monitoring tools for Amazon Aurora](MonitoringOverview.md)
+ [Viewing cluster status](accessing-monitoring.md)
+ [Recommendations from Amazon Aurora](monitoring-recommendations.md)
+ [Viewing metrics in the Amazon RDS console](USER_Monitoring.md)
+ [Viewing combined metrics with the Performance Insights dashboard](Viewing_Unifiedmetrics.md)
+ [Monitoring Amazon Aurora metrics with Amazon CloudWatch](monitoring-cloudwatch.md)
+ [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md)
+ [Monitoring DB load with Performance Insights on Amazon Aurora](USER_PerfInsights.md)
+ [Analyzing Aurora performance anomalies with Amazon DevOps Guru for Amazon RDS](devops-guru-for-rds.md)
+ [Monitoring OS metrics with Enhanced Monitoring](USER_Monitoring.OS.md)
+ [Metrics reference for Amazon Aurora](metrics-reference.md)

## Monitoring plan
<a name="MonitoringOverview.plan"></a>

Before you start monitoring Amazon Aurora, create a monitoring plan. This plan should answer the following questions:
+ What are your monitoring goals?
+ Which resources will you monitor?
+ How often will you monitor these resources?
+ Which monitoring tools will you use?
+ Who will perform the monitoring tasks?
+ Whom should be notified when something goes wrong?

## Performance baseline
<a name="MonitoringOverview.baseline"></a>

To achieve your monitoring goals, you need to establish a baseline. To do this, measure performance under different load conditions at various times in your Amazon Aurora environment. You can monitor metrics such as the following:
+ Network throughput
+ Client connections
+ I/O for read, write, or metadata operations
+ Burst credit balances for your DB instances

We recommend that you store historical performance data for Amazon Aurora. Using the stored data, you can compare current performance against past trends. You can also distinguish normal performance patterns from anomalies, and devise techniques to address issues.

## Performance guidelines
<a name="MonitoringOverview.guidelines"></a>

In general, acceptable values for performance metrics depend on what your application is doing relative to your baseline. Investigate consistent or trending variances from your baseline. The following metrics are often the source of performance issues:
+  **High CPU or RAM consumption** – High values for CPU or RAM consumption might be appropriate, if they're in keeping with your goals for your application (like throughput or concurrency) and are expected. 
+  **Disk space consumption** – Investigate disk space consumption if space used is consistently at or above 85 percent of the total disk space. See if it is possible to delete data from the instance or archive data to a different system to free up space. 
+  **Network traffic** – For network traffic, talk with your system administrator to understand what expected throughput is for your domain network and internet connection. Investigate network traffic if throughput is consistently lower than expected. 
+  **Database connections** – If you see high numbers of user connections and also decreases in instance performance and response time, consider constraining database connections. The best number of user connections for your DB instance varies based on your instance class and the complexity of the operations being performed. To determine the number of database connections, associate your DB instance with a parameter group where the `User Connections` parameter is set to a value other than 0 (unlimited). You can either use an existing parameter group or create a new one. For more information, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md). 
+  **IOPS metrics** – The expected values for IOPS metrics depend on disk specification and server configuration, so use your baseline to know what is typical. Investigate if values are consistently different than your baseline. For best IOPS performance, make sure that your typical working set fits into memory to minimize read and write operations. 

When performance falls outside your established baseline, you might need to make changes to optimize your database availability for your workload. For example, you might need to change the instance class of your DB instance. Or you might need to change the number of DB instances and read replicas that are available for clients. 

# Monitoring tools for Amazon Aurora
<a name="MonitoringOverview"></a>

Monitoring is an important part of maintaining the reliability, availability, and performance of Amazon Aurora and your other AWS solutions. AWS provides various monitoring tools to watch Amazon Aurora, report when something is wrong, and take automatic actions when appropriate.

**Topics**
+ [Automated monitoring tools](#MonitoringOverview.tools.automated)
+ [Manual monitoring tools](#monitoring_manual_tools)

## Automated monitoring tools
<a name="MonitoringOverview.tools.automated"></a>

We recommend that you automate monitoring tasks as much as possible.

**Topics**
+ [Amazon Aurora cluster status and recommendations](#MonitoringOverview.tools.automated.rds)
+ [Amazon CloudWatch metrics for Amazon Aurora](#MonitoringOverview.tools.automated.integrated)
+ [Amazon RDS Performance Insights and operating-system monitoring](#MonitoringOverview.tools.automated.metrics.rds)
+ [Integrated services](#MonitoringOverview.tools.automated.integrated.events-logs-streams)

### Amazon Aurora cluster status and recommendations
<a name="MonitoringOverview.tools.automated.rds"></a>

You can use the following automated tools to watch Amazon Aurora and report when something is wrong:
+ **Amazon Aurora cluster status** — View details about the current status of your cluster by using the Amazon RDS console, the AWS CLI, or the RDS API.
+ **Amazon Aurora recommendations** — Respond to automated recommendations for database resources, such as DB instances, DB clusters, and DB cluster parameter groups. For more information, see [Recommendations from Amazon Aurora](monitoring-recommendations.md).

### Amazon CloudWatch metrics for Amazon Aurora
<a name="MonitoringOverview.tools.automated.integrated"></a>

Amazon Aurora integrates with Amazon CloudWatch for additional monitoring capabilities.
+ **Amazon CloudWatch** – This service monitors your AWS resources and the applications you run on AWS in real time. You can use the following Amazon CloudWatch features with Amazon Aurora:
  + **Amazon CloudWatch metrics** – Amazon Aurora automatically sends metrics to CloudWatch every minute for each active database. You don't get additional charges for Amazon RDS metrics in CloudWatch. For more information, see [Amazon CloudWatch metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md) 
  + **Amazon CloudWatch alarms** – You can watch a single Amazon Aurora metric over a specific time period. You can then perform one or more actions based on the value of the metric relative to a threshold that you set. 

### Amazon RDS Performance Insights and operating-system monitoring
<a name="MonitoringOverview.tools.automated.metrics.rds"></a>

You can use the following automated tools to monitor Amazon Aurora performance:
+ **Amazon RDS Performance Insights** – Assess the load on your database, and determine when and where to take action. For more information, see [Monitoring DB load with Performance Insights on Amazon Aurora](USER_PerfInsights.md).
+ **Amazon RDS Enhanced Monitoring** – Look at metrics in real time for the operating system. For more information, see [Monitoring OS metrics with Enhanced Monitoring](USER_Monitoring.OS.md).

### Integrated services
<a name="MonitoringOverview.tools.automated.integrated.events-logs-streams"></a>

The following AWS services are integrated with Amazon Aurora:
+ *Amazon EventBridge* is a serverless event bus service that makes it easy to connect your applications with data from a variety of sources. For more information, see [Monitoring Amazon Aurora events](working-with-events.md).
+ *Amazon CloudWatch Logs* lets you monitor, store, and access your log files from Amazon Aurora instances, CloudTrail, and other sources. For more information, see [Monitoring Amazon Aurora log files](USER_LogAccess.md).
+ *AWS CloudTrail* captures API calls and related events made by or on behalf of your AWS account and delivers the log files to an Amazon S3 bucket that you specify. For more information, see [Monitoring Amazon Aurora API calls in AWS CloudTrail](logging-using-cloudtrail.md).
+ *Database Activity Streams* is an Amazon Aurora feature that provides a near-real-time stream of the activity in your DB cluster. For more information, see [Monitoring Amazon Aurora with Database Activity Streams](DBActivityStreams.md).
+ *DevOps Guru for RDS* is a capability of Amazon DevOps Guru that applies machine learning to Performance Insights metrics for Amazon Aurora databases. For more information, see [Analyzing Aurora performance anomalies with Amazon DevOps Guru for Amazon RDS](devops-guru-for-rds.md).

## Manual monitoring tools
<a name="monitoring_manual_tools"></a>

You need to manually monitor those items that the CloudWatch alarms don't cover. The Amazon RDS, CloudWatch, AWS Trusted Advisor and other AWS console dashboards provide an at-a-glance view of the state of your AWS environment. We recommend that you also check the log files on your DB instance.
+ From the Amazon RDS console, you can monitor the following items for your resources:
  + The number of connections to a DB instance
  + The amount of read and write operations to a DB instance
  + The amount of storage that a DB instance is currently using
  + The amount of memory and CPU being used for a DB instance
  + The amount of network traffic to and from a DB instance
+ From the Trusted Advisor dashboard, you can review the following cost optimization, security, fault tolerance, and performance improvement checks:
  + Amazon RDS Idle DB Instances
  + Amazon RDS Security Group Access Risk
  + Amazon RDS Backups
  + Amazon RDS Multi-AZ
  + Aurora DB Instance Accessibility

  For more information on these checks, see [Trusted Advisor best practices (checks)](https://aws.amazon.com/premiumsupport/trustedadvisor/best-practices/).
+ CloudWatch home page shows:
  + Current alarms and status
  + Graphs of alarms and resources
  + Service health status

  In addition, you can use CloudWatch to do the following: 
  + Create [customized dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CloudWatch_Dashboards.html) to monitor the services that you care about.
  + Graph metric data to troubleshoot issues and discover trends.
  + Search and browse all your AWS resource metrics.
  + Create and edit alarms to be notified of problems.

# Viewing cluster status
<a name="accessing-monitoring"></a>

Using the Amazon RDS console, you can quickly access the status of your DB cluster.

**Topics**
+ [Viewing an Amazon Aurora DB cluster](#Aurora.Viewing)
+ [Viewing DB cluster status](#Aurora.Status)
+ [Viewing DB instance statusin an Aurora cluster](#Overview.DBInstance.Status)

## Viewing an Amazon Aurora DB cluster
<a name="Aurora.Viewing"></a>

You have several options for viewing information about your Amazon Aurora DB clusters and the DB instances in your DB clusters.
+ You can view DB clusters and DB instances in the Amazon RDS console by choosing **Databases** from the navigation pane. 
+ You can get DB cluster and DB instance information using the AWS Command Line Interface (AWS CLI).
+ You can get DB cluster and DB instance information using the Amazon RDS API.

### Console
<a name="Aurora.Viewing.Console"></a>

In the Amazon RDS console, you can see details about a DB cluster by choosing **Databases** from the console's navigation pane. You can also see details about DB instances that are members of an Amazon Aurora DB cluster.

**To view or modify DB clusters in the Amazon RDS console**

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 name of the Aurora DB cluster that you want to view from the list.

   For example, the following image shows the details page for the DB cluster named `aurora-test`. The DB cluster has four DB instances shown in the DB identifier list. The writer DB instance, `dbinstance4`, is the primary DB instance for the DB cluster.  
![\[Amazon Aurora DB cluster View\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AuroraView01.png)

1. To modify a DB cluster, select the DB cluster from the list and choose **Modify**.

**To view or modify DB instances of a DB cluster in the Amazon RDS console**

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. Do one of the following:
   + To view a DB instance, choose one from the list that is a member of the Aurora DB cluster.

     For example, if you choose the `dbinstance4` DB instance identifier, the console shows the details page for the `dbinstance4` DB instance, as shown in the following image.  
![\[Amazon Aurora DB instance View\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AuroraView02.png)
   + To modify a DB instance, choose the DB instance from the list and choose **Modify**. For more information about modifying a DB cluster, see [Modifying an Amazon Aurora DB cluster](Aurora.Modifying.md). 

### AWS CLI
<a name="Aurora.Viewing.CLI"></a>

To view DB cluster information by using the AWS CLI, use the [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) command. For example, the following AWS CLI command lists the DB cluster information for all of the DB clusters in the modify `us-east-1` region for the configured AWS account.

```
aws rds describe-db-clusters --region us-east-1
```

The command returns the following output if your AWS CLI is configured for JSON output.

```
{
    "DBClusters": [
        {
            "Status": "available",
            "Engine": "aurora-mysql",
            "Endpoint": "sample-cluster1.cluster-123456789012.us-east-1.rds.amazonaws.com"
            "AllocatedStorage": 1,
            "DBClusterIdentifier": "sample-cluster1",
            "MasterUsername": "mymasteruser",
            "EarliestRestorableTime": "2023-03-30T03:35:42.563Z",
            "DBClusterMembers": [
                {
                    "IsClusterWriter": false,
                    "DBClusterParameterGroupStatus": "in-sync",
                    "DBInstanceIdentifier": "sample-replica"
                },
                {
                    "IsClusterWriter": true,
                    "DBClusterParameterGroupStatus": "in-sync",
                    "DBInstanceIdentifier": "sample-primary"
                }
            ],
            "Port": 3306,
            "PreferredBackupWindow": "03:34-04:04",
            "VpcSecurityGroups": [
                {
                    "Status": "active",
                    "VpcSecurityGroupId": "sg-ddb65fec"
                }
            ],
            "DBSubnetGroup": "default",
            "StorageEncrypted": false,
            "DatabaseName": "sample",
            "EngineVersion": "5.7.mysql_aurora.2.11.0",
            "DBClusterParameterGroup": "default.aurora-mysql5.7",
            "BackupRetentionPeriod": 1,
            "AvailabilityZones": [
                "us-east-1b",
                "us-east-1c",
                "us-east-1d"
            ],
            "LatestRestorableTime": "2023-03-31T20:06:08.903Z",
            "PreferredMaintenanceWindow": "wed:08:15-wed:08:45"
        },
        {
            "Status": "available",
            "Engine": "aurora-mysql",
            "Endpoint": "aurora-sample.cluster-123456789012.us-east-1.rds.amazonaws.com",
            "AllocatedStorage": 1,
            "DBClusterIdentifier": "aurora-sample-cluster",
            "MasterUsername": "mymasteruser",
            "EarliestRestorableTime": "2023-03-30T10:21:34.826Z",
            "DBClusterMembers": [
                {
                    "IsClusterWriter": false,
                    "DBClusterParameterGroupStatus": "in-sync",
                    "DBInstanceIdentifier": "aurora-replica-sample"
                },
                {
                    "IsClusterWriter": true,
                    "DBClusterParameterGroupStatus": "in-sync",
                    "DBInstanceIdentifier": "aurora-sample"
                }
            ],
            "Port": 3306,
            "PreferredBackupWindow": "10:20-10:50",
            "VpcSecurityGroups": [
                {
                    "Status": "active",
                    "VpcSecurityGroupId": "sg-55da224b"
                }
            ],
            "DBSubnetGroup": "default",
            "StorageEncrypted": false,
            "DatabaseName": "sample",
            "EngineVersion": "5.7.mysql_aurora.2.11.0",
            "DBClusterParameterGroup": "default.aurora-mysql5.7",
            "BackupRetentionPeriod": 1,
            "AvailabilityZones": [
                "us-east-1b",
                "us-east-1c",
                "us-east-1d"
            ],
            "LatestRestorableTime": "2023-03-31T20:00:11.491Z",
            "PreferredMaintenanceWindow": "sun:03:53-sun:04:23"
        }
    ]
}
```

### RDS API
<a name="Aurora.Viewing.API"></a>

To view DB cluster information using the Amazon RDS API, use the [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) operation.

## Viewing DB cluster status
<a name="Aurora.Status"></a>

The status of a DB cluster indicates its current operational state. You can view the status of a DB cluster and the cluster instances by using the Amazon RDS console, the AWS CLI, or the API.

**Note**  
Aurora also uses another status called *maintenance status*, which is shown in the **Maintenance** column of the Amazon RDS console. This value indicates the status of any maintenance patches that need to be applied to a DB cluster. Maintenance status is independent of DB cluster status. For more information about maintenance status, see [Applying updates to a DB cluster](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades).

Find the possible status values for DB clusters in the following table.


| DB cluster status | Billed | Description | 
| --- | --- | --- | 
| Available | Billed |  The DB cluster is available for modifications. When an Aurora Serverless cluster is available and paused, you're billed for storage only.  | 
| Backing-up | Billed |  The DB cluster is currently being backed up.  | 
| Backtracking | Billed |  The DB cluster is currently being backtracked. This status only applies to Aurora MySQL.  | 
| Cloning-failed | Not billed |  Cloning a DB cluster failed.  | 
| Creating | Not billed |  The DB cluster is being created. The DB cluster is inaccessible while it is being created.  | 
| Deleting | Not billed |  The DB cluster is being deleted.  | 
| Failing-over | Billed |  A failover from the primary instance to an Aurora Replica is being performed.  | 
| Inaccessible-encryption-credentials | Not billed |  The AWS KMS key used to encrypt or decrypt the DB cluster can't be accessed or recovered.  | 
|  **Inaccessible-encryption-credentials-recoverable**  | Billed for storage |  The KMS key used to encrypt or decrypt the DB cluster can't be accessed. However, if the KMS key is active, restarting the DB cluster can recover it. For more information, see [Encrypting an Amazon Aurora DB cluster](Overview.Encryption.md#Overview.Encryption.Enabling).  | 
| Maintenance | Billed |  Amazon RDS is applying a maintenance update to the DB cluster. This status is used for DB cluster-level maintenance that RDS schedules well in advance.  | 
| Migrating | Billed |  A DB cluster snapshot is being restored to a DB cluster.  | 
| Migration-failed | Not billed |  A migration failed.  | 
| Modifying | Billed |  The DB cluster is being modified because of a customer request to modify the DB cluster.  | 
| Promoting | Billed |  A read replica is being promoted to a standalone DB cluster.  | 
| Preparing-data-migration | Billed |  Amazon RDS is preparing to migrate data to Aurora.  | 
| Renaming | Billed |  The DB cluster is being renamed because of a customer request to rename it.  | 
| Resetting-master-credentials | Billed |  The master credentials for the DB cluster are being reset because of a customer request to reset them.  | 
| Starting | Billed for storage |  The DB cluster is starting.  | 
| Stopped | Billed for storage |  The DB cluster is stopped.  | 
| Stopping | Billed for storage |  The DB cluster is being stopped.  | 
| Storage-optimization | Billed |  Your DB instance is being modified to change the storage size or type. The DB instance is fully operational. However, while the status of your DB instance is **storage-optimization**, you can't request any changes to the storage of your DB instance. The storage optimization process is usually short, but can sometimes take up to and even beyond 24 hours.  | 
| Update-iam-db-auth | Billed |  IAM authorization for the DB cluster is being updated.  | 
| Upgrading | Billed |  The DB cluster engine or operating system version is being upgraded.  | 
|  **upgrade-failed**  |  Not billed  |  The DB cluster has failed to upgrade to a supported version. Aurora creates a final snapshot with the prefix `rds-final`.   | 

### Console
<a name="DBcluster.Status.Console"></a>

**To view the status of 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**.

   The **Databases page** appears with the list of DB clusters. For each DB cluster, the status value is displayed.  
![\[Viewing the status of a DB cluster\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Aurora_cluster_status.png)

### CLI
<a name="DBcluster.Status.Cli"></a>

To view just the status of the DB clusters, use the following query in AWS CLI.

```
aws rds describe-db-clusters --query 'DBClusters[*].[DBClusterIdentifier,Status]' --output table
```

## Viewing DB instance statusin an Aurora cluster
<a name="Overview.DBInstance.Status"></a>

The status of a DB instance in an Aurora cluster indicates its current operational state. You can use the following procedures to view the DB instance status of a cluster in the Amazon RDS console, the AWS CLI command, or the API operation.

**Note**  
Amazon RDS also uses another status called *maintenance status*, which is shown in the **Maintenance** column of the Amazon RDS console. This value indicates the status of any maintenance patches that need to be applied to a DB instance. Maintenance status is independent of DB instance status. For more information about maintenance status, see [Applying updates to a DB cluster](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades). 

Find the possible status values for DB instances in the following table. This table also shows whether you will be billed for the DB instance and storage, billed only for storage, or not billed. For all DB instance statuses, you are always billed for backup usage.


| DB instance status | Billed  | Description | 
| --- | --- | --- | 
|  **available**  |  Billed  |  The DB instance is available for modifications.  | 
|  **backing-up**  |  Billed  |  The DB instance is currently being backed up.  | 
| backtracking |  Billed  |  The DB instance is currently being backtracked. This status only applies to Aurora MySQL.  | 
|  **configuring-enhanced-monitoring**  |  Billed  |  Enhanced Monitoring is being enabled or disabled for this DB instance.  | 
|  **configuring-iam-database-auth**  |  Billed  |  AWS Identity and Access Management (IAM) database authentication is being enabled or disabled for this DB instance.  | 
|  **configuring-log-exports**  |  Billed  |  Publishing log files to Amazon CloudWatch Logs is being enabled or disabled for this DB instance.  | 
|  **converting-to-vpc**  |  Billed  |  The DB instance is being converted from a DB instance that is not in an Amazon Virtual Private Cloud (Amazon VPC) to a DB instance that is in an Amazon VPC.  | 
|  **creating**  |  Not billed (non-PITR) Billed (PITR only)  |  The DB instance is being created. The DB instance is inaccessible while it is being created.  If you restore a database during point-in-time recovery (PITR), you're billed while the database is in the **creating** state. This is the only scenario in which the **creating** state incurs charges.  | 
|  **delete-precheck**  |  Not billed  |  Amazon RDS is validating that read replicas are safe to delete.  | 
|  **deleting**  |  Not billed  |  The DB instance is being deleted.  | 
|  **failed**  |  Not billed  |  The DB instance has failed and Amazon RDS can't recover it. Perform a point-in-time restore to the latest restorable time of the DB instance to recover the data.   | 
|  **inaccessible-encryption-credentials**  |  Not billed  |  The AWS KMS key used to encrypt or decrypt the DB instance can't be accessed or recovered.   | 
|  **inaccessible-encryption-credentials-recoverable**  |  Billed for storage  |  The KMS key used to encrypt or decrypt the DB instance can't be accessed. However, if the KMS key is active, restarting the DB instance can recover it. For more information, see [Encrypting an Amazon Aurora DB cluster](Overview.Encryption.md#Overview.Encryption.Enabling).  | 
|  **incompatible-create**  |  Not billed  |  Amazon RDS is attempting to create a DB instance but can't do so because resources are incompatible with your DB instance. This status can occur if, for example, the instance profile for your DB instance doesn't have the correct permissions.  | 
|  **incompatible-network**  |  Not billed  |  Amazon RDS is attempting to perform a recovery action on a DB instance but can't do so because the VPC is in a state that prevents the action from being completed. This status can occur if, for example, all available IP addresses in a subnet are in use and Amazon RDS can't get an IP address for the DB instance.   | 
|  **incompatible-option-group**  |  Billed  |  Amazon RDS attempted to apply an option group change but can't do so, and Amazon RDS can't roll back to the previous option group state. For more information, check the **Recent Events** list for the DB instance. This status can occur if, for example, the option group contains an option such as TDE and the DB instance doesn't contain encrypted information.   | 
|  **incompatible-parameters**  |  Billed  |  Amazon RDS can't start the DB instance because the parameters specified in the DB instance's DB parameter group aren't compatible with the DB instance. Revert the parameter changes or make them compatible with the DB instance to regain access to your DB instance. For more information about the incompatible parameters, check the **Recent Events** list for the DB instance.   | 
|  **incompatible-restore**  |  Not billed  |  Amazon RDS can't do a point-in-time restore. Common causes for this status include using temp tables or using MyISAM tables with MySQL.  | 
| insufficient-capacity |  Not billed  |  Amazon RDS can't create your instance because sufficient capacity isn't currently available. To create your DB instance in the same AZ with the same instance type, delete your DB instance, wait a few hours, and try to create again. Alternatively, create a new instance using a different instance class or AZ.  | 
|  **maintenance**  |  Billed  |  Amazon RDS is applying a maintenance update to the DB instance. This status is used for instance-level maintenance that RDS schedules well in advance.   | 
|  **modifying**  |  Billed  |  The DB instance is being modified because of a customer request to modify the DB instance.   | 
|  **moving-to-vpc**  |  Billed  |  The DB instance is being moved to a new Amazon Virtual Private Cloud (Amazon VPC).  | 
|  **rebooting**  |  Billed  |  The DB instance is being rebooted because of a customer request or an Amazon RDS process that requires the rebooting of the DB instance.  | 
|  **resetting-master-credentials**  |  Billed  |  The master credentials for the DB instance are being reset because of a customer request to reset them.  | 
|  **renaming**  |  Billed  |  The DB instance is being renamed because of a customer request to rename it.   | 
|  **restore-error**  |  Billed  |  The DB instance encountered an error attempting to restore to a point-in-time or from a snapshot.  | 
|  **starting**  |  Billed for storage  |  The DB instance is starting.  | 
|  **stopped**  |  Billed for storage  |  The DB instance is stopped.  | 
|  **stopping**  |  Billed for storage  |  The DB instance is being stopped.  | 
|  **storage-config-upgrade**  |  Billed  |  The storage file system configuration of the DB instance is being upgraded. This status only applies to green databases within a blue/green deployment, or to DB instance read replicas.  | 
|  **storage-full**  |  Billed  |  The DB instance has reached its storage capacity allocation. This is a critical status, and we recommend that you fix this issue immediately. To do so, scale up your storage by modifying the DB instance. To avoid this situation, set Amazon CloudWatch alarms to warn you when storage space is getting low.   | 
| storage-initialization |  Billed  |  The DB instance is loading data blocks from Amazon S3 to optimize volume performance after being restored from a snapshot. It remains available for operations, but performance mights not be at its fullest until initialization completes.  | 
|  **storage-optimization**  |  Billed  |  Amazon RDS is optimizing the storage of your DB instance. The storage optimization process is usually short, but can sometimes take up to and even beyond 24 hours. During storage optimization, the DB instance remains available. Storage optimization is a background process that doesn't affect the instance's availability.  | 
|  **upgrading**  |  Billed  |  The database engine or operating system version is being upgraded.  | 
|  **upgrade-failed**  |  Not billed  |  The DB instance has failed to upgrade to a supported version. Aurora creates a final snapshot with the prefix `rds-final`.   | 

### Console
<a name="DBinstance.Status.Console"></a>

**To view the status of a DB instance**

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**.

   The **Databases page** appears with the list of DB instances. For each DB instance in a cluster, the status value is displayed.   
![\[View the status of a DB instance\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Aurora_instance_status.png)

### CLI
<a name="DBinstance.Status.Cli"></a>

To view DB instance and its status information by using the AWS CLI, use the [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) command. For example, the following AWS CLI command lists all the DB instances information .

```
aws rds describe-db-instances
```

To view a specific DB instance and its status, call the [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) command with the following option:
+ `DBInstanceIdentifier` – The name of the DB instance. 

```
aws rds describe-db-instances --db-instance-identifier mydbinstance
```

To view just the status of all the DB instances, use the following query in AWS CLI.

```
aws rds describe-db-instances --query 'DBInstances[*].[DBInstanceIdentifier,DBInstanceStatus]' --output table
```

### API
<a name="DBinstance.Status.Api"></a>

To view the status of the DB instance using the Amazon RDS API, call the [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) operation.

# Recommendations from Amazon Aurora
<a name="monitoring-recommendations"></a>

Amazon Aurora provides automated recommendations for database resources, such as DB instances, DB clusters, and DB parameter groups. These recommendations provide best practice guidance by analyzing DB cluster configuration,  DB instance configuration, usage, and performance data.

Amazon RDS Performance Insights monitors specific metrics and automatically creates thresholds by analyzing what levels are considered potentially problematic for a specified resource. When new metric values cross a predefined threshold over a given period of time, Performance Insights generates a proactive recommendation. This recommendation helps to prevent future database performance impact. For example, the "Idle In Transaction" recommendation is generated for Aurora PostgreSQL instances when the sessions connected to the database are not performing active work, but can keep database resources blocked. To receive proactive recommendations, you must turn on Performance Insights with a paid tier retention period. For information about turning on Performance Insights, see [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md). For information about pricing and data retention for Performance Insights see [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md).

DevOps Guru for RDS monitors certain metrics to detect when the metric's behavior becomes highly unusual or anomalous. These anomalies are reported as reactive insights with recommendations. For example, DevOps Guru for RDS might recommend you to consider increasing CPU capacity or investigate wait events that are contributing to DB load. DevOps Guru for RDS also provides threshold based proactive recommendations. For these recommendations, you must turn on DevOps Guru for RDS. For information about turning on DevOps Guru for RDS, see [Turning on DevOps Guru and specifying resource coverage](devops-guru-for-rds.md#devops-guru-for-rds.configuring.coverage). 

Recommendations will be in any of the following status: active, dismissed, pending, or resolved. Resolved recommendations are available for 365 days.

You can view or dismiss the recommendations. You can apply a configuration based active recommendation immediately, schedule it in the next maintenance window, or dismiss it. For threshold based proactive and machine learning based reactive recommendations, you need to review the suggested cause of the issue and then perform the recommended actions to fix the issue. 

Recommendations are supported in the following AWS Regions:
+ US East (Ohio)
+ US East (N. Virginia)
+ US West (N. California)
+ US West (Oregon)
+ Asia Pacific (Mumbai)
+ Asia Pacific (Seoul)
+ Asia Pacific (Singapore)
+ Asia Pacific (Sydney)
+ Asia Pacific (Tokyo)
+ Canada (Central)
+ Europe (Frankfurt)
+ Europe (Ireland)
+ Europe (London)
+ Europe (Paris)
+ Europe (Stockholm)
+ South America (São Paulo)

Learn to view, apply, dismiss, and modify recommendations from Amazon Aurora in the following sections.

**Topics**
+ [Viewing Amazon Aurora recommendations](UserRecommendationsView.md)
+ [Applying Amazon Aurora recommendations](USERRecommendationsManage.ApplyRecommendation.md)
+ [Dismissing Amazon Aurora recommendations](USERRecommendationsManage.DismissRecommendation.md)
+ [Modifying dismissed Amazon Aurora recommendations to active recommendations](USERRecommendationsManage.DismissToActiveRecommendation.md)
+ [Recommendations from Amazon Aurora reference](USERRecommendationsManage.RecommendationReference.md)

# Viewing Amazon Aurora recommendations
<a name="UserRecommendationsView"></a>

Using the Amazon RDS console, you can view Amazon Aurora recommendations for your database resources. For a DB cluster, the recommendations appear for the DB cluster and its instances.

## Console
<a name="UserRecommendationsView.Con"></a>

**To view the Amazon Aurora recommendations**

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, do any of the following:
   + Choose **Recommendations**. The number of active recommendations for your resources and the number of recommendations with the highest severity generated in the last month are available next to **Recommendations**. To find the number of active recommendations for each severity, choose the number that shows the highest severity.   
![\[Select Recommendations in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/recommendations-select.png)

     By default, the **Recommendations** page displays a list of new recommendations in the last month. Amazon Aurora gives recommendations for all the resources in your account and sorts the recommendations by their severity.  
![\[Main Recommendations page in the console which contains all the recommendations\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_List.png)

     You can choose a recommendation to view a section at the bottom of the page which contains the affected resources and details of how the recommendation will be applied.
   + In the **Databases** page, choose **Recommendations** for a resource.  
![\[Recommendation option selected on Databases page in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_DBpage.png)

     The **Recommendations** tab displays the recommendations and its details for the selected resource.  
![\[Recommendations tab on Databases page in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/RecommendationsTab_DBpage.png)

   The following details are available for the recommendations:
   + **Severity** – The implication level of the issue. The severity levels are **High**, **Medium**, **Low**, and **Informational**.
   + **Detection** – The number of affected resources and a short description of the issue. Choose this link to view the recommendation and the analysis details.
   + **Recommendation** – A short description of the recommended action to apply.
   + **Impact** – A short description of the possible impact when the recommendation isn't applied.
   + **Category** – The type of recommendation. The categories are **Performance efficiency**, **Security**, **Reliability**, **Cost optimization**, **Operational excellence**, and **Sustainability**.
   + **Status** – The current status of the recommendation. The possible statuses are **All**, **Active**, **Dismissed**, **Resolved**, and **Pending**.
   + **Start time** – The time when the issue began. For example, **18 hours ago**.
   + **Last modified** – The time when the recommendation was last updated by the system because of a change in the **Severity**, or the time you responded to the recommendation. For example, **10 hours ago**.
   + **End time** – The time when the issue ended. The time won't display for any continuing issues.
   + **Resource identifier** – The name of one or more resources.

1. (Optional) Choose **Severity** or **Category** operators in the field to filter the list of recommendations.  
![\[Recommendations page with severity operation in the console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_Severity.png)

   The recommendations for the selected operation appear.

1. (Optional) Choose any of the following recommendation status:
   + **Active** (default) – Shows the current recommendations that you can apply, schedule it for the next maintenance window, or dismiss. 
   + **All** – Shows all the recommendations with the current status.
   + **Dismissed** – Shows the dismissed recommendations.
   + **Resolved** – Shows the recommendations that are resolved.
   + **Pending** – Shows the recommendations whose recommended actions are in progress or scheduled for the next maintenance window.   
![\[Recommendations filtered by status in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_Status.png)

1. (Optional) Choose **Relative mode** or **Absolute mode** in **Last modified** to modify the time period. The **Recommendations** page displays the recommendations generated in the time period. The default time period is the last month. In the **Absolute mode**, you can choose the time period, or enter the time in **Start date** and **End date** fields.  
![\[Recommendations filtered by time period in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_TimeMode.png)

   The recommendations for the set time period display.

   Note that you can see all recommendations for resources in your account by setting the range to **All**.

1. (Optional) Choose **Preferences** in the right to customize the details to display. You can choose a page size, wrap the lines of the text, and allow or hide the columns.

1. (Optional) Choose a recommendation and then choose **View details**.  
![\[Recommendations page in the console with a selected recommendation and view details button chosen.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_viewDetailsSelect.png)

   The recommendation details page appears. The title provides the total count of the resources with the issue detected and the severity.

   For information about the components on the details page for an anomaly based reactive recommendation, see [Viewing reactive anomalies](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-rds.analyzing.metrics.html) in the *Amazon DevOps Guru User Guide*.

   For information about the components on the details page for a threshold based proactive recommendation, see [Viewing Performance Insights proactive recommendations](USER_PerfInsights.InsightsRecommendationViewDetails.md).

   The other automated recommendations display the following components on the recommendation details page:
   + **Recommendation** – A summary of the recommendation and whether downtime is required to apply the recommendation.  
![\[Recommendations details page showing Recommendation section in the console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/RecommendationSummary.png)
   + **Resources affected** – Details of the affected resources.  
![\[Recommendations details page showing Resources Affected section in the console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_AffectedResources.png)
   + **Recommendation details** – Supported engine information, any required associated cost to apply the recommendation, and documentation link to learn more.  
![\[Recommendations details page showing Recommendation details section in the console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/RecommendationDetails.png)

## CLI
<a name="UserRecommendationsView.Cli"></a>

To view Amazon RDS recommendations of the DB instances or DB clusters, use the following command in AWS CLI.

```
aws rds describe-db-recommendations
```

## RDS API
<a name="UserRecommendationsView.API"></a>

To view Amazon RDS recommendations using the Amazon RDS API, use the [DescribeDBRecommendations](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBRecommendations.html) operation.

# Applying Amazon Aurora recommendations
<a name="USERRecommendationsManage.ApplyRecommendation"></a>

To apply Amazon Aurora recommendations using the Amazon RDS console, select a configuration based recommendation or an affected resource in the details page. Then, choose to apply the recommendation immediately or schedule it for the next maintenance window. The resource might need to restart for the change to take effect. For a few DB parameter group recommendations, you might need to restart the resources.

The threshold based proactive or anomaly based reactive recommendations won't have the apply option and might need additional review.

## Console
<a name="USERRecommendationsManage.ApplyRecommendation-Console"></a>

**To apply a configuration based recommendation**

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, perform any of the following:
   + Choose **Recommendations**.

     The **Recommendations** page appears with the list of all recommendations.
   + Choose **Databases** and then choose **Recommendations** for a resource in the databases page.

     The details appear in the **Recommendations** tab for the selected recommendation.
   + Choose **Detection** for an active recommendation in the **Recommendations** page or the **Recommendations** tab in the **Databases** page.

     The recommendation details page appears.

1. Choose a recommendation, or one or more affected resources in the recommendation details page, and do any of the following:
   + Choose **Apply** and then choose **Apply immediately** to apply the recommendation immediately.
   + Choose **Apply** and then choose **Apply in next maintenance window** to schedule in the next maintenance window.

     The selected recommendation status is updated to pending until the next maintenance window.  
![\[An active recommendation selected and Apply button with its options highlighted in the console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_Apply_Defer.png)

   A confirmation window appears.

1. Choose **Confirm application** to apply the recommendation. This window confirms whether the resources need an automatic or manual restart for the changes to take effect.

   The following example shows the confirmation window to apply the recommendation immediately.  
![\[The confirmation window in the console to apply the recommendation immediately\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_ApplyImmediately.png)

   The following example shows the confirmation window to schedule applying the recommendation in the next maintenance window.  
![\[The confirmation window in the console to schedule applying the recommendation in the next maintenance window\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_Defer.png)

   A banner displays a message when the recommendation applied is successful or has failed.

   The following example shows the banner with the successful message.   
![\[A banner in the console showing the message with the number of resources that will apply the recommendation\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendation-Apply-Banner.png)

   The following example shows the banner with the failure message.   
![\[A banner in the console showing the message with the resource that failed to apply the recommendation and the reason for the failure\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendation-Apply-Banner-failure.png)

## RDS API
<a name="USERRecommendationsManage.ApplyRecommendation-API"></a>

**To apply a configuration based Aurora recommendation using the Amazon RDS API**

1. Use the [DescribeDBRecommendations](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBRecommendations.html) operation. The `RecommendedActions` in the output can have one or more recommended actions.

1. Use the [RecommendedAction](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RecommendedAction.html) object for each recommended action from step 1. The output contains `Operation` and `Parameters`.

   The following example shows the output with one recommended action.

   ```
       "RecommendedActions": [
           {
               "ActionId": "0b19ed15-840f-463c-a200-b10af1b552e3",
               "Title": "Turn on auto backup", // localized
               "Description": "Turn on auto backup for my-mysql-instance-1", // localized
               "Operation": "ModifyDbInstance",
               "Parameters": [
                   {
                       "Key": "DbInstanceIdentifier",
                       "Value": "my-mysql-instance-1"
                   },
                   {
                       "Key": "BackupRetentionPeriod",
                       "Value": "7"
                   }
               ],
               "ApplyModes": ["immediately", "next-maintenance-window"],
               "Status": "applied"
           },
           ... // several others
       ],
   ```

1. Use the `operation` for each recommended action from the output in step 2 and input the `Parameters` values.

1. After the operation in step 2 is successful, use the [ModifyDBRecommendation](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBRecommendation.html) operation to modify the recommendation status.

# Dismissing Amazon Aurora recommendations
<a name="USERRecommendationsManage.DismissRecommendation"></a>

You can dismiss one or more Amazon Aurora recommendations using the Amazon RDS console, AWS CLI, or Amazon RDS API.

## Console
<a name="USERRecommendationsManage.DismissRecommendation-Console"></a>

**To dismiss one or more recommendations**

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, perform any of the following:
   + Choose **Recommendations**.

     The **Recommendations** page appears with the list of all recommendations.
   + Choose **Databases** and then choose **Recommendations** for a resource in the databases page.

     The details appear in the **Recommendations** tab for the selected recommendation.
   + Choose **Detection** for an active recommendation in the **Recommendations** page or the **Recommendations** tab in the **Databases** page.

     The recommendation details page displays the list of affected resources.

1. Choose one or more recommendation, or one or more affected resources in the recommendation details page, and then choose **Dismiss**.

   The following example shows the **Recommendations** page with multiple active recommendations selected to dismiss.  
![\[A few active recommendations selected and dismiss button highlighted in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_Dismiss.png)

   A banner displays a message when the selected one or more recommendations are dismissed.

   The following example shows the banner with the successful message.   
![\[A banner in the console showing the message with the number of resources that were successful to dismiss the recommendation\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendation-Dismiss-Banner.png)

   The following example shows the banner with the failure message.  
![\[A banner in the console showing the message with the resource that failed to dismiss the recommendation\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendation-Dismiss-Banner-failure.png)

## CLI
<a name="USERRecommendationsManage.DismissRecommendation-Cli"></a>

**To dismiss an Aurora recommendation using the AWS CLI**

1. Run the command `aws rds describe-db-recommendations --filters "Name=status,Values=active"`.

   The output provides a list of recommendations in `active` status.

1. Find the `recommendationId` for the recommendation that you want to dismiss from step 1.

1. Run the command `>aws rds modify-db-recommendation --status dismissed --recommendationId <ID>` with the `recommendationId` from step 2 to dismiss the recommendation.

## RDS API
<a name="USERRecommendationsManage.DismissRecommendation-API"></a>

To dismiss an Aurora recommendation using the Amazon RDS API, use the [ModifyDBRecommendation](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBRecommendation.html) operation.

# Modifying dismissed Amazon Aurora recommendations to active recommendations
<a name="USERRecommendationsManage.DismissToActiveRecommendation"></a>

You can move one or more dismissed Amazon Aurora recommendations to active recommendations using the Amazon RDS console, AWS CLI, or Amazon RDS API.

## Console
<a name="USERRecommendationsManage.DismissToActiveRecommendation-Console"></a>

**To move one or more dismissed recommendations to active recommendations**

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, perform any of the following:
   + Choose **Recommendations**.

     The **Recommendations** page displays a list of recommendations sorted by the severity for all the resources in your account.
   + Choose **Databases** and then choose **Recommendations** for a resource in the databases page.

     The **Recommendations** tab displays the recommendations and its details for the selected resource.

1. Choose one or more dismissed recommendations from the list and then choose **Move to active**.  
![\[A few dismissed recommendations selected and Move to active button highlighted in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendations_DismissToActive.png)

   A banner displays a successful or failure message when the moving the selected recommendations from dismissed to active status.

   The following example shows the banner with the successful message.  
![\[a banner in the console showing the message with the number of resources moved successfully from dismissed to active recommendations\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendation-DismissToActive-Banner.png)

   The following example shows the banner with the failure message.  
![\[a banner in the console showing the message with the resource that failed to move from dismissed to active recommendations\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Recommendation-DismissToActive-Banner-Failure.png)

## CLI
<a name="USERRecommendationsManage.DismissToActiveRecommendation-Cli"></a>

**To change a dismissed Aurora recommendation to active recommendation using the AWS CLI**

1. Run the command `aws rds describe-db-recommendations --filters "Name=status,Values=dismissed"`.

   The output provides a list of recommendations in `dismissed` status.

1. Find the `recommendationId` for the recommendation that you want to change the status from step 1.

1. Run the command `>aws rds modify-db-recommendation --status active --recommendationId <ID>` with the `recommendationId` from step 2 to change to active recommendation.

## RDS API
<a name="USERRecommendationsManage.DismissToActiveRecommendation-API"></a>

To change a dismissed Aurora recommendation to active recommendation using the Amazon RDS API, use the [ModifyDBRecommendation](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBRecommendation.html) operation.

# Recommendations from Amazon Aurora reference
<a name="USERRecommendationsManage.RecommendationReference"></a>

Amazon Aurora generates recommendations for a resource when the resource is created or modified. You can find examples of recommendations from Amazon Aurora in the following table. 


| Type | Description | Recommendation | Downtime required | Additional information | 
| --- | --- | --- | --- | --- | 
|  Resource Automated backups is turned off  |  Automated backups aren't turned on for your DB instances. Automated backups are recommended because they enable point-in-time recovery of your DB instances.  |  Turn on automated backups with a retention period of up to 14 days.  |  Yes  |  [Overview of backing up and restoring an Aurora DB cluster](Aurora.Managing.Backups.md) [ Demystifying Amazon RDS backup storage costs](https://aws.amazon.com/blogs/database/demystifying-amazon-rds-backup-storage-costs/) on the AWS Database Blog   | 
|  Engine minor version upgrade is required  |  Your database resources aren't running the latest minor DB engine version. The latest minor version contains the latest security fixes and other improvements.  |  Upgrade to latest engine version.  |  Yes  |  [Maintaining an Amazon Aurora DB cluster](USER_UpgradeDBInstance.Maintenance.md)  | 
|  Enhanced Monitoring is turned off  |  Your database resources don't have Enhanced Monitoring turned on. Enhanced Monitoring provides real-time operating system metrics for monitoring and troubleshooting.  |  Turn on Enhanced Monitoring.  |  No  |  [Monitoring OS metrics with Enhanced Monitoring](USER_Monitoring.OS.md)  | 
|  Storage encryption is turned off  |  Amazon RDS supports encryption at rest for all the database engines by using the keys that you manage in AWS Key Management Service (AWS KMS). On an active DB instance with Amazon RDS encryption, the data stored at rest in the storage is encrypted, similar to automated backups, read replicas, and snapshots. If encryption isn't turned on while creating an Aurora DB cluster, you must restore a decrypted snapshot to an encrypted DB cluster.  |  Turn on encryption of data at rest for your DB cluster.  |  Yes  |  [Security in Amazon Aurora](UsingWithRDS.md)  | 
|  DB clusters with all instances in the same Availability Zone  |  The DB clusters are currently in a single Availability Zone. Use multiple Availability Zones to improve the availability.  |  Add the DB instances to multiple Availability Zones in your DB cluster.  |  No  |  [High availability for Amazon Aurora](Concepts.AuroraHighAvailability.md)  | 
|  DB instances in the clusters with heterogeneous instance sizes  |  We recommend that you use the same DB instance class and size for all the DB instances in your DB cluster.  |  Use the same instance class and size for all the DB instances in your DB cluster.  |  Yes  |  [Replication with Amazon Aurora](Aurora.Replication.md)  | 
|  DB instances in the clusters with heterogeneous instance classes  |  We recommend that you use the same DB instance class and size for all the DB instances in your DB cluster.  |  Use the same instance class and size for all the DB instances in your DB cluster.  |  Yes  |  [Replication with Amazon Aurora](Aurora.Replication.md)  | 
|  DB instances in the clusters with heterogeneous parameter groups  |  We recommend that all of the DB instances in the DB cluster use the same DB parameter group.  |  Associate the DB instance with the DB parameter group associated with the writer instance in your DB cluster.  |  No  |  [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md)  | 
| Amazon RDS DB clusters have one DB instance | Add at least one more DB instance to your DB cluster to improve availability and performance. | Add a reader DB instance to your DB cluster. | No |  [High availability for Amazon Aurora](Concepts.AuroraHighAvailability.md)  | 
| Performance Insights is turned off | Performance Insights monitors your DB instance load to help you analyze and resolve database performance issues. We recommend that you turn on Performance Insights. | Turn on Performance Insights. | No |  [Monitoring DB load with Performance Insights on Amazon Aurora](USER_PerfInsights.md)  | 
|  RDS resources major versions update is required | Databases with the current major version for the DB engine won't be supported. We recommend that you upgrade to the latest major version which includes new functionality and enhancements. | Upgrade to the latest major version for the DB engine. | Yes |  [Amazon Aurora updates](Aurora.Updates.md) [Creating a blue/green deployment in Amazon Aurora](blue-green-deployments-creating.md)  | 
| DB cluster maximum volume size | Newer engine versions support larger storage volumes for your DB cluster. | We recommend that you upgrade the engine version of your DB cluster to the latest version to benefit from increased storage capacity.  | Yes |  [Amazon Aurora size limits](CHAP_Limits.md#RDS_Limits.FileSize.Aurora)  | 
| DB clusters with all reader instances in the same Availability Zone | Availability Zones (AZs) are locations that are distinct from each other to provide isolation in case of outages within each AWS Region. We recommend that you distribute the primary instance and reader instances in your DB cluster across multiple AZs to improve the availability of your DB cluster. You can create a Multi-AZ cluster using the AWS Management Console, AWS CLI, or Amazon RDS API when you create the cluster. You can modify the existing Aurora cluster to a Multi-AZ cluster by adding a new reader instance and specifying a different AZ. | Your DB cluster has all of its read instances in the same Availability Zone. We recommend that you distribute the reader instances across multiple Availability Zones. Distribution increases availability and improves response time by reducing network latency between clients and the database. | No |  [High availability for Amazon Aurora](Concepts.AuroraHighAvailability.md)  | 
| DB memory parameters are diverging from default | The memory parameters of the DB instances are significantly different from the default values. These settings can impact performance and cause errors. We recommend that you reset the custom memory parameters for the DB instance to their default values in the DB parameter group.  | Reset the memory parameters to their default values. | No |  [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md)  | 
| Query cache parameter is turned on | When changes require that your query cache is purged, your DB instance will appear to stall. Most workloads don't benefit from a query cache. The query cache was removed from MySQL 8.0 and higher versions. We recommend that you set the query\$1cache\$1type parameter to 0. | Set the `query_cache_type` parameter value to `0` in your DB parameter groups. | Yes |  [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md)  | 
| `log_output` parameter is set to table | When `log_output` is set to `TABLE`, more storage is used than when `log_output` is set to `FILE`. We recommend that you set the parameter to `FILE`, to avoid reaching the storage size limit. Set to `FILE` by default in MySQL 8.4 and higher versions. | Set the `log_output` parameter value to `FILE` in your DB parameter groups. | No |  [AuroraMySQL database log files](USER_LogAccess.Concepts.MySQL.md)  | 
| `autovacuum` parameter is turned off | The autovacuum parameter is turned off for your DB clusters. Turning autovacuum off increases the table and index bloat and impacts the performance. We recommend that you turn on autovacuum in your DB parameter groups.  | Turn on the autovacuum parameter in your DB cluster parameter groups. | No |  [ Understanding autovacuum in Amazon RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) on the AWS Database Blog  | 
| `synchronous_commit` parameter is turned off | When `synchronous_commit` parameter is turned off, data can be lost in a database crash. The durability of the database is at risk. We recommend that you turn on the `synchronous_commit` parameter.  | Turn on `synchronous_commit` parameter in your DB parameter groups. | Yes |  [ Amazon Aurora PostgreSQL parameters: Replication, security, and logging](https://aws.amazon.com/blogs/database/amazon-aurora-postgresql-parameters-part-2-replication-security-and-logging/) on the AWS Database Blog  | 
| `track_counts` parameter is turned off | When the `track_counts` parameter is turned off, the database doesn't collect the database activity statistics. Autovacuum requires these statistics to work correctly. We recommend that you set `track_counts` parameter to `1`. | Set `track_counts` parameter to `1`. | No |  [Run-time Statistics for PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-COUNTS)   | 
| `enable_indexonlyscan` parameter is turned off | The query planner or optimizer can't use the index-only scan plan type when it is turned off. We recommend that you set the `enable_indexonlyscan` parameter value to `1`. | Set the `enable_indexonlyscan` parameter value to `1`. | No |  [Planner Method Configuration for PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-ENABLE-INDEXONLYSCAN)  | 
| `enable_indexscan` parameter is turned off | The query planner or optimizer can't use the index scan plan type when it is turned off. We recommend that you set the `enable_indexscan` value to `1`. | Set the `enable_indexscan` parameter value to `1`. | No |  [Planner Method Configuration for PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-ENABLE-INDEXONLYSCAN)  | 
| `innodb_flush_log_at_trx` parameter is turned off | The value of the `innodb_flush_log_at_trx` parameter of your DB instance isn't safe value. This parameter controls the persistence of commit operations to disk. We recommend that you set the `innodb_flush_log_at_trx` parameter to `1`. | Set the `innodb_flush_log_at_trx` parameter value to `1`. | No |  [Configuring how frequently the log buffer is flushed](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)  | 
| `innodb_stats_persistent` parameter is turned off | Your DB instance isn't configured to persist the InnoDB statistics to the disk. When the statistics aren't stored, they are recalculated each time the instance restarts and the table accessed. This leads to variations in the query execution plan. You can modify the value of this global parameter at the table level. We recommend that you set the `innodb_stats_persistent` parameter value to `ON`. | Set the `innodb_stats_persistent` parameter value to `ON`. | No |  [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md)  | 
| `innodb_open_files` parameter is low | The `innodb_open_files` parameter controls the number of files InnoDB can open at one time. InnoDB opens all of the log and system tablespace files when mysqld is running. Your DB instance has a low value for the maximum number of files InnoDB can open at one time. We recommend that you set the `innodb_open_files` parameter to a minimum value of `65`. | Set the `innodb_open_files` parameter to a minimum value of `65`. | Yes | [InnoDB open files for MySQL](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_open_files)  | 
| `max_user_connections` parameter is low | Your DB instance has a low value for the maximum number of simultaneous connections for each database account. We recommend setting the `max_user_connections` parameter to a number greater than `5`. | Increase the value of the `max_user_connections` parameter to a number greater than `5`. | Yes | [Setting Account Resource Limits for MySQL](https://dev.mysql.com/doc/refman/8.0/en/user-resources.html) | 
| Read Replicas are open in writable mode | Your DB instance has a read replica in writable mode, which allows updates from clients. We recommend that you set the `read_only` parameter to `TrueIfReplica` so that the read replicas isn't in writable mode. | Set the `read_only` parameter value to `TrueIfReplica`. | No |  [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md)  | 
| `innodb_default_row_format` parameter setting is unsafe | Your DB instance encounters a known issue: A table created in a MySQL version lower than 8.0.26 with the `row_format` set to `COMPACT` or `REDUNDANT` will be inaccessible and unrecoverable when the index exceeds 767 bytes. We recommend that you set the `innodb_default_row_format` parameter value to `DYNAMIC`. | Set the `innodb_default_row_format` parameter value to `DYNAMIC`. | No | [ Changes in MySQL 8.0.26](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-26.html#mysqld-8-0-26-bug) | 
| `general_logging` parameter is turned on | The general logging is turned on for your DB instance. This setting is useful while troubleshooting the database issues. However, turning on general logging increases the amount of I/O operations and allocated storage space, which might result in contention and performance degradation. Check your requirements for general logging usage. We recommend that you set the `general_logging` parameter value to `0`. | Check your requirements for general logging usage. If it isn't mandatory, we recommend that you to set the `general_logging` parameter value to `0`. | No |  [Overview of Aurora MySQL database logs](USER_LogAccess.MySQL.LogFileSize.md)  | 
| DB cluster under-provisioned for read workload | We recommend that you add a reader DB instance to your DB cluster with the same instance class and size as the writer DB instance in the cluster. The current configuration has one DB instance with a continuously high database load caused mostly by read operations. Distribute these operations by adding another DB instance to the cluster and directing the read workload to the DB cluster read-only endpoint. | Add a reader DB instance to the cluster. | No | [Adding Aurora Replicas to a DB cluster](aurora-replicas-adding.md) [Managing performance and scaling for Aurora DB clusters](Aurora.Managing.Performance.md) [Amazon RDS pricing](https://aws.amazon.com/rds/pricing/)  | 
| RDS instance under-provisioned for system memory capacity | We recommend that you tune your queries to use lesser memory or use a DB instance type with higher allocated memory. When the instance is running low on memory, then the database performance is impacted.  | Use a DB instance with higher memory capacity | Yes |  [ Scaling Your Amazon RDS Instance Vertically and Horizontally](https://aws.amazon.com/blogs/database/scaling-your-amazon-rds-instance-vertically-and-horizontally/) on the AWS Database Blog [Amazon RDS instance types](https://aws.amazon.com/rds/instance-types/) [Amazon RDS pricing](https://aws.amazon.com/rds/pricing/)  | 
| RDS instance under-provisioned for system CPU capacity | We recommend that you tune your queries to use less CPU or modify your DB instance to use a DB instance class with higher allocated vCPUs. Database performance might decline when a DB instance is running low on CPU. | Use a DB instance with higher CPU capacity | Yes |  [ Scaling Your Amazon RDS Instance Vertically and Horizontally](https://aws.amazon.com/blogs/database/scaling-your-amazon-rds-instance-vertically-and-horizontally/) on the AWS Database Blog [Amazon RDS instance types](https://aws.amazon.com/rds/instance-types/) [Amazon RDS pricing](https://aws.amazon.com/rds/pricing/)  | 
| RDS resources are not utilizing connection pooling correctly | We recommend that you enable Amazon RDS Proxy to efficiently pool and share existing database connections. If you are already using a proxy for your database, configure it correctly to improve connection pooling and load balancing across multiple DB instances. RDS Proxy can help reduce the risk of connection exhaustion and downtime while improving availability and scalability. | Enable RDS Proxy or modify your existing proxy configuration | No |  [ Scaling Your Amazon RDS Instance Vertically and Horizontally](https://aws.amazon.com/blogs/database/scaling-your-amazon-rds-instance-vertically-and-horizontally/) on the AWS Database Blog [Amazon RDS Proxyfor Aurora](rds-proxy.md) [Amazon RDS Proxy Pricing](https://aws.amazon.com/rds/proxy/pricing/)  | 

# Viewing metrics in the Amazon RDS console
<a name="USER_Monitoring"></a>

Amazon RDS integrates with Amazon CloudWatch to display a variety of Aurora DB cluster metrics in the RDS console. Some metrics are apply at the cluster level, whereas others apply at the instance level. For descriptions of the instance-level and cluster-level metrics, see [Metrics reference for Amazon Aurora](metrics-reference.md).

For your Aurora DB cluster, the following categories of metrics are monitored:
+ **CloudWatch** – Shows the Amazon CloudWatch metrics for Aurora that you can access in the RDS console. You can also access these metrics in the CloudWatch console. Each metric includes a graph that shows the metric monitored over a specific time span. For a list of CloudWatch metrics, see [Amazon CloudWatch metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md).
+ **Enhanced monitoring** – Shows a summary of operating-system metrics when your Aurora DB cluster has turned on Enhanced Monitoring. RDS delivers the metrics from Enhanced Monitoring to your Amazon CloudWatch Logs account. Each OS metric includes a graph showing the metric monitored over a specific time span. For an overview, see [Monitoring OS metrics with Enhanced Monitoring](USER_Monitoring.OS.md). For a list of Enhanced Monitoring metrics, see [OS metrics in Enhanced Monitoring](USER_Monitoring-Available-OS-Metrics.md).
+ **OS Process list** – Shows details for each process running in your DB cluster.
+ **Performance Insights** – Opens the Amazon RDS Performance Insights dashboard for a DB instance in your Aurora DB cluster. Performance Insights isn't supported at the cluster level. For an overview of Performance Insights, see [Monitoring DB load with Performance Insights on Amazon Aurora](USER_PerfInsights.md). For a list of Performance Insights metrics, see [Amazon CloudWatch metrics for Amazon RDS Performance Insights](USER_PerfInsights.Cloudwatch.md).

Amazon RDS now provides a consolidated view of Performance Insights and CloudWatch metrics in the Performance Insights dashboard. Performance Insights must be turned on for your DB cluster to use this view. You can choose the new monitoring view in the **Monitoring** tab or **Performance Insights** in the navigation pane. To view the instructions for choosing this view, see [Viewing combined metrics with the Performance Insights dashboard](Viewing_Unifiedmetrics.md).

# Viewing combined metrics with the Performance Insights dashboard
<a name="Viewing_Unifiedmetrics"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

Amazon RDS provides a consolidated view of Performance Insights and CloudWatch metrics for your DB instance in the Performance Insights dashboard. You can use the preconfigured dashboard or create a custom dashboard. The preconfigured dashboard provides the most commonly used metrics to help diagnose performance issues for a database engine. Alternatively, you can create a custom dashboard with the metrics for a database engine that meet your analysis requirements. Then, use this dashboard for all the DB instances of that database engine type in your AWS account. 

You can choose the monitoring view in the **Monitoring** tab or **Performance Insights** in the navigation pane.

Performance Insights must be turned on for your DB cluster to view the combined metrics in the Performance Insights dashboard. For more information about turning on Performance Insights, see [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md). 

In the following sections, you can learn to display Performance Insights and CloudWatch metrics.

**Topics**
+ [Choosing the new monitoring view from the Monitoring tab](Viewing_Unifiedmetrics.MonitoringTab.md)
+ [Choosing the new monitoring view from the Performance Insights page](Viewing_Unifiedmetrics.PInavigationPane.md)
+ [Creating a custom dashboard with Performance Insights](Viewing_Unifiedmetrics.PIcustomizeMetricslist.md)
+ [Choosing the preconfigured dashboard with Performance Insights](Viewing_Unifiedmetrics.PI-preconfigured-dashboard.md)

# Choosing the new monitoring view from the Monitoring tab
<a name="Viewing_Unifiedmetrics.MonitoringTab"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

From the Amazon RDS console, you can choose the new monitoring view to view Performance Insights and CloudWatch metrics for your DB instance.

**To choose the new monitoring view in the Monitoring tab**

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 left navigation pane, choose **Databases**.

1. Choose the Aurora DB cluster that you want to monitor.

1. Scroll down and choose the **Monitoring** tab.

   A banner appears with the option to choose the new monitoring view. The following example shows the banner to choose the new monitoring view.  
![\[Banner with navigation to new monitoring view.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/NewMonitoringViewOption.png)

1. Choose **Go to new monitoring view** to open the Performance Insights dashboard with Performance Insights and CloudWatch metrics for your DB cluster.

1. (Optional) If Performance Insights is turned off for your DB instance, a banner appears with the option to modify your DB instance and turn on Performance Insights.

   The following example shows the banner to modify the DB instance in the **Monitoring** tab .  
![\[Modify DB instance to turn on Performance Insights.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_modifyInstnc_banner.png)

   Choose **Modify** to modify your DB instance and turn on Performance Insights. For more information about turning on Performance Insights, see [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md)

# Choosing the new monitoring view from the Performance Insights page
<a name="Viewing_Unifiedmetrics.PInavigationPane"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

From the Amazon RDS console, you can choose the new monitoring view to view Performance Insights and CloudWatch metrics for your DB instance.

**To choose the new monitoring view with Performance Insights in the navigation pane**

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 left navigation pane, choose **Performance Insights**.

1. Choose a DB instance to view the Performance Insights dashboard that shows both Performance Insights and CloudWatch metrics for your DB instance.  
![\[Consolidated Performance Insights and CloudWatch metrics dashboard.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_UnifiedDashboard.png)

# Creating a custom dashboard with Performance Insights
<a name="Viewing_Unifiedmetrics.PIcustomizeMetricslist"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

In the new monitoring view, you can create a custom dashboard with the metrics you need to meet your analysis requirements.

You can create a custom dashboard by selecting Performance Insights and CloudWatch metrics for your DB instance. You can use this custom dashboard for other DB instances of the same database engine type in your AWS account.

**Note**  
The customized dashboard supports up to 50 metrics.

Use the widget settings menu to edit or delete the dashboard, and move or resize the widget window.

**To create a custom dashboard with Performance Insights in the navigation pane**

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 left navigation pane, choose **Performance Insights**.

1. Choose a DB instance.

1. Scroll down to the **Metrics tab** in the window.

1. Select the custom dashboard from the drop down list. The following example shows the custom dashboard creation.  
![\[Custom metrics dashboard with no widgets yet.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_custmDashbrd_addWidget.png)

1. Choose **Add widget** to open the **Add widget** window. You can open and view the available operating system (OS) metrics, database metrics, and CloudWatch metrics in the window.

   The following example shows the **Add widget** window with the metrics.  
![\[The metrics options in the Add Widget window.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_AddWidget.png)

1. Select the metrics that you want to view in the dashboard and choose **Add widget**. You can use the search field to find a specific metric. 

   The selected metrics appear on your dashboard.

1. (Optional) If you want to modify or delete your dashboard, choose the settings icon on the upper right of the widget, and then select one of the following actions in the menu.
   + **Edit** – Modify the metrics list in the window. Choose **Update widget** after you select the metrics for your dashboard.
   + **Delete** – Deletes the widget. Choose **Delete** in the confirmation window. 

# Choosing the preconfigured dashboard with Performance Insights
<a name="Viewing_Unifiedmetrics.PI-preconfigured-dashboard"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

You can view the most commonly used metrics with the preconfigured dashboard. This dashboard helps diagnose performance issues with a database engine and reduce the average recovery time from hours to minutes.

**Note**  
This dashboard can't be edited.

**To choose the preconfigured dashboard with Performance Insights in the navigation pane**

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 left navigation pane, choose **Performance Insights**.

1. Choose a DB instance.

1. Scroll down to the **Metrics tab** in the window

1. Select a preconfigured dashboard from the drop down list.

   You can view the metrics for the DB instance in the dashboard. The following example shows a preconfigured metrics dashboard.  
![\[Preconfigured metrics dashboard.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_preconfigDashboard.png)

# Monitoring Amazon Aurora metrics with Amazon CloudWatch
<a name="monitoring-cloudwatch"></a>

Amazon CloudWatch is a metrics repository. The repository collects and processes raw data from Amazon Aurora into readable, near real-time metrics. For a complete list of Amazon Aurora metrics sent to CloudWatch, see  [ Metrics reference for Amazon Aurora](https://docs.aws.amazon.com/en_us/AmazonRDS/latest/AuroraUserGuide/metrics-reference.html).

To analyze and troubleshoot the performance of your databases at scale, use [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.html).

**Topics**
+ [Overview of Amazon Aurora and Amazon CloudWatch](#cw-metrics-overview)
+ [Viewing DB cluster metrics in the CloudWatch console and AWS CLI](metrics_dimensions.md)
+ [Exporting Performance Insights metrics to CloudWatch](PI_metrics_export_CW.md)
+ [Creating CloudWatch alarms to monitor Amazon Aurora](creating_alarms.md)

## Overview of Amazon Aurora and Amazon CloudWatch
<a name="cw-metrics-overview"></a>

By default, Amazon Aurora automatically sends metric data to CloudWatch in 1-minute periods. For example, the `CPUUtilization` metric records the percentage of CPU utilization for a DB instance over time. Data points with a period of 60 seconds (1 minute) are available for 15 days. This means that you can access historical information and see how your web application or service is performing.

You can now export Performance Insights metrics dashboards from Amazon RDS to Amazon CloudWatch. You can export either the preconfigured or customized metrics dashboards as a new dashboard or add them to an existing CloudWatch dashboard. The exported dashboard is available to view in the CloudWatch console. For more information on how to export the Performance Insights metrics dashboards to CloudWatch, see [Exporting Performance Insights metrics to CloudWatch](PI_metrics_export_CW.md).

As shown in the following diagram, you can set up alarms for your CloudWatch metrics. For example, you might create an alarm that signals when the CPU utilization for an instance is over 70%. You can configure Amazon Simple Notification Service to email you when the threshold is passed.

![\[RDS metrics in AWS CloudWatch\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/rds-cloudwatch.png)


Amazon RDS publishes the following types of metrics to Amazon CloudWatch:
+ Aurora metrics at both the cluster and instance level

  For a table of these metrics, see [Amazon CloudWatch metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md).
+ Performance Insights metrics

  For a table of these metrics, see [Amazon CloudWatch metrics for Amazon RDS Performance Insights](USER_PerfInsights.Cloudwatch.md) and [Performance Insights counter metrics](USER_PerfInsights_Counters.md).
+ Enhanced Monitoring metrics (published to Amazon CloudWatch Logs)

  For a table of these metrics, see [OS metrics in Enhanced Monitoring](USER_Monitoring-Available-OS-Metrics.md).
+ Usage metrics for the Amazon RDS service quotas in your AWS account

  For a table of these metrics, see [Amazon CloudWatch usage metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#rds-metrics-usage). For more information about Amazon RDS quotas, see [Quotas and constraints for Amazon Aurora](CHAP_Limits.md).

For more information about CloudWatch, see [ What is Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) in the *Amazon CloudWatch User Guide*. For more information about CloudWatch metrics retention, see [Metrics retention](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/cloudwatch_concepts.html#metrics-retention).

# Viewing DB cluster metrics in the CloudWatch console and AWS CLI
<a name="metrics_dimensions"></a>

Following, you can find details about how to view metrics for your DB instance using CloudWatch. For information on monitoring metrics for your DB instance's operating system in real time using CloudWatch Logs, see [Monitoring OS metrics with Enhanced Monitoring](USER_Monitoring.OS.md).

When you use Amazon Aurora resources, Amazon Aurora sends metrics and dimensions to Amazon CloudWatch every minute.

You can now export Performance Insights metrics dashboards from Amazon RDS to Amazon CloudWatch and view these metrics in the CloudWatch console. For more information on how to export the Performance Insights metrics dashboards to CloudWatch, see [Exporting Performance Insights metrics to CloudWatch](PI_metrics_export_CW.md).

Use the following procedures to view the metrics for Amazon Aurora in the CloudWatch console and CLI.

## Console
<a name="metrics_dimensions.console"></a>

**To view metrics using the Amazon CloudWatch console**

Metrics are grouped first by the service namespace, and then by the various dimension combinations within each namespace.

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

   The CloudWatch overview home page appears.  
![\[CloudWatch overview page\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/monitoring-overviewpage-console2.png)

1. If necessary, change the AWS Region. From the navigation bar, choose the AWS Region where your AWS resources are. For more information, see [Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html).

1. In the navigation pane, choose **Metrics** and then **All metrics**.  
![\[Choose metric namespace\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/cw-all-metrics.png)

1. Scroll down and choose the **RDS** metric namespace.

   The page displays the Amazon Aurora dimensions. For descriptions of these dimensions, see [Amazon CloudWatch dimensions for Aurora](dimensions.md).  
![\[Choose metric namespace\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/rds-monitoring-01.png)

1. Choose a metric dimension, for example **By Database Class**.  
![\[Filter metrics\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/metrics-by-instance-class.png)

1. Do any of the following actions:
   + To sort the metrics, use the column heading.
   + To graph a metric, select the check box next to the metric.
   + To filter by resource, choose the resource ID, and then choose **Add to search**.
   + To filter by metric, choose the metric name, and then choose **Add to search**.

   The following example filters on the **db.t3.medium** class and graphs the **CPUUtilization** metric.  
![\[Filter metrics\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/rds-monitoring-03.png)

You can find details about how to analyze resource usage for Aurora PostgreSQL using CloudWatch metrics. For more information, see [Using Amazon CloudWatch metrics to analyze resource usage for Aurora PostgreSQL](AuroraPostgreSQL_AnayzeResourceUsage.md) 

## AWS CLI
<a name="metrics_dimensions.CLI"></a>

To obtain metric information by using the AWS CLI, use the CloudWatch command [https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html). In the following example, you list all metrics in the `AWS/RDS` namespace.

```
aws cloudwatch list-metrics --namespace AWS/RDS
```

To obtain metric data, use the command [https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html).

The following example gets `CPUUtilization` statistics for instance `my-instance` over the specific 24-hour period, with a 5-minute granularity.

Create a JSON file `CPU_metric.json` with the following contents.

```
 1. {
 2.    "StartTime" : "2023-12-25T00:00:00Z",
 3.    "EndTime" : "2023-12-26T00:00:00Z",
 4.    "MetricDataQueries" : [{
 5.      "Id" : "cpu",	    
 6.      "MetricStat" : {
 7. 	   "Metric" : {	  
 8.   	     "Namespace" : "AWS/RDS",
 9.   	     "MetricName" : "CPUUtilization",
10.   	     "Dimensions" : [{ "Name" : "DBInstanceIdentifier" , "Value" : my-instance}]
11. 	   },  
12.        "Period" : 360,
13.        "Stat" : "Minimum" 
14.      }
15.    }]
16. }
```

**Example**  
For Linux, macOS, or Unix:  

```
1. aws cloudwatch get-metric-data \
2.     --cli-input-json file://CPU_metric.json
```
For Windows:  

```
1. aws cloudwatch get-metric-data ^
2.      --cli-input-json file://CPU_metric.json
```
Sample output appears as follows:  

```
{
    "MetricDataResults": [
        {
            "Id": "cpu",
            "Label": "CPUUtilization",
            "Timestamps": [
                "2023-12-15T23:48:00+00:00",
                "2023-12-15T23:42:00+00:00",
                "2023-12-15T23:30:00+00:00",
                "2023-12-15T23:24:00+00:00",
                ...
            ],
            "Values": [
                13.299778337027714,
                13.677507543049558,
                14.24976250395827,
                13.02521708695145,
                ...
            ],
            "StatusCode": "Complete"
        }
    ],
    "Messages": []
}
```
For more information, see [Getting statistics for a metric](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/getting-metric-data.html) in the *Amazon CloudWatch User Guide*.

# Exporting Performance Insights metrics to CloudWatch
<a name="PI_metrics_export_CW"></a>

Performance Insights lets you export the preconfigured or custom metrics dashboard for your DB instance to Amazon CloudWatch. You can export the metrics dashboard as a new dashboard or add it to an existing CloudWatch dashboard. When you choose to add the dashboard to an existing CloudWatch dashboard, you can create a header label so that the metrics appear in a separate section in the CloudWatch dashboard.

You can view the exported metrics dashboard in the CloudWatch console. If you add new metrics to a Performance Insights metrics dashboard after you export it, you must export this dashboard again to view the new metrics in the CloudWatch console.

You can also select a metric widget in the Performance Insights dashboard and view the metrics data in the CloudWatch console.

For more information about viewing the metrics in the CloudWatch console, see [Viewing DB cluster metrics in the CloudWatch console and AWS CLI](metrics_dimensions.md).

In the following sections, export Performance Insights metrics to CloudWatch as a new or existing dashboard and view Performance Insights metrics in CloudWatch.

**Topics**
+ [Exporting Performance Insights metrics as a new dashboard to CloudWatch](PI_metrics_export_CW.new_dashboard.md)
+ [Adding Performance Insights metrics to an existing CloudWatch dashboard](PI_metrics_export_CW.existing_dashboard.md)
+ [Viewing a Performance Insights metric widget in CloudWatch](PI_metrics_export_CW.individual_widget.md)

# Exporting Performance Insights metrics as a new dashboard to CloudWatch
<a name="PI_metrics_export_CW.new_dashboard"></a>

Choose a preconfigured or custom metrics dashboard from the Performance Insights dashboard and export it as a new dashboard to CloudWatch. You can view the exported dashboard in the CloudWatch console.

**To export a Performance Insights metric dashboard as a new dashboard to CloudWatch**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the left navigation pane, choose **Performance Insights**.

1. Choose a DB instance. 

   The Performance Insights dashboard appears for the DB instance.

1. Scroll down and choose **Metrics**.

   By default, the preconfigured dashboard with Performance Insights metrics appears.

1. Choose a preconfigured or custom dashboard and then choose **Export to CloudWatch**.

   The **Export to CloudWatch** window appears.  
![\[Performance Insights dashboard with export to CloudWatch button\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI-ExprtToCW.png)

1. Choose **Export as new dashboard**.  
![\[Export to CloudWatch window with export as new dashboard option selected\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI-ExprtToCW-NewDashboard.png)

1. Enter a name for the new dashboard in the **Dashboard name** field and choose **Confirm**.

   A banner displays a message after the dashboard export is successful.  
![\[Banner with successful message\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI-ExprtToCW-SuccessBanner.png)

1. Choose the link or **View in CloudWatch** in the banner to view the metrics dashboard in the CloudWatch console.

# Adding Performance Insights metrics to an existing CloudWatch dashboard
<a name="PI_metrics_export_CW.existing_dashboard"></a>

Add a preconfigured or custom metrics dashboard to an existing CloudWatch dashboard. You can add a label to the metrics dashboard to appear in a separate section in the CloudWatch dashboard.

**To export the metrics to an existing CloudWatch dashboard**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the left navigation pane, choose **Performance Insights**.

1. Choose a DB instance. 

   The Performance Insights dashboard appears for the DB instance.

1. Scroll down and choose **Metrics**.

   By default, the preconfigured dashboard with Performance Insights metrics appears.

1. Choose the preconfigured or custom dashboard and then choose **Export to CloudWatch**.

   The **Export to CloudWatch** window appears. 

1. Choose **Add to existing dashboard**.  
![\[Export to CloudWatch window with add to existing dashboard option selected\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Pi-ExprtToCW-AddToExistingBoard.png)

1. Specify the dashboard destination and label, and then choose **Confirm**.
   + **CloudWatch dashboard destination** - Choose an existing CloudWatch dashboard.
   + **CloudWatch dashboard section label - optional** - Enter a name for the Performance Insights metrics to appear in this section in the CloudWatch dashboard.

   A banner displays a message after the dashboard export is successful.

1. Choose the link or **View in CloudWatch** in the banner to view the metrics dashboard in the CloudWatch console.

# Viewing a Performance Insights metric widget in CloudWatch
<a name="PI_metrics_export_CW.individual_widget"></a>

Select a Performance Insights metric widget in the Amazon RDS Performance Insights dashboard and view the metric data in the CloudWatch console. 

**To export a metric widget and view the metrics data in the CloudWatch console**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the left navigation pane, choose **Performance Insights**.

1. Choose a DB instance. 

   The Performance Insights dashboard appears for the DB instance.

1. Scroll down to **Metrics**.

   By default, the preconfigured dashboard with Performance Insights metrics appears.

1. Choose a metric widget and then choose **View in CloudWatch** in the menu.  
![\[Selected widget with menu to view in CloudWatch\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI-ExprtToCW-SelectedMetric.png)

   The metric data appears in the CloudWatch console.

# Creating CloudWatch alarms to monitor Amazon Aurora
<a name="creating_alarms"></a>

You can create a CloudWatch alarm that sends an Amazon SNS message when the alarm changes state. An alarm watches a single metric over a time period that you specify. The alarm can also perform one or more actions based on the value of the metric relative to a given threshold over a number of time periods. The action is a notification sent to an Amazon SNS topic or Amazon EC2 Auto Scaling policy.

Alarms invoke actions for sustained state changes only. CloudWatch alarms don't invoke actions simply because they are in a particular state. The state must have changed and have been maintained for a specified number of time periods.

**Note**  
For Aurora, use `WRITER` or `READER` role metrics to set up alarms instead of relying on metrics for specific DB instances. Aurora DB instance roles can change roles over time. You can find these role-based metrics in the CloudWatch console.  
Aurora Auto Scaling automatically sets alarms based on `READER` role metrics. For more information about Aurora Auto Scaling, see [Amazon Aurora Auto Scaling with Aurora Replicas](Aurora.Integrating.AutoScaling.md). 

You can use the **DB\$1PERF\$1INSIGHTS** metric math function in the CloudWatch console to query Amazon RDS for Performance Insights counter metrics. The **DB\$1PERF\$1INSIGHTS** function also includes the DBLoad metric at sub-minute intervals. You can set CloudWatch alarms on these metrics.

For more details on how to create an alarm, see [ Create an alarm on Performance Insights counter metrics from an AWS database](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_alarm_database_performance_insights.html).

**To set an alarm using the AWS CLI**
+ Call [https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html). For more information, see *[AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/)*.

**To set an alarm using the CloudWatch API**
+ Call [https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html). For more information, see *[Amazon CloudWatch API Reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/)* 

For more information about setting up Amazon SNS topics and creating alarms, see [Using Amazon CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).

# Monitoring Amazon Aurora databases with CloudWatch Database Insights
<a name="USER_DatabaseInsights"></a>

Monitor the database load (DB Load) for your fleet of Amazon Aurora DB instances with Database Insights. DB Load measures the level of session activity in your database. You can use Database Insights to analyze and troubleshoot the performance of your Amazon Aurora databases at scale.

With Database Insights, you can visualize the DB Load on your fleet of databases and filter the load by waits, SQL statements, hosts, or users.

By default, RDS enables the Standard mode of Database Insights for your Amazon Aurora databases. When you turn on the Advanced mode of Database Insights for a DB cluster, RDS enables Database Insights for every DB instance in the cluster.

For information about using Database Insights in the Amazon CloudWatch console, see [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html) in the *Amazon CloudWatch User Guide*.

## Pricing
<a name="USER_Database-Insights-pricing"></a>

For information about pricing, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).

**Topics**
+ [Pricing](#USER_Database-Insights-pricing)
+ [Amazon Aurora DB engine, Region, and instance class support for Database Insights](USER_DatabaseInsights.Engines.md)
+ [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md)
+ [Turning on the Standard mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnStandard.md)
+ [Configuring your database to monitor slow SQL queries with Database Insights for Amazon Aurora](USER_DatabaseInsights.SlowSQL.md)
+ [Considerations for Database Insights for Amazon Aurora](USER_DatabaseInsights.Considerations.md)

# Amazon Aurora DB engine, Region, and instance class support for Database Insights
<a name="USER_DatabaseInsights.Engines"></a>

The following table provides Amazon Aurora DB engines that support Database Insights.


| Amazon Aurora DB engine | Supported engine versions and Regions | Instance class restrictions | 
| --- | --- | --- | 
| Amazon Aurora MySQL-Compatible Edition | For more information on version and Region availability of Database Insights with Aurora MySQL, see [Performance Insights with Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.amy). |  Database Insights has the following engine class restrictions: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.Engines.html)  | 
|  Amazon Aurora PostgreSQL-Compatible Edition  |  For more information on version and Region availability of Database Insights with Aurora PostgreSQL, see [Performance Insights with Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.apg). |  Not applicable  | 
|  Aurora PostgreSQL Limitless Database  |  For more information about using Database Insights with Aurora PostgreSQL Limitless Database, see [Monitoring Aurora PostgreSQL Limitless Database with CloudWatch Database Insights](limitless-monitoring.cwdbi.md). |  Not applicable  | 

Database Insights supports Amazon Aurora Serverless v2.

## Amazon Aurora DB engine, Region, and instance class support for Database Insights features
<a name="database-insights-feature-support"></a>

The following table provides Amazon Aurora DB engines that support Database Insights features.


| Feature | [Pricing tier](https://aws.amazon.com/rds/performance-insights/pricing/) |  [Supported regions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions)  |  Supported DB engines  |  [Supported instance classes](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html#Concepts.DBInstanceClass.Types)  | 
| --- | --- | --- | --- | --- | 
| [SQL statistics for Performance Insights](sql-statistics.md) | All | All |  All  | All | 
| [Analyzing database performance for a period of time](USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod.md) | Paid tier only |  All  |  All  |  All except db.serverless (Aurora Serverless v2)  | 
|  [Viewing Performance Insights proactive recommendations](USER_PerfInsights.InsightsRecommendationViewDetails.md) | Paid tier only | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.Engines.html)  |  All  |  All except db.serverless (Aurora Serverless v2)  | 

## Amazon Aurora Region support for Database Insights
<a name="database-insights-region-support"></a>

Aurora supports Database Insights in the following AWS Regions.
+ US East (N. Virginia)
+ US East (Ohio)
+ US West (N. California)
+ US West (Oregon)
+ Africa (Cape Town)
+ Asia Pacific (Hong Kong)
+ Asia Pacific (Hyderabad)
+ Asia Pacific (Jakarta)
+ Asia Pacific (Malaysia)
+ Asia Pacific (Melbourne)
+ Asia Pacific (Mumbai)
+ Asia Pacific (Osaka)
+ Asia Pacific (Seoul)
+ Asia Pacific (Singapore)
+ Asia Pacific (Sydney)
+ Asia Pacific (Tokyo)
+ Canada (Central)
+ Canada West (Calgary)
+ Europe (Frankfurt)
+ Europe (Ireland)
+ Europe (London)
+ Europe (Milan)
+ Europe (Paris)
+ Europe (Spain)
+ Europe (Stockholm)
+ Europe (Zurich)
+ Israel (Tel Aviv)
+ Middle East (Bahrain)
+ Middle East (UAE)
+ South America (São Paulo)
+ AWS GovCloud (US-East)
+ AWS GovCloud (US-West)

# Turning on the Advanced mode of Database Insights for Amazon Aurora
<a name="USER_DatabaseInsights.TurningOnAdvanced"></a>

To turn on the Advanced mode of Database Insights for Amazon Aurora, use the following procedures.

## Turning on the Advanced mode of Database Insights when creating a DB cluster
<a name="USER_DatabaseInsights.TurnOnCreateDatabase"></a>

Turn on the Advanced mode of Database Insights when creating a database for Amazon Aurora.

------
#### [ Console ]

In the console, you can turn on the Advanced mode of Database Insights when you create a DB cluster. Settings for Database Insights apply to all DB instances in your DB cluster.

**To turn on the Advanced mode of Database Insights when creating a DB cluster using the console**

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. Choose **Databases**.

1. Choose **Create database**.

1. In the **Database Insights** section, select **Advanced mode**. Then, choose the following options:
   + **Retention** – The amount of time to retain Performance Insights data. The retention period must be 15 months for the Advanced mode of Database Insights.
   + **AWS KMS key** – Specify your KMS key. Performance Insights encrypts all potentially sensitive data using your KMS key. Data is encrypted in flight and at rest. For more information, see [Encrypting Amazon Aurora resources](Overview.Encryption.md).

1. Choose **Create database**.

------
#### [ AWS CLI ]

To turn on the Advanced mode of Database Insights when creating a DB cluster, call the [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI command and supply the following values:
+ `--database-insights-mode advanced` to turn on the Advanced mode of Database Insights.
+ `--engine` – The database engine for the DB cluster.
+ `--db-cluster-identifier` – The identifier for the DB cluster.
+ `--enable-performance-insights` to turn on Performance Insights for Database Insights.
+ `--performance-insights-retention-period` – The retention period for data for your DB cluster. To turn on Database Insights, the retention period must be at least 465 days.

The following example enables the Advanced mode of Database Insights when creating a DB cluster.

For Linux, macOS, or Unix:

```
aws rds create-db-cluster \
    --database-insights-mode advanced \ 
    --engine aurora-postgresql \
    --db-cluster-identifier sample-db-identifier \
    --enable-performance-insights \
    --performance-insights-retention-period 465
```

For Windows:

```
aws rds create-db-cluster ^
    --database-insights-mode advanced ^ 
    --engine aurora-postgresql ^
    --db-cluster-identifier sample-db-identifier ^
    --enable-performance-insights ^
    --performance-insights-retention-period 465
```

------
#### [ RDS API ]

To turn on the Advanced mode of Database Insights when you create a DB cluster, specify the following parameters for your [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API operation.
+ `DatabaseInsightsMode` to `advanced`
+ `EnablePerformanceInsights` to `True`
+ `PerformanceInsightsRetentionPeriod` to at least 465 days

------

## Turning on the Advanced mode of Database Insights when modifying a DB cluster
<a name="USER_DatabaseInsights.TurnOnModifyDatabase"></a>

Turn on Database Insights when modifying a database for Amazon Aurora. Modifying a DB cluster to enable the Advanced mode of Database Insights doesn't cause downtime.

**Note**  
To enable Database Insights, each DB instance in a DB cluster must have the same Performance Insights and Enhanced Monitoring settings.

------
#### [ Console ]

In the console, you can turn on the Advanced mode of Database Insights when you modify a DB cluster. Settings for Database Insights apply to all DB instances in your DB cluster.

**To turn on the Advanced mode of Database Insights when modifying a DB cluster using the console**

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. Choose **Databases**.

1. Choose a DB cluster, and choose **Modify**.

1. In the **Database Insights** section, select **Advanced mode**. Then, choose the following options:
   + **Retention** – The amount of time to retain Performance Insights data. The retention period must be 15 months for the Advanced mode of Database Insights.
   + **AWS KMS key** – Specify your KMS key. Performance Insights encrypts all potentially sensitive data using your KMS key. Data is encrypted in flight and at rest. For more information, see [Encrypting Amazon Aurora resources](Overview.Encryption.md).

1. Choose **Continue**.

1. For **Scheduling of Modifications**, choose **Apply immediately**. If you choose **Apply during the next scheduled maintenance window**, your database ignores this setting and turns on the Advanced mode of Database Insights immediately.

1. Choose **Modify cluster**.

------
#### [ AWS CLI ]

To turn on the Advanced mode of Database Insights when modifying a DB cluster, call the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI command and supply the following values:
+ `--database-insights-mode advanced` to turn on the Advanced mode of Database Insights.
+ `--db-cluster-identifier` – The identifier for the DB cluster.
+ `--enable-performance-insights` to turn on Performance Insights for Database Insights.
+ `--performance-insights-retention-period` – The retention period for data for your DB cluster. To turn on the Advanced mode of Database Insights, the retention period must be at least 465 days.

The following example enables the Advanced mode of Database Insights when modifying a DB cluster.

For Linux, macOS, or Unix:

```
aws rds modify-db-cluster \
    --database-insights-mode advanced \
    --db-cluster-identifier sample-db-identifier \
    --enable-performance-insights \
    --performance-insights-retention-period 465
```

For Windows:

```
aws rds modify-db-cluster ^
    --database-insights-mode advanced ^
    --db-cluster-identifier sample-db-identifier ^
    --enable-performance-insights ^
    --performance-insights-retention-period 465
```

------
#### [ RDS API ]

To turn on the Advanced mode of Database Insights when you modify a DB cluster, specify the following parameters for your [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) Amazon RDS API operation.
+ `DatabaseInsightsMode` to `advanced`
+ `EnablePerformanceInsights` to `True`
+ `PerformanceInsightsRetentionPeriod` to at least 465 days

------

# Turning on the Standard mode of Database Insights for Amazon Aurora
<a name="USER_DatabaseInsights.TurningOnStandard"></a>

To turn on the Standard mode of Database Insights for Amazon Aurora, use the following procedures.

## Turning on the Standard mode of Database Insights when creating a DB cluster
<a name="USER_DatabaseInsights.TurnOnCreateDatabaseStandard"></a>

Turn on the Standard mode of Database Insights when creating a database for Amazon Aurora.

------
#### [ Console ]

In the console, you can turn on the Standard mode of Database Insights when you create a DB cluster. Settings for Database Insights apply to all DB instances in your DB cluster.

**To turn on the Standard mode of Database Insights when creating a DB cluster using the console**

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. Choose **Databases**.

1. Choose **Create database**.

1. In the **Database Insights** section, select **Standard mode**. Then, choose from the following options to turn Performance Insights on or off:
   + To turn off Performance Insights, deselect **Enable Performance Insights**.
   + To turn on Performance Insights, select **Enable Performance Insights**. To configure Performance Insights, specify the following options:
     + **Retention** – The amount of time to retain Performance Insights data. The retention period must be at least 7 days.
     + **AWS KMS key** – Specify your KMS key. Performance Insights encrypts all potentially sensitive data using your KMS key. Data is encrypted in flight and at rest. For more information, see [Encrypting Amazon Aurora resources](Overview.Encryption.md).

1. Choose **Create database**.

------
#### [ AWS CLI ]

To turn on the Standard mode of Database Insights when creating a DB cluster, call the [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI command and supply the following values:
+ `--database-insights-mode standard` to turn on the Standard mode of Database Insights.
+ `--engine` – The database engine for the DB cluster.
+ `--db-cluster-identifier` – The identifier for the DB cluster.
+ `--enable-performance-insights` or `--no-enable-performance-insights` to turn Performance Insights on or off. If you specify `--enable-performance-insights`, you must also specify the `--performance-insights-retention-period` – The retention period for data for your DB cluster. The retention period must be at least 7 days.

The following example enables the Standard mode of Database Insights and Performance Insights when creating a DB cluster.

For Linux, macOS, or Unix:

```
aws rds create-db-cluster \
    --database-insights-mode standard \ 
    --engine aurora-postgresql \
    --db-cluster-identifier sample-db-identifier \
    --enable-performance-insights \
    --performance-insights-retention-period 7
```

For Windows:

```
aws rds create-db-cluster ^
    --database-insights-mode standard ^ 
    --engine aurora-postgresql ^
    --db-cluster-identifier sample-db-identifier ^
    --enable-performance-insights ^
    --performance-insights-retention-period 7
```

The following example enables the Standard mode of Database Insights and disables Performance Insights when creating a DB cluster.

For Linux, macOS, or Unix:

```
aws rds create-db-cluster \
    --database-insights-mode standard \ 
    --engine aurora-postgresql \
    --db-cluster-identifier sample-db-identifier \
    --no-enable-performance-insights
```

For Windows:

```
aws rds create-db-cluster ^
    --database-insights-mode standard ^ 
    --engine aurora-postgresql ^
    --db-cluster-identifier sample-db-identifier ^
    --no-enable-performance-insights
```

------
#### [ RDS API ]

To turn on the Standard mode of Database Insights when you create a DB cluster, specify the following parameters for your [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API operation.
+ `DatabaseInsightsMode` to `standard`
+ `EnablePerformanceInsights` to `True` or `False`. If you set `EnablePerformanceInsights` to `True`, you must set `PerformanceInsightsRetentionPeriod` to at least 7 days.

------

## Turning on the Standard mode of Database Insights when modifying a DB cluster
<a name="USER_DatabaseInsights.TurnOnModifyDatabaseStandard"></a>

Turn on Standard mode of Database Insights when modifying a database for Amazon Aurora. Modifying a DB cluster to enable the Standard mode of Database Insights doesn't cause downtime.

**Note**  
To enable Database Insights, each DB instance in a DB cluster must have the same Performance Insights and Enhanced Monitoring settings.

------
#### [ Console ]

In the console, you can turn on the Standard mode of Database Insights when you modify a DB cluster. Settings for Database Insights apply to all DB instances in your DB cluster.

**To turn on the Standard mode of Database Insights when modifying a DB cluster using the console**

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. Choose **Databases**.

1. Choose a DB cluster, and choose **Modify**.

1. In the **Database Insights** section, select **Standard mode**. Then, choose from the following options:
   + To turn off Performance Insights, deselect **Enable Performance Insights**.
   + To turn on Performance Insights, select **Enable Performance Insights**. To configure Performance Insights, specify the following options:
     + **Retention** – The amount of time to retain Performance Insights data. The retention period must be at least 7 days.
     + **AWS KMS key** – Specify your KMS key. Performance Insights encrypts all potentially sensitive data using your KMS key. Data is encrypted in flight and at rest. For more information, see [Encrypting Amazon Aurora resources](Overview.Encryption.md).

1. Choose **Continue**.

1. For **Scheduling of Modifications**, choose **Apply immediately**. If you choose **Apply during the next scheduled maintenance window**, your database ignores this setting and turns on the Standard mode of Database Insights immediately.

1. Choose **Modify cluster**.

------
#### [ AWS CLI ]

To turn on the Standard mode of Database Insights when modifying a DB cluster, call the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI command and supply the following values:
+ `--database-insights-mode standard` to turn on the Standard mode of Database Insights.
+ `--db-cluster-identifier` – The identifier for the DB cluster.
+ `--enable-performance-insights` or `--no-enable-performance-insights` to turn Performance Insights on or off. If you specify `--enable-performance-insights`, you must also specify the `--performance-insights-retention-period` – The retention period for data for your DB cluster. The retention period must be at least 7 days.

The following example enables the Standard mode of Database Insights and enables Performance Insights when modifying a DB cluster.

For Linux, macOS, or Unix:

```
aws rds modify-db-cluster \
    --database-insights-mode standard \
    --db-cluster-identifier sample-db-identifier \
    --enable-performance-insights \
    --performance-insights-retention-period 7
```

For Windows:

```
aws rds modify-db-cluster ^
    --database-insights-mode standard ^
    --db-cluster-identifier sample-db-identifier ^
    --enable-performance-insights ^
    --performance-insights-retention-period 7
```

The following example enables the Standard mode of Database Insights and disables Performance Insights when modifying a DB cluster.

For Linux, macOS, or Unix:

```
aws rds modify-db-cluster \
    --database-insights-mode standard \
    --db-cluster-identifier sample-db-identifier \
    --no-enable-performance-insights
```

For Windows:

```
aws rds modify-db-cluster ^
    --database-insights-mode standard ^
    --db-cluster-identifier sample-db-identifier ^
    --no-enable-performance-insights
```

------
#### [ RDS API ]

To turn on the Standard mode of Database Insights when you modify a DB cluster, specify the following parameters for your [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) Amazon RDS API operation.
+ `DatabaseInsightsMode` to `standard`
+ `EnablePerformanceInsights` to `True` or `False`. If you set `EnablePerformanceInsights` to `True`, you must set `PerformanceInsightsRetentionPeriod` to at least 7 days.

------

# Configuring your database to monitor slow SQL queries with Database Insights for Amazon Aurora
<a name="USER_DatabaseInsights.SlowSQL"></a>

To monitor slow SQL queries for your database, you can use the **Slow SQL Queries** section in the Database Insights dashboard. Before configuring your database to monitor slow SQL queries, the **Slow SQL Queries** section is blank.

For more information about monitoring slow SQL queries in the Database Insights dashboard, see [Viewing the Database Instance Dashboard for CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) in the *Amazon CloudWatch User Guide*.

To configure your database to monitor slow SQL queries with Database Insights, complete the following steps:

1. Enable log exports to CloudWatch Logs.

1. Create or modify the DB cluster parameter group for your DB cluster.

For information about configuring log exports, see [Publishing database logs to Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.html#USER_LogAccess.Procedural.UploadtoCloudWatch) in the *Amazon Aurora User Guide*.

To create or modify your DB cluster parameter group, see the following topics.
+ [Creating a DB cluster parameter groupin Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md)
+ [Modifying parameters in a DB cluster parameter groupin Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md)

------
#### [ Amazon Aurora MySQL ]

To configure your Amazon Aurora MySQL DB cluster to monitor slow SQL queries, you can use the following parameter combination as an example:
+ `slow_query_log` – set to `1`
+ `long_query_time` – set to `1.0`
+ `log_output` – set to `FILE`

This is one possible configuration. For a comprehensive guide to MySQL slow query log parameters and additional configuration options, see the [MySQL documentation for the slow query log](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html).

------
#### [ Amazon Aurora PostgreSQL ]

To configure your Amazon Aurora PostgreSQL DB cluster to monitor slow SQL queries, you can use the following parameter combination as an example. Note that setting these parameters might reduce the performance of your DB cluster.
+ `log_min_duration_statement` – set to `1000`
+ `log_statement` – set to `none`
+ `log_destination` – set to `stderr`

This is one possible configuration. For a comprehensive guide to PostgreSQL logging parameters and additional configuration options, see the [PostgreSQL documentation for logging configuration](https://www.postgresql.org/docs/current/runtime-config-logging.html).

------

**Note**  
For Aurora MySQL, you can configure the parameter `long_query_time` with 1‐microsecond granularity. For example, you can set this parameter to `0.000001`. Depending on the amount of queries on the DB instance, the value of the parameter `long_query_time` can reduce performance. Start with the value `1.0`, and adjust it based on your workload. When you set this parameter to `0`, Database Insights logs all queries.

For information about Aurora MySQL and Aurora PostgreSQL logs, see the following.
+ [AuroraMySQL database log files](USER_LogAccess.Concepts.MySQL.md)
+ [Aurora PostgreSQL database log files](USER_LogAccess.Concepts.PostgreSQL.md)

# Considerations for Database Insights for Amazon Aurora
<a name="USER_DatabaseInsights.Considerations"></a>

Following are considerations for Database Insights for Amazon Aurora.
+ You can't manage Database Insights for a DB instance in a DB cluster.
+ To enable the Advanced mode of Database Insights, you must enable Performance Insights and set the Performance Insights retention period to at least 465 days (15 months). There is no additional cost to set the Performance Insights retention period to 15 months besides the cost of Database Insights. For information about pricing for Database Insights, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
+ To enable Database Insights, each DB instance in a DB cluster must have the same Performance Insights and Enhanced Monitoring settings.
+ Modifying a DB cluster to enable either mode of Database Insights doesn't cause downtime.

# Monitoring DB load with Performance Insights on Amazon Aurora
<a name="USER_PerfInsights"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

Performance Insights expands on existing  Amazon Aurora monitoring features to illustrate and help you analyze your cluster performance. With the Performance Insights dashboard, you can visualize the database load on your Amazon Aurora cluster load and filter the load by waits, SQL statements, hosts, or users. For information about using Performance Insights with Amazon DocumentDB, see *[Amazon DocumentDB Developer Guide](https://docs.aws.amazon.com/documentdb/latest/developerguide/performance-insights.html)*.

**Topics**
+ [Overview of Performance Insights on Amazon Aurora](USER_PerfInsights.Overview.md)
+ [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md)
+ [Overview of the Performance Schema for Performance Insights on Aurora MySQL](USER_PerfInsights.EnableMySQL.md)
+ [Configuring access policies for Performance Insights](USER_PerfInsights.access-control.md)
+ [Analyzing metrics with the Performance Insights dashboard](USER_PerfInsights.UsingDashboard.md)
+ [Viewing Performance Insights proactive recommendations](USER_PerfInsights.InsightsRecommendationViewDetails.md)
+ [Retrieving metrics with the Performance Insights API for Aurora](USER_PerfInsights.API.md)
+ [Logging Performance Insights calls using AWS CloudTrail](USER_PerfInsights.CloudTrail.md)
+ [Performance Insights API and interface VPC endpoints (AWS PrivateLink)](pi-vpc-interface-endpoints.md)

# Overview of Performance Insights on Amazon Aurora
<a name="USER_PerfInsights.Overview"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

By default, RDS enables Performance Insights in the console create wizard for all Amazon RDS engines. If you turn on Performance Insights at the DB cluster level, RDS enables Performance Insights for every DB instance in the cluster. If you have more than one database on a DB instance, Performance Insights aggregates performance data.

You can find an overview of Performance Insights for Amazon Aurora in the following video.

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


**Topics**
+ [Database load](USER_PerfInsights.Overview.ActiveSessions.md)
+ [Maximum CPU](USER_PerfInsights.Overview.MaxCPU.md)
+ [Amazon Aurora DB engine, Region, and instance class support for Performance Insights](USER_PerfInsights.Overview.Engines.md)
+ [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md)

# Database load
<a name="USER_PerfInsights.Overview.ActiveSessions"></a>

*Database load (DB load)* measures the level of session activity in your database. `DBLoad` is the key metric in Performance Insights, and Performance Insights collects DB load every second.

**Topics**
+ [Active sessions](#USER_PerfInsights.Overview.ActiveSessions.active-sessions)
+ [Average active sessions](#USER_PerfInsights.Overview.ActiveSessions.AAS)
+ [Average active executions](#USER_PerfInsights.Overview.ActiveSessions.AAE)
+ [Dimensions](#USER_PerfInsights.Overview.ActiveSessions.dimensions)

## Active sessions
<a name="USER_PerfInsights.Overview.ActiveSessions.active-sessions"></a>

A *database session* represents an application's dialogue with a relational database. An active session is a connection that has submitted work to the DB engine and is waiting for a response. 

A session is active when it's either running on CPU or waiting for a resource to become available so that it can proceed. For example, an active session might wait for a page (or block) to be read into memory, and then consume CPU while it reads data from the page. 

## Average active sessions
<a name="USER_PerfInsights.Overview.ActiveSessions.AAS"></a>

The *average active sessions (AAS)* is the unit for the `DBLoad` metric in Performance Insights. It measures how many sessions are concurrently active on the database.

Every second, Performance Insights samples the number of sessions concurrently running a query. For each active session, Performance Insights collects the following data:
+ SQL statement
+ Session state (running on CPU or waiting)
+ Host
+ User running the SQL

Performance Insights calculates the AAS by dividing the total number of sessions by the number of samples for a specific time period. For example, the following table shows 5 consecutive samples of a running query taken at 1-second intervals.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html)

In the preceding example, the DB load for the time interval was 2 AAS. This measurement means that, on average, 2 sessions were active at any given time during the interval when the 5 samples were taken.

## Average active executions
<a name="USER_PerfInsights.Overview.ActiveSessions.AAE"></a>

The average active executions (AAE) per second is related to AAS. To calculate the AAE, Performance Insights divides the total execution time of a query by the time interval. The following table shows the AAE calculation for the same query in the preceding table.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html)

In most cases, the AAS and AAE for a query are approximately the same. However, because the inputs to the calculations are different data sources, the calculations often vary slightly.

## Dimensions
<a name="USER_PerfInsights.Overview.ActiveSessions.dimensions"></a>

The `db.load` metric is different from the other time-series metrics because you can break it into subcomponents called dimensions. You can think of dimensions as "slice by" categories for the different characteristics of the `DBLoad` metric.

When you are diagnosing performance issues, the following dimensions are often the most useful:

**Topics**
+ [Wait events](#USER_PerfInsights.Overview.ActiveSessions.waits)
+ [Top SQL](#USER_PerfInsights.Overview.ActiveSessions.top-sql)

For a complete list of dimensions for the Aurora engines, see [DB load sliced by dimensions](USER_PerfInsights.UsingDashboard.Components.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.dims).

### Wait events
<a name="USER_PerfInsights.Overview.ActiveSessions.waits"></a>

A *wait event* causes a SQL statement to wait for a specific event to happen before it can continue running. Wait events are an important dimension, or category, for DB load because they indicate where work is impeded. 

Every active session is either running on the CPU or waiting. For example, sessions consume CPU when they search memory for a buffer, perform a calculation, or run procedural code. When sessions aren't consuming CPU, they might be waiting for a memory buffer to become free, a data file to be read, or a log to be written to. The more time that a session waits for resources, the less time it runs on the CPU. 

When you tune a database, you often try to find out the resources that sessions are waiting for. For example, two or three wait events might account for 90 percent of DB load. This measure means that, on average, active sessions are spending most of their time waiting for a small number of resources. If you can find out the cause of these waits, you can attempt a solution. 

Wait events vary by DB engine: 
+ For a list of the common wait events for Aurora MySQL, see [Aurora MySQL wait events](AuroraMySQL.Reference.Waitevents.md). To learn how to tune using these wait events, see [Tuning Aurora MySQL](AuroraMySQL.Managing.Tuning.md).
+ For information about all MySQL wait events, see [Wait Event Summary Tables](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-wait-summary-tables.html) in the MySQL documentation.
+ For a list of common wait events for Aurora PostgreSQL, see [Amazon Aurora PostgreSQL wait events](AuroraPostgreSQL.Reference.Waitevents.md). To learn how to tune using these wait events, see [Tuning with wait events for Aurora PostgreSQL](AuroraPostgreSQL.Tuning.md).
+ For information about all PostgreSQL wait events, see [The Statistics Collector > Wait Event tables](https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-TABLE) in the PostgreSQL documentation.

### Top SQL
<a name="USER_PerfInsights.Overview.ActiveSessions.top-sql"></a>

Where wait events show bottlenecks, top SQL shows which queries are contributing the most to DB load. For example, many queries might be currently running on the database, but a single query might consume 99 percent of the DB load. In this case, the high load might indicate a problem with the query.

By default, the Performance Insights console displays top SQL queries that are contributing to the database load. The console also shows relevant statistics for each statement. To diagnose performance problems for a specific statement, you can examine its execution plan.

# Maximum CPU
<a name="USER_PerfInsights.Overview.MaxCPU"></a>

In the dashboard, the **Database load** chart collects, aggregates, and displays session information. To see whether active sessions are exceeding the maximum CPU, look at their relationship to the **Max vCPU** line. Performance Insights determines the **Max vCPU** value by the number of vCPU (virtual CPU) cores for your DB instance. For Aurora Serverless v2, **Max vCPU** represents the estimated number of vCPUs.

One process can run on a vCPU at a time. If the number of processes exceeds the number of vCPUs, the processes start queuing. When queuing increases, database performance decreases. If the DB load is often above the **Max vCPU** line, and the primary wait state is CPU, the CPU is overloaded. In this case, you might want to throttle connections to the instance, tune any SQL queries with a high CPU load, or consider a larger instance class. High and consistent instances of any wait state indicate that there might be bottlenecks or resource contention issues to resolve. This can be true even if the DB load doesn't cross the **Max vCPU** line.

# Amazon Aurora DB engine, Region, and instance class support for Performance Insights
<a name="USER_PerfInsights.Overview.Engines"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

The following table provides Amazon Aurora DB engines that support Performance Insights.


| Amazon Aurora DB engine | Supported engine versions and Regions | Instance class restrictions | 
| --- | --- | --- | 
| Amazon Aurora MySQL-Compatible Edition | For more information on version and Region availability of Performance Insights with Aurora MySQL, see [Performance Insights with Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.amy). |  Performance Insights has the following engine class restrictions: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.Engines.html)  | 
|  Amazon Aurora PostgreSQL-Compatible Edition  |  For more information on version and Region availability of Performance Insights with Aurora PostgreSQL, see [Performance Insights with Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.apg). |  N/A  | 

## Amazon Aurora DB engine, Region, and instance class support for Performance Insights features
<a name="USER_PerfInsights.Overview.PIfeatureEngnRegSupport"></a>

The following table provides Amazon Aurora DB engines that support Performance Insights features.


| Feature | [Pricing tier](https://aws.amazon.com/rds/performance-insights/pricing/) |  [Supported regions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions)  |  Supported DB engines  |  [Supported instance classes](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html#Concepts.DBInstanceClass.Types)  | 
| --- | --- | --- | --- | --- | 
| [SQL statistics for Performance Insights](sql-statistics.md) | All | All |  All  | All | 
| [Analyzing database performance for a period of time](USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod.md) | Paid tier only |  All  |  All  |  All except db.serverless (Aurora Serverless v2)  | 
|  [Viewing Performance Insights proactive recommendations](USER_PerfInsights.InsightsRecommendationViewDetails.md) | Paid tier only | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.Engines.html)  |  All  |  All except db.serverless (Aurora Serverless v2)  | 

# Pricing and data retention for Performance Insights
<a name="USER_PerfInsights.Overview.cost"></a>

By default, Performance Insights includes 7 days of performance data history and 1 million API requests per month. You can also purchase longer retention periods. For complete pricing information, see [Performance Insights Pricing](https://aws.amazon.com/rds/performance-insights/pricing/).

In the RDS console, you can choose any of the following retention periods for your Performance Insights data:
+ **Default (7 days)**
+ ***n* months**, where ***n*** is a number from 1–24

![\[Choose a retention period for your Performance Insights data.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/pi-retention-periods.png)


To learn how to set a retention period using the AWS CLI, see [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md).

**Note**  
Stopping a DB cluster with Performance Insights enabled doesn't affect data retention. While a DB cluster is stopped, Performance Insights won't collect any data.

# Turning Performance Insights on and off for Aurora
<a name="USER_PerfInsights.Enabling"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

You can turn on Performance Insights for your DB cluster when you create it. If needed, you can turn it off later by modifying your  DB cluster from the console. Turning Performance Insights on and off doesn't cause downtime, a reboot, or a failover.

**Note**  
Performance Schema is an optional performance tool used by Aurora MySQL. If you turn Performance Schema on or off, you need to reboot. If you turn Performance Insights on or off, however, you don't need to reboot. For more information, see [Overview of the Performance Schema for Performance Insights on Aurora MySQL](USER_PerfInsights.EnableMySQL.md).

If you use Performance Insights with Aurora global databases, turn on Performance Insights individually for the databases in each AWS Region. For details, see [Monitoring an Amazon Aurora global database with Amazon RDS Performance Insights](aurora-global-database-monitoring.md#aurora-global-database-pi). 

The Performance Insights agent consumes limited CPU and memory on the DB host. When the DB load is high, the agent limits the performance impact by collecting data less frequently.

------
#### [ Console ]

In the console, you can turn Performance Insights on or off when you create a DB cluster. Enabling Performance Insights allows you to manage Performance Insights settings and options for your DB cluster. Cluster level settings apply to all DB instances in the cluster.

**Turning Performance Insights on or off when creating a DB cluster**

After creating a new DB cluster, Amazon RDS enables Performance Insights by default. To turn off Performance Insights for your DB cluster, choose the option **Database Insights – Standard** and deselect the option **Enable Performance Insights**.

 To create a DB cluster, follow the instructions for your DB engine in [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md). 

The following screenshot shows the **Performance Insights** section.

![\[Turn on Performance Insights during DB cluster creation with console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_cluster_enabling.png)


If you choose **Enable Performance Insights**, you have the following options:
+ **Retention** (for the Standard mode of Database Insights only) – The amount of time to retain Performance Insights data. The retention setting is **Default (7 days)**. To retain your performance data for longer, specify 1–24 months. For more information about retention periods, see [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md).
+ **AWS KMS key** – Specify your AWS KMS key. Performance Insights encrypts all potentially sensitive data using your KMS key. Data is encrypted in flight and at rest. For more information, see [Changing an AWS KMS policy for Performance Insights](USER_PerfInsights.access-control.cmk-policy.md).

**Turning Performance Insights on or off when modifying a DB cluster**

In the console, you can modify a DB cluster to manage Performance Insights. 

**To manage Performance Insights for a DB cluster using the console**

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. Choose **Databases**.

1. Choose a DB cluster, and choose **Modify**.

1. To turn on Performance Insights, select **Enable Performance Insights**. To turn off Performance Insights for your DB cluster, choose the option **Database Insights – Standard** and deselect the option **Enable Performance Insights**.

   If you choose **Enable Performance Insights**, you have the following options:
   + **Retention** (for the Standard mode of Database Insights only) – The amount of time to retain Performance Insights data. The retention setting is **Default (7 days)**. To retain your performance data for longer, specify 1–24 months. For more information about retention periods, see [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md).
   + **AWS KMS key** – Specify your KMS key. Performance Insights encrypts all potentially sensitive data using your KMS key. Data is encrypted in flight and at rest. For more information, see [Encrypting Amazon Aurora resources](Overview.Encryption.md).  
![\[Modify Performance Insights during DB cluster modifying with console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_cluster_modifying.png)

1. Choose **Continue**.

1. For **Scheduling of Modifications**, choose Apply immediately. If you choose Apply during the next scheduled maintenance window, your instance ignores this setting and turns on Performance Insights immediately.

1. Choose **Modify instance**.

------
#### [ AWS CLI ]

When you use the [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI command, turn on Performance Insights by specifying `--enable-performance-insights` and set `--database-insights-mode` to either `advanced` or `standard`. To turn off Performance Insights, specify `--no-enable-performance-insights` and set `database-insights-mode` to `standard`.

You can also specify these values using the following AWS CLI commands:
+  [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) 
+  [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 
+  [create-db-instance-read-replica](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html) 
+  [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 
+  [restore-db-instance-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html) 

**To manage Performance Insights for a DB cluster using the AWS CLI**
+ Call the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI command and supply the following values:
  + `--db-cluster-identifier` – The name of the DB instance in your DB cluster.
  + `--enable-performance-insights` to turn on or `--no-enable-performance-insights` to turn off
  + `database-insights-mode` – The mode of Database Insights for the DB cluster. To turn off Performance Insights, set this value to `standard`.

  The following example turns on Performance Insights for `sample-db-cluster`.

  For Linux, macOS, or Unix:

  ```
  aws rds modify-db-cluster \
  	--database-insights-mode standard \
      --db-cluster-identifier sample-db-instance \
      --enable-performance-insights
  ```

  For Windows:

  ```
  aws rds modify-db-cluster ^
  	--database-insights-mode standard ^
      --db-cluster-identifier sample-db-instance ^
      --enable-performance-insights
  ```

When you turn on Performance Insights in the CLI, you can optionally specify the number of days to retain Performance Insights data with the `--performance-insights-retention-period` option. You can specify `7`, *month* \$1 31 (where *month* is a number from 1–23), or `731`. For example, if you want to retain your performance data for 3 months, specify `93`, which is 3 \$1 31. The default is `7` days. For more information about retention periods, see [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md).

The following example turns on Performance Insights for `sample-db-cluster` and specifies that Performance Insights data is retained for 93 days (3 months).

For Linux, macOS, or Unix:

```
aws rds modify-db-cluster \
	--database-insights-mode standard \
    --db-cluster-identifier sample-db-instance \
    --enable-performance-insights \
    --performance-insights-retention-period 93
```

For Windows:

```
aws rds modify-db-cluster ^
	--database-insights-mode standard ^
    --db-cluster-identifier sample-db-instance ^
    --enable-performance-insights ^
    --performance-insights-retention-period 93
```

If you specify a retention period such as 94 days, which isn't a valid value, RDS issues an error.

```
An error occurred (InvalidParameterValue) when calling the CreateDBInstance operation: 
Invalid Performance Insights retention period. Valid values are: [7, 31, 62, 93, 124, 155, 186, 217, 
248, 279, 310, 341, 372, 403, 434, 465, 496, 527, 558, 589, 620, 651, 682, 713, 731]
```

**Note**  
You can only toggle Performance Insights for an instance in a DB cluster where Performance Insights is not managed at the cluster level.

------
#### [ RDS API ]

When you create a new DB instance in your DB cluster using the [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) operation Amazon RDS API operation, turn on Performance Insights by setting `EnablePerformanceInsights` to `True`. To turn off Performance Insights, set `EnablePerformanceInsights` to `False` and set `DatabaseInsightsMode` to `standard`.

You can also specify the `EnablePerformanceInsights` value using the following API operations:
+  [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) 
+  [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) 
+  [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) 
+  [CreateDBInstanceReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html) 
+  [RestoreDBInstanceFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html) 

When you turn on Performance Insights, you can optionally specify the amount of time, in days, to retain Performance Insights data with the `PerformanceInsightsRetentionPeriod` parameter. You can specify `7`, *month* \$1 31 (where *month* is a number from 1–23), or `731`. For example, if you want to retain your performance data for 3 months, specify `93`, which is 3 \$1 31. The default is `7` days. For more information about retention periods, see [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md).

------

# Overview of the Performance Schema for Performance Insights on Aurora MySQL
<a name="USER_PerfInsights.EnableMySQL"></a>

The Performance Schema is an optional feature for monitoring Aurora MySQL runtime performance at a low level of detail. The Performance Schema is designed to have minimal impact on database performance. Performance Insights is a separate feature that you can use with or without the Performance Schema.

**Topics**
+ [Overview of the Performance Schema](#USER_PerfInsights.EnableMySQL.overview)
+ [Performance Insights and the Performance Schema](#USER_PerfInsights.effect-of-pfs)
+ [Automatic management of the Performance Schema by Performance Insights](#USER_PerfInsights.EnableMySQL.options)
+ [Effect of a reboot on the Performance Schema](#USER_PerfInsights.EnableMySQL.reboot)
+ [Determining whether Performance Insights is managing the Performance Schema](USER_PerfInsights.EnableMySQL.determining-status.md)
+ [Turn on the Performance Schema for Aurora MySQL](USER_PerfInsights.EnableMySQL.RDS.md)

## Overview of the Performance Schema
<a name="USER_PerfInsights.EnableMySQL.overview"></a>

The Performance Schema monitors events in Aurora MySQL databases. An *event* is a database server action that consumes time and has been instrumented so that timing information can be collected. Examples of events include the following:
+ Function calls
+ Waits for the operating system
+ Stages of SQL execution
+ Groups of SQL statements

The `PERFORMANCE_SCHEMA` storage engine is a mechanism for implementing the Performance Schema feature. This engine collects event data using instrumentation in the database source code. The engine stores events in memory-only tables in the `performance_schema` database. You can query `performance_schema` just as you can query any other tables. For more information, see [MySQL Performance Schema](https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html) in the *MySQL Reference Manual*.

## Performance Insights and the Performance Schema
<a name="USER_PerfInsights.effect-of-pfs"></a>

Performance Insights and the Performance Schema are separate features, but they are connected. The behavior of Performance Insights for Aurora MySQL depends on whether the Performance Schema is turned on, and if so, whether Performance Insights manages the Performance Schema automatically. The following table describes the behavior.


| Performance Schema turned on | Performance Insights management mode | Performance Insights behavior | 
| --- | --- | --- | 
|  Yes  |  Automatic  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.EnableMySQL.html)  | 
|  Yes  |  Manual  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.EnableMySQL.html)  | 
|  No  |  N/A  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.EnableMySQL.html)  | 

## Automatic management of the Performance Schema by Performance Insights
<a name="USER_PerfInsights.EnableMySQL.options"></a>

When you create an Aurora MySQL DB instance with Performance Insights turned on, the Performance Schema is also turned on. In this case, Performance Insights automatically manages your Performance Schema parameters. This is the recommended configuration.

When Performance Insights manages the Performance Schema automatically, the **Source** of `performance_schema` is `System default`.

**Note**  
Automatic management of the Performance Schema isn't supported for the t4g.medium instance class.

You can also manage the Performance Schema manually. If you choose this option, set the parameters according to the values in the following table.


| Parameter name | Parameter value | 
| --- | --- | 
|  `performance_schema`  |  `1` (**Source** column has the value `Modified`)  | 
|  `performance-schema-consumer-events-waits-current`  |  `ON`  | 
|  `performance-schema-instrument`  |  `wait/%=ON`  | 
|  `performance_schema_consumer_global_instrumentation`  |  `1`  | 
|  `performance_schema_consumer_thread_instrumentation`  |  `1`  | 

If you change the `performance_schema` parameter value manually, and then later want to change to automatic management, see [Turn on the Performance Schema for Aurora MySQL](USER_PerfInsights.EnableMySQL.RDS.md).

**Important**  
When Performance Insights turns on the Performance Schema, it doesn't change the parameter group values. However, the values are changed on the DB instances that are running. The only way to see the changed values is to run the `SHOW GLOBAL VARIABLES` command.

## Effect of a reboot on the Performance Schema
<a name="USER_PerfInsights.EnableMySQL.reboot"></a>

Performance Insights and the Performance Schema differ in their requirements for DB instance reboots:

**Performance Schema**  
To turn this feature on or off, you must reboot the DB instance.

**Performance Insights**  
To turn this feature on or off, you don't need to reboot the DB instance.

If the Performance Schema isn't currently turned on, and you turn on Performance Insights without rebooting the DB instance, the Performance Schema won't be turned on.

# Determining whether Performance Insights is managing the Performance Schema
<a name="USER_PerfInsights.EnableMySQL.determining-status"></a>

To find out whether Performance Insights is currently managing the Performance Schema for all supported major engine versions, review the following table.


| Setting of performance\$1schema parameter | Setting of the Source column | Performance Insights is managing the Performance Schema? | 
| --- | --- | --- | 
| 0 | System default | Yes | 
| 0 or 1 | Modified | No | 

In the following procedure, you determine whether Performance Insights is managing the Performance Schema automatically.

**To determine whether Performance Insights is managing the Performance Schema automatically**

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. Choose **Parameter groups**.

1. Select the name of the parameter group for your DB instance.

1. Enter **performance\$1schema** in the search bar.

1. Check whether **Source** is the system default and **Value** is **0**. If so, Performance Insights is managing the Performance Schema automatically.

   In the example shown here, Performance Insights isn't managing the Performance Schema automatically.  
![\[Shows that the settings for the performance_schema parameter are modified.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_schema_user.png)

# Turn on the Performance Schema for Aurora MySQL
<a name="USER_PerfInsights.EnableMySQL.RDS"></a>

Assume that Performance Insights is turned on for your DB instance but isn't currently managing the Performance Schema. If you want to allow Performance Insights to manage the Performance Schema automatically, complete the following steps.

**To configure the Performance Schema for automatic management**

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. Choose **Parameter groups**.

1. Select the name of the parameter group for your DB instance.

1. Choose **Edit**.

1. Enter **performance\$1schema** in the search bar.

1. Select the `performance_schema` parameter.

1. Choose **Set to default value**.

1. Confirm by choosing **Set values to default**.

1. Choose **Save Changes**.

1. Reboot the DB instance.
**Important**  
Whenever you turn the Performance Schema on or off, make sure to reboot the DB instance.

For more information about modifying instance parameters, see [Modifying parameters in a DB parameter group in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). For more information about the dashboard, see [Analyzing metrics with the Performance Insights dashboard](USER_PerfInsights.UsingDashboard.md). For more information about the MySQL performance schema, see [MySQL Performance Schema](https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html) (for 8.0) and [MySQL Performance Schema](https://dev.mysql.com/doc/refman/8.4/en/performance-schema.html) (for 8.4) in the MySQL documentation.

# Configuring access policies for Performance Insights
<a name="USER_PerfInsights.access-control"></a>

To access Performance Insights, a principal must have the appropriate permissions from AWS Identity and Access Management (IAM).

**Note**  
To use Performance Insights with a customer-managed key, grant users the `kms:Decrypt` and `kms:GenerateDataKey` permissions for your AWS AWS KMS key.

Access Performance Insights using these methods:
+ [Attach the `AmazonRDSPerformanceInsightsReadOnly` managed policy for read-only access](USER_PerfInsights.access-control.managed-policy.md)
+ [Attach the `AmazonRDSPerformanceInsightsFullAccess` managed policy for access to all operations of the Performance Insights API](USER_PerfInsights.access-control.FullAccess-managed-policy.md)
+ [Create a custom IAM policy with specific permissions](USER_PerfInsights.access-control.custom-policy.md)
+ [Configure AWS KMS permissions for encrypted Performance Insights data](USER_PerfInsights.access-control.cmk-policy.md)
+ [Set up fine-grained access using resource-level permissions](USER_PerfInsights.access-control.dimensionAccess-policy.md)
+ [Use tag-based access control to manage permissions through resource tags](USER_PerfInsights.access-control.tag-based-policy.md)

# Attaching the AmazonRDSPerformanceInsightsReadOnly policy to an IAM principal
<a name="USER_PerfInsights.access-control.managed-policy"></a>

`AmazonRDSPerformanceInsightsReadOnly` is an AWS managed policy that grants access to all read-only operations of the Amazon RDS Performance Insights API. 

If you attach `AmazonRDSPerformanceInsightsReadOnly` to a permission set or role, you must also attach the following CloudWatch permissions:
+ `GetMetricStatistics`
+ `ListMetrics`
+ `GetMetricData`

With these permissions, the recipient can use Performance Insights with other console features.

 For more information about CloudWatch permissions, see [Amazon CloudWatch permissions reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/permissions-reference-cw.html).

For more information about `AmazonRDSPerformanceInsightsReadOnly`, see [AWS managed policy: AmazonRDSPerformanceInsightsReadOnly](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly).

# Attaching the AmazonRDSPerformanceInsightsFullAccess policy to an IAM principal
<a name="USER_PerfInsights.access-control.FullAccess-managed-policy"></a>

`AmazonRDSPerformanceInsightsFullAccess` is an AWS managed policy that grants access to all operations of the Amazon RDS Performance Insights API.

If you attach `AmazonRDSPerformanceInsightsFullAccess` to a permission set or role, you must also attach the following CloudWatch permissions:
+ `GetMetricStatistics`
+ `ListMetrics`
+ `GetMetricData`

With these permissions, the recipient can use Performance Insights with other console features.

 For more information about CloudWatch permissions, see [Amazon CloudWatch permissions reference](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/permissions-reference-cw.html).

For more information about `AmazonRDSPerformanceInsightsFullAccess`, see [AWS managed policy: AmazonRDSPerformanceInsightsFullAccess](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess).

# Creating a custom IAM policy for Performance Insights
<a name="USER_PerfInsights.access-control.custom-policy"></a>

For users who don't have either the `AmazonRDSPerformanceInsightsReadOnly` or `AmazonRDSPerformanceInsightsFullAccess` policy, you can grant access to Performance Insights by creating or modifying a user-managed IAM policy. When you attach the policy to an IAM permission set or role, the recipient can use Performance Insights.

**To create a custom policy**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Policies**.

1. Choose **Create policy**.

1. On the **Create Policy** page, choose the **JSON** option.

1. Copy and paste the text provided in the *JSON policy document* section in the *AWS Managed Policy Reference Guide* for [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsReadOnly.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsReadOnly.html) or [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsFullAccess.html) policy.

1. Choose **Review policy**.

1. Provide a name for the policy and optionally a description, and then choose **Create policy**.

You can now attach the policy to a permission set or role. The following procedure assumes that you already have a user available for this purpose.

**To attach the policy to a user**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Choose an existing user from the list.
**Important**  
To use Performance Insights, make sure that you have access to Amazon RDS in addition to the custom policy. For example, the `AmazonRDSPerformanceInsightsReadOnly` predefined policy provides read-only access to Amazon RDS. For more information, see [Managing access using policies](UsingWithRDS.IAM.md#security_iam_access-manage).

1. On the **Summary** page, choose **Add permissions**.

1. Choose **Attach existing policies directly**. For **Search**, type the first few characters of your policy name, as shown in the following image.   
![\[Choose a Policy\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_attach_iam_policy.png)

1. Choose your policy, and then choose **Next: Review**.

1. Choose **Add permissions**.

# Changing an AWS KMS policy for Performance Insights
<a name="USER_PerfInsights.access-control.cmk-policy"></a>

Performance Insights uses an AWS KMS key to encrypt sensitive data. When you enable Performance Insights through the API or the console, you can do either of the following:
+ Choose the default AWS managed key.

  Amazon RDS uses the AWS managed key for your new DB instance. Amazon RDS creates an AWS managed key for your AWS account. Your AWS account has a different AWS managed key for Amazon RDS for each AWS Region.
+ Choose a customer managed key.

  If you specify a customer managed key, users in your account that call the Performance Insights API need the `kms:Decrypt` and `kms:GenerateDataKey` permissions on the KMS key. You can configure these permissions through IAM policies. However, we recommend that you manage these permissions through your KMS key policy. For more information, see [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) in the *AWS Key Management Service Developer Guide*. 

**Example**  
The following example shows how to add statements to your KMS key policy. These statements allow access to Performance Insights. Depending on how you use the KMS key, you might want to change some restrictions. Before adding statements to your policy, remove all comments.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id" : "your-policy",
    "Statement" : [ 
        {
            "Sid" : "AllowViewingRDSPerformanceInsights",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::444455556666:role/Role1"
                ]
                },
             "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey"
                ],
            "Resource": "*",
            "Condition" : {
            "StringEquals" : {
                "kms:ViaService" : "rds.us-east-1.amazonaws.com"
                },
            "ForAnyValue:StringEquals": {
                "kms:EncryptionContext:aws:pi:service": "rds",
                "kms:EncryptionContext:service": "pi",
                "kms:EncryptionContext:aws:rds:db-id": "db-AAAAABBBBBCCCCDDDDDEEEEE"
                }
            }
        }
    ]
}
```

## How Performance Insights uses AWS KMS customer managed key
<a name="USER_PerfInsights.access-control.PI-using-KMS-cmk-policy"></a>

Performance Insights uses customer managed keys to encrypt sensitive data. When you turn on Performance Insights, you can provide an AWS KMS key through the API. Performance Insights creates AWS KMS permissions on this key. It uses the key and performs the necessary operations to process sensitive data. Sensitive data includes fields such as user, database, application, and SQL query text. Performance Insights ensures that the data remains encrypted both at rest and in-flight.

## How Performance Insights IAM works with AWS KMS
<a name="USER_PerfInsights.access-control.PI-work-with-kms"></a>

IAM gives permissions to specific APIs. Performance Insights has the following public APIs, which you can restrict using IAM policies:
+ `DescribeDimensionKeys`
+ `GetDimensionKeyDetails`
+ `GetResourceMetadata`
+ `GetResourceMetrics`
+ `ListAvailableResourceDimensions`
+ `ListAvailableResourceMetrics`

You can use the following API requests to get sensitive data.
+ `DescribeDimensionKeys`
+ `GetDimensionKeyDetails`
+ `GetResourceMetrics`

When you use the API to get sensitive data, Performance Insights leverages the caller's credentials. This check ensures that access to sensitive data is limited to those with access to the KMS key.

When calling these APIs, you need permissions to call the API through the IAM policy and permissions to invoke the `kms:decrypt` action through the AWS KMS key policy.

The `GetResourceMetrics` API can return both sensitive and non-sensitive data. The request parameters determine whether the response should include sensitive data. The API returns sensitive data when the request includes a sensitive dimension in either the filter or group-by parameters. 

For more information about the dimensions that you can use with the `GetResourceMetrics` API, see [DimensionGroup](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DimensionGroup.html).

**Examples**  
The following example requests the sensitive data for the `db.user` group:  

```
POST / HTTP/1.1
Host: <Hostname>
Accept-Encoding: identity
X-Amz-Target: PerformanceInsightsv20180227.GetResourceMetrics
Content-Type: application/x-amz-json-1.1
User-Agent: <UserAgentString>
X-Amz-Date: <Date> 
Authorization: AWS4-HMAC-SHA256 Credential=<Credential>, SignedHeaders=<Headers>, Signature=<Signature>
Content-Length: <PayloadSizeBytes>
{
  "ServiceType": "RDS",
  "Identifier": "db-ABC1DEFGHIJKL2MNOPQRSTUV3W",
  "MetricQueries": [
    {
      "Metric": "db.load.avg",
      "GroupBy": {
        "Group": "db.user",
        "Limit": 2
      }
    }
  ],
  "StartTime": 1693872000,
  "EndTime": 1694044800,
  "PeriodInSeconds": 86400
}
```

**Example**  
The following example requests the non-sensitive data for the `db.load.avg` metric:  

```
POST / HTTP/1.1
Host: <Hostname>
Accept-Encoding: identity
X-Amz-Target: PerformanceInsightsv20180227.GetResourceMetrics
Content-Type: application/x-amz-json-1.1
User-Agent: <UserAgentString>
X-Amz-Date: <Date> 
Authorization: AWS4-HMAC-SHA256 Credential=<Credential>, SignedHeaders=<Headers>, Signature=<Signature>
Content-Length: <PayloadSizeBytes>
{
    "ServiceType": "RDS",
    "Identifier": "db-ABC1DEFGHIJKL2MNOPQRSTUV3W",
    "MetricQueries": [
        {
            "Metric": "db.load.avg"
        }
    ],
    "StartTime": 1693872000,
    "EndTime": 1694044800,
    "PeriodInSeconds": 86400
}
```

# Granting fine-grained access for Performance Insights
<a name="USER_PerfInsights.access-control.dimensionAccess-policy"></a>

Fine-grained access control offers additional ways of controlling access to Performance Insights. This access control can allow or deny access to individual dimensions for `GetResourceMetrics`, `DescribeDimensionKeys`, and `GetDimensionKeyDetails` Performance Insights actions. To use fine-grained access, specify dimensions in the IAM policy by using condition keys. The evaluation of the access follows the IAM policy evaluation logic. For more information, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*. If the IAM policy statement doesn't specify any dimension, then the statement controls access to all the dimensions for the specified action. For the list of available dimensions, see [https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DimensionGroup.html](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DimensionGroup.html).

To find out the dimensions that your credentials are authorized to access, use the `AuthorizedActions` parameter in `ListAvailableResourceDimensions` and specify the action. The allowed values for `AuthorizedActions` are as follows:
+ `GetResourceMetrics`
+ `DescribeDimensionKeys`
+ `GetDimensionKeyDetails`

For example, if you specify `GetResourceMetrics` to the `AuthorizedActions` parameter, `ListAvailableResourceDimensions` returns the list of dimensions that the `GetResourceMetrics` action is authorized to access. If you specify multiple actions in the `AuthorizedActions` parameter, then `ListAvailableResourceDimensions` returns an intersection of dimensions that those actions are authorized to access.

**Example**  
The following example provides access to the specified dimensions for `GetResourceMetrics` and `DescribeDimensionKeys` actions.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowToDiscoverDimensions",
            "Effect": "Allow",
            "Action": [
                "pi:ListAvailableResourceDimensions"
            ],
            "Resource": [
                "arn:aws:pi:us-east-1:123456789012:metrics/rds/db-ABC1DEFGHIJKL2MNOPQRSTUV3W"
            ]
        },
        {
            "Sid": "SingleAllow",
            "Effect": "Allow",
            "Action": [
                "pi:GetResourceMetrics",
                "pi:DescribeDimensionKeys"
            ],
            "Resource": [
                "arn:aws:pi:us-east-1:123456789012:metrics/rds/db-ABC1DEFGHIJKL2MNOPQRSTUV3W"
            ],
            "Condition": {
                "ForAllValues:StringEquals": {
                    "pi:Dimensions": [
                        "db.sql_tokenized.id",
                        "db.sql_tokenized.statement"
                    ]
                }
            }
        }
        

    ]
}
```
The following is the response for the requested dimension:  

```
	// ListAvailableResourceDimensions API
// Request
{
    "ServiceType": "RDS",
    "Identifier": "db-ABC1DEFGHIJKL2MNOPQRSTUV3W",
    "Metrics": [ "db.load" ],
    "AuthorizedActions": ["DescribeDimensionKeys"]
}

// Response
{    
    "MetricDimensions": [ {
        "Metric": "db.load",
        "Groups": [
            {
                "Group": "db.sql_tokenized",
                "Dimensions": [
                    { "Identifier": "db.sql_tokenized.id" },
                  //  { "Identifier": "db.sql_tokenized.db_id" }, // not included because not allows in the IAM Policy
                    { "Identifier": "db.sql_tokenized.statement" }
                ] 
            }
            
        ] }
    ]
}
```
The following example specifies one allow and two deny access for the dimensions.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
          {
            "Sid": "AllowToDiscoverDimensions",
            "Effect": "Allow",
            "Action": [
                "pi:ListAvailableResourceDimensions"
            ],
            "Resource": [
                "arn:aws:pi:us-east-1:123456789012:metrics/rds/db-ABC1DEFGHIJKL2MNOPQRSTUV3W"
            ]
          },

          {
            "Sid": "O01AllowAllWithoutSpecifyingDimensions",
            "Effect": "Allow",
            "Action": [
                "pi:GetResourceMetrics",
                "pi:DescribeDimensionKeys"
            ],
            "Resource": [
                "arn:aws:pi:us-east-1:123456789012:metrics/rds/db-ABC1DEFGHIJKL2MNOPQRSTUV3W"
            ]
        },
        
        {
            "Sid": "O01DenyAppDimensionForAll",
            "Effect": "Deny",
            "Action": [
                "pi:GetResourceMetrics",
                "pi:DescribeDimensionKeys"
            ],
            "Resource": [
                "arn:aws:pi:us-east-1:123456789012:metrics/rds/db-ABC1DEFGHIJKL2MNOPQRSTUV3W"
            ],
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "pi:Dimensions": [
                        "db.application.name"
                    ]
                }
            }
        },
        
        {
            "Sid": "O01DenySQLForGetResourceMetrics",
            "Effect": "Deny",
            "Action": [
                "pi:GetResourceMetrics"
            ],
            "Resource": [
                "arn:aws:pi:us-east-1:123456789012:metrics/rds/db-ABC1DEFGHIJKL2MNOPQRSTUV3W"
            ],
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "pi:Dimensions": [
                        "db.sql_tokenized.statement"
                    ]
                }
            }
        }
    ]
}
```
The following are the responses for the requested dimensions:  

```
			// ListAvailableResourceDimensions API
// Request
{
    "ServiceType": "RDS",
    "Identifier": "db-ABC1DEFGHIJKL2MNOPQRSTUV3W",
    "Metrics": [ "db.load" ],
    "AuthorizedActions": ["GetResourceMetrics"]
}

// Response
{    
    "MetricDimensions": [ {
        "Metric": "db.load",
        "Groups": [
            {
                "Group": "db.application",
                "Dimensions": [
                
                  // removed from response because denied by the IAM Policy
                  //  { "Identifier": "db.application.name" }  
                ]
            },
            {
                "Group": "db.sql_tokenized",
                "Dimensions": [
                    { "Identifier": "db.sql_tokenized.id" },
                    { "Identifier": "db.sql_tokenized.db_id" },
                    
                  // removed from response because denied by the IAM Policy
                  //  { "Identifier": "db.sql_tokenized.statement" }
                ] 
            },
            ...
        ] }
    ]
}
```

```
// ListAvailableResourceDimensions API
// Request
{
    "ServiceType": "RDS",
    "Identifier": "db-ABC1DEFGHIJKL2MNOPQRSTUV3W",
    "Metrics": [ "db.load" ],
    "AuthorizedActions": ["DescribeDimensionKeys"]
}

// Response
{    
    "MetricDimensions": [ {
        "Metric": "db.load",
        "Groups": [
            {
                "Group": "db.application",
                "Dimensions": [
                  // removed from response because denied by the IAM Policy
                  //  { "Identifier": "db.application.name" }  
                ]
            },
            {
                "Group": "db.sql_tokenized",
                "Dimensions": [
                    { "Identifier": "db.sql_tokenized.id" },
                    { "Identifier": "db.sql_tokenized.db_id" },
                    
                  // allowed for DescribeDimensionKeys because our IAM Policy 
                  // denies it only for GetResourceMetrics
                    { "Identifier": "db.sql_tokenized.statement" }
                ] 
            },
            ...
        ] }
    ]
}
```

# Using tag-based access control for Performance Insights
<a name="USER_PerfInsights.access-control.tag-based-policy"></a>

You can control access to Performance Insights metrics using tags inherited from the parent DB instance. To control access to Performance Insights operations, use IAM policies. These policies can check the tags on your DB instance to determine permissions.

## How tags work with Performance Insights
<a name="USER_PerfInsights.access-control.tag-inheritance"></a>

Performance Insights automatically applies your DB instance tags to authorize Performance Insights metrics. When you add tags to your DB instance, you can immediately use those tags to control access to Performance Insights data.
+ To add or update tags for Performance Insights metrics, modify the tags on your DB instance.
+ To view tags for Performance Insights metrics, call `ListTagsForResource` on the Performance Insights metric resource. It will return the tags from the DB instance associated with the metric.

**Note**  
The `TagResource` and `UntagResource` operations return an error if you try to use them directly on Performance Insights metrics.

## Creating tag-based IAM policies
<a name="USER_PerfInsights.access-control.tag-based-policies"></a>

To control access to Performance Insights operations, use the `aws:ResourceTag` condition key in your IAM policies. These policies check the tags on yourDB instance.

**Example**  
This policy prevents access to Performance Insights metrics for production databases. The policy denies the `pi:GetResourceMetrics` operation in Performance Insights for any database resource tagged with `env:prod`.   

```
 {
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "pi:GetResourceMetrics",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/env": "prod"
                }
            }
        }
    ]
}
```

# Analyzing metrics with the Performance Insights dashboard
<a name="USER_PerfInsights.UsingDashboard"></a>

**Important**  
 AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights.   
 We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).   
 If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis.   
 With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). 

The Performance Insights dashboard contains database performance information to help you analyze and troubleshoot performance issues. On the main dashboard page, you can view information about the database load. You can "slice" DB load by dimensions such as wait events or SQL.

**Topics**
+ [Overview of the Performance Insights dashboard](USER_PerfInsights.UsingDashboard.Components.md)
+ [Accessing the Performance Insights dashboard](USER_PerfInsights.UsingDashboard.Opening.md)
+ [Analyzing DB load by wait events](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.md)
+ [Analyzing database performance for a period of time](USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod.md)
+ [Analyzing queries with the Top SQL tab in Performance Insights](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md)

# Overview of the Performance Insights dashboard
<a name="USER_PerfInsights.UsingDashboard.Components"></a>

The dashboard is the easiest way to interact with Performance Insights. The following example shows the dashboard for a PostgreSQL DB instance.

![\[Enable Performance Insights during DB instance creation with console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora_perf_insights_enabling.png)


**Topics**
+ [Time range filter](#USER_PerfInsights.UsingDashboard.Components.time-range)
+ [Counter metrics chart](#USER_PerfInsights.UsingDashboard.Components.Countermetrics)
+ [Database load chart](#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions)
+ [Top dimensions table](#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable)

## Time range filter
<a name="USER_PerfInsights.UsingDashboard.Components.time-range"></a>

By default, the Performance Insights dashboard shows DB load for the last hour. You can adjust this range to be as short as 5 minutes or as long as 2 years. You can also select a custom relative range.

You can select an absolute range with a beginning and ending date and time. The following example shows the time range beginning at midnight on 9/25/24 and ending at 11:59 PM on 9/28/24.

By default, the time zone for the Performance Insights dashboard is Coordinated Universal Time (UTC). You can also choose the local time zone.

## Counter metrics chart
<a name="USER_PerfInsights.UsingDashboard.Components.Countermetrics"></a>

With counter metrics, you can customize the Performance Insights dashboard to include up to 10 additional graphs. These graphs show a selection of dozens of operating system and database performance metrics. You can correlate this information with DB load to help identify and analyze performance problems.

 The **Counter metrics** chart displays data for performance counters. The default metrics depend on the DB engine:
+ Aurora MySQL– `db.SQL.Innodb_rows_read.avg`
+ Aurora PostgreSQL – `db.Transactions.xact_commit.avg`

![\[Counter metrics\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/oracle_perf_insights_counters.png)


To change the performance counters, choose **Manage Metrics**. You can select multiple **OS metrics** or **Database metrics**, as shown in the following screenshot. To see details for any metric, hover over the metric name.

![\[Filter metrics\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_select_metrics.png)


For descriptions of the counter metrics that you can add for each DB engine, see [Performance Insights counter metrics](USER_PerfInsights_Counters.md).

## Database load chart
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions"></a>

The **Database load** chart shows how the database activity compares to DB instance capacity as represented by the **Max vCPU** line. By default, the stacked line chart represents DB load as average active sessions per unit of time. The DB load is sliced (grouped) by wait states. 

![\[Database load\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_2.png)


### DB load sliced by dimensions
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.dims"></a>

You can choose to display load as active sessions grouped by any supported dimensions. The following table shows which dimensions are supported for the different engines.


| Dimension | Aurora PostgreSQL | Aurora MySQL | 
| --- | --- | --- | 
|  Host  |  Yes  |  Yes  | 
|  SQL  |  Yes  |  Yes  | 
|  User  |  Yes  |  Yes  | 
|  Waits  |  Yes  |  Yes  | 
|  Application  |  Yes  |  No  | 
|  Database  |  Yes  |  Yes  | 
|  Session type  |  Yes  |  No  | 

The following image shows the dimensions for a PostgreSQL DB instance.

![\[Filter metrics\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_2b.png)


### DB load details for a dimension item
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.item-details"></a>

To see details about a DB load item within a dimension, hover over the item name. The following image shows details for a SQL statement.

![\[Database load item details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_2c.png)


To see details for any item for the selected time period in the legend, hover over that item.

![\[Time period details for DB load\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_3.png)


## Top dimensions table
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable"></a>

The Top dimensions table slices DB load by different dimensions. A dimension is a category or "slice by" for different characteristics of DB load. If the dimension is SQL, **Top SQL** shows the SQL statements that contribute the most to DB load.

![\[Top N dimensions\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_4c.png)


Choose any of the following dimension tabs.


| Tab | Description | Supported engines | 
| --- | --- | --- | 
|  Top SQL  |  The SQL statements that are currently running  |  All  | 
|  Top waits  |  The event for which the database backend is waiting  |  All  | 
|  Top hosts  |  The host name of the connected client  |  All  | 
|  Top users  |  The user logged in to the database  |  All  | 
|  Top applications  |  The name of the application that is connected to the database  |  Aurora PostgreSQL only  | 
|  Top session types  |  The type of the current session  | Aurora PostgreSQL only | 

To learn how to analyze queries by using the **Top SQL** tab, see [Overview of the Top SQL tab](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL).

# Accessing the Performance Insights dashboard
<a name="USER_PerfInsights.UsingDashboard.Opening"></a>

Amazon RDS provides a consolidated view of Performance Insights and CloudWatch metrics in the Performance Insights dashboard.

To access the Performance Insights dashboard, use the following procedure.

**To view the Performance Insights dashboard in the AWS Management Console**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the left navigation pane, choose **Performance Insights**.

1. Choose a DB instance.

   For DB instances with Performance Insights turned on, you can also access the Performance Insights dashboard by choosing the **Sessions** item in the list of DB instances. Under **Current activity**, the **Sessions** item shows the database load in average active sessions over the last five minutes. The bar graphically shows the load. When the bar is empty, the DB instance is idle. As the load increases, the bar fills with blue. When the load passes the number of virtual CPUs (vCPUs) on the DB instance class, the bar turns red, indicating a potential bottleneck.  
![\[Filter metrics\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_0a.png)

1. (Optional) Choose the date or time range in the upper right and specify a different relative or absolute time interval. You can now specify a time period, and generate a database performance analysis report. The report provides the identified insights and recommendations. For more information, see [Creating a performance analysis report in Performance Insights](USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod.md).  
![\[Filter metrics by time interval\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_0c.png)

   In the following screenshot, the DB load interval is 5 hours.  
![\[Set time interval to 5 hours\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_1.png)

1. (Optional) To zoom in on a portion of the DB load chart, choose the start time and drag to the end of the time period you want. 

   The selected area is highlighted in the DB load chart.  
![\[DB load for a specified time interval\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_zoom_in.png)

   When you release the mouse, the DB load chart zooms in on the selected AWS Region, and the **Top *dimensions*** table is recalculated.  
![\[Zoom in on the selected DB load\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_zoom_in_b.png)

1. (Optional) To refresh your data automatically, select **Auto refresh**.  
![\[Set automatic refresh\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_1b.png)

   The Performance Insights dashboard automatically refreshes with new data. The refresh rate depends on the amount of data displayed: 
   + 5 minutes refreshes every 10 seconds.
   + 1 hour refreshes every 5 minutes.
   + 5 hours refreshes every 5 minutes.
   + 24 hours refreshes every 30 minutes.
   + 1 week refreshes every day.
   + 1 month refreshes every day.

# Analyzing DB load by wait events
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad"></a>

If the **Database load** chart shows a bottleneck, you can find out where the load is coming from. To do so, look at the top load items table below the **Database load** chart. Choose a particular item, like a SQL query or a user, to drill down into that item and see details about it.

DB load grouped by waits and top SQL queries is the default Performance Insights dashboard view. This combination typically provides the most insight into performance issues. DB load grouped by waits shows if there are any resource or concurrency bottlenecks in the database. In this case, the **SQL** tab of the top load items table shows which queries are driving that load.

Your typical workflow for diagnosing performance issues is as follows:

1. Review the **Database load** chart and see if there are any incidents of database load exceeding the **Max CPU** line.

1. If there is, look at the **Database load** chart and identify which wait state or states are primarily responsible.

1. Identify the digest queries causing the load by seeing which of the queries the **SQL** tab on the top load items table are contributing most to those wait states. You can identify these by the **DB Load by Wait** column.

1. Choose one of these digest queries in the **SQL** tab to expand it and see the child queries that it is composed of.

For example, in the dashboard following, **log file sync** waits account for most of the DB load. The **LGWR all worker groups** wait is also high. The **Top SQL** chart shows what is causing the **log file sync** waits: frequent `COMMIT` statements. In this case, committing less frequently will reduce DB load.

![\[log file sync errors\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_7.png)


# Analyzing database performance for a period of time
<a name="USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod"></a>

Analyze database performance with on-demand analysis by creating a performance analysis report for a period of time. View performance analysis reports to find performance issues, such as resource bottlenecks or changes in a query in your DB instance. The Performance Insights dashboard allows you to select a time period and create a performance analysis report. You can also add one or more tags to the report. 

To use this feature, you must be using the paid tier retention period. For more information, see [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md)

The report is available in the **Performance analysis reports - new** tab to select and view. The report contains the insights, related metrics, and recommendations to resolve the performance issue. The report is available to view for the duration of Performance Insights retention period.

The report is deleted if the start time of the report analysis period is outside of the retention period. You can also delete the report before the retention period ends.

To detect the performance issues and generate the analysis report for your DB instance, you must turn on Performance Insights. For more information about turning on Performance Insights, see [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md). 

For the region, DB engine, and instance class support information for this feature, see [ Amazon Aurora DB engine, Region, and instance class support for Performance Insights features](USER_PerfInsights.Overview.Engines.md#USER_PerfInsights.Overview.PIfeatureEngnRegSupport)

In the following sections, you can create, view, add tags, and delete a performance analysis report.

**Topics**
+ [Creating a performance analysis report in Performance Insights](USER_PerfInsights.UsingDashboard.CreatingPerfAnlysisReport.md)
+ [Viewing a performance analysis report in Performance Insights](USER_PerfInsights.UsingDashboard.ViewPerfAnalysisReport.md)
+ [Adding tags to a performance analysis report in Performance Insights](USER_PerfInsights.UsingDashboard.ManagePerfAnalysisReportTags.md)
+ [Deleting a performance analysis report in Performance Insights](USER_PerfInsights.UsingDashboard.DeletePerfAnalysisReport.md)

# Creating a performance analysis report in Performance Insights
<a name="USER_PerfInsights.UsingDashboard.CreatingPerfAnlysisReport"></a>

You can create a performance analysis report for a specific period in the Performance Insights dashboard. You can select a time period and add one or more tags to the analysis report.

The analysis period can range from 5 minutes to 6 days. There must be at least 24 hours of performance data before the analysis start time.

For the region, DB engine, and instance class support information for this feature, see [ Amazon Aurora DB engine, Region, and instance class support for Performance Insights features](USER_PerfInsights.Overview.Engines.md#USER_PerfInsights.Overview.PIfeatureEngnRegSupport)

**To create a performance analysis report for a time period**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the left navigation pane, choose **Performance Insights**.

1. Choose a DB instance. 

1. Choose **Analyze performance** in **Database load** section on the Performance Insights dashboard.

   The fields to set the time period and add one or more tags to the performance analysis report are displayed.  
![\[Performance Insights dashboard showing fields to create analysis report\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_CreateAnalysisReport.png)

1. Choose the time period. If you set a time period in the **Relative range** or **Absolute range** in the upper right, you can only enter or select the analysis report date and time within this time period. If you select the analysis period outside of this time period, an error message displays.

    To set the time period, you can do any of the following:
   + Press and drag any of the sliders on the DB load chart.

     The **Performance analysis period** box displays the selected time period and DB load chart highlights the selected time period.
   + Choose the **Start date**, **Start time**, **End date**, and **End time** in the **Performance analysis period** box.  
![\[Performance Insights dashboard with analysis period selected\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_CreateAnalysisRep_TimePeriod.png)

1. (Optional) Enter **Key** and **Value-*optional*** to add a tag for the report.  
![\[Performance Insights dashboard with fields to add a new tag\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_CreateAnalysisRep_AddTag.png)

1. Choose **Analyze performance**.

   A banner displays a message whether the report generation is successful or failed. The message also provides the link to view the report.

   The following example shows the banner with the report creation successful message.  
![\[Analysis report creation successful message banner\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_CreateAnaysisRep_SuccessMsg.png)

   The report is available to view in **Performance analysis reports - new** tab. 

You can create a performance analysis report using the AWS CLI. For an example on how to create a report using AWS CLI, see [Creating a performance analysis report for a time period](USER_PerfInsights.API.Examples.md#USER_PerfInsights.API.Examples.CreatePerfAnalysisReport).

# Viewing a performance analysis report in Performance Insights
<a name="USER_PerfInsights.UsingDashboard.ViewPerfAnalysisReport"></a>

The **Performance analysis reports - new** tab lists all the reports that are created for the DB instance. The following are displayed for each report:
+ **ID**: Unique identifier of the report.
+ **Name**: Tag key added to the report.
+ **Report creation time**: Time you created the report.
+ **Analysis start time**: Start time of the analysis in the report.
+ **Analysis end time**: End time of the analysis in the report.

**To view a performance analysis report**

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 left navigation pane, choose **Performance Insights**.

1. Choose a DB instance for which you want to view the analysis report. 

1. Scroll down and choose **Performance analysis reports - new** tab in the Performance Insights dashboard.

   All the analysis reports for the different time periods are displayed.

1. Choose **ID** of the report you want to view.

   The DB load chart displays the entire analysis period by default if more than one insight is identified. If the report has identified one insight then the DB load chart displays the insight by default. 

   The dashboard also lists the tags for the report in the **Tags** section.

   The following example shows the entire analysis period for the report.  
![\[DB load chart showing entire analysis report period\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_EntireAnalysisRep.png)

1. Choose the insight in the **Database load insights** list you want to view if more than one insight is identified in the report.

   The dashboard displays the insight message, DB load chart highlighting the time period of the insight, analysis and recommendations, and the list of report tags.

   The following example shows the DB load insight in the report.   
![\[DB load chart showing insight in the report\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_AnalysisRepInsight_chart.png)  
![\[Report insight analysis and recommendation section\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_AnalysisRepInsight_Recommendations.png)

# Adding tags to a performance analysis report in Performance Insights
<a name="USER_PerfInsights.UsingDashboard.ManagePerfAnalysisReportTags"></a>

You can add a tag when you create or view a report. You can add up to 50 tags for a report.

You need permissions to add the tags. For more information about the access policies for Performance Insights, see [Configuring access policies for Performance Insights](USER_PerfInsights.access-control.md)

To add one or more tags while creating a report, see step 6 in the procedure [Creating a performance analysis report in Performance Insights](USER_PerfInsights.UsingDashboard.CreatingPerfAnlysisReport.md).

**To add one or more tags when viewing a report**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the left navigation pane, choose **Performance Insights**.

1. Choose a DB instance. 

   The Performance Insights dashboard appears for the DB instance.

1. Scroll down and choose **Performance analysis reports - new** tab.

1. Choose the report for which you want to add the tags.

   The dashboard displays the report.

1. Scroll down to **Tags** and choose **Manage tags**.

1. Choose **Add new tag**.

1. Enter the **Key** and **Value - *optional***, and choose **Add new tag**.

   The following example provides the option to add a new tag for the selected report.  
![\[Manage Tags window to add new tags to the report\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_AddTag_ManageTags.png)

   A new tag is created for the report.

   The list of tags for the report is displayed in the **Tags** section on the dashboard. If you want to remove a tag from the report, choose **Remove** next to the tag.

# Deleting a performance analysis report in Performance Insights
<a name="USER_PerfInsights.UsingDashboard.DeletePerfAnalysisReport"></a>

You can delete a report from the list of reports displayed in the **Performance analysis reports** tab or while viewing a report. 

**To delete a report**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the left navigation pane, choose **Performance Insights**.

1. Choose a DB instance. 

   The Performance Insights dashboard appears for the DB instance.

1. Scroll down and choose **Performance analysis reports - new** tab.

1. Select the report you want to delete and choose **Delete** in the upper right.  
![\[Performance Insights dashboard to delete with a report selected for deletion\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/PI_DeleteAnalysisRep.png)

   A confirmation window is displayed. The report is deleted after you choose confirm.

1. (Optional) Choose **ID** of the report you want to delete.

   In the report page, choose **Delete** in the upper right.

   A confirmation window is displayed. The report is deleted after you choose confirm.

# Analyzing queries with the Top SQL tab in Performance Insights
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics"></a>

In the Amazon RDS Performance Insights dashboard, you can find information about running and recent queries in the **Top SQL** tab in the **Top dimensions** table. You can use this information to tune your queries.

**Topics**
+ [Overview of the Top SQL tab](#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL)
+ [Accessing more SQL text in the Performance Insights dashboard](USER_PerfInsights.UsingDashboard.SQLTextSize.md)
+ [Viewing SQL statistics in the Performance Insights dashboard](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.AnalyzingSQLLevel.md)

## Overview of the Top SQL tab
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL"></a>

By default, the **Top SQL** tab shows the 25 queries that are contributing the most to DB load. To help tune your queries, you can analyze information such as the query text and SQL statistics. You can also choose the statistics that you want to appear in the **Top SQL** tab.

**Topics**
+ [SQL text](#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.text)
+ [SQL statistics](#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.statistics)
+ [Load by waits (AAS)](#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.Load-by-waits)
+ [View SQL information](#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.SQL-information)
+ [Choose statistics preferences](#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.Preferences)

### SQL text
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.text"></a>

By default, each row in the **Top SQL** table shows 500 bytes of text for each statement. 

![\[SQL text\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/sql-text-apg.png)


To learn how to see more than the default 500 bytes of SQL text, see [Accessing more SQL text in the Performance Insights dashboard](USER_PerfInsights.UsingDashboard.SQLTextSize.md).

A *SQL digest* is a composite of multiple actual queries that are structurally similar but might have different literal values. The digest replaces hardcoded values with a question mark. For example, a digest might be `SELECT * FROM emp WHERE lname= ?`. This digest might include the following child queries:

```
SELECT * FROM emp WHERE lname = 'Sanchez'
SELECT * FROM emp WHERE lname = 'Olagappan'
SELECT * FROM emp WHERE lname = 'Wu'
```

To see the literal SQL statements in a digest, select the query, and then choose the plus symbol (\$1). In the following example, the selected query is a digest.

![\[Selected SQL digest\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_4b.png)


**Note**  
A SQL digest groups similar SQL statements, but doesn't redact sensitive information.

### SQL statistics
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.statistics"></a>

*SQL statistics* are performance-related metrics about SQL queries. For example, Performance Insights might show executions per second or rows processed per second. Performance Insights collects statistics for only the most common queries. Typically, these match the top queries by load shown in the Performance Insights dashboard. 

Every line in the **Top SQL** table shows relevant statistics for the SQL statement or digest, as shown in the following example.

![\[Top SQL\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_4.png)


Performance Insights can report `0.00` and `-` (unknown) for SQL statistics. This situation occurs under the following conditions:
+ Only one sample exists. For example, Performance Insights calculates rates of change for Aurora PostgreSQL queries based on multiple samples from the `pg_stat_statements` view. When a workload runs for a short time, Performance Insights might collect only one sample, which means that it can't calculate a rate of change. The unknown value is represented with a dash (`-`).
+ Two samples have the same values. Performance Insights can't calculate a rate of change because no change has occurred, so it reports the rate as `0.00`.
+ An Aurora PostgreSQL statement lacks a valid identifier. PostgreSQL creates a identifier for a statement only after parsing and analysis. Thus, a statement can exist in the PostgreSQL internal in-memory structures with no identifier. Because Performance Insights samples internal in-memory structures once per second, low-latency queries might appear for only a single sample. If the query identifier isn't available for this sample, Performance Insights can't associate this statement with its statistics. The unknown value is represented with a dash (`-`).

For a description of the SQL statistics for the Aurora engines, see [SQL statistics for Performance Insights](sql-statistics.md).

### Load by waits (AAS)
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.Load-by-waits"></a>

In **Top SQL**, the **Load by waits (AAS)** column illustrates the percentage of the database load associated with each top load item. This column reflects the load for that item by whatever grouping is currently selected in the **DB Load Chart**. For more information about Average active sessions (AAS), see [Average active sessions](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.AAS).

For example, you might group the **DB load** chart by wait states. You examine SQL queries in the top load items table. In this case, the **DB Load by Waits** bar is sized, segmented, and color-coded to show how much of a given wait state that query is contributing to. It also shows which wait states are affecting the selected query.

![\[DB load by waits\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_6.png)


### View SQL information
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.SQL-information"></a>

In the **Top SQL** table, you can open a statement to view its information. The information appears in the bottom pane.

![\[Top SQL table with literal query selected\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-sql-ids-open.png)


The following types of identifiers (IDs) that are associated with SQL statements:
+ **Support SQL ID** – A hash value of the SQL ID. This value is only for referencing a SQL ID when you are working with AWS Support. AWS Support doesn't have access to your actual SQL IDs and SQL text.
+ **Support Digest ID** – A hash value of the digest ID. This value is only for referencing a digest ID when you are working with AWS Support. AWS Support doesn't have access to your actual digest IDs and SQL text.

### Choose statistics preferences
<a name="USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.Preferences"></a>

You can control the statistics displayed in the **Top SQL** tab by choosing the **Preferences** icon.

![\[Statistics preferences\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-sql-ids-preferences-icon.png)


When you choose the **Preferences** icon, the **Preferences** window opens. The following screenshot is an example of the **Preferences** window.

![\[Preferences window\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-sql-ids-preferences.png)


To enable the statistics that you want to appear in the **Top SQL** tab, use your mouse to scroll to the bottom of the window, and then choose **Continue**. 

For more information about per-second or per-call statistics for the Aurora engines, see the engine specific SQL statistics section in [SQL statistics for Performance Insights](sql-statistics.md)

# Accessing more SQL text in the Performance Insights dashboard
<a name="USER_PerfInsights.UsingDashboard.SQLTextSize"></a>

By default, each row in the **Top SQL** table shows 500 bytes of SQL text for each SQL statement.

![\[500 bytes of SQL\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-top-sql-bytes.png)


When a SQL statement exceeds 500 bytes, you can view more text in the **SQL text** section below the **Top SQL** table. In this case, the maximum length for the text displayed in **SQL text** is 4 KB. This limit is introduced by the console and is subject to the limits set by the database engine. To save the text shown in **SQL text**, choose **Download**.

**Topics**
+ [Text size limits for Aurora MySQL](#sql-text-engine-limits)
+ [Setting the SQL text limit for Aurora PostgreSQL DB instances](USER_PerfInsights.UsingDashboard.SQLTextLimit.md)
+ [Viewing and downloading SQL text in the Performance Insights dashboard](view-download-text.md)

## Text size limits for Aurora MySQL
<a name="sql-text-engine-limits"></a>

When you download SQL text, the database engine determines its maximum length. You can download SQL text up to the following per-engine limits.


| DB engine | Maximum length of downloaded text | 
| --- | --- | 
| Aurora MySQL | The length is fixed at 4,096 bytes. | 

The **SQL text** section of the Performance Insights console displays up to the maximum that the engine returns. For example, if Aurora MySQL returns at most 1 KB to Performance Insights, it can only collect and show 1 KB, even if the original query is larger. Thus, when you view the query in **SQL text** or download it, Performance Insights returns the same number of bytes.

If you use the AWS CLI or API, Performance Insights doesn't have the 4 KB limit enforced by the console. `DescribeDimensionKeys` and `GetResourceMetrics` return at most 500 bytes. 

**Note**  
`GetDimensionKeyDetails` returns the full query, but the size is subject to the engine limit.

# Setting the SQL text limit for Aurora PostgreSQL DB instances
<a name="USER_PerfInsights.UsingDashboard.SQLTextLimit"></a>

Aurora PostgreSQL handles text differently. You can set the text size limit with the DB instance parameter `track_activity_query_size`. This parameter has the following characteristics:

Default text size  
On Aurora PostgreSQL version 9.6, the default setting for the `track_activity_query_size` parameter is 1,024 bytes. On Aurora PostgreSQL version 10 or higher, the default is 4,096 bytes.

Maximum text size  
The limit for `track_activity_query_size` is 102,400 bytes for Aurora PostgreSQL version 12 and lower. The maximum is 1 MB for version 13 and higher.   
If the engine returns 1 MB to Performance Insights, the console displays only the first 4 KB. If you download the query, you get the full 1 MB. In this case, viewing and downloading return different numbers of bytes. For more information about the `track_activity_query_size` DB instance parameter, see [Run-time Statistics](https://www.postgresql.org/docs/current/runtime-config-statistics.html) in the PostgreSQL documentation.

To increase the SQL text size, increase the `track_activity_query_size` limit. To modify the parameter, change the parameter setting in the parameter group that is associated with the Aurora PostgreSQL DB instance.

**To change the setting when the instance uses the default parameter group**

1. Create a new DB instance parameter group for the appropriate DB engine and DB engine version.

1. Set the parameter in the new parameter group.

1. Associate the new parameter group with the DB instance.

For information about setting a DB instance parameter, see [Modifying parameters in a DB parameter group in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).

# Viewing and downloading SQL text in the Performance Insights dashboard
<a name="view-download-text"></a>

In the Performance Insights dashboard, you can view or download SQL text.

**To view more SQL text in the Performance Insights dashboard**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the navigation pane, choose **Performance Insights**.

1. Choose a DB instance.

1. Scroll down to the **Top SQL** tab in the Performance Insights dashboard.

1. Choose the plus sign to expand a SQL digest and choose one of the digest's child queries.

   SQL statements with text larger than 500 bytes look similar to the following image.  
![\[SQL statements with large text\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-large-text-aurora-1.png)

1. Scroll down to the **SQL text** tab.  
![\[SQL information section shows more of the SQL text\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-large-text-aurora-2.png)

   The Performance Insights dashboard can display up to 4,096 bytes for each SQL statement.

1. (Optional) Choose **Copy** to copy the displayed SQL statement, or choose **Download** to download the SQL statement to view the SQL text up to the DB engine limit.
**Note**  
To copy or download the SQL statement, disable pop-up blockers. 

# Viewing SQL statistics in the Performance Insights dashboard
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.AnalyzingSQLLevel"></a>

In the Performance Insights dashboard, SQL statistics are available in the **Top SQL** tab of the **Database load** chart.

**To view SQL statistics**

1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. In the left navigation pane, choose **Performance Insights**.

1. At the top of the page, choose the database whose SQL statistics you want to see.

1. Scroll to the bottom of the page and choose the **Top SQL** tab.

1. Choose an individual statement (Aurora MySQL only) or digest query.  
![\[Viewing metrics for running queries\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_per_sql_digest.png)

1. Choose which statistics to display by choosing the gear icon in the upper-right corner of the chart. For descriptions of the SQL statistics for the Amazon RDSAurora engines, see [SQL statistics for Performance Insights](sql-statistics.md).

   The following example shows the preferences for Aurora PostgreSQL.  
![\[Preferences for metrics for running queries for Aurora PostgreSQL DB instances\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_per_sql_pref_apg.png)

   The following example shows the preferences for Aurora MySQL DB instances.  
![\[Preferences for metrics for running queries for Aurora MySQL DB instances.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf_insights_per_sql_pref_ams.png)

1. Choose Save to save your preferences.

   The **Top SQL** table refreshes.

# Viewing Performance Insights proactive recommendations
<a name="USER_PerfInsights.InsightsRecommendationViewDetails"></a>

Amazon RDS Performance Insights monitors specific metrics and automatically creates thresholds by analyzing what levels might be potentially problematic for a specified resource. When the new metric values cross a predefined threshold over a given period of time, Performance Insights generates a proactive recommendation. This recommendation helps to prevent future database performance impact. To receive these proactive recommendations, you must turn on Performance Insights with a paid tier retention period.

For more information about turning on Performance Insights, see [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md). For information about pricing and data retention for Performance Insights, see [Pricing and data retention for Performance Insights](USER_PerfInsights.Overview.cost.md).

To find out the regions, DB engines, and instance classes supported for the proactive recommendations, see [ Amazon Aurora DB engine, Region, and instance class support for Performance Insights features](USER_PerfInsights.Overview.Engines.md#USER_PerfInsights.Overview.PIfeatureEngnRegSupport). 

You can view the detailed analysis and recommended investigations of proactive recommendations in the recommendation details page.

For more information about recommendations, see [Recommendations from Amazon Aurora](monitoring-recommendations.md).

**To view the detailed analysis of a proactive recommendation**

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, do any of the following:
   + Choose **Recommendations**.

     The **Recommendations** page displays a list of recommendations sorted by the severity for all the resources in your account.
   + Choose **Databases** and then choose **Recommendations** for a resource in the databases page.

     The **Recommendations** tab displays the recommendations and its details for the selected resource.

1. Find a proactive recommendation and choose **View details**.

   The recommendation details page appears. The title provides the name of the affected resource with the issue detected and the severity.

   The following are the components on the recommendation details page:
   + **Recommendation summary** – The detected issue, recommendation and issue status, issue start and end time, recommendation modified time, and the engine type.  
![\[Recommendation details page for proactive recommendation showing the Recommendation summary section in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/RecommendationProactive-RecSummary.png)
   + **Metrics** – The graphs of the detected issue. Each graph displays a threshold determined by the resource's baseline behavior and data of the metric reported from the issue start time.  
![\[Recommendation details page for proactive recommendation showing the Metrics section in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/RecommedationProactive_Metrics.png)
   + **Analysis and recommendations** – The recommendation and the reason for the suggested recommendation.  
![\[Recommendation details page for proactive recommendation showing the Analysis and recommendations section in the console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/ProactiveRecommendation-AnalysisAndRec.png)

   You can review the cause of the issue and then perform the suggested recommended actions to fix the issue, or choose **Dismiss** in the upper right to dismiss the recommendation.

# Retrieving metrics with the Performance Insights API for Aurora
<a name="USER_PerfInsights.API"></a>

When Performance Insights is turned on, the API provides visibility into instance performance. Amazon CloudWatch Logs provides the authoritative source for vended monitoring metrics for AWS services. 

Performance Insights offers a domain-specific view of database load measured as average active sessions (AAS). This metric appears to API consumers as a two-dimensional time-series dataset. The time dimension of the data provides DB load data for each time point in the queried time range. Each time point decomposes overall load in relation to the requested dimensions, such as `SQL`, `Wait-event`, `User`, or `Host`, measured at that time point.

Amazon RDS Performance Insights monitors your Amazon Aurora cluster so that you can analyze and troubleshoot database performance. One way to view Performance Insights data is in the AWS Management Console. Performance Insights also provides a public API so that you can query your own data. You can use the API to do the following:
+ Offload data into a database
+ Add Performance Insights data to existing monitoring dashboards
+ Build monitoring tools

To use the Performance Insights API, enable Performance Insights on one of your Amazon RDS DB instances. For information about enabling Performance Insights, see [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md). For more information about the Performance Insights API, see the [Amazon RDS Performance Insights API Reference](https://docs.aws.amazon.com/performance-insights/latest/APIReference/Welcome.html).

The Performance Insights API provides the following operations.


****  

|  Performance Insights action  |  AWS CLI command  |  Description  | 
| --- | --- | --- | 
|  [https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_CreatePerformanceAnalysisReport.html](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_CreatePerformanceAnalysisReport.html)  |  [https://docs.aws.amazon.com/cli/latest/reference/pi/CreatePerformanceAnalysisReport.html](https://docs.aws.amazon.com/cli/latest/reference/pi/CreatePerformanceAnalysisReport.html)  |  Creates a performance analysis report for a specific time period for the DB instance. The result is `AnalysisReportId` which is the unique identifier of the report.  | 
|  [https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DeletePerformanceAnalysisReport.html](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DeletePerformanceAnalysisReport.html)  |  [https://docs.aws.amazon.com/cli/latest/reference/pi/DeletePerformanceAnalysisReport.html](https://docs.aws.amazon.com/cli/latest/reference/pi/DeletePerformanceAnalysisReport.html)  |  Deletes a performance analysis report.  | 
|  [https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DescribeDimensionKeys.html](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DescribeDimensionKeys.html)  |  [https://docs.aws.amazon.com/cli/latest/reference/pi/describe-dimension-keys.html](https://docs.aws.amazon.com/cli/latest/reference/pi/describe-dimension-keys.html)  |  Retrieves the top N dimension keys for a metric for a specific time period.  | 
|  [https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_GetDimensionKeyDetails.html](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_GetDimensionKeyDetails.html)  |  [https://docs.aws.amazon.com/cli/latest/reference/pi/get-dimension-key-details.html](https://docs.aws.amazon.com/cli/latest/reference/pi/get-dimension-key-details.html)  |  Retrieves the attributes of the specified dimension group for a DB instance or data source. For example, if you specify a SQL ID, and if the dimension details are available, `GetDimensionKeyDetails` retrieves the full text of the dimension `db.sql.statement` associated with this ID. This operation is useful because `GetResourceMetrics` and `DescribeDimensionKeys` don't support retrieval of large SQL statement text.   | 
|  [https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_GetPerformanceAnalysisReport.html](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_GetPerformanceAnalysisReport.html)  |  [https://docs.aws.amazon.com/cli/latest/reference/pi/GetPerformanceAnalysisReport.html](https://docs.aws.amazon.com/cli/latest/reference/pi/GetPerformanceAnalysisReport.html)  |  Retrieves the report including the insights for the report. The result includes the report status, report ID, report time details, insights, and recommendations.  | 
| [GetResourceMetadata](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_GetResourceMetadata.html) |  [https://docs.aws.amazon.com/cli/latest/reference/pi/get-resource-metadata.html](https://docs.aws.amazon.com/cli/latest/reference/pi/get-resource-metadata.html)  |  Retrieve the metadata for different features. For example, the metadata might indicate that a feature is turned on or off on a specific DB instance.   | 
|  [https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_GetResourceMetrics.html](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_GetResourceMetrics.html)  |  [https://docs.aws.amazon.com/cli/latest/reference/pi/get-resource-metrics.html](https://docs.aws.amazon.com/cli/latest/reference/pi/get-resource-metrics.html)  |  Retrieves Performance Insights metrics for a set of data sources over a time period. You can provide specific dimension groups and dimensions, and provide aggregation and filtering criteria for each group.  | 
| [ListAvailableResourceDimensions](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_ListAvailableResourceDimensions.html) |  [https://docs.aws.amazon.com/cli/latest/reference/pi/list-available-resource-dimensions.html](https://docs.aws.amazon.com/cli/latest/reference/pi/list-available-resource-dimensions.html)  |  Retrieve the dimensions that can be queried for each specified metric type on a specified instance.   | 
| [ListAvailableResourceMetrics](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_ListAvailableResourceMetrics.html) |  [https://docs.aws.amazon.com/cli/latest/reference/pi/list-available-resource-metrics.html](https://docs.aws.amazon.com/cli/latest/reference/pi/list-available-resource-metrics.html)  |  Retrieve all available metrics of the specified metric types that can be queried for a specified DB instance.  | 
|  `[ListPerformanceAnalysisReports](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_ListPerformanceAnalysisReports.html)` |  [https://docs.aws.amazon.com/cli/latest/reference/pi/list-performance-analysis-reports.html](https://docs.aws.amazon.com/cli/latest/reference/pi/list-performance-analysis-reports.html)  | Retrieves all the analysis reports available for the DB instance. The reports are listed based on the start time of each report. | 
|  `[ListTagsForResource](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_ListTagsForResource.html)` |  [https://docs.aws.amazon.com/cli/latest/reference/pi/list-tags-for-resource.html](https://docs.aws.amazon.com/cli/latest/reference/pi/list-tags-for-resource.html)  |  Lists all the metadata tags added to the resource. The list includes the name and value of the tag.  | 
|  `[TagResource](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_TagResource.html)` |  [https://docs.aws.amazon.com/cli/latest/reference/pi/tag-resource.html](https://docs.aws.amazon.com/cli/latest/reference/pi/tag-resource.html)  |  Adds metadata tags to the Amazon RDS resource. The tag includes a name and a value.  | 
|  `[UntagResource](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_UntagResource.html)` |  [https://docs.aws.amazon.com/cli/latest/reference/pi/untag-resource.html](https://docs.aws.amazon.com/cli/latest/reference/pi/untag-resource.html)  |  Removes the metadata tag from the resource.  | 

For more information about retrieving time-series metrics and AWS CLI examples for Performance Insights, see the following topics.

**Topics**
+ [Retrieving time-series metrics for Performance Insights](USER_PerfInsights.API.TimeSeries.md)
+ [AWS CLI examples for Performance Insights](USER_PerfInsights.API.Examples.md)

# Retrieving time-series metrics for Performance Insights
<a name="USER_PerfInsights.API.TimeSeries"></a>

The `GetResourceMetrics` operation retrieves one or more time-series metrics from the Performance Insights data. `GetResourceMetrics` requires a metric and time period, and returns a response with a list of data points. 

For example, the AWS Management Console uses `GetResourceMetrics` to populate the **Counter Metrics** chart and the **Database Load** chart, as seen in the following image.

![\[Counter Metrics and Database Load charts\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-api-charts.png)


All metrics returned by `GetResourceMetrics` are standard time-series metrics, with the exception of `db.load`. This metric is displayed in the **Database Load** chart. The `db.load` metric is different from the other time-series metrics because you can break it into subcomponents called *dimensions*. In the previous image, `db.load` is broken down and grouped by the waits states that make up the `db.load`.

**Note**  
`GetResourceMetrics` can also return the `db.sampleload` metric, but the `db.load` metric is appropriate in most cases.

For information about the counter metrics returned by `GetResourceMetrics`, see [Performance Insights counter metrics](USER_PerfInsights_Counters.md).

The following calculations are supported for the metrics:
+ Average – The average value for the metric over a period of time. Append `.avg` to the metric name.
+ Minimum – The minimum value for the metric over a period of time. Append `.min` to the metric name.
+ Maximum – The maximum value for the metric over a period of time. Append `.max` to the metric name.
+ Sum – The sum of the metric values over a period of time. Append `.sum` to the metric name.
+ Sample count – The number of times the metric was collected over a period of time. Append `.sample_count` to the metric name.

For example, assume that a metric is collected for 300 seconds (5 minutes), and that the metric is collected one time each minute. The values for each minute are 1, 2, 3, 4, and 5. In this case, the following calculations are returned:
+ Average – 3
+ Minimum – 1
+ Maximum – 5
+ Sum – 15
+ Sample count – 5

For information about using the `get-resource-metrics` AWS CLI command, see [https://docs.aws.amazon.com/cli/latest/reference/pi/get-resource-metrics.html](https://docs.aws.amazon.com/cli/latest/reference/pi/get-resource-metrics.html).

For the `--metric-queries` option, specify one or more queries that you want to get results for. Each query consists of a mandatory `Metric` and optional `GroupBy` and `Filter` parameters. The following is an example of a `--metric-queries` option specification.

```
{
   "Metric": "string",
   "GroupBy": {
     "Group": "string",
     "Dimensions": ["string", ...],
     "Limit": integer
   },
   "Filter": {"string": "string"
     ...}
```

# AWS CLI examples for Performance Insights
<a name="USER_PerfInsights.API.Examples"></a>

In the following sections, learn more about the AWS Command Line Interface (AWS CLI) for Performance Insights and use AWS CLI examples.

**Topics**
+ [Built-in help for the AWS CLI for Performance Insights](#USER_PerfInsights.API.CLI)
+ [Retrieving counter metrics](#USER_PerfInsights.API.Examples.CounterMetrics)
+ [Retrieving the DB load average for top wait events](#USER_PerfInsights.API.Examples.DBLoadAverage)
+ [Retrieving the DB load average for top SQL](#USER_PerfInsights.API.Examples.DBLoadAverageTop10SQL)
+ [Retrieving the DB load average filtered by SQL](#USER_PerfInsights.API.Examples.DBLoadAverageFilterBySQL)
+ [Retrieving the full text of a SQL statement](#USER_PerfInsights.API.Examples.GetDimensionKeyDetails)
+ [Creating a performance analysis report for a time period](#USER_PerfInsights.API.Examples.CreatePerfAnalysisReport)
+ [Retrieving a performance analysis report](#USER_PerfInsights.API.Examples.GetPerfAnalysisReport)
+ [Listing all the performance analysis reports for the DB instance](#USER_PerfInsights.API.Examples.ListPerfAnalysisReports)
+ [Deleting a performance analysis report](#USER_PerfInsights.API.Examples.DeletePerfAnalysisReport)
+ [Adding tag to a performance analysis report](#USER_PerfInsights.API.Examples.TagPerfAnalysisReport)
+ [Listing all the tags for a performance analysis report](#USER_PerfInsights.API.Examples.ListTagsPerfAnalysisReport)
+ [Deleting tags from a performance analysis report](#USER_PerfInsights.API.Examples.UntagPerfAnalysisReport)

## Built-in help for the AWS CLI for Performance Insights
<a name="USER_PerfInsights.API.CLI"></a>

You can view Performance Insights data using the AWS CLI. You can view help for the AWS CLI commands for Performance Insights by entering the following on the command line.

```
aws pi help
```

If you don't have the AWS CLI installed, see [Installing the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) in the *AWS CLI User Guide *for information about installing it.

## Retrieving counter metrics
<a name="USER_PerfInsights.API.Examples.CounterMetrics"></a>

The following screenshot shows two counter metrics charts in the AWS Management Console.

![\[Counter Metrics charts.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-api-counters-charts.png)


The following example shows how to gather the same data that the AWS Management Console uses to generate the two counter metric charts.

For Linux, macOS, or Unix:

```
aws pi get-resource-metrics \
   --service-type RDS \
   --identifier db-ID \
   --start-time 2018-10-30T00:00:00Z \
   --end-time   2018-10-30T01:00:00Z \
   --period-in-seconds 60 \
   --metric-queries '[{"Metric": "os.cpuUtilization.user.avg"  },
                      {"Metric": "os.cpuUtilization.idle.avg"}]'
```

For Windows:

```
aws pi get-resource-metrics ^
   --service-type RDS ^
   --identifier db-ID ^
   --start-time 2018-10-30T00:00:00Z ^
   --end-time   2018-10-30T01:00:00Z ^
   --period-in-seconds 60 ^
   --metric-queries '[{"Metric": "os.cpuUtilization.user.avg"  },
                      {"Metric": "os.cpuUtilization.idle.avg"}]'
```

You can also make a command easier to read by specifying a file for the `--metrics-query` option. The following example uses a file called query.json for the option. The file has the following contents.

```
[
    {
        "Metric": "os.cpuUtilization.user.avg"
    },
    {
        "Metric": "os.cpuUtilization.idle.avg"
    }
]
```

Run the following command to use the file.

For Linux, macOS, or Unix:

```
aws pi get-resource-metrics \
   --service-type RDS \
   --identifier db-ID \
   --start-time 2018-10-30T00:00:00Z \
   --end-time   2018-10-30T01:00:00Z \
   --period-in-seconds 60 \
   --metric-queries file://query.json
```

For Windows:

```
aws pi get-resource-metrics ^
   --service-type RDS ^
   --identifier db-ID ^
   --start-time 2018-10-30T00:00:00Z ^
   --end-time   2018-10-30T01:00:00Z ^
   --period-in-seconds 60 ^
   --metric-queries file://query.json
```

The preceding example specifies the following values for the options:
+ `--service-type` – `RDS` for Amazon RDS
+ `--identifier` – The resource ID for the DB instance
+ `--start-time` and `--end-time` – The ISO 8601 `DateTime` values for the period to query, with multiple supported formats

It queries for a one-hour time range:
+ `--period-in-seconds` – `60` for a per-minute query
+ `--metric-queries` – An array of two queries, each just for one metric.

  The metric name uses dots to classify the metric in a useful category, with the final element being a function. In the example, the function is `avg` for each query. As with Amazon CloudWatch, the supported functions are `min`, `max`, `total`, and `avg`.

The response looks similar to the following.

```
{
    "Identifier": "db-XXX",
    "AlignedStartTime": 1540857600.0,
    "AlignedEndTime": 1540861200.0,
    "MetricList": [
        { //A list of key/datapoints 
            "Key": {
                "Metric": "os.cpuUtilization.user.avg" //Metric1
            },
            "DataPoints": [
                //Each list of datapoints has the same timestamps and same number of items
                {
                    "Timestamp": 1540857660.0, //Minute1
                    "Value": 4.0
                },
                {
                    "Timestamp": 1540857720.0, //Minute2
                    "Value": 4.0
                },
                {
                    "Timestamp": 1540857780.0, //Minute 3
                    "Value": 10.0
                }
                //... 60 datapoints for the os.cpuUtilization.user.avg metric
            ]
        },
        {
            "Key": {
                "Metric": "os.cpuUtilization.idle.avg" //Metric2
            },
            "DataPoints": [
                {
                    "Timestamp": 1540857660.0, //Minute1
                    "Value": 12.0
                },
                {
                    "Timestamp": 1540857720.0, //Minute2
                    "Value": 13.5
                },
                //... 60 datapoints for the os.cpuUtilization.idle.avg metric 
            ]
        }
    ] //end of MetricList
} //end of response
```

The response has an `Identifier`, `AlignedStartTime`, and `AlignedEndTime`. B the `--period-in-seconds` value was `60`, the start and end times have been aligned to the minute. If the `--period-in-seconds` was `3600`, the start and end times would have been aligned to the hour.

The `MetricList` in the response has a number of entries, each with a `Key` and a `DataPoints` entry. Each `DataPoint` has a `Timestamp` and a `Value`. Each `Datapoints` list has 60 data points because the queries are for per-minute data over an hour, with `Timestamp1/Minute1`, `Timestamp2/Minute2`, and so on, up to `Timestamp60/Minute60`. 

Because the query is for two different counter metrics, there are two elements in the response `MetricList`.

## Retrieving the DB load average for top wait events
<a name="USER_PerfInsights.API.Examples.DBLoadAverage"></a>

The following example is the same query that the AWS Management Console uses to generate a stacked area line graph. This example retrieves the `db.load.avg` for the last hour with load divided according to the top seven wait events. The command is the same as the command in [Retrieving counter metrics](#USER_PerfInsights.API.Examples.CounterMetrics). However, the query.json file has the following contents.

```
[
    {
        "Metric": "db.load.avg",
        "GroupBy": { "Group": "db.wait_event", "Limit": 7 }
    }
]
```

Run the following command.

For Linux, macOS, or Unix:

```
aws pi get-resource-metrics \
   --service-type RDS \
   --identifier db-ID \
   --start-time 2018-10-30T00:00:00Z \
   --end-time   2018-10-30T01:00:00Z \
   --period-in-seconds 60 \
   --metric-queries file://query.json
```

For Windows:

```
aws pi get-resource-metrics ^
   --service-type RDS ^
   --identifier db-ID ^
   --start-time 2018-10-30T00:00:00Z ^
   --end-time   2018-10-30T01:00:00Z ^
   --period-in-seconds 60 ^
   --metric-queries file://query.json
```

The example specifies the metric of `db.load.avg` and a `GroupBy` of the top seven wait events. For details about valid values for this example, see [DimensionGroup](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DimensionGroup.html) in the *Performance Insights API Reference.*

The response looks similar to the following.

```
{
    "Identifier": "db-XXX",
    "AlignedStartTime": 1540857600.0,
    "AlignedEndTime": 1540861200.0,
    "MetricList": [
        { //A list of key/datapoints 
            "Key": {
                //A Metric with no dimensions. This is the total db.load.avg
                "Metric": "db.load.avg"
            },
            "DataPoints": [
                //Each list of datapoints has the same timestamps and same number of items
                {
                    "Timestamp": 1540857660.0, //Minute1
                    "Value": 0.5166666666666667
                },
                {
                    "Timestamp": 1540857720.0, //Minute2
                    "Value": 0.38333333333333336
                },
                {
                    "Timestamp": 1540857780.0, //Minute 3
                    "Value": 0.26666666666666666
                }
                //... 60 datapoints for the total db.load.avg key
            ]
        },
        {
            "Key": {
                //Another key. This is db.load.avg broken down by CPU
                "Metric": "db.load.avg",
                "Dimensions": {
                    "db.wait_event.name": "CPU",
                    "db.wait_event.type": "CPU"
                }
            },
            "DataPoints": [
                {
                    "Timestamp": 1540857660.0, //Minute1
                    "Value": 0.35
                },
                {
                    "Timestamp": 1540857720.0, //Minute2
                    "Value": 0.15
                },
                //... 60 datapoints for the CPU key
            ]
        },
        //... In total we have 8 key/datapoints entries, 1) total, 2-8) Top Wait Events
    ] //end of MetricList
} //end of response
```

In this response, there are eight entries in the `MetricList`. There is one entry for the total `db.load.avg`, and seven entries each for the `db.load.avg` divided according to one of the top seven wait events. Unlike in the first example, because there was a grouping dimension, there must be one key for each grouping of the metric. There can't be only one key for each metric, as in the basic counter metric use case.

## Retrieving the DB load average for top SQL
<a name="USER_PerfInsights.API.Examples.DBLoadAverageTop10SQL"></a>

The following example groups `db.wait_events` by the top 10 SQL statements. There are two different groups for SQL statements:
+ `db.sql` – The full SQL statement, such as `select * from customers where customer_id = 123`
+ `db.sql_tokenized` – The tokenized SQL statement, such as `select * from customers where customer_id = ?`

When analyzing database performance, it can be useful to consider SQL statements that only differ by their parameters as one logic item. So, you can use `db.sql_tokenized` when querying. However, especially when you're interested in explain plans, sometimes it's more useful to examine full SQL statements with parameters, and query grouping by `db.sql`. There is a parent-child relationship between tokenized and full SQL, with multiple full SQL (children) grouped under the same tokenized SQL (parent).

The command in this example is the similar to the command in [Retrieving the DB load average for top wait events](#USER_PerfInsights.API.Examples.DBLoadAverage). However, the query.json file has the following contents.

```
[
    {
        "Metric": "db.load.avg",
        "GroupBy": { "Group": "db.sql_tokenized", "Limit": 10 }
    }
]
```

The following example uses `db.sql_tokenized`.

For Linux, macOS, or Unix:

```
aws pi get-resource-metrics \
   --service-type RDS \
   --identifier db-ID \
   --start-time 2018-10-29T00:00:00Z \
   --end-time   2018-10-30T00:00:00Z \
   --period-in-seconds 3600 \
   --metric-queries file://query.json
```

For Windows:

```
aws pi get-resource-metrics ^
   --service-type RDS ^
   --identifier db-ID ^
   --start-time 2018-10-29T00:00:00Z ^
   --end-time   2018-10-30T00:00:00Z  ^
   --period-in-seconds 3600 ^
   --metric-queries file://query.json
```

This example queries over 24 hours, with a one hour period-in-seconds.

The example specifies the metric of `db.load.avg` and a `GroupBy` of the top seven wait events. For details about valid values for this example, see [DimensionGroup](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_DimensionGroup.html) in the *Performance Insights API Reference.*

The response looks similar to the following.

```
{
    "AlignedStartTime": 1540771200.0,
    "AlignedEndTime": 1540857600.0,
    "Identifier": "db-XXX",

    "MetricList": [ //11 entries in the MetricList
        {
            "Key": { //First key is total
                "Metric": "db.load.avg"
            }
            "DataPoints": [ //Each DataPoints list has 24 per-hour Timestamps and a value
                {
                    "Value": 1.6964980544747081,
                    "Timestamp": 1540774800.0
                },
                //... 24 datapoints
            ]
        },
        {
            "Key": { //Next key is the top tokenized SQL  
                "Dimensions": {
                    "db.sql_tokenized.statement": "INSERT INTO authors (id,name,email) VALUES\n( nextval(?)  ,?,?)",
                    "db.sql_tokenized.db_id": "pi-2372568224",
                    "db.sql_tokenized.id": "AKIAIOSFODNN7EXAMPLE"
                },
                "Metric": "db.load.avg"
            },
            "DataPoints": [ //... 24 datapoints 
            ]
        },
        // In total 11 entries, 10 Keys of top tokenized SQL, 1 total key 
    ] //End of MetricList
} //End of response
```

This response has 11 entries in the `MetricList` (1 total, 10 top tokenized SQL), with each entry having 24 per-hour `DataPoints`.

For tokenized SQL, there are three entries in each dimensions list:
+ `db.sql_tokenized.statement` – The tokenized SQL statement.
+ `db.sql_tokenized.db_id ` – Either the native database ID used to refer to the SQL, or a synthetic ID that Performance Insights generates for you if the native database ID isn't available. This example returns the `pi-2372568224` synthetic ID.
+ `db.sql_tokenized.id` – The ID of the query inside Performance Insights.

  In the AWS Management Console, this ID is called the Support ID. It's named this because the ID is data that AWS Support can examine to help you troubleshoot an issue with your database. AWS takes the security and privacy of your data extremely seriously, and almost all data is stored encrypted with your AWS KMS key. Therefore, nobody inside AWS can look at this data. In the example preceding, both the `tokenized.statement` and the `tokenized.db_id` are stored encrypted. If you have an issue with your database, AWS Support can help you by referencing the Support ID.

When querying, it might be convenient to specify a `Group` in `GroupBy`. However, for finer-grained control over the data that's returned, specify the list of dimensions. For example, if all that is needed is the `db.sql_tokenized.statement`, then a `Dimensions` attribute can be added to the query.json file.

```
[
    {
        "Metric": "db.load.avg",
        "GroupBy": {
            "Group": "db.sql_tokenized",
            "Dimensions":["db.sql_tokenized.statement"],
            "Limit": 10
        }
    }
]
```

## Retrieving the DB load average filtered by SQL
<a name="USER_PerfInsights.API.Examples.DBLoadAverageFilterBySQL"></a>

![\[Filter by SQL chart.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/perf-insights-api-filter-chart.png)


The preceding image shows that a particular query is selected, and the top average active sessions stacked area line graph is scoped to that query. Although the query is still for the top seven overall wait events, the value of the response is filtered. The filter causes it to take into account only sessions that are a match for the particular filter.

The corresponding API query in this example is similar to the command in [Retrieving the DB load average for top SQL](#USER_PerfInsights.API.Examples.DBLoadAverageTop10SQL). However, the query.json file has the following contents.

```
[
 {
        "Metric": "db.load.avg",
        "GroupBy": { "Group": "db.wait_event", "Limit": 5  }, 
        "Filter": { "db.sql_tokenized.id": "AKIAIOSFODNN7EXAMPLE" }
    }
]
```

For Linux, macOS, or Unix:

```
aws pi get-resource-metrics \
   --service-type RDS \
   --identifier db-ID \
   --start-time 2018-10-30T00:00:00Z \
   --end-time   2018-10-30T01:00:00Z \
   --period-in-seconds 60 \
   --metric-queries file://query.json
```

For Windows:

```
aws pi get-resource-metrics ^
   --service-type RDS ^
   --identifier db-ID ^
   --start-time 2018-10-30T00:00:00Z ^
   --end-time   2018-10-30T01:00:00Z ^
   --period-in-seconds 60 ^
   --metric-queries file://query.json
```

The response looks similar to the following.

```
{
    "Identifier": "db-XXX", 
    "AlignedStartTime": 1556215200.0, 
    "MetricList": [
        {
            "Key": {
                "Metric": "db.load.avg"
            }, 
            "DataPoints": [
                {
                    "Timestamp": 1556218800.0, 
                    "Value": 1.4878117913832196
                }, 
                {
                    "Timestamp": 1556222400.0, 
                    "Value": 1.192823803967328
                }
            ]
        }, 
        {
            "Key": {
                "Metric": "db.load.avg", 
                "Dimensions": {
                    "db.wait_event.type": "io", 
                    "db.wait_event.name": "wait/io/aurora_redo_log_flush"
                }
            }, 
            "DataPoints": [
                {
                    "Timestamp": 1556218800.0, 
                    "Value": 1.1360544217687074
                }, 
                {
                    "Timestamp": 1556222400.0, 
                    "Value": 1.058051341890315
                }
            ]
        }, 
        {
            "Key": {
                "Metric": "db.load.avg", 
                "Dimensions": {
                    "db.wait_event.type": "io", 
                    "db.wait_event.name": "wait/io/table/sql/handler"
                }
            }, 
            "DataPoints": [
                {
                    "Timestamp": 1556218800.0, 
                    "Value": 0.16241496598639457
                }, 
                {
                    "Timestamp": 1556222400.0, 
                    "Value": 0.05163360560093349
                }
            ]
        }, 
        {
            "Key": {
                "Metric": "db.load.avg", 
                "Dimensions": {
                    "db.wait_event.type": "synch", 
                    "db.wait_event.name": "wait/synch/mutex/innodb/aurora_lock_thread_slot_futex"
                }
            }, 
            "DataPoints": [
                {
                    "Timestamp": 1556218800.0, 
                    "Value": 0.11479591836734694
                }, 
                {
                    "Timestamp": 1556222400.0, 
                    "Value": 0.013127187864644107
                }
            ]
        }, 
        {
            "Key": {
                "Metric": "db.load.avg", 
                "Dimensions": {
                    "db.wait_event.type": "CPU", 
                    "db.wait_event.name": "CPU"
                }
            }, 
            "DataPoints": [
                {
                    "Timestamp": 1556218800.0, 
                    "Value": 0.05215419501133787
                }, 
                {
                    "Timestamp": 1556222400.0, 
                    "Value": 0.05805134189031505
                }
            ]
        }, 
        {
            "Key": {
                "Metric": "db.load.avg", 
                "Dimensions": {
                    "db.wait_event.type": "synch", 
                    "db.wait_event.name": "wait/synch/mutex/innodb/lock_wait_mutex"
                }
            }, 
            "DataPoints": [
                {
                    "Timestamp": 1556218800.0, 
                    "Value": 0.017573696145124718
                }, 
                {
                    "Timestamp": 1556222400.0, 
                    "Value": 0.002333722287047841
                }
            ]
        }
    ], 
    "AlignedEndTime": 1556222400.0
} //end of response
```

In this response, all values are filtered according to the contribution of tokenized SQL AKIAIOSFODNN7EXAMPLE specified in the query.json file. The keys also might follow a different order than a query without a filter, because it's the top five wait events that affected the filtered SQL.

## Retrieving the full text of a SQL statement
<a name="USER_PerfInsights.API.Examples.GetDimensionKeyDetails"></a>

The following example retrieves the full text of a SQL statement for DB instance `db-10BCD2EFGHIJ3KL4M5NO6PQRS5`. The `--group` is `db.sql`, and the `--group-identifier` is `db.sql.id`. In this example, *my-sql-id* represents a SQL ID retrieved by invoking `pi get-resource-metrics` or `pi describe-dimension-keys`.

Run the following command.

For Linux, macOS, or Unix:

```
aws pi get-dimension-key-details \
   --service-type RDS \
   --identifier db-10BCD2EFGHIJ3KL4M5NO6PQRS5 \
   --group db.sql \
   --group-identifier my-sql-id \
   --requested-dimensions statement
```

For Windows:

```
aws pi get-dimension-key-details ^
   --service-type RDS ^
   --identifier db-10BCD2EFGHIJ3KL4M5NO6PQRS5 ^
   --group db.sql ^
   --group-identifier my-sql-id ^
   --requested-dimensions statement
```

In this example, the dimensions details are available. Thus, Performance Insights retrieves the full text of the SQL statement, without truncating it.

```
{
    "Dimensions":[
    {
        "Value": "SELECT e.last_name, d.department_name FROM employees e, departments d WHERE e.department_id=d.department_id",
        "Dimension": "db.sql.statement",
        "Status": "AVAILABLE"
    },
    ...
    ]
}
```

## Creating a performance analysis report for a time period
<a name="USER_PerfInsights.API.Examples.CreatePerfAnalysisReport"></a>

The following example creates a performance analysis report with the `1682969503` start time and `1682979503` end time for the `db-loadtest-0` database.

```
aws pi create-performance-analysis-report \
        --service-type RDS \
        --identifier db-loadtest-0 \
        --start-time 1682969503 \
        --end-time 1682979503 \
        --region us-west-2
```

The response is the unique identifier `report-0234d3ed98e28fb17` for the report.

```
{
   "AnalysisReportId": "report-0234d3ed98e28fb17"
}
```

## Retrieving a performance analysis report
<a name="USER_PerfInsights.API.Examples.GetPerfAnalysisReport"></a>

The following example retrieves the analysis report details for the `report-0d99cc91c4422ee61` report.

```
aws pi get-performance-analysis-report \
--service-type RDS \
--identifier db-loadtest-0 \
--analysis-report-id report-0d99cc91c4422ee61 \
--region us-west-2
```

The response provides the report status, ID, time details, and insights.

```
        {
    "AnalysisReport": {
        "Status": "Succeeded", 
        "ServiceType": "RDS", 
        "Identifier": "db-loadtest-0", 
        "StartTime": 1680583486.584, 
        "AnalysisReportId": "report-0d99cc91c4422ee61", 
        "EndTime": 1680587086.584, 
        "CreateTime": 1680587087.139, 
        "Insights": [
           ... (Condensed for space)
        ]
    }
}
```

## Listing all the performance analysis reports for the DB instance
<a name="USER_PerfInsights.API.Examples.ListPerfAnalysisReports"></a>

The following example lists all the available performance analysis reports for the `db-loadtest-0` database.

```
aws pi list-performance-analysis-reports \
--service-type RDS \
--identifier db-loadtest-0 \
--region us-west-2
```

The response lists all the reports with the report ID, status, and time period details.

```
{
    "AnalysisReports": [
        {
            "Status": "Succeeded", 
            "EndTime": 1680587086.584, 
            "CreationTime": 1680587087.139, 
            "StartTime": 1680583486.584, 
            "AnalysisReportId": "report-0d99cc91c4422ee61"
        }, 
        {
            "Status": "Succeeded", 
            "EndTime": 1681491137.914, 
            "CreationTime": 1681491145.973, 
            "StartTime": 1681487537.914, 
            "AnalysisReportId": "report-002633115cc002233"
        }, 
        {
            "Status": "Succeeded", 
            "EndTime": 1681493499.849, 
            "CreationTime": 1681493507.762, 
            "StartTime": 1681489899.849, 
            "AnalysisReportId": "report-043b1e006b47246f9"
        }, 
        {
            "Status": "InProgress", 
            "EndTime": 1682979503.0, 
            "CreationTime": 1682979618.994, 
            "StartTime": 1682969503.0, 
            "AnalysisReportId": "report-01ad15f9b88bcbd56"
        }
    ]
}
```

## Deleting a performance analysis report
<a name="USER_PerfInsights.API.Examples.DeletePerfAnalysisReport"></a>

The following example deletes the analysis report for the `db-loadtest-0` database.

```
aws pi delete-performance-analysis-report \
--service-type RDS \
--identifier db-loadtest-0 \
--analysis-report-id report-0d99cc91c4422ee61 \
--region us-west-2
```

## Adding tag to a performance analysis report
<a name="USER_PerfInsights.API.Examples.TagPerfAnalysisReport"></a>

The following example adds a tag with a key `name` and value `test-tag` to the `report-01ad15f9b88bcbd56` report.

```
aws pi tag-resource \
--service-type RDS \
--resource-arn arn:aws:pi:us-west-2:356798100956:perf-reports/RDS/db-loadtest-0/report-01ad15f9b88bcbd56 \
--tags Key=name,Value=test-tag \
--region us-west-2
```

## Listing all the tags for a performance analysis report
<a name="USER_PerfInsights.API.Examples.ListTagsPerfAnalysisReport"></a>

The following example lists all the tags for the `report-01ad15f9b88bcbd56` report.

```
aws pi list-tags-for-resource \
--service-type RDS \
--resource-arn arn:aws:pi:us-west-2:356798100956:perf-reports/RDS/db-loadtest-0/report-01ad15f9b88bcbd56 \
--region us-west-2
```

The response lists the value and key for all the tags added to the report:

```
{
    "Tags": [
        {
            "Value": "test-tag", 
            "Key": "name"
        }
    ]
}
```

## Deleting tags from a performance analysis report
<a name="USER_PerfInsights.API.Examples.UntagPerfAnalysisReport"></a>

The following example deletes the `name` tag from the `report-01ad15f9b88bcbd56` report.

```
aws pi untag-resource \
--service-type RDS \
--resource-arn arn:aws:pi:us-west-2:356798100956:perf-reports/RDS/db-loadtest-0/report-01ad15f9b88bcbd56 \
--tag-keys name \
--region us-west-2
```

After the tag is deleted, calling the `list-tags-for-resource` API doesn't list this tag.

# Logging Performance Insights calls using AWS CloudTrail
<a name="USER_PerfInsights.CloudTrail"></a>

Performance Insights runs with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Performance Insights. CloudTrail captures all API calls for Performance Insights as events. This capture includes calls from the Amazon RDS console and from code calls to the Performance Insights API operations. 

If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Performance Insights. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the data collected by CloudTrail, you can determine certain information. This information includes the request that was made to Performance Insights, the IP address the request was made from, who made the request, and when it was made. It also includes additional details. 

To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).

## Working with Performance Insights information in CloudTrail
<a name="USER_PerfInsights.CloudTrail.service-name-info"></a>

CloudTrail is enabled on your AWS account when you create the account. When activity occurs in Performance Insights, that activity is recorded in a CloudTrail event along with other AWS service events in the CloudTrail console in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing Events with CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) in *AWS CloudTrail User Guide.*

For an ongoing record of events in your AWS account, including events for Performance Insights, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all AWS Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following topics in *AWS CloudTrail User Guide:*
+ [Overview for Creating a Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Supported Services and Integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuring Amazon SNS Notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Receiving CloudTrail Log Files from Multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail Log Files from Multiple Accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)

All Performance Insights operations are logged by CloudTrail and are documented in the [Performance Insights API Reference](https://docs.aws.amazon.com/performance-insights/latest/APIReference/Welcome.html). For example, calls to the `DescribeDimensionKeys` and `GetResourceMetrics` operations generate entries in the CloudTrail log files. 

Every event or log entry contains information about who generated the request. The identity information helps you determine the following: 
+ Whether the request was made with root or IAM user credentials.
+ Whether the request was made with temporary security credentials for a role or federated user.
+ Whether the request was made by another AWS service.

For more information, see the [CloudTrail userIdentity Element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).

## Performance Insights log file entries
<a name="USER_PerfInsights.CloudTrail.service-name-entries"></a>

A *trail* is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An *event* represents a single request from any source. Each event includes information about the requested operation, the date and time of the operation, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order. 

The following example shows a CloudTrail log entry that demonstrates the `GetResourceMetrics` operation.

```
{
    "eventVersion": "1.05",
    "userIdentity": {
        "type": "IAMUser",
         "principalId": "AKIAIOSFODNN7EXAMPLE",
        "arn": "arn:aws:iam::123456789012:user/johndoe",
        "accountId": "123456789012",
        "accessKeyId": "AKIAI44QH8DHBEXAMPLE",
        "userName": "johndoe"
    },
    "eventTime": "2019-12-18T19:28:46Z",
    "eventSource": "pi.amazonaws.com",
    "eventName": "GetResourceMetrics",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "72.21.198.67",
    "userAgent": "aws-cli/1.16.240 Python/3.7.4 Darwin/18.7.0 botocore/1.12.230",
    "requestParameters": {
        "identifier": "db-YTDU5J5V66X7CXSCVDFD2V3SZM",
        "metricQueries": [
            {
                "metric": "os.cpuUtilization.user.avg"
            },
            {
                "metric": "os.cpuUtilization.idle.avg"
            }
        ],
        "startTime": "Dec 18, 2019 5:28:46 PM",
        "periodInSeconds": 60,
        "endTime": "Dec 18, 2019 7:28:46 PM",
        "serviceType": "RDS"
    },
    "responseElements": null,
    "requestID": "9ffbe15c-96b5-4fe6-bed9-9fccff1a0525",
    "eventID": "08908de0-2431-4e2e-ba7b-f5424f908433",
    "eventType": "AwsApiCall",
    "recipientAccountId": "123456789012"
}
```

# Performance Insights API and interface VPC endpoints (AWS PrivateLink)
<a name="pi-vpc-interface-endpoints"></a>

You can use AWS PrivateLink to create a private connection between your VPC and Amazon RDS Performance Insights. You can access Performance Insights as if it were in your VPC, without the use of an internet gateway, NAT device, VPN connection, or Direct Connect connection. Instances in your VPC don't need public IP addresses to access Performance Insights.

You establish this private connection by creating an *interface endpoint*, powered by AWS PrivateLink. We create an endpoint network interface in each subnet that you enable for the interface endpoint. These are requester-managed network interfaces that serve as the entry point for traffic destined for Performance Insights.

For more information, see [Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) in the *AWS PrivateLink Guide*.

## Considerations for Performance Insights
<a name="vpc-endpoint-considerations"></a>

Before you set up an interface endpoint for Performance Insights, review [Considerations](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) in the *AWS PrivateLink Guide*.

Performance Insights supports making calls to all of its API actions through the interface endpoint.

By default, full access to Performance Insights is allowed through the interface endpoint. To control traffic to Performance Insights through the interface endpoint, associate a security group with the endpoint network interfaces.

## Availability
<a name="rds-and-vpc-interface-endpoints-availability"></a>

Performance Insights API currently supports VPC endpoints in AWS Regions that support Performance Insights. For information about Performance Insights availability, see [Supported Regions and Aurora DB engines for Performance Insights](Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.md).

## Create an interface endpoint for Performance Insights
<a name="vpc-endpoint-create"></a>

You can create an interface endpoint for Performance Insights using either the Amazon VPC console or the AWS Command Line Interface (AWS CLI). For more information, see [Create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) in the *AWS PrivateLink Guide*.

Create an interface endpoint for Performance Insights using the following service name:

If you enable private DNS for the interface endpoint, you can make API requests to Performance Insights using its default Regional DNS name. For example, `pi.us-east-1.amazonaws.com`.

## Creating a VPC endpoint policy for Performance Insights API
<a name="vpc-endpoint-policy"></a>

An endpoint policy is an IAM resource that you can attach to an interface endpoint. The default endpoint policy allows full access to Performance Insights through the interface endpoint. To control the access allowed to Performance Insights from your VPC, attach a custom endpoint policy to the interface endpoint.

An endpoint policy specifies the following information:
+ The principals that can perform actions (AWS accounts, IAM users, and IAM roles).
+ The actions that can be performed.
+ The resources on which the actions can be performed.

For more information, see [Control access to services using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) in the *AWS PrivateLink Guide*.

**Example: VPC endpoint policy for Performance Insights actions**  
The following is an example of a custom endpoint policy. When you attach this policy to your interface endpoint, it grants access to the listed Performance Insights actions for all principals on all resources.

```
{
   "Statement":[
      {
         "Principal":"*",
         "Effect":"Allow",
         "Action":[
            "rds:CreatePerformanceAnalysisReport",
            "rds:DeletePerformanceAnalysisReport",
            "rds:GetPerformanceAnalysisReport"
         ],
         "Resource":"*"
      }
   ]
}
```

**Example: VPC endpoint policy that denies all access from a specified AWS account**  
The following VPC endpoint policy denies AWS account `123456789012` all access to resources using the endpoint. The policy allows all actions from other accounts.

```
{
  "Statement": [
    {
      "Action": "*",
      "Effect": "Allow",
      "Resource": "*",
      "Principal": "*"
    },
    {
      "Action": "*",
      "Effect": "Deny",
      "Resource": "*",
      "Principal": { "AWS": [ "123456789012" ] }
     }
   ]
}
```

## IP addressing for Performance Insights
<a name="pi-ip-addressing"></a>

IP addresses enable resources in your VPC to communicate with each other, and with resources over the internet. Performance Insights supports both IPv4 and IPv6 addressing protocols. By default, Performance Insights and Amazon VPC use the IPv4 addressing protocol. You can't turn off this behavior. When you create a VPC, make sure to specify an IPv4 CIDR block (a range of private IPv4 addresses). 

You can optionally assign an IPv6 CIDR block to your VPC and subnets, and assign IPv6 addresses from that block to RDS resources in your subnet. Support for the IPv6 protocol expands the number of supported IP addresses. By using the IPv6 protocol, you ensure that you have sufficient available addresses for the future growth of the internet. New and existing RDS resources can use IPv4 and IPv6 addresses within your VPC. Configuring, securing, and translating network traffic between the two protocols used in different parts of an application can cause operational overhead. You can standardize on the IPv6 protocol for Amazon RDS resources to simplify your network configuration. For more information about service endpoints and quotas, see [Amazon Relational Database Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/rds-service.html).

For more information about Aurora IP addressing, see [Aurora IP addressing](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.IP_addressing).

# Analyzing Aurora performance anomalies with Amazon DevOps Guru for Amazon RDS
<a name="devops-guru-for-rds"></a>

Amazon DevOps Guru is a fully managed operations service that helps developers and operators improve the performance and availability of their applications. DevOps Guru offloads the tasks associated with identifying operational issues so that you can quickly implement recommendations to improve your application. For more information, see [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) in the *Amazon DevOps Guru User Guide*.

DevOps Guru detects, analyzes, and makes recommendations for existing operational issues for all Amazon RDS DB engines. DevOps Guru for RDS extends this capability by applying machine learning to Performance Insights metrics for Amazon Aurora databases. These monitoring features allow DevOps Guru for RDS to detect and diagnose performance bottlenecks and recommend specific corrective actions. DevOps Guru for RDS can also detect problematic conditions in your Aurora databases before they occur.

You can now view these recommendations in RDS console. For more information, see [Recommendations from Amazon Aurora](monitoring-recommendations.md).

**Important**  
Amazon DevOps Guru isn't available for Aurora Serverless DB clusters.

The following video is an overview of DevOps Guru for RDS.

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


For a deep dive on this subject, see [Amazon DevOps Guru for RDS under the hood.](https://aws.amazon.com/blogs/database/amazon-devops-guru-for-rds-under-the-hood/)

**Topics**
+ [Benefits of DevOps Guru for RDS](#devops-guru-for-rds.benefits)
+ [How DevOps Guru for RDS works](#devops-guru-for-rds.how-it-works)
+ [Setting up DevOps Guru for RDS](#devops-guru-for-rds.configuring)

## Benefits of DevOps Guru for RDS
<a name="devops-guru-for-rds.benefits"></a>

If you're responsible for an Amazon Aurora database, you might not know that an event or regression that is affecting that database is occurring. When you learn about the issue, you might not know why it's occurring or what to do about it. Rather than turning to a database administrator (DBA) for help or relying on third-party tools, you can follow recommendations from DevOps Guru for RDS. 

You gain the following advantages from the detailed analysis of DevOps Guru for RDS:

**Fast diagnosis**  
DevOps Guru for RDS continuously monitors and analyzes database telemetry. Performance Insights, Enhanced Monitoring, and Amazon CloudWatch collect telemetry data for your database cluster. DevOps Guru for RDS uses statistical and machine learning techniques to mine this data and detect anomalies. To learn more about telemetry data, see [Monitoring DB load with Performance Insights on Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html) and [Monitoring OS metrics with Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Monitoring.OS.html) in the *Amazon Aurora User Guide* .

**Fast resolution**  
Each anomaly identifies the performance issue and suggests avenues of investigation or corrective actions. For example, DevOps Guru for RDS might recommend that you investigate specific wait events. Or it might recommend that you tune your application pool settings to limit the number of database connections. Based on these recommendations, you can resolve performance issues more quickly than by troubleshooting manually.

**Proactive insights**  
DevOps Guru for RDS uses metrics from your resources to detect potentially problematic behavior before it becomes a bigger problem. For example, it can detect when your database is using an increasing number of on-disk temporary tables, which could start to impact performance. DevOps Guru then provides recommendations to help you address issues before they become bigger problems.

**Deep knowledge of Amazon engineers and machine learning**  
To detect performance issues and help you resolve bottlenecks, DevOps Guru for RDS relies on machine learning (ML) and advanced mathematical formulas. Amazon database engineers contributed to the development of the DevOps Guru for RDS findings, which encapsulate many years of managing hundreds of thousands of databases. By drawing on this collective knowledge, DevOps Guru for RDS can teach you best practices.

## How DevOps Guru for RDS works
<a name="devops-guru-for-rds.how-it-works"></a>

DevOps Guru for RDS collects data about your Aurora databases from Amazon RDS Performance Insights. The most important metric is `DBLoad`. DevOps Guru for RDS consumes the Performance Insights metrics, analyzes them with machine learning, and publishes insights to the dashboard.

An *insight* is a collection of related anomalies that were detected by DevOps Guru.

In DevOps Guru for RDS, an *anomaly* is a pattern that deviates from what is considered normal performance for your Amazon Aurora database. 

### Proactive insights
<a name="devops-guru-for-rds.how-it-works.insights.proactive"></a>

A *proactive insight* lets you know about problematic behavior before it occurs. It contains anomalies with recommendations and related metrics to help you address issues in your Amazon Aurora databases before become bigger problems. These insights are published in the DevOps Guru dashboard.

For example, DevOps Guru might detect that your Aurora PostgreSQL database is creating many on-disk temporary tables. If not addressed, this trend might lead to performance issues. Each proactive insight includes recommendations for corrective behavior and links to relevant topics in either [Tuning Aurora MySQL with Amazon DevOps Guru proactive insights](MySQL.Tuning.proactive-insights.md) or [Tuning Aurora PostgreSQL with Amazon DevOps Guru proactive insights](PostgreSQL.Tuning_proactive_insights.md). For more information, see [Working with insights in DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-insights.html) in the *Amazon DevOps Guru User Guide*. 

### Reactive insights
<a name="devops-guru-for-rds.how-it-works.insights.reactive"></a>

A *reactive insight* identifies anomalous behavior as it occurs. If DevOps Guru for RDS finds performance issues in your Amazon Aurora DB instances, it publishes a reactive insight in the DevOps Guru dashboard. For more information, see [Working with insights in DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-insights.html) in the *Amazon DevOps Guru User Guide*.

#### Causal anomalies
<a name="devops-guru-for-rds.how-it-works.anomalies.causal"></a>

A *causal anomaly* is a top-level anomaly within a reactive insight. **Database load (DB load)** is the causal anomaly for DevOps Guru for RDS. 

An anomaly measures performance impact by assigning a severity level of **High**, **Medium**, or **Low**. To learn more, see [Key concepts for DevOps Guru for RDS](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-rds.overview.definitions.html) in the *Amazon DevOps Guru User Guide*.

If DevOps Guru detects a current anomaly on your DB instance, you're alerted in the **Databases** page of the RDS console. The console also alerts you to anomalies that occurred in the past 24 hours. To go to the anomaly page from the RDS console, choose the link in the alert message. The RDS console also alerts you in the page for your Amazon Aurora DB cluster .

#### Contextual anomalies
<a name="devops-guru-for-rds.how-it-works.anomalies.contextual"></a>

A *contextual anomaly* is a finding within **Database load (DB load)** that is related to a reactive insight. Each contextual anomaly describes a specific Amazon Aurora performance issue that requires investigation. For example, DevOps Guru for RDS might recommend that you consider increasing CPU capacity or investigate wait events that are contributing to DB load.

**Important**  
We recommend that you test any changes on a test instance before modifying a production instance. In this way, you understand the impact of the change.

To learn more, see [Analyzing anomalies in Amazon RDS](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-rds.analyzing.html) in the *Amazon DevOps Guru User Guide*.

## Setting up DevOps Guru for RDS
<a name="devops-guru-for-rds.configuring"></a>

To allow DevOps Guru for Amazon RDS to publish insights for an Amazon Aurora database, complete the following tasks.

**Topics**
+ [Configuring IAM access policies for DevOps Guru for RDS](#devops-guru-for-rds.configuring.access)
+ [Turning on Performance Insights for your Aurora DB instances](#devops-guru-for-rds.configuring.performance-insights)
+ [Turning on DevOps Guru and specifying resource coverage](#devops-guru-for-rds.configuring.coverage)

### Configuring IAM access policies for DevOps Guru for RDS
<a name="devops-guru-for-rds.configuring.access"></a>

To view alerts from DevOps Guru in the RDS console, your AWS Identity and Access Management (IAM) user or role must have either of the following policies:
+ The AWS managed policy `AmazonDevOpsGuruConsoleFullAccess`
+ The AWS managed policy `AmazonDevOpsGuruConsoleReadOnlyAccess` and either of the following policies:
  + The AWS managed policy `AmazonRDSFullAccess`
  + A customer managed policy that includes `pi:GetResourceMetrics` and `pi:DescribeDimensionKeys`

For more information, see [Configuring access policies for Performance Insights](USER_PerfInsights.access-control.md).

### Turning on Performance Insights for your Aurora DB instances
<a name="devops-guru-for-rds.configuring.performance-insights"></a>

DevOps Guru for RDS relies on Performance Insights for its data. Without Performance Insights, DevOps Guru publishes anomalies, but doesn't include the detailed analysis and recommendations.

When you create an Aurora DB cluster or modify a cluster instance, you can turn on Performance Insights. For more information, see [Turning Performance Insights on and off for Aurora](USER_PerfInsights.Enabling.md).

### Turning on DevOps Guru and specifying resource coverage
<a name="devops-guru-for-rds.configuring.coverage"></a>

You can turn on DevOps Guru to have it monitor your  Amazon Aurora databases in either of the following ways.

**Topics**
+ [Turning on DevOps Guru in the RDS console](#devops-guru-for-rds.configuring.coverage.rds-console)
+ [Adding Aurora resources in the DevOps Guru console](#devops-guru-for-rds.configuring.coverage.guru-console)
+ [Adding Aurora resources using CloudFormation](#devops-guru-for-rds.configuring.coverage.cfn)

#### Turning on DevOps Guru in the RDS console
<a name="devops-guru-for-rds.configuring.coverage.rds-console"></a>

You can take multiple paths in the Amazon RDS console to turn on DevOps Guru.

**Topics**
+ [Turning on DevOps Guru when you create an Aurora database](#devops-guru-for-rds.configuring.coverage.rds-console.create)
+ [Turning on DevOps Guru from the notification banner](#devops-guru-for-rds.configuring.coverage.rds-console.existing)
+ [Responding to a permissions error when you turn on DevOps Guru](#devops-guru-for-rds.configuring.coverage.rds-console.error)

##### Turning on DevOps Guru when you create an Aurora database
<a name="devops-guru-for-rds.configuring.coverage.rds-console.create"></a>

The creation workflow includes a setting that turns on DevOps Guru coverage for your database. This setting is turned on by default when you choose the **Production** template.

**To turn on DevOps Guru when you create an Aurora database**

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. Follow the steps in [Creating a DB cluster](Aurora.CreateInstance.md#Aurora.CreateInstance.Creating), up to but not including the step where you choose monitoring settings.

1. In **Monitoring**, choose **Turn on Performance Insights**. For DevOps Guru for RDS to provide detailed analysis of performance anomalies, Performance Insights must be turned on.

1. Choose **Turn on DevOps Guru**.  
![\[Turn on DevOps Guru when you create a DB cluster\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/devops-guru-enable-create.png)

1. Create a tag for your database so that DevOps Guru can monitor it. Do the following:
   + In the text field for **Tag key**, enter a name that begins with **Devops-Guru-**.
   + In the text field for **Tag value**, enter any value. For example, if you enter **rds-database-1** for the name of your Aurora database, you can also enter **rds-database-1** as the tag value.

   For more information about tags, see "[Use tags to identify resources in your DevOps Guru applications](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-resource-tags.html)" in the *Amazon DevOps Guru User Guide*.

1. Complete the remaining steps in [Creating a DB cluster](Aurora.CreateInstance.md#Aurora.CreateInstance.Creating).

##### Turning on DevOps Guru from the notification banner
<a name="devops-guru-for-rds.configuring.coverage.rds-console.existing"></a>

If your resources aren't covered by DevOps Guru, Amazon RDS notifies you with a banner in the following locations:
+ The **Monitoring** tab of a DB cluster instance
+ The Performance Insights dashboard

![\[DevOps Guru banner\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/devops-guru-enable-banner.png)


**To turn on DevOps Guru for your Aurora database**

1. In the banner, choose **Turn on DevOps Guru for RDS**.

1. Enter a tag key name and value. For more information about tags, see "[Use tags to identify resources in your DevOps Guru applications](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-resource-tags.html)" in the *Amazon DevOps Guru User Guide*.  
![\[Turn on DevOps Guru in the RDS console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/devops-guru-turn-on.png)

1. Choose **Turn on DevOps Guru**.

##### Responding to a permissions error when you turn on DevOps Guru
<a name="devops-guru-for-rds.configuring.coverage.rds-console.error"></a>

If you turn on DevOps Guru from the RDS console when you create a database, RDS might display the following banner about missing permissions.

![\[Banner with a missing permissions error\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/devops-guru-permissions-error.png)


**To respond to a permissions error**

1. Grant your IAM user or role the user managed role `AmazonDevOpsGuruConsoleFullAccess`. For more information, see [Configuring IAM access policies for DevOps Guru for RDS](#devops-guru-for-rds.configuring.access).

1. Open the RDS console.

1. In the navigation pane, choose **Performance Insights**.

1. Choose a DB instance in the cluster that you just created.

1. Choose the switch to turn on **DevOps Guru for RDS**.  
![\[Choose the switch to turn on DevOps Guru for RDS\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/devops-guru-pi-toggle-off.png)

1. Choose a tag value. For more information, see "[Use tags to identify resources in your DevOps Guru applications](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-resource-tags.html)" in the *Amazon DevOps Guru User Guide*.  
![\[Turn on DevOps Guru in the Amazon RDS console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/devops-guru-turn-on.png)

1. Choose **Turn on DevOps Guru**.

#### Adding Aurora resources in the DevOps Guru console
<a name="devops-guru-for-rds.configuring.coverage.guru-console"></a>

You can specify your DevOps Guru resource coverage on the DevOps Guru console. Follow the step described in [Specify your DevOps Guru resource coverage](https://docs.aws.amazon.com/devops-guru/latest/userguide/choose-coverage.html) in the *Amazon DevOps Guru User Guide*. When you edit your analyzed resources, choose one of the following options:
+ Choose **All account resources** to analyze all supported resources, including the Aurora databases, in your AWS account and Region.
+ Choose **CloudFormation stacks** to analyze the Aurora databases that are in stacks you choose. For more information, see [Use AWS CloudFormation stacks to identify resources in your DevOps Guru applications](https://docs.aws.amazon.com//devops-guru/latest/userguide/working-with-cfn-stacks.html) in the *Amazon DevOps Guru User Guide*.
+ Choose **Tags** to analyze the Aurora databases that you have tagged. For more information, see [Use tags to identify resources in your DevOps Guru applications](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-resource-tags.html) in the *Amazon DevOps Guru User Guide*.

For more information, see [Enable DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/getting-started-enable-service.html) in the *Amazon DevOps Guru User Guide*.

#### Adding Aurora resources using CloudFormation
<a name="devops-guru-for-rds.configuring.coverage.cfn"></a>

You can use tags to add coverage for your Aurora resources to your CloudFormation templates. The following procedure assumes that you have a CloudFormation template both for your Aurora DB instance and DevOps Guru stack.

**To specify an Aurora DB instance using a CloudFormation tag**

1. In the CloudFormation template for your DB instance, define a tag using a key/value pair.

   The following example assigns the value `my-aurora-db-instance1` to `Devops-guru-cfn-default` for an Aurora DB instance.

   ```
   MyAuroraDBInstance1:
     Type: "AWS::RDS::DBInstance"
     Properties:
       DBClusterIdentifier: my-aurora-db-cluster
       DBInstanceIdentifier: my-aurora-db-instance1
       Tags:
         - Key: Devops-guru-cfn-default
           Value: devopsguru-my-aurora-db-instance1
   ```

1. In the CloudFormation template for your DevOps Guru stack, specify the same tag in your resource collection filter.

   The following example configures DevOps Guru to provide coverage for the resource with the tag value `my-aurora-db-instance1`.

   ```
   DevOpsGuruResourceCollection:
     Type: AWS::DevOpsGuru::ResourceCollection
     Properties:
       ResourceCollectionFilter:
         Tags:
           - AppBoundaryKey: "Devops-guru-cfn-default"
             TagValues:
             - "devopsguru-my-aurora-db-instance1"
   ```

   The following example provides coverage for all resources within the application boundary `Devops-guru-cfn-default`.

   ```
   DevOpsGuruResourceCollection:
     Type: AWS::DevOpsGuru::ResourceCollection
     Properties:
       ResourceCollectionFilter:
         Tags:
           - AppBoundaryKey: "Devops-guru-cfn-default"
             TagValues:
             - "*"
   ```

For more information, see [AWS::DevOpsGuru::ResourceCollection](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-devopsguru-resourcecollection.html) and [AWS::RDS::DBInstance](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbinstance.html) in the *CloudFormation User Guide*.

# Monitoring OS metrics with Enhanced Monitoring
<a name="USER_Monitoring.OS"></a>

With Enhanced Monitoring, you can monitor the operating system of your DB instance in real time. When you want to see how different processes or threads use the CPU, Enhanced Monitoring metrics are useful.

**Topics**
+ [Overview of Enhanced Monitoring](#USER_Monitoring.OS.overview)
+ [Setting up and enabling Enhanced Monitoring](USER_Monitoring.OS.Enabling.md)
+ [Viewing OS metrics in the RDS console](USER_Monitoring.OS.Viewing.md)
+ [Viewing OS metrics using CloudWatch Logs](USER_Monitoring.OS.CloudWatchLogs.md)

## Overview of Enhanced Monitoring
<a name="USER_Monitoring.OS.overview"></a>

Amazon RDS provides metrics in real time for the operating system (OS) that your DB instance runs on. You can view all the system metrics and process information for your RDS DB instances on the console. You can manage which metrics you want to monitor for each instance and customize the dashboard according to your requirements. For descriptions of the Enhanced Monitoring metrics, see [OS metrics in Enhanced Monitoring](USER_Monitoring-Available-OS-Metrics.md).

RDS delivers the metrics from Enhanced Monitoring into your Amazon CloudWatch Logs account. You can create metrics filters in CloudWatch from CloudWatch Logs and display the graphs on the CloudWatch dashboard. You can consume the Enhanced Monitoring JSON output from CloudWatch Logs in a monitoring system of your choice. For more information, see [Enhanced Monitoring](https://aws.amazon.com/rds/faqs/#Enhanced_Monitoring) in the Amazon RDS FAQs.

**Topics**
+ [Differences between CloudWatch and Enhanced Monitoring metrics](#USER_Monitoring.OS.CloudWatchComparison)
+ [Retention of Enhanced Monitoring metrics](#USER_Monitoring.OS.retention)
+ [Cost of Enhanced Monitoring](#USER_Monitoring.OS.cost)

### Differences between CloudWatch and Enhanced Monitoring metrics
<a name="USER_Monitoring.OS.CloudWatchComparison"></a>

A *hypervisor* creates and runs virtual machines (VMs). Using a hypervisor, an instance can support multiple guest VMs by virtually sharing memory and CPU. CloudWatch gathers metrics about CPU utilization from the hypervisor for a DB instance. In contrast, Enhanced Monitoring gathers its metrics from an agent on the DB instance.

You might find differences between the CloudWatch and Enhanced Monitoring measurements, because the hypervisor layer performs a small amount of work. The differences can be greater if your DB instances use smaller instance classes. In this scenario, more virtual machines (VMs) are probably managed by the hypervisor layer on a single physical instance.

For descriptions of the Enhanced Monitoring metrics, see [OS metrics in Enhanced Monitoring](USER_Monitoring-Available-OS-Metrics.md). For more information about CloudWatch metrics, see the *[Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)*.

### Retention of Enhanced Monitoring metrics
<a name="USER_Monitoring.OS.retention"></a>

By default, Enhanced Monitoring metrics are stored for 30 days in the CloudWatch Logs. This retention period is different from typical CloudWatch metrics.

To modify the amount of time the metrics are stored in the CloudWatch Logs, change the retention for the `RDSOSMetrics` log group in the CloudWatch console. For more information, see [Change log data retention in CloudWatch logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) in the *Amazon CloudWatch Logs User Guide*.

### Cost of Enhanced Monitoring
<a name="USER_Monitoring.OS.cost"></a>

Enhanced Monitoring metrics are stored in the CloudWatch Logs instead of in CloudWatch metrics. The cost of Enhanced Monitoring depends on the following factors:
+ You are charged for Enhanced Monitoring only if you exceed the amount of data transfer and storage provided by Amazon CloudWatch Logs. Charges are based on CloudWatch Logs data transfer and storage rates.
+ The amount of information transferred for an RDS instance is directly proportional to the defined granularity for the Enhanced Monitoring feature. A smaller monitoring interval results in more frequent reporting of OS metrics and increases your monitoring cost. To manage costs, set different granularities for different instances in your accounts.
+ Usage costs for Enhanced Monitoring are applied for each DB instance that Enhanced Monitoring is enabled for. Monitoring a large number of DB instances is more expensive than monitoring only a few.
+ DB instances that support a more compute-intensive workload have more OS process activity to report and higher costs for Enhanced Monitoring.

For more information about pricing, see [Amazon CloudWatch pricing](https://aws.amazon.com/cloudwatch/pricing/).

# Setting up and enabling Enhanced Monitoring
<a name="USER_Monitoring.OS.Enabling"></a>

To use Enhanced Monitoring, you must create an IAM role, and then enable Enhanced Monitoring.

**Topics**
+ [Creating an IAM role for Enhanced Monitoring](#USER_Monitoring.OS.Enabling.Prerequisites)
+ [Turning Enhanced Monitoring on and off](#USER_Monitoring.OS.Enabling.Procedure)
+ [Protecting against the confused deputy problem](#USER_Monitoring.OS.confused-deputy)

## Creating an IAM role for Enhanced Monitoring
<a name="USER_Monitoring.OS.Enabling.Prerequisites"></a>

Enhanced Monitoring requires permission to act on your behalf to send OS metric information to CloudWatch Logs. You grant Enhanced Monitoring permissions using an AWS Identity and Access Management (IAM) role. You can either create this role when you enable Enhanced Monitoring or create it beforehand.

**Topics**
+ [Creating the IAM role when you enable Enhanced Monitoring](#USER_Monitoring.OS.Enabling.Prerequisites.creating-role-automatically)
+ [Creating the IAM role before you enable Enhanced Monitoring](#USER_Monitoring.OS.Enabling.Prerequisites.creating-role-manually)

### Creating the IAM role when you enable Enhanced Monitoring
<a name="USER_Monitoring.OS.Enabling.Prerequisites.creating-role-automatically"></a>

When you enable Enhanced Monitoring in the RDS console, Amazon RDS can create the required IAM role for you. The role is named `rds-monitoring-role`. RDS uses this role for the specified DB instance, read replica, or Multi-AZ DB cluster.

**To create the IAM role when enabling Enhanced Monitoring**

1. Follow the steps in [Turning Enhanced Monitoring on and off](#USER_Monitoring.OS.Enabling.Procedure).

1. Set **Monitoring Role** to **Default** in the step where you choose a role.

### Creating the IAM role before you enable Enhanced Monitoring
<a name="USER_Monitoring.OS.Enabling.Prerequisites.creating-role-manually"></a>

You can create the required role before you enable Enhanced Monitoring. When you enable Enhanced Monitoring, specify your new role's name. You must create this required role if you enable Enhanced Monitoring using the AWS CLI or the RDS API.

The user that enables Enhanced Monitoring must be granted the `PassRole` permission. For more information, see Example 2 in [Granting a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) in the *IAM User Guide*.<a name="USER_Monitoring.OS.IAMRole"></a>

**To create an IAM role for Amazon RDS enhanced monitoring**

1. Open the [IAM console](https://console.aws.amazon.com/iam/home?#home) at [https://console.aws.amazon.com](https://console.aws.amazon.com/).

1. In the navigation pane, choose **Roles**.

1. Choose **Create role**.

1. Choose the **AWS service** tab, and then choose **RDS** from the list of services.

1. Choose **RDS - Enhanced Monitoring**, and then choose **Next**.

1. Ensure that the **Permissions policies** shows **AmazonRDSEnhancedMonitoringRole**, and then choose **Next**.

1. For **Role name**, enter a name for your role. For example, enter **emaccess**.

   The trusted entity for your role is the AWS service **monitoring.rds.amazonaws.com**.

1. Choose **Create role**.

## Turning Enhanced Monitoring on and off
<a name="USER_Monitoring.OS.Enabling.Procedure"></a>

You can manage Enhanced Monitoring using the AWS Management Console, AWS CLI, or RDS API. You can set different granularities for metric collection on each DB cluster. You can also toggle Enhanced Monitoring for an existing DB cluster from the console.

### Console
<a name="USER_Monitoring.OS.Enabling.Procedure.Console"></a>

You can turn on Enhanced Monitoring when you create a DB cluster or read replica, or when you modify a DB cluster. If you modify a DB instance or cluster to turn on Enhanced Monitoring, you don't need to reboot your DB instance for the change to take effect. 

You can turn on Enhanced Monitoring in the RDS console when you do one of the following actions in the **Databases** page: 
+ **Create a DB cluster** – Choose **Create database**.
+ **Create a read replica** – Choose **Actions**, then **Create read replica**.
+ **Modify a DB instance or DB cluster ** – Choose **Modify**.

**Note**  
When you enable Enhanced Monitoring for a DB cluster, you can't manage Enhanced Monitoring for individual DB instances within the cluster.

If you are managing Enhanced Monitoring for individual DB instances in a DB cluster and the granularity is set to different values for different instances, your DB cluster is heterogeneous with respect to Enhanced Monitoring. In such cases, you can't modify the DB cluster to manage Enhanced Monitoring at the cluster level.

**To turn Enhanced Monitoring on or off in the RDS console**

1. Scroll to **Additional configuration**.

1. In **Monitoring**, choose **Enable Enhanced Monitoring** for your DB , cluster, or read replica. Enabling Enhanced Monitoring at the cluster level allows you manage Enhanced Monitoring settings and options at the cluster level. Cluster level settings apply to all DB instances the cluster. Deselect the option to disable Enhanced Monitoring at the cluster level. You can later modify Enhanced Monitoring settings for individual DB instances in the cluster. 

   In the **Create database** page, you can select to turn on Enhanced Monitoring at the cluster level.  
![\[Turn on Enhanced Monitoring during DB cluster creation with console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/em_cluster_enabling.png)

   If you don't enable Enhanced Monitoring while creating a cluster, you can modify the cluster In the **Modify DB cluster** page.  
![\[Turn on Performance Insights during DB cluster creation with console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/em_cluster_modifying.png)
**Note**  
You can't manage Enhanced Monitoring for an individual DB instance in a DB cluster that already has Enhanced Monitoring managed at the cluster level. 

1. You can't choose to manage Enhanced Monitoring at the cluster level if the cluster is heterogeneous with respect to Enhanced Monitoring. To manage Enhanced Monitoring at the cluster level, change the Enhanced Monitoring settings for each instance so they match. You can now choose to manage Enhanced Monitoring at the cluster level when you modify your cluster.

1. Set the **Monitoring Role** property to the IAM role that you created to permit Amazon RDS to communicate with Amazon CloudWatch Logs for you, or choose **Default** to have RDS create a role for you named `rds-monitoring-role`.

1. Set the **Granularity** property to the interval, in seconds, between points when metrics are collected for your DB instance, DB cluster, or read replica. The **Granularity** property can be set to one of the following values: `1`, `5`, `10`, `15`, `30`, or `60`.

   The fastest that the RDS console refreshes is every 5 seconds. If you set the granularity to 1 second in the RDS console, you still see updated metrics only every 5 seconds. You can retrieve 1-second metric updates by using CloudWatch Logs.

### AWS CLI
<a name="USER_Monitoring.OS.Enabling.Procedure.CLI"></a>

To turn on Enhanced Monitoring using the AWS CLI, in the following commands, set the `--monitoring-interval` option to a value other than `0` and set the `--monitoring-role-arn` option to the role you created in [Creating an IAM role for Enhanced Monitoring](#USER_Monitoring.OS.Enabling.Prerequisites).
+ [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [create-db-instance-read-replica](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html)
+ [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)

The `--monitoring-interval` option specifies the interval, in seconds, between points when Enhanced Monitoring metrics are collected. Valid values for the option are `0`, `1`, `5`, `10`, `15`, `30`, and `60`.

To turn off Enhanced Monitoring using the AWS CLI, set the `--monitoring-interval` option to `0` in these commands.

**Example**  
The following example turns on Enhanced Monitoring for a DB instance:  
For Linux, macOS, or Unix:  

```
aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --monitoring-interval 30 \
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess
```
For Windows:  

```
aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --monitoring-interval 30 ^
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess
```

**Example**  
The following example turns on Enhanced Monitoring for a DB cluster:  
For Linux, macOS, or Unix:  

```
aws rds modify-db-cluster \
    --db-cluster-identifier mydbinstance \
    --monitoring-interval 30 \
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess
```
For Windows:  

```
aws rds modify-db-cluster ^
    --db-cluster-identifier mydbinstance ^
    --monitoring-interval 30 ^
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess
```

**Example**  
The following example turns on Enhanced Monitoring for a Multi-AZ DB cluster:  
For Linux, macOS, or Unix:  

```
aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --monitoring-interval 30 \
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess
```
For Windows:  

```
aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --monitoring-interval 30 ^
    --monitoring-role-arn arn:aws:iam::123456789012:role/emaccess
```

### RDS API
<a name="USER_Monitoring.OS.Enabling.Procedure.API"></a>

To turn on Enhanced Monitoring using the RDS API, set the `MonitoringInterval` parameter to a value other than `0` and set the `MonitoringRoleArn` parameter to the role you created in [Creating an IAM role for Enhanced Monitoring](#USER_Monitoring.OS.Enabling.Prerequisites). Set these parameters in the following actions:
+ [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html)
+ [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [CreateDBInstanceReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html)
+ [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)

The `MonitoringInterval` parameter specifies the interval, in seconds, between points when Enhanced Monitoring metrics are collected. Valid values are `0`, `1`, `5`, `10`, `15`, `30`, and `60`.

To turn off Enhanced Monitoring using the RDS API, set `MonitoringInterval` to `0`.

## Protecting against the confused deputy problem
<a name="USER_Monitoring.OS.confused-deputy"></a>

The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account. For more information, see [The confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).

To limit the permissions to the resource that Amazon RDS can give another service, we recommend using the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in a trust policy for your Enhanced Monitoring role. If you use both global condition context keys, they must use the same account ID.

The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. For Amazon RDS, set `aws:SourceArn` to `arn:aws:rds:Region:my-account-id:db:dbname`.

The following example uses the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in a trust policy to prevent the confused deputy problem.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "monitoring.rds.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "aws:SourceArn": "arn:aws:rds:Region:my-123456789012:db:dbname"
        },
        "StringEquals": {
          "aws:SourceAccount": "my-123456789012"
        }
      }
    }
  ]
}
```

------

# Viewing OS metrics in the RDS console
<a name="USER_Monitoring.OS.Viewing"></a>

You can view OS metrics reported by Enhanced Monitoring in the RDS console by choosing **Enhanced monitoring** for **Monitoring**.

The following example shows the Enhanced Monitoring page. For descriptions of the Enhanced Monitoring metrics, see [OS metrics in Enhanced Monitoring](USER_Monitoring-Available-OS-Metrics.md).

![\[Dashboard view\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/metrics1.png)


If you want to see details for the processes running on your DB instance, choose **OS process list** for **Monitoring**.

The **Process List** view is shown following.

![\[Process list view\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/metrics2.png)


The Enhanced Monitoring metrics shown in the **Process list** view are organized as follows:
+ **RDS child processes** – Shows a summary of the RDS processes that support the DB instance, for example `aurora` for Amazon Aurora DB clusters. Process threads appear nested beneath the parent process. Process threads show CPU utilization only as other metrics are the same for all threads for the process. The console displays a maximum of 100 processes and threads. The results are a combination of the top CPU consuming and memory consuming processes and threads. If there are more than 50 processes and more than 50 threads, the console displays the top 50 consumers in each category. This display helps you identify which processes are having the greatest impact on performance.
+ **RDS processes** – Shows a summary of the resources used by the RDS management agent, diagnostics monitoring processes, and other AWS processes that are required to support RDS DB instances.
+ **OS processes** – Shows a summary of the kernel and system processes, which generally have minimal impact on performance.

The items listed for each process are:
+ **VIRT** – Displays the virtual size of the process.
+ **RES** – Displays the actual physical memory being used by the process.
+ **CPU%** – Displays the percentage of the total CPU bandwidth being used by the process.
+ **MEM%** – Displays the percentage of the total memory being used by the process.

The monitoring data that is shown in the RDS console is retrieved from Amazon CloudWatch Logs. You can also retrieve the metrics for a DB instance as a log stream from CloudWatch Logs. For more information, see [Viewing OS metrics using CloudWatch Logs](USER_Monitoring.OS.CloudWatchLogs.md).

Enhanced Monitoring metrics are not returned during the following: 
+ A failover of the DB instance.
+ Changing the instance class of the DB instance (scale compute).

Enhanced Monitoring metrics are returned during a reboot of a DB instance because only the database engine is rebooted. Metrics for the operating system are still reported.

# Viewing OS metrics using CloudWatch Logs
<a name="USER_Monitoring.OS.CloudWatchLogs"></a>

After you have enabled Enhanced Monitoring for your DB cluster, you can view the metrics for it using CloudWatch Logs, with each log stream representing a single DB instance or DB cluster being monitored. The log stream identifier is the resource identifier (`DbiResourceId`) for the DB instance or DB cluster.

**To view Enhanced Monitoring log data**

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. If necessary, choose the AWS Region that your DB cluster is in. For more information, see [Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html) in the *Amazon Web Services General Reference*.

1. Choose **Logs** in the navigation pane.

1. Choose **RDSOSMetrics** from the list of log groups.

1. Choose the log stream that you want to view from the list of log streams.

# Metrics reference for Amazon Aurora
<a name="metrics-reference"></a>

In this reference, you can find descriptions of Amazon Aurora metrics for Amazon CloudWatch, Performance Insights, and Enhanced Monitoring.

**Topics**
+ [Amazon CloudWatch metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md)
+ [Amazon CloudWatch dimensions for Aurora](dimensions.md)
+ [Availability of Aurora metrics in the Amazon RDS console](Aurora.Monitoring.Metrics.RDSAvailability.md)
+ [Amazon CloudWatch metrics for Amazon RDS Performance Insights](USER_PerfInsights.Cloudwatch.md)
+ [Performance Insights counter metrics](USER_PerfInsights_Counters.md)
+ [SQL statistics for Performance Insights](sql-statistics.md)
+ [OS metrics in Enhanced Monitoring](USER_Monitoring-Available-OS-Metrics.md)

# Amazon CloudWatch metrics for Amazon Aurora
<a name="Aurora.AuroraMonitoring.Metrics"></a>

The `AWS/RDS` namespace includes the following metrics that apply to database entities running on Amazon Aurora. Some metrics apply to either Aurora MySQL, Aurora PostgreSQL, or both. Furthermore, some metrics are specific to a DB cluster, primary DB instance, replica DB instance, or all DB instances.

For Aurora global database metrics, see [Amazon CloudWatch metrics for write forwarding in Aurora MySQL](aurora-global-database-write-forwarding-ams.md#aurora-global-database-write-forwarding-cloudwatch-ams) and [Amazon CloudWatch metrics for write forwarding in Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-cloudwatch-apg). For Aurora parallel query metrics, see [Monitoring parallel query for Aurora MySQL](aurora-mysql-parallel-query-monitoring.md).

**Topics**
+ [Cluster-level metrics for Amazon Aurora](#Aurora.AuroraMySQL.Monitoring.Metrics.clusters)
+ [Instance-level metrics for Amazon Aurora](#Aurora.AuroraMySQL.Monitoring.Metrics.instances)
+ [Amazon CloudWatch usage metrics for Amazon Aurora](#rds-metrics-usage)

## Cluster-level metrics for Amazon Aurora
<a name="Aurora.AuroraMySQL.Monitoring.Metrics.clusters"></a>

The following table describes metrics that are specific to Aurora clusters.


| Metric | Description | Applies to | Units | 
| --- | --- | --- | --- | 
|  `AuroraGlobalDBDataTransferBytes`  |  In an Aurora Global Database, the amount of redo log data transferred from the source AWS Region to a secondary AWS Region.  This metric is available only in secondary AWS Regions.   |  Aurora MySQL and Aurora PostgreSQL  |  Bytes  | 
|  `AuroraGlobalDBProgressLag`  |  In an Aurora Global Database, he measure of how far the secondary cluster's storage volume is behind the primary cluster's storage volume for both user transactions and system transactions.  This metric is available only in secondary AWS Regions.   |  Aurora MySQL and Aurora PostgreSQL  |  Milliseconds  | 
|  `AuroraGlobalDBReplicatedWriteIO`  |  In an Aurora Global Database, the number of write I/O operations replicated from the primary AWS Region to the cluster volume in a secondary AWS Region. The billing calculations for the secondary AWS Regions in a global database use `VolumeWriteIOPs` to account for writes performed within the cluster. The billing calculations for the primary AWS Region in a global database use `VolumeWriteIOPs` to account for the write activity within that cluster, and `AuroraGlobalDBReplicatedWriteIO` to account for cross-Region replication within the global database.  This metric is available only in secondary AWS Regions.   |  Aurora MySQL and Aurora PostgreSQL  |  Count  | 
|  `AuroraGlobalDBReplicationLag`  |  For an Aurora Global Database, the average time elapsed replicating updates between the primary cluster's replication server and the secondary cluster's replication server.  This metric is available only in secondary AWS Regions.   |  Aurora MySQL and Aurora PostgreSQL  |  Milliseconds  | 
|  `AuroraGlobalDBRPOLag`  |  In an Aurora Global Database, the recovery point objective (RPO) lag time. This metric measures how far the secondary cluster is behind the primary cluster for user transactions.  This metric is available only in secondary AWS Regions.   |  Aurora MySQL and Aurora PostgreSQL  |  Milliseconds  | 
|  `AuroraVolumeBytesLeftTotal`  |  The remaining available space for the cluster volume. As the cluster volume grows, this value decreases. If it reaches zero, the cluster reports an out-of-space error. If you want to detect whether your Aurora MySQL cluster is approaching the size limit of 128 tebibytes (TiB), this value is simpler and more reliable to monitor than `VolumeBytesUsed`. `AuroraVolumeBytesLeftTotal` takes into account storage used for internal housekeeping and other allocations that don't affect your storage billing.  |  Aurora MySQL  |  Bytes  | 
|  `BacktrackChangeRecordsCreationRate`  |  The number of backtrack change records created over 5 minutes for your DB cluster.  |  Aurora MySQL  |  Count per 5 minutes  | 
|  `BacktrackChangeRecordsStored`  |  The number of backtrack change records used by your DB cluster.  |  Aurora MySQL  |  Count  | 
|  `BackupRetentionPeriodStorageUsed`  |  The total amount of backup storage used to support the point-in-time restore feature within the Aurora DB cluster's backup retention window. This amount is included in the total reported by the `TotalBackupStorageBilled` metric. It is computed separately for each Aurora cluster. For instructions, see [Understanding Amazon Aurora backup storage usage](aurora-storage-backup.md).   |  Aurora MySQL and Aurora PostgreSQL  |  Bytes  | 
|  `ServerlessDatabaseCapacity`  |  The current capacity of an Aurora Serverless DB cluster.  |  Aurora MySQL and Aurora PostgreSQL  |  Count  | 
|  `SnapshotStorageUsed`  |  The total amount of backup storage consumed by all Aurora snapshots for an Aurora DB cluster outside its backup retention window. This amount is included in the total reported by the `TotalBackupStorageBilled` metric. It is computed separately for each Aurora cluster. For instructions, see [Understanding Amazon Aurora backup storage usage](aurora-storage-backup.md).   |  Aurora MySQL and Aurora PostgreSQL  |  Bytes  | 
|  `TotalBackupStorageBilled`  |  The total amount of backup storage in bytes for which you are billed for a given Aurora DB cluster. The metric includes the backup storage measured by the `BackupRetentionPeriodStorageUsed` and `SnapshotStorageUsed` metrics. This metric is computed separately for each Aurora cluster. For instructions, see [Understanding Amazon Aurora backup storage usage](aurora-storage-backup.md).   |  Aurora MySQL and Aurora PostgreSQL  |  Bytes  | 
|  `VolumeBytesUsed`  |  The amount of storage used by your Aurora DB cluster. This value affects the cost of the Aurora DB cluster (for pricing information, see the [Amazon RDS pricing page](http://aws.amazon.com/rds/pricing)).  This value doesn't reflect some internal storage allocations that don't affect storage billing. For Aurora MySQL you can anticipate out-of-space issues more accurately by testing whether `AuroraVolumeBytesLeftTotal` is approaching zero instead of comparing `VolumeBytesUsed` against the storage limit of 128 TiB. For clusters that are clones, the value of this metric depends on the amount of data added or changed on the clone. The metric can also increase or decrease when the original cluster is deleted, or as new clones are added or deleted. For details, see [Deleting a source cluster volume](Aurora.Managing.Clone.md#Aurora.Managing.Clone.Deleting)  Note that it doesn't make sense to choose a `--period` value that's small, because Amazon RDS collects this metrics at intervals, not continuously.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes  | 
|  `VolumeReadIOPs`  |  The number of billed read I/O operations from a cluster volume within a 5-minute interval. Billed read operations are calculated at the cluster volume level, aggregated from all instances in the Aurora DB cluster, and then reported at 5-minute intervals. The value is calculated by taking the value of the **Read operations** metric over a 5-minute period. You can determine the amount of billed read operations per second by taking the value of the **Billed read operations** metric and dividing by 300 seconds. For example, if the **Billed read operations** returns 13,686, then the billed read operations per second is 45 (13,686 / 300 = 45.62).  You accrue billed read operations for queries that request database pages that aren't in the buffer cache and must be loaded from storage. You might see spikes in billed read operations as query results are read from storage and then loaded into the buffer cache. Note that it doesn't make sense to choose a `--period` value that's small, because Amazon RDS collects this metrics at intervals, not continuously.   If your Aurora MySQL cluster uses parallel query, you might see an increase in `VolumeReadIOPS` values. Parallel queries don't use the buffer pool. Thus, although the queries are fast, this optimized processing can result in an increase in read operations and associated charges.    |  Aurora MySQL and Aurora PostgreSQL  |  Count per 5 minutes  | 
|  `VolumeWriteIOPs`  |  The number of write disk I/O operations to the cluster volume, reported at 5-minute intervals. For a detailed description of how billed write operations are calculated, see `VolumeReadIOPs`. Note that it doesn't make sense to choose a `--period` value that's small, because Amazon RDS collects this metrics at intervals, not continuously.  |  Aurora MySQL and Aurora PostgreSQL  |  Count per 5 minutes  | 

## Instance-level metrics for Amazon Aurora
<a name="Aurora.AuroraMySQL.Monitoring.Metrics.instances"></a>

The following instance-specific Amazon CloudWatch metrics apply to all Aurora MySQL and Aurora PostgreSQL instances unless noted otherwise.


| Metric | Description | Applies to | Units | 
| --- | --- | --- | --- | 
|  `AbortedClients`  | The number of client connections that have not been closed properly. |  Aurora MySQL  |  Count  | 
|  `ActiveTransactions`  |  The average number of current transactions executing on an Aurora database instance per second.  By default, Aurora doesn't enable this metric. To begin measuring this value, set `innodb_monitor_enable='all'` in the DB parameter group for a specific DB instance.   |  Aurora MySQL  |  Count per second  | 
|  `ACUUtilization`  |  The value of the `ServerlessDatabaseCapacity` metric divided by the maximum ACU value of the DB cluster. This metric is applicable only for Aurora Serverless v2.   |  Aurora MySQL and Aurora PostgreSQL  |  Percentage  | 
|  `AuroraBinlogReplicaLag`  |  The amount of time that a binary log replica DB cluster running on Aurora MySQL lags behind the binary log replication source. A lag means that the source is generating records faster than the replica can apply them. This metric reports different values depending on the engine version: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html) You can use this metric to monitor errors and replica lag in a cluster that acts as a binary log replica. The metric value indicates the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html) Because binary log replication only occurs on the writer instance of the cluster, we recommend using the version of this metric associated with the WRITER role. For more information about administering replication, see [Replicating Amazon Aurora MySQL DB clusters across AWS Regions](AuroraMySQL.Replication.CrossRegion.md). For more information about troubleshooting, see [ Amazon Aurora MySQL replication issues](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL).  |  Primary for Aurora MySQL  |  Seconds  | 
|  `AuroraDMLRejectedMasterFull`  |  The number of forwarded queries that are rejected because the session is full on the writer DB instance.  |  Primary for Aurora MySQL version 2  |  Count  | 
|  `AuroraDMLRejectedWriterFull`  |  The number of forwarded queries that are rejected because the session is full on the writer DB instance.  |  Primary for Aurora MySQL version 3  |  Count  | 
| `AuroraEstimatedSharedMemoryBytes` |  The estimated amount of shared buffer or buffer pool memory which was actively used during the last configured polling interval.  | Aurora PostgreSQL |  Bytes  | 
|  `AuroraMemoryHealthState`  |  Indicates the memory health state. A value of `0` equals `NORMAL`. A value of `10` equals `RESERVED`, which means that the server is approaching a critical level of memory usage. For more information, see [Troubleshooting out-of-memory issues for Aurora MySQL databases](AuroraMySQLOOM.md).  |  Aurora MySQL version 3.06.1 and higher  |  Gauge  | 
|  `AuroraMemoryNumDeclinedSqlTotal`  |  The incremental number of queries declined as part of out-of-memory (OOM) avoidance. For more information, see [Troubleshooting out-of-memory issues for Aurora MySQL databases](AuroraMySQLOOM.md).  |  Aurora MySQL version 3.06.1 and higher  |  Count  | 
|  `AuroraMemoryNumKillConnTotal`  |  The incremental number of connections closed as part of OOM avoidance. For more information, see [Troubleshooting out-of-memory issues for Aurora MySQL databases](AuroraMySQLOOM.md).  |  Aurora MySQL version 3.06.1 and higher  |  Count  | 
|  `AuroraMemoryNumKillQueryTotal`  |  The incremental number of queries ended as part of OOM avoidance. For more information, see [Troubleshooting out-of-memory issues for Aurora MySQL databases](AuroraMySQLOOM.md).  |  Aurora MySQL version 3.06.1 and higher  |  Count  | 
|  `AuroraMillisecondsSpentInOomRecovery`  |  The amount of time since the memory health dropped below the normal state. For more information, see [Troubleshooting out-of-memory issues for Aurora MySQL databases](AuroraMySQLOOM.md).  |  Aurora MySQL version 3.08.0 and higher  |  Milliseconds  | 
|  `AuroraNumOomRecoverySuccessful`  |  The number of times that the memory health was restored to the normal state. For more information, see [Troubleshooting out-of-memory issues for Aurora MySQL databases](AuroraMySQLOOM.md).  |  Aurora MySQL version 3.08.0 and higher  |  Count  | 
|  `AuroraNumOomRecoveryTriggered`  |  The number of times that the memory health dropped below the normal state. For more information, see [Troubleshooting out-of-memory issues for Aurora MySQL databases](AuroraMySQLOOM.md).  |  Aurora MySQL version 3.08.0 and higher  |  Count  | 
|  `AuroraOptimizedReadsCacheHitRatio`  |  The percentage of requests that are served by the Optimized Reads cache. The value is calculated using the following formula: `orcache_blks_hit/ (orcache_blks_hit + storage_blks_read)` When `AuroraOptimizedReadsCacheHitRatio` is 100%, it means that all pages were read from the optimized reads cache. If the `AuroraOptimizedReadsCacheHitRatio` is `0`, it means that no pages were read from the optimized reads cache.  |  Primary for Aurora PostgreSQL  |  Percentage  | 
|  `AuroraReplicaLag`  |  In a single-region Aurora cluster or Global Database primary cluster, the amount of time elapsed replicating updates to a replica instance from the writer instance in the same region. In a Global Database secondary cluster, the amount of time elapsed replicating updates to the replica instance and the secondary cluster's replication server in the same region.  |  Replica for Aurora MySQL and Aurora PostgreSQL  |  Milliseconds  | 
|  `AuroraReplicaLagMaximum`  |  The maximum amount of lag between the primary instance and any of the Aurora DB instance in the DB cluster. When read replicas are deleted or renamed, there can be a temporary spike in replication lag as the old resource undergoes a recycling process. To obtain an accurate representation of the replication lag during that period, we recommend that you monitor the `AuroraReplicaLag` metric on each read replica instance.  |  Primary for Aurora MySQL and Aurora PostgreSQL  |  Milliseconds  | 
|  `AuroraReplicaLagMinimum`  |  The minimum amount of lag between the primary instance and any of the Aurora DB instance in the DB cluster.  |  Primary for Aurora MySQL and Aurora PostgreSQL  |  Milliseconds  | 
|  `AuroraSlowConnectionHandleCount`  |  The number of connections that have waited two seconds or longer to start the handshake. This metric applies only to Aurora MySQL version 3.  |  Aurora MySQL  |  Count  | 
|  `AuroraSlowHandshakeCount`  |  The number of connections that have taken 50 milliseconds or longer to finish the handshake. This metric applies only to Aurora MySQL version 3.  |  Aurora MySQL  |  Count  | 
|  `BacktrackWindowActual`  |  The difference between the target backtrack window and the actual backtrack window.  |  Primary for Aurora MySQL  |  Minutes  | 
|  `BacktrackWindowAlert`  |  The number of times that the actual backtrack window is smaller than the target backtrack window for a given period of time.  |  Primary for Aurora MySQL  |  Count  | 
|  `BlockedTransactions`  |  The average number of transactions in the database that are blocked per second.  |  Aurora MySQL  |  Count per second  | 
|  `BufferCacheHitRatio`  |  The percentage of requests that are served by the buffer cache.  |  Aurora MySQL and Aurora PostgreSQL  |  Percentage  | 
|  `CommitLatency`  |  The average duration taken by the engine and storage to complete the commit operations.  |  Aurora MySQL and Aurora PostgreSQL  |  Milliseconds  | 
|  `CommitThroughput`  |  The average number of commit operations per second.  |  Aurora MySQL and Aurora PostgreSQL  |  Count per second  | 
|  `ConnectionAttempts`  |  The number of attempts to connect to an instance, whether successful or not.  |  Aurora MySQL  |  Count  | 
| `CPUCreditBalance`  |  The number of CPU credits that an instance has accumulated, reported at 5-minute intervals. You can use this metric to determine how long a DB instance can burst beyond its baseline performance level at a given rate. This metric applies only to these instance classes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html)  We recommend using the T DB instance classes only for development and test servers, or other non-production servers. For more details on the T instance classes, see [DB instance class types](Concepts.DBInstanceClass.Types.md).  Launch credits work the same way in Amazon RDS as they do in Amazon EC2. For more information, see [Launch credits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode-concepts.html#launch-credits) in the *Amazon Elastic Compute Cloud User Guide for Linux Instances*.  |  Aurora MySQL and Aurora PostgreSQL  |  Count  | 
| `CPUCreditUsage`  |  The number of CPU credits consumed during the specified period, reported at 5-minute intervals. This metric measures the amount of time during which physical CPUs have been used for processing instructions by virtual CPUs allocated to the DB instance.  This metric applies only to these instance classes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html)  We recommend using the T DB instance classes only for development and test servers, or other non-production servers. For more details on the T instance classes, see [DB instance class types](Concepts.DBInstanceClass.Types.md).   |  Aurora MySQL and Aurora PostgreSQL  |  Count  | 
| `CPUSurplusCreditBalance` |  The number of surplus credits that have been spent by an unlimited instance when its `CPUCreditBalance` value is zero. The `CPUSurplusCreditBalance` value is paid down by earned CPU credits. If the number of surplus credits exceeds the maximum number of credits that the instance can earn in a 24-hour period, the spent surplus credits above the maximum incur an additional charge. CPU credit metrics are available at a 5-minute frequency only.  |  Aurora MySQL and Aurora PostgreSQL  |  Credits (vCPU-minutes)   | 
| `CPUSurplusCreditsCharged` |  The number of spent surplus credits that are not paid down by earned CPU credits, and which thus incur an additional charge. Spent surplus credits are charged when any of the following occurs: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html) CPU credit metrics are available at a 5-minute frequency only.  |  Aurora MySQL and Aurora PostgreSQL  |  Credits (vCPU-minutes)  | 
|  `CPUUtilization`  |  The percentage of CPU used by an Aurora DB instance.  |  Aurora MySQL and Aurora PostgreSQL  |  Percentage  | 
|  `DatabaseConnections`  |  The number of client network connections to the database instance. The number of database sessions can be higher than the metric value because the metric value doesn't include the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html) |  Aurora MySQL and Aurora PostgreSQL  |  Count  | 
|  `DDLLatency`  |  The average duration of requests such as example, create, alter, and drop requests.  |  Aurora MySQL  |  Milliseconds  | 
|  `DDLThroughput`  |  The average number of DDL requests per second.  |  Aurora MySQL  |  Count per second  | 
|  `Deadlocks`  |  The average number of deadlocks in the database per second.  |  Aurora MySQL and Aurora PostgreSQL  |  Count per second  | 
|  `DeleteLatency`  |  The average duration of delete operations.  |  Aurora MySQL  |  Milliseconds  | 
|  `DeleteThroughput`  |  The average number of delete queries per second.  |  Aurora MySQL  |  Count per second  | 
|  `DiskQueueDepth`  |  The number of outstanding read/write requests waiting to access the disk.  |  Aurora MySQL and Aurora PostgreSQL  |  Count  | 
|  `DMLLatency`  |  The average duration of inserts, updates, and deletes.  |  Aurora MySQL  |  Milliseconds  | 
|  `DMLThroughput`  |  The average number of inserts, updates, and deletes per second.  |  Aurora MySQL  |  Count per second  | 
|  `EngineUptime`  |  The amount of time that the instance has been running.  |  Aurora MySQL and Aurora PostgreSQL  |  Seconds  | 
|  `FreeableMemory`  |  The amount of available random access memory. For Aurora MySQL and Aurora PostgreSQL databases, this metric reports the value of the `MemAvailable` field of `/proc/meminfo`.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes  | 
|  `FreeEphemeralStorage`  |  The amount of available Ephemeral NVMe storage.  |  Aurora PostgreSQL  |  Bytes  | 
|  `FreeLocalStorage`  |  The amount of local storage available. Unlike for other DB engines, for Aurora DB instances this metric reports the amount of storage available to each DB instance. This value depends on the DB instance class (for pricing information, see the [Amazon RDS pricing page](http://aws.amazon.com/rds/pricing)). You can increase the amount of free storage space for an instance by choosing a larger DB instance class for your instance. (This doesn't apply to Aurora Serverless v2.)  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes  | 
|  `InsertLatency`  |  The average duration of insert operations.  |  Aurora MySQL  |  Milliseconds  | 
|  `InsertThroughput`  |  The average number of insert operations per second.  |  Aurora MySQL  |  Count per second  | 
|  `LoginFailures`  |  The average number of failed login attempts per second.  |  Aurora MySQL  |  Count per second  | 
|  `MaximumUsedTransactionIDs`  |  The age of the oldest unvacuumed transaction ID, in transactions. If this value reaches 2,146,483,648 (2^31 - 1,000,000), the database is forced into read-only mode, to avoid transaction ID wraparound. For more information, see [Preventing transaction ID wraparound failures](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) in the PostgreSQL documentation.  |  Aurora PostgreSQL  |  Count  | 
|  `NetworkReceiveThroughput`  |  The amount of network throughput received from clients by each instance in the Aurora DB cluster. This throughput doesn't include network traffic between instances in the Aurora DB cluster and the cluster volume.  |  Aurora MySQL and Aurora PostgreSQL   |  Bytes per second (console shows Megabytes per second)  | 
|  `NetworkThroughput`  |  The amount of network throughput both received from and transmitted to clients by each instance in the Aurora DB cluster. This throughput doesn't include network traffic between instances in the Aurora DB cluster and the cluster volume.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes per second  | 
|  `NetworkTransmitThroughput`  |  The amount of network throughput sent to clients by each instance in the Aurora DB cluster. This throughput doesn't include network traffic between instances in the DB cluster and the cluster volume.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes per second (console shows Megabytes per second)  | 
|  `NumBinaryLogFiles`  |  The number of binlog files generated.  | Aurora MySQL |  Count  | 
|  `OldestReplicationSlotLag`  |  The lagging size of the replica lagging the most in terms of write-ahead log (WAL) data received.  |  Aurora PostgreSQL  |  Bytes  | 
|  `PurgeBoundary`  |  Transaction number up to which InnoDB purging is allowed. If this metric doesn't advance for extended periods of time, it's a good indication that InnoDB purging is blocked by long-running transactions. To investigate, check the active transactions on your Aurora MySQL DB cluster.  |  Aurora MySQL version 2, versions 2.11 and higher Aurora MySQL version 3, versions 3.08 and higher  | Count | 
|  `PurgeFinishedPoint`  |  Transaction number up to which InnoDB purging is performed. This metric can help you examine how fast InnoDB purging is progressing.  |  Aurora MySQL version 2, versions 2.11 and higher Aurora MySQL version 3, versions 3.08 and higher  | Count | 
|  `Queries`  |  The average number of queries executed per second.  |  Aurora MySQL  |  Count per second  | 
|  `RDSToAuroraPostgreSQLReplicaLag`  |  The lag when replicating updates from the primary RDS PostgreSQL instance to other nodes in the cluster.  |  Replica for Aurora PostgreSQL  |  Seconds  | 
|  `ReadIOPS`  |  The average number of disk I/O operations per second but the reports read and write separately, in 1-minute intervals.  |  Aurora MySQL and Aurora PostgreSQL  |  Count per second  | 
|  `ReadIOPSEphemeralStorage`  |  The average number of disk read I/O operations to Ephemeral NVMe storage.  |  Aurora PostgreSQL  |  Count per second  | 
|  `ReadLatency`  |  The average amount of time taken per disk I/O operation.  |  Aurora MySQL and Aurora PostgreSQL  |  Seconds  | 
|  `ReadLatencyEphemeralStorage`  |  The average amount of time taken per disk read I/O operation for Ephemeral NVMe storage.  |  Aurora PostgreSQL  |  Seconds  | 
|  `ReadThroughput`  |  The average number of bytes read from disk per second.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes per second  | 
|  `ReadThroughputEphemeralStorage`  |  The average number of bytes read from disk per second for Ephemeral NVMe storage.  |  Aurora PostgreSQL  |  Bytes per second  | 
|  `ReplicationSlotDiskUsage`  |  The amount of disk space consumed by replication slot files.   |  Aurora PostgreSQL  |  Bytes  | 
|  `ResultSetCacheHitRatio`  |  The percentage of requests that are served by the Resultset cache.  |  Aurora MySQL version 2  |  Percentage  | 
|  `RollbackSegmentHistoryListLength`  |  The undo logs that record committed transactions with delete-marked records. These records are scheduled to be processed by the InnoDB purge operation.  |  Aurora MySQL  |  Count  | 
|  `RowLockTime`  |  The total time spent acquiring row locks for InnoDB tables.  |  Aurora MySQL  |  Milliseconds  | 
|  `SelectLatency`  |  The average amount of time for select operations.  |  Aurora MySQL  |  Milliseconds  | 
|  `SelectThroughput`  |  The average number of select queries per second.  |  Aurora MySQL  |  Count per second  | 
|  `ServerlessDatabaseCapacity`  |  The current capacity of an Aurora Serverless DB cluster.  |  Aurora MySQL and Aurora PostgreSQL  |  Count  | 
|  `StorageNetworkReceiveThroughput`  |  The amount of network throughput received from the Aurora storage subsystem by each instance in the DB cluster.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes per second   | 
|  `StorageNetworkThroughput`  |  The amount of network throughput received from and sent to the Aurora storage subsystem by each instance in the Aurora DB cluster.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes per second   | 
|  `StorageNetworkTransmitThroughput`  |  The amount of network throughput sent to the Aurora storage subsystem by each instance in the Aurora DB cluster.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes per second   | 
|  `SumBinaryLogSize`  |  The total size of the binlog files.  |  Aurora MySQL  |  Bytes  | 
|  `SwapUsage`  | The amount of swap space used. This metric isn't available for the following DB instance classes:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMonitoring.Metrics.html) |  Aurora MySQL and Aurora PostgreSQL  |  Bytes  | 
|  `TempStorageIOPS`  |  The number of IOPS for both read and writes on local storage attached to the DB instance. This metric represents a count and is measured once per second. This metric is applicable only for Aurora Serverless v2.  |  Aurora MySQL and Aurora PostgreSQL  |  Count per second  | 
|  `TempStorageThroughput `  |  The amount of data transferred to and from local storage associated with the DB instance. This metric represents bytes and is measured once per second. This metric is applicable only for Aurora Serverless v2.   |  Aurora MySQL and Aurora PostgreSQL  | Bytes per second | 
|  `TransactionAgeMaximum`  |  The age of the oldest active running transaction.  |  Aurora MySQL version 3, versions 3.08 and higher  |  Seconds  | 
|  `TransactionLogsDiskUsage`  |  The amount of disk space consumed by transaction logs on the Aurora PostgreSQL DB instance. This metric is generated only when Aurora PostgreSQL is using logical replication or AWS Database Migration Service. By default, Aurora PostgreSQL uses log records, not transaction logs. When transaction logs aren't in use, the value for this metric is `-1`.  |  Primary for Aurora PostgreSQL  |  Bytes  | 
|  `TruncateFinishedPoint`  |  The transaction identifier up to which undo truncation is performed.  |  Aurora MySQL version 2, versions 2.11 and higher Aurora MySQL version 3, versions 3.08 and higher  | Count | 
|  `UpdateLatency`  |  The average amount of time taken for update operations.  |  Aurora MySQL  |  Milliseconds  | 
|  `UpdateThroughput`  |  The average number of updates per second.  |  Aurora MySQL  |  Count per second  | 
|  `WriteIOPS`  |  The number of Aurora storage write records generated per second. This is more or less the number of log records generated by the database. These do not correspond to 8K page writes, and do not correspond to network packets sent.  |  Aurora MySQL and Aurora PostgreSQL  |  Count per second  | 
|  `WriteIOPSEphemeralStorage`  |  The average number of disk write I/O operations to Ephemeral NVMe storage.  |  Aurora PostgreSQL  |  Count per second  | 
|  `WriteLatency`  |  The average amount of time taken per disk I/O operation.  |  Aurora MySQL and Aurora PostgreSQL  |  Seconds  | 
|  `WriteLatencyEphemeralStorage`  |  The average amount of time taken per disk write I/O operation for Ephemeral NVMe storage.  |  Aurora PostgreSQL  |  Seconds  | 
|  `WriteThroughput`  |  The average number of bytes written to persistent storage every second.  |  Aurora MySQL and Aurora PostgreSQL  |  Bytes per second  | 
|  `WriteThroughputEphemeralStorage`  |  The average number of bytes written to disk per second for Ephemeral NVMe storage.  |  Aurora PostgreSQL  |  Bytes per second  | 

## Amazon CloudWatch usage metrics for Amazon Aurora
<a name="rds-metrics-usage"></a>

The `AWS/Usage` namespace in Amazon CloudWatch includes account-level usage metrics for your Amazon RDS service quotas. CloudWatch collects usage metrics automatically for all AWS Regions.

For more information, see [CloudWatch usage metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Usage-Metrics.html) in the *Amazon CloudWatch User Guide*. For more information about quotas, see [Quotas and constraints for Amazon Aurora](CHAP_Limits.md) and [Requesting a quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*.


| Metric | Description | Units\$1 | 
| --- | --- | --- | 
| AuthorizationsPerDBSecurityGroup |  The number of ingress rules per DB security group in your AWS account. The used value is the highest number of ingress rules in a DB security group in the account. Other DB security groups in the account might have a lower number of ingress rules.  |  Count  | 
| CustomEndpointsPerDBCluster |  The number of custom endpoints per DB cluster in your AWS account. The used value is the highest number of custom endpoints in a DB cluster in the account. Other DB clusters in the account might have a lower number of custom endpoints.  |  Count  | 
| DBClusterParameterGroups |  The number of DB cluster parameter groups in your AWS account. The count excludes default parameter groups.  |  Count  | 
| DBClusterRoles |  The number of associated AWS Identity and Access Management (IAM) roles per DB cluster in your AWS account. The used value is the highest number of associated IAM roles for a DB cluster in the account. Other DB clusters in the account might have a lower number of associated IAM roles.  |  Count  | 
| DBClusters |  The number of Amazon Aurora DB clusters in your AWS account.  |  Count  | 
| DBInstanceRoles |  The number of associated AWS Identity and Access Management (IAM) roles per DB instance in your AWS account. The used value is the highest number of associated IAM roles for a DB instance in the account. Other DB instances in the account might have a lower number of associated IAM roles.  |  Count  | 
| DBInstances |  The number of DB instances in your AWS account.  |  Count  | 
| DBParameterGroups |  The number of DB parameter groups in your AWS account. The count excludes the default DB parameter groups.  |  Count  | 
| DBSubnetGroups  |  The number of DB subnet groups in your AWS account. The count excludes the default subnet group.  |  Count  | 
| EventSubscriptions | The number of event notification subscriptions in your AWS account. | Count | 
| Integrations | The number of zero-ETL integrations with Amazon Redshift in your AWS account. | Count | 
| ManualClusterSnapshots |  The number of manually created DB cluster snapshots in your AWS account. The count excludes invalid snapshots.  |  Count  | 
| OptionGroups |  The number of option groups in your AWS account. The count excludes the default option groups.  |  Count  | 
| Proxies |  The number of RDS proxies in your AWS account.  |  Count  | 
| ReadReplicasPerMaster |  The number of read replicas per DB instance in your account. The used value is the highest number of read replicas for a DB instance in the account. Other DB instances in the account might have a lower number of read replicas.  |  Count  | 
| ReservedDBInstances |  The number of reserved DB instances in your AWS account. The count excludes retired or declined instances.  |  Count  | 
| SubnetsPerDBSubnetGroup |  The number of subnets per DB subnet group in your AWS account. The highest number of subnets for a DB subnet group in the account. Other DB subnet groups in the account might have a lower number of subnets.  |  Count  | 

**Note**  
Amazon RDS doesn't publish units for usage metrics to CloudWatch. The units only appear in the documentation.

# Amazon CloudWatch dimensions for Aurora
<a name="dimensions"></a>

You can filter Aurora metrics data by using any dimension in the following table.


|  Dimension  |  Filters the requested data for . . .  | 
| --- | --- | 
|  DBInstanceIdentifier  |  A specific DB instance.  | 
|  DBClusterIdentifier  |  A specific Aurora DB cluster.  | 
|  DBClusterIdentifier, Role |  A specific Aurora DB cluster, aggregating the metric by instance role (WRITER/READER). For example, you can aggregate metrics for all READER instances that belong to a cluster.  | 
|  DbClusterIdentifier, EngineName  |  A specific Aurora DB cluster and engine name combination. For example, you can view the `VolumeReadIOPs` metric for cluster `ams1` and engine `aurora`.  | 
|  DatabaseClass  |  All instances in a database class. For example, you can aggregate metrics for all instances that belong to the database class `db.r5.large`.  | 
|  EngineName  |  The identified engine name only. For example, you can aggregate metrics for all instances that have the engine name `aurora-postgresql`.  | 
|  SourceRegion  |  The specified Region only. For example, you can aggregate metrics for all DB instances in the `us-east-1` Region.  | 

# Availability of Aurora metrics in the Amazon RDS console
<a name="Aurora.Monitoring.Metrics.RDSAvailability"></a>

Not all metrics provided by Amazon Aurora are available in the Amazon RDS console. You can view these metrics using tools such as the AWS CLI and CloudWatch API. Also, some metrics in the Amazon RDS console are either shown only for specific instance classes, or with different names and units of measurement. 

**Topics**
+ [Aurora metrics available in the Last Hour view](#Aurora.Monitoring.Metrics.RDSAvailability.LMV)
+ [Aurora metrics available in specific cases](#Aurora.Monitoring.Metrics.RDSAvailability.specific-cases)
+ [Aurora metrics that aren't available in the console](#Aurora.Monitoring.Metrics.RDSAvailability.unavailable)

## Aurora metrics available in the Last Hour view
<a name="Aurora.Monitoring.Metrics.RDSAvailability.LMV"></a>

You can view a subset of categorized Aurora metrics in the default Last Hour view in the Amazon RDS console. The following table lists the categories and associated metrics displayed in the Amazon RDS console for an Aurora instance.


| Category | Metrics | 
| --- | --- | 
| SQL |  `ActiveTransactions` `BlockedTransactions` `BufferCacheHitRatio` `CommitLatency` `CommitThroughput` `DatabaseConnections` `DDLLatency` `DDLThroughput` `Deadlocks` `DMLLatency` `DMLThroughput` `LoginFailures` `ResultSetCacheHitRatio` `SelectLatency` `SelectThroughput`  | 
| System |  `AuroraReplicaLag` `AuroraReplicaLagMaximum` `AuroraReplicaLagMinimum` `CPUCreditBalance` `CPUCreditUsage` `CPUUtilization` `FreeableMemory` `FreeLocalStorage` (This doesn't apply to Aurora Serverless v2.) `NetworkReceiveThroughput`  | 
| Deployment |  `AuroraReplicaLag` `BufferCacheHitRatio` `ResultSetCacheHitRatio` `SelectThroughput`  | 

## Aurora metrics available in specific cases
<a name="Aurora.Monitoring.Metrics.RDSAvailability.specific-cases"></a>

In addition, some Aurora metrics are either shown only for specific instance classes, or only for DB instances, or with different names and different units of measurement:
+ The `CPUCreditBalance` and `CPUCreditUsage` metrics are displayed only for Aurora MySQL `db.t2` instance classes and for Aurora PostgreSQL `db.t3` instance classes.
+ The following metrics that are displayed with different names, as listed:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Monitoring.Metrics.RDSAvailability.html)
+ The following metrics apply to an entire Aurora DB cluster, but are displayed only when viewing DB instances for an Aurora DB cluster in the Amazon RDS console:
  + `VolumeBytesUsed`
  + `VolumeReadIOPs`
  + `VolumeWriteIOPs`
+ The following metrics are displayed in megabytes, instead of bytes, in the Amazon RDS console:
  + `FreeableMemory`
  + `FreeLocalStorage`
  + `NetworkReceiveThroughput`
  + `NetworkTransmitThroughput`
+ The following metrics apply to an Aurora PostgreSQL DB cluster with Aurora Optimized Reads:
  + `AuroraOptimizedReadsCacheHitRatio`
  + `FreeEphemeralStorage`
  + `ReadIOPSEphemeralStorage`
  + `ReadLatencyEphemeralStorage`
  + `ReadThroughputEphemeralStorage`
  + `WriteIOPSEphemeralStorage`
  + `WriteLatencyEphemeralStorage`
  + `WriteThroughputEphemeralStorage`

## Aurora metrics that aren't available in the console
<a name="Aurora.Monitoring.Metrics.RDSAvailability.unavailable"></a>

The following Aurora metrics aren't available in the Amazon RDS console:
+ `AuroraBinlogReplicaLag`
+ `DeleteLatency`
+ `DeleteThroughput`
+ `EngineUptime`
+ `InsertLatency`
+ `InsertThroughput`
+ `NetworkThroughput`
+ `Queries`
+ `UpdateLatency`
+ `UpdateThroughput`

# Amazon CloudWatch metrics for Amazon RDS Performance Insights
<a name="USER_PerfInsights.Cloudwatch"></a>

Performance Insights automatically publishes some metrics to Amazon CloudWatch. The same data can be queried from Performance Insights, but having the metrics in CloudWatch makes it easy to add CloudWatch alarms. It also makes it easy to add the metrics to existing CloudWatch Dashboards.


| Metric | Description | 
| --- | --- | 
|  DBLoad  |  The number of active sessions for the database. Typically, you want the data for the average number of active sessions. In Performance Insights, this data is queried as `db.load.avg`.  | 
|  DBLoadCPU  |  The number of active sessions where the wait event type is CPU. In Performance Insights, this data is queried as `db.load.avg`, filtered by the wait event type `CPU`.  | 
|  DBLoadNonCPU  |  The number of active sessions where the wait event type is not CPU.  | 
| DBLoadRelativeToNumVCPUs |  The ratio of the DB load to the number of virtual CPUs for the database.  | 

**Note**  
These metrics are published to CloudWatch only if there is load on the DB instance.

You can examine these metrics using the CloudWatch console, the AWS CLI, or the CloudWatch API. You can also examine other Performance Insights counter metrics using a special metric math function. For more information, see [Querying other Performance Insights counter metrics in CloudWatch](#USER_PerfInsights.Cloudwatch.ExtraMetrics).

For example, you can get the statistics for the `DBLoad` metric by running the [get-metric-statistics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-statistics.html) command.

```
aws cloudwatch get-metric-statistics \
    --region us-west-2 \
    --namespace AWS/RDS \
    --metric-name DBLoad  \
    --period 60 \
    --statistics Average \
    --start-time 1532035185 \
    --end-time 1532036185 \
    --dimensions Name=DBInstanceIdentifier,Value=db-loadtest-0
```

This example generates output similar to the following.

```
{
		"Datapoints": [
		{
		"Timestamp": "2021-07-19T21:30:00Z",
		"Unit": "None",
		"Average": 2.1
		},
		{
		"Timestamp": "2021-07-19T21:34:00Z",
		"Unit": "None",
		"Average": 1.7
		},
		{
		"Timestamp": "2021-07-19T21:35:00Z",
		"Unit": "None",
		"Average": 2.8
		},
		{
		"Timestamp": "2021-07-19T21:31:00Z",
		"Unit": "None",
		"Average": 1.5
		},
		{
		"Timestamp": "2021-07-19T21:32:00Z",
		"Unit": "None",
		"Average": 1.8
		},
		{
		"Timestamp": "2021-07-19T21:29:00Z",
		"Unit": "None",
		"Average": 3.0
		},
		{
		"Timestamp": "2021-07-19T21:33:00Z",
		"Unit": "None",
		"Average": 2.4
		}
		],
		"Label": "DBLoad"
		}
```

For more information about CloudWatch, see [What is Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) in the *Amazon CloudWatch User Guide*. 

## Querying other Performance Insights counter metrics in CloudWatch
<a name="USER_PerfInsights.Cloudwatch.ExtraMetrics"></a>

**Note**  
If you enable the Advanced mode of Database Insights, Amazon RDS publishes Performance Insights counter metrics to Amazon CloudWatch. With Database Insights, you don't need to use the `DB_PERF_INSIGHTS` metric math function. You can use the CloudWatch Database Insights dashboard to search, query, and set alarms for Performance Insights counter metrics.

You can query, alarm, and graphs on RDS Performance Insights metrics from CloudWatch. You can access information about your DB cluster by using the `DB_PERF_INSIGHTS` metric math function for CloudWatch. This function allows you to use the Performance Insights metrics that are not directly reported to CloudWatch to create a new time series.

You can use the new Metric Math function by clicking on the **Add Math** drop-down menu in the **Select metric** screen in the CloudWatch console. You can use it to create alarms and graphs on Performance Insights metrics or on combinations of CloudWatch and Performance Insights metrics, including high-resolution alarms for sub-minute metrics. You can also use the function programmatically by including the Metric Math expression in a [https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) request. For more information, see [Metric math syntax and functions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#metric-math-syntax-functions-list) and [Create an alarm on Performance Insights counter metrics from an AWS database](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_alarm_database_performance_insights.html).

# Performance Insights counter metrics
<a name="USER_PerfInsights_Counters"></a>

Counter metrics are operating system and database performance metrics in the Performance Insights dashboard. To help identify and analyze performance problems, you can correlate counter metrics with DB load. You must append a statistic function to the metric to get the metric values. For example, the supported functions for `os.memory.active` metric are `.avg`, `.min`, `.max`, `.sum`, and `.sample_count`. 

The counter metrics are collected one time each minute. The OS metrics collection depends on whether Enhanced Monitoring is turned on or off. If Enhanced Monitoring is turned off, the OS metrics are collected one time each minute. If Enhanced Monitoring is turned on, the OS metrics are collected for the selected time period. For more information about turning Enhanced Monitoring on or off, see [Turning Enhanced Monitoring on and off](USER_Monitoring.OS.Enabling.md#USER_Monitoring.OS.Enabling.Procedure).

**Topics**
+ [Performance Insights operating system counters](#USER_PerfInsights_Counters.OS)
+ [Performance Insights counters for Aurora MySQL](#USER_PerfInsights_Counters.Aurora_MySQL)
+ [Performance Insights counters for Aurora PostgreSQL](#USER_PerfInsights_Counters.Aurora_PostgreSQL)

## Performance Insights operating system counters
<a name="USER_PerfInsights_Counters.OS"></a>

The following operating system counters, which are prefixed with `os`, are available with Performance Insights for Aurora PostgreSQL and Aurora MySQL.

You can use `ListAvailableResourceMetrics` API for the list of available counter metrics for your DB instance. For more information, see [ ListAvailableResourceMetrics](https://docs.aws.amazon.com/performance-insights/latest/APIReference/API_ListAvailableResourceMetrics) in the Amazon RDS Performance Insights API Reference guide.


| Counter | Type | Unit | Metric | Description | 
| --- | --- | --- | --- | --- | 
| Active | Memory | Kilobytes | os.memory.active | The amount of assigned memory, in kilobytes. | 
| Buffers | Memory | Kilobytes | os.memory.buffers | The amount of memory used for buffering I/O requests prior to writing to the storage device, in kilobytes. | 
| Cached | Memory | Kilobytes | os.memory.cached | The amount of memory used for caching file system–based I/O, in kilobytes. | 
| DB Cache | Memory | Bytes | os.memory.db.cache |  The amount of memory used for page cache by database process including tmpfs (shmem), in bytes.  | 
| DB Resident Set Size | Memory | Bytes | os.memory.db.residentSetSize |  The amount of memory used for anonymous and swap cache by database process not including tmpfs (shmem), in bytes.  | 
| DB Swap | Memory | Bytes | os.memory.db.swap |   The amount of memory used for swap by database process, in bytes.  | 
| Dirty | Memory | Kilobytes | os.memory.dirty | The amount of memory pages in RAM that have been modified but not written to their related data block in storage, in kilobytes. | 
| Free | Memory | Kilobytes | os.memory.free | The amount of unassigned memory, in kilobytes. | 
| Huge Pages Free | Memory | Pages | os.memory.hugePagesFree | The number of free huge pages. Huge pages are a feature of the Linux kernel. | 
| Huge Pages Rsvd | Memory | Pages | os.memory.hugePagesRsvd | The number of committed huge pages. | 
| Huge Pages Size | Memory | Kilobytes | os.memory.hugePagesSize | The size for each huge pages unit, in kilobytes. | 
| Huge Pages Surp | Memory | Pages | os.memory.hugePagesSurp | The number of available surplus huge pages over the total. | 
| Huge Pages Total | Memory | Pages | os.memory.hugePagesTotal | The total number of huge pages. | 
| Inactive | Memory | Kilobytes | os.memory.inactive | The amount of least-frequently used memory pages, in kilobytes. | 
| Mapped | Memory | Kilobytes | os.memory.mapped | The total amount of file-system contents that is memory mapped inside a process address space, in kilobytes. | 
| Out of Memory Kill Count | Memory | Kills | os.memory.outOfMemoryKillCount |  The number of OOM kills that happened over the last collection interval.  | 
| Page Tables | Memory | Kilobytes | os.memory.pageTables | The amount of memory used by page tables, in kilobytes. | 
| Slab | Memory | Kilobytes | os.memory.slab | The amount of reusable kernel data structures, in kilobytes. | 
| Total | Memory | Kilobytes | os.memory.total | The total amount of memory, in kilobytes. | 
| Writeback | Memory | Kilobytes | os.memory.writeback | The amount of dirty pages in RAM that are still being written to the backing storage, in kilobytes. | 
| Guest | Cpu Utilization | Percentage | os.cpuUtilization.guest | The percentage of CPU in use by guest programs. | 
| Idle | Cpu Utilization | Percentage | os.cpuUtilization.idle | The percentage of CPU that is idle. | 
| Irq | Cpu Utilization | Percentage | os.cpuUtilization.irq | The percentage of CPU in use by software interrupts. | 
| Nice | Cpu Utilization | Percentage | os.cpuUtilization.nice | The percentage of CPU in use by programs running at lowest priority. | 
| Steal | Cpu Utilization | Percentage | os.cpuUtilization.steal | The percentage of CPU in use by other virtual machines. | 
| System | Cpu Utilization | Percentage | os.cpuUtilization.system | The percentage of CPU in use by the kernel. | 
| Total | Cpu Utilization | Percentage | os.cpuUtilization.total | The total percentage of the CPU in use. This value includes the nice value. | 
| User | Cpu Utilization | Percentage | os.cpuUtilization.user | The percentage of CPU in use by user programs. | 
| Wait | Cpu Utilization | Percentage | os.cpuUtilization.wait | The percentage of CPU unused while waiting for I/O access. | 
|  Aurora Storage Aurora Storage Bytes Rx  | Disk IO | Bytes per second | os.diskIO.auroraStorage.auroraStorageBytesRx |  The number of bytes received from Aurora storage per second.  | 
|  Aurora Storage Aurora Storage Bytes Tx  | Disk IO | Bytes per second | os.diskIO.auroraStorage.auroraStorageBytesTx |  The number of bytes uploaded to aurora storage per second.  | 
|  Aurora Storage Disk Queue Depth  | Disk IO | Requests |  os.diskIO.auroraStorage.diskQueueDepth  |  The length of Aurora storage disk queue.  | 
|  Aurora Storage Read IOs PS  | Disk IO | Requests per second |  os.diskIO.auroraStorage.readIOsPS  | The number of read operations per second. | 
|  Aurora Storage Read Latency  | Disk IO | Milliseconds |  os.diskIO.auroraStorage.readLatency  | The average latency of a read I/O request to Aurora storage, in milliseconds. | 
|  Aurora Storage Read Throughput  | Disk IO | Bytes per second |  os.diskIO.auroraStorage.readThroughput  | The amount of network throughput used by requests to the DB cluster, in bytes per second. | 
|  Aurora Storage Write IOs PS  | Disk IO | Requests per second |  os.diskIO.auroraStorage.writeIOsPS  | The number of write operations per second. | 
|  Aurora Storage Write Latency  | Disk IO | Milliseconds |  os.diskIO.auroraStorage.writeLatency  | The average latency of a write I/O request to Aurora storage, in milliseconds. | 
|  Aurora Storage Write Throughput  | Disk IO | Bytes per second |  os.diskIO.auroraStorage.writeThroughput  | The amount of network throughput used by responses from the DB cluster, in bytes per second. | 
| Rdstemp Avg Queue Len  | Disk IO | Requests |  os.diskIO.rdstemp.avgQueueLen  | The number of requests waiting in the I/O device's queue. | 
|  Rdstemp Avg Req Sz  | Disk IO | Requests |  os.diskIO.rdstemp.avgReqSz  | The number of requests waiting in the I/O device's queue. | 
|  Rdstemp Await  | Disk IO | Milliseconds |  os.diskIO.rdstemp.await  | The number of milliseconds required to respond to requests, including queue time and service time. | 
|  Rdstemp Read IOs PS  | Disk IO | Requests |  os.diskIO.rdstemp.readIOsPS  | The number of read operations per second. | 
|  Rdstemp Read KB  | Disk IO | Kilobytes |  os.diskIO.rdstemp.readKb  | The total number of kilobytes read. | 
|  Rdstemp Read KB PS  | Disk IO | Kilobytes per second |  os.diskIO.rdstemp.readKbPS  | The number of kilobytes read per second. | 
|  Rdstemp Rrqm PS  | Disk IO | Requests per second |  os.diskIO.rdstemp.rrqmPS  | The number of merged read requests queued per second. | 
|  Rdstemp TPS  | Disk IO | Transactions per second |  os.diskIO.rdstemp.tps  | The number of I/O transactions per second. | 
|  Rdstemp Util  | Disk IO | Percentage |  os.diskIO.rdstemp.util  | The percentage of CPU time during which requests were issued. | 
|  Rdstemp Write IOs PS  | Disk IO | Requests per second |  os.diskIO.rdstemp.writeIOsPS  | The number of write operations per second. | 
|  Rdstemp Write KB  | Disk IO | Kilobytes |  os.diskIO.rdstemp.writeKb  | The total number of kilobytes written. | 
|  Rdstemp Write KB PS  | Disk IO | Kilobytes per second |  os.diskIO.rdstemp.writeKbPS  | The number of kilobytes written per second. | 
|  Rdstemp Wrqm PS  | Disk IO | Requests per second |  os.diskIO.rdstemp.wrqmPS  | The number of merged write requests queued per second. | 
| Blocked | Tasks | Tasks | os.tasks.blocked | The number of tasks that are blocked. | 
| Running | Tasks | Tasks | os.tasks.running | The number of tasks that are running. | 
| Sleeping | Tasks | Tasks | os.tasks.sleeping | The number of tasks that are sleeping. | 
| Stopped | Tasks | Tasks | os.tasks.stopped | The number of tasks that are stopped. | 
| Total | Tasks | Tasks | os.tasks.total | The total number of tasks. | 
| Zombie | Tasks | Tasks | os.tasks.zombie | The number of child tasks that are inactive with an active parent task. | 
| One | Load Average Minute | Processes | os.loadAverageMinute.one | The number of processes requesting CPU time over the last minute. | 
| Fifteen | Load Average Minute | Processes | os.loadAverageMinute.fifteen | The number of processes requesting CPU time over the last 15 minutes. | 
| Five | Load Average Minute | Processes | os.loadAverageMinute.five | The number of processes requesting CPU time over the last 5 minutes. | 
| Cached | Swap | Kilobytes | os.swap.cached | The amount of swap memory, in kilobytes, used as cache memory. | 
| Free | Swap | Kilobytes | os.swap.free | The amount of swap memory free, in kilobytes.  | 
| In | Swap | Kilobytes | os.swap.in | The amount of memory, in kilobytes, swapped in from disk. | 
| Out | Swap | Kilobytes | os.swap.out | The amount of memory, in kilobytes, swapped out to disk. | 
| Total | Swap | Kilobytes | os.swap.total |  The total amount of swap memory available in kilobytes.  | 
| Max Files | File Sys | Files | os.fileSys.maxFiles | The maximum number of files that can be created for the file system across all storage volumes. | 
| Used Files | File Sys | Files | os.fileSys.usedFiles | The number of files in the file system across all storage volumes. | 
| Used File Percent | File Sys | Files | os.fileSys.usedFilePercent | The percentage of available files in use across all storage volumes. | 
| Used Percent | File Sys | Percentage | os.fileSys.usedPercent | The percentage of the file-system disk space in use across all storage volumes. | 
| Used | File Sys | Kilobytes | os.fileSys.used | The amount of disk space used by files in the file system across all storage volumes, in kilobytes. | 
| Total | File Sys | Kilobytes | os.fileSys.total | The total disk space available for the file system across all storage volumes, in kilobytes. | 
| Max Files | File Sys | Files | os.fileSys.<volumeName>.maxFiles | The maximum number of files that can be created for the storage volume. | 
| Used Files | File Sys | Files | os.fileSys.<volumeName>.usedFiles | The number of files in the storage volume. | 
| Used File Percent | File Sys | Files | os.fileSys.<volumeName>.usedFilePercent | The percentage of available files in use in the storage volume. | 
| Used Percent | File Sys | Percentage | os.fileSys.<volumeName>.usedPercent | The percentage of the storage volume disk space in use. | 
| Used | File Sys | Kilobytes | os.fileSys.<volumeName>.used | The amount of disk space used by files in the storage volume, in kilobytes. | 
| Total | File Sys | Kilobytes | os.fileSys.<volumeName>.total | The total disk space available in the storage volume, in kilobytes. | 
| Rx | Network | Bytes per second | os.network.rx | The number of bytes received per second. | 
| Tx | Network | Bytes per second | os.network.tx | The number of bytes uploaded per second. | 
| Acu Utilization | General | Percentage | os.general.acuUtilization |  The percentage of current capacity out of the maximum configured capacity.  | 
| Max Configured Acu | General | ACUs | os.general.maxConfiguredAcu |  The maximum capacity configured by the user, in Aurora capacity units (ACUs).  | 
| Min Configured Acu | General | ACUs | os.general.minConfiguredAcu |  The minimum capacity configured by the user, in ACUs.  | 
| Num VCPUs | General | vCPUs | os.general.numVCPUs | The number of virtual CPUs (vCPUs) for the DB instance. | 
| Serverless Database Capacity | General | ACUs | os.general.serverlessDatabaseCapacity |  The current capacity of the instance, in ACUs.  | 

## Performance Insights counters for Aurora MySQL
<a name="USER_PerfInsights_Counters.Aurora_MySQL"></a>

The following database counters are available with Performance Insights for Aurora MySQL.

**Topics**
+ [Native counters for Aurora MySQL](#USER_PerfInsights_Counters.Aurora_MySQL.Native)
+ [Non-native counters for Aurora MySQL](#USER_PerfInsights_Counters.Aurora_MySQL.NonNative)

### Native counters for Aurora MySQL
<a name="USER_PerfInsights_Counters.Aurora_MySQL.Native"></a>

Native metrics are defined by the database engine and not by Amazon Aurora. You can find definitions for these native metrics in [Server status variables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html) in the MySQL documentation.


| Counter | Type | Unit | Metric | 
| --- | --- | --- | --- | 
| Com\$1analyze | SQL | Queries per second | db.SQL.Com\$1analyze | 
| Com\$1optimize | SQL | Queries per second | db.SQL.Com\$1optimize | 
| Com\$1select | SQL | Queries per second | db.SQL.Com\$1select | 
| Innodb\$1rows\$1deleted | SQL | Rows per second | db.SQL.Innodb\$1rows\$1deleted | 
| Innodb\$1rows\$1inserted | SQL | Rows per second | db.SQL.Innodb\$1rows\$1inserted | 
| Innodb\$1rows\$1read | SQL | Rows per second | db.SQL.Innodb\$1rows\$1read | 
| Innodb\$1rows\$1updated | SQL | Rows per second | db.SQL.Innodb\$1rows\$1updated | 
| Queries | SQL | Queries per second | db.SQL.Queries | 
| Questions | SQL | Queries per second | db.SQL.Questions | 
| Select\$1full\$1join | SQL | Queries per second | db.SQL.Select\$1full\$1join | 
| Select\$1full\$1range\$1join | SQL | Queries per second | db.SQL.Select\$1full\$1range\$1join | 
| Select\$1range | SQL | Queries per second | db.SQL.Select\$1range | 
| Select\$1range\$1check | SQL | Queries per second | db.SQL.Select\$1range\$1check | 
| Select\$1scan | SQL | Queries per second | db.SQL.Select\$1scan | 
| Slow\$1queries | SQL | Queries per second | db.SQL.Slow\$1queries | 
| Sort\$1merge\$1passes | SQL | Queries per second | db.SQL.Sort\$1merge\$1passes | 
| Sort\$1range | SQL | Queries per second | db.SQL.Sort\$1range | 
| Sort\$1rows | SQL | Queries per second | db.SQL.Sort\$1rows | 
| Sort\$1scan | SQL | Queries per second | db.SQL.Sort\$1scan | 
| Total\$1query\$1time | SQL | Milliseconds | db.SQL.Total\$1query\$1time | 
| Table\$1locks\$1immediate | Locks | Requests per second | db.Locks.Table\$1locks\$1immediate | 
| Table\$1locks\$1waited | Locks | Requests per second | db.Locks.Table\$1locks\$1waited | 
| Innodb\$1row\$1lock\$1time | Locks | Milliseconds (average) | db.Locks.Innodb\$1row\$1lock\$1time | 
| Aborted\$1clients | Users | Connections | db.Users.Aborted\$1clients | 
| Aborted\$1connects | Users | Connections | db.Users.Aborted\$1connects | 
| Connections | Users | Connections | db.Users.Connections | 
| External\$1threads\$1connected | Users | Connections | db.Users.External\$1threads\$1connected | 
| max\$1connections | Users | Connections | db.Users.max\$1connections | 
| Threads\$1connected | Users | Connections | db.Users.Threads\$1connected | 
| Threads\$1created | Users | Connections | db.Users.Threads\$1created | 
| Threads\$1running | Users | Connections | db.Users.Threads\$1running | 
| Created\$1tmp\$1disk\$1tables | Temp | Tables per second | db.Temp.Created\$1tmp\$1disk\$1tables | 
| Created\$1tmp\$1tables | Temp | Tables per second | db.Temp.Created\$1tmp\$1tables | 
| Innodb\$1buffer\$1pool\$1pages\$1data | Cache | Pages | db.Cache.Innodb\$1buffer\$1pool\$1pages\$1data | 
| Innodb\$1buffer\$1pool\$1pages\$1total | Cache | Pages | db.Cache.Innodb\$1buffer\$1pool\$1pages\$1total | 
| Innodb\$1buffer\$1pool\$1read\$1requests | Cache | Pages per second | db.Cache.Innodb\$1buffer\$1pool\$1read\$1requests | 
| Innodb\$1buffer\$1pool\$1reads | Cache | Pages per second | db.Cache.Innodb\$1buffer\$1pool\$1reads | 
| Opened\$1tables | Cache | Tables | db.Cache.Opened\$1tables | 
| Opened\$1table\$1definitions | Cache | Tables | db.Cache.Opened\$1table\$1definitions | 
| Qcache\$1hits | Cache | Queries | db.Cache.Qcache\$1hits | 

### Non-native counters for Aurora MySQL
<a name="USER_PerfInsights_Counters.Aurora_MySQL.NonNative"></a>

Non-native counter metrics are counters defined by Amazon RDS. A non-native metric can be a metric that you get with a specific query. A non-native metric also can be a derived metric, where two or more native counters are used in calculations for ratios, hit rates, or latencies.


| Counter | Type | Unit | Metric | Description | Definition | 
| --- | --- | --- | --- | --- | --- | 
| active\$1transactions | Transactions | db.Transactions.active\$1transactions | The total active transactions. | SELECT COUNT(1) AS active\$1transactions FROM INFORMATION\$1SCHEMA.INNODB\$1TRX | 
| innodb\$1buffer\$1pool\$1hit\$1rate | Cache | db.Cache.innoDB\$1buffer\$1pool\$1hit\$1rate | The percentage of reads that InnoDB could satisfy from the buffer pool. | 100 \$1 innodb\$1buffer\$1pool\$1read\$1requests / (innodb\$1buffer\$1pool\$1read\$1requests \$1 innodb\$1buffer\$1pool\$1reads) | 
| innodb\$1buffer\$1pool\$1hits | Cache | Pages per second | db.Cache.innoDB\$1buffer\$1pool\$1hits | The number of reads that InnoDB could satisfy from the buffer pool. | innodb\$1buffer\$1pool\$1read\$1requests - innodb\$1buffer\$1pool\$1reads | 
| innodb\$1buffer\$1pool\$1usage | Cache | Percentage | db.Cache.innoDB\$1buffer\$1pool\$1usage |  The percentage of the InnoDB buffer pool that contains data (pages).  When using compressed tables, this value can vary. For more information, see the information about `Innodb_buffer_pool_pages_data` and `Innodb_buffer_pool_pages_total` in [Server status sariables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html) in the MySQL documentation.   | Innodb\$1buffer\$1pool\$1pages\$1data / Innodb\$1buffer\$1pool\$1pages\$1total \$1 100.0 | 
| innodb\$1deadlocks | Locks | db.Locks.innodb\$1deadlocks | The total number of deadlocks. | SELECT COUNT AS innodb\$1deadlocks FROM INFORMATION\$1SCHEMA.INNODB\$1METRICS WHERE NAME='lock\$1deadlocks' | 
| innodb\$1lock\$1timeouts | Locks | db.Locks.innodb\$1lock\$1timeouts | The total number of deadlocks that timed out. | SELECT COUNT AS innodb\$1lock\$1timeouts FROM INFORMATION\$1SCHEMA.INNODB\$1METRICS WHERE NAME='lock\$1timeouts' | 
| innodb\$1row\$1lock\$1waits | Locks | db.Locks.innodb\$1row\$1lock\$1waits | The total number of row locks that resulted in a wait. | SELECT COUNT AS innodb\$1row\$1lock\$1waits FROM INFORMATION\$1SCHEMA.INNODB\$1METRICS WHERE NAME='lock\$1row\$1lock\$1waits' | 
| innodb\$1rows\$1changed | SQL | db.SQL.innodb\$1rows\$1changed | The total InnoDB row operations. | db.SQL.Innodb\$1rows\$1inserted \$1 db.SQL.Innodb\$1rows\$1deleted \$1 db.SQL.Innodb\$1rows\$1updated | 
| query\$1cache\$1hit\$1rate | Cache | Percentage | db.Cache.query\$1cache\$1hit\$1rate | The hit ratio for the MySQL result set cache (query cache). | Qcache\$1hits / (QCache\$1hits \$1 Com\$1select) \$1 100 | 
| temp\$1disk\$1tables\$1percent | Temp | db.Temp.temp\$1disk\$1tables\$1percent | The percentage of temporary tables that are created on disk by the server when running statements. | (db.Temp.Created\$1tmp\$1disk\$1tables / db.Temp.Created\$1tmp\$1tables) \$1 100 | 
| trx\$1rseg\$1history\$1len | Transactions | None | db.Transactions.trx\$1rseg\$1history\$1len | A list of the undo log pages for committed transactions that is maintained by the InnoDB transaction system to implement multi-version concurrency control. For more information about undo log records details, see [https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html](https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html) in the MySQL documentation. | SELECT COUNT AS trx\$1rseg\$1history\$1len FROM INFORMATION\$1SCHEMA.INNODB\$1METRICS WHERE NAME='trx\$1rseg\$1history\$1len'  | 

## Performance Insights counters for Aurora PostgreSQL
<a name="USER_PerfInsights_Counters.Aurora_PostgreSQL"></a>

The following database counters are available with Performance Insights for Aurora PostgreSQL.

**Topics**
+ [Native counters for Aurora PostgreSQL](#USER_PerfInsights_Counters.Aurora_PostgreSQL.Native)
+ [Non-native counters for Aurora PostgreSQL](#USER_PerfInsights_Counters.Aurora_PostgreSQL.NonNative)

### Native counters for Aurora PostgreSQL
<a name="USER_PerfInsights_Counters.Aurora_PostgreSQL.Native"></a>

Native metrics are defined by the database engine and not by Amazon Aurora. You can find definitions for these native metrics in [Viewing Statistics](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-VIEWS) in the PostgreSQL documentation.


| Counter | Type | Unit | Metric | 
| --- | --- | --- | --- | 
| tup\$1deleted | SQL | Tuples per second | db.SQL.tup\$1deleted | 
| tup\$1fetched | SQL | Tuples per second | db.SQL.tup\$1fetched | 
| tup\$1inserted | SQL | Tuples per second | db.SQL.tup\$1inserted | 
| tup\$1returned | SQL | Tuples per second | db.SQL.tup\$1returned | 
| tup\$1updated | SQL | Tuples per second | db.SQL.tup\$1updated | 
| blks\$1hit | Cache | Blocks per second | db.Cache.blks\$1hit | 
| buffers\$1alloc | Cache | Blocks per second | db.Cache.buffers\$1alloc | 
| buffers\$1checkpoint | Checkpoint | Blocks per second | db.Checkpoint.buffers\$1checkpoint | 
| checkpoints\$1req | Checkpoint | Checkpoints per minute | db.Checkpoint.checkpoints\$1req | 
| checkpoint\$1sync\$1time | Checkpoint | Milliseconds per checkpoint | db.Checkpoint.checkpoint\$1sync\$1time | 
| checkpoints\$1timed | Checkpoint | Checkpoints per minute | db.Checkpoint.checkpoints\$1timed | 
| checkpoint\$1write\$1time | Checkpoint | Milliseconds per checkpoint | db.Checkpoint.checkpoint\$1write\$1time | 
| maxwritten\$1clean | Checkpoint | Bgwriter clean stops per minute | db.Checkpoint.maxwritten\$1clean | 
| deadlocks | Concurrency | Deadlocks per minute | db.Concurrency.deadlocks | 
| blk\$1read\$1time | I/O | Milliseconds | db.IO.blk\$1read\$1time | 
| blks\$1read | I/O | Blocks per second | db.IO.blks\$1read | 
| buffers\$1backend | I/O | Blocks per second | db.IO.buffers\$1backend | 
| buffers\$1backend\$1fsync | I/O | Blocks per second | db.IO.buffers\$1backend\$1fsync | 
| buffers\$1clean | I/O | Blocks per second | db.IO.buffers\$1clean | 
| temp\$1bytes | Temp | Bytes per second | db.Temp.temp\$1bytes | 
| temp\$1files | Temp | Files per minute | db.Temp.temp\$1files | 
| xact\$1commit | Transactions | Commits per second | db.Transactions.xact\$1commit | 
| xact\$1rollback | Transactions | Rollbacks per second | db.Transactions.xact\$1rollback | 
| numbackends | User | Connections | db.User.numbackends | 
| archived\$1count | WAL | Files per minute | db.WAL.archived\$1count | 

### Non-native counters for Aurora PostgreSQL
<a name="USER_PerfInsights_Counters.Aurora_PostgreSQL.NonNative"></a>

Non-native counter metrics are counters defined by Amazon Aurora. A non-native metric can be a metric that you get with a specific query. A non-native metric also can be a derived metric, where two or more native counters are used in calculations for ratios, hit rates, or latencies.


| Counter | Type | Unit | Metric | Description | Definition | 
| --- | --- | --- | --- | --- | --- | 
| checkpoint\$1sync\$1latency | Checkpoint | Milliseconds | db.Checkpoint.checkpoint\$1sync\$1latency | The total amount of time that has been spent in the portion of checkpoint processing where files are synchronized to disk. | checkpoint\$1sync\$1time / (checkpoints\$1timed \$1 checkpoints\$1req) | 
| checkpoint\$1write\$1latency | Checkpoint | Milliseconds | db.Checkpoint.checkpoint\$1write\$1latency | The total amount of time that has been spent in the portion of checkpoint processing where files are written to disk. | checkpoint\$1write\$1time / (checkpoints\$1timed \$1 checkpoints\$1req) | 
| local\$1blks\$1read | I/O | Blocks | db.IO.local\$1blks\$1read | Total number of local blocks read. | Not applicable | 
| local\$1blk\$1read\$1time | I/O | Milliseconds | db.IO.local\$1blk\$1read\$1time | If track\$1io\$1timing is enabled, it tracks the total time spent reading local data file blocks, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING). | Not applicable | 
| num\$1blocked\$1sessions | Locks | db.Locks.num\$1blocked\$1sessions | The number of blocked sessions. | – | 
| orcache\$1blks\$1hit | I/O | Queries | db.IO.orcache\$1blks\$1hit | Total number of shared blocks hits from optimized reads cache. | Not applicable | 
| orcache\$1blk\$1read\$1time | I/O | Milliseconds | db.IO.orcache\$1blk\$1read\$1time | If track\$1io\$1timing is enabled, it tracks the total time spent reading data file blocks from Optimized Reads cache, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING). | Not applicable | 
| read\$1latency | I/O | Milliseconds | db.IO.read\$1latency | The time spent reading data file blocks by backends in this instance. | blk\$1read\$1time / blks\$1read | 
| storage\$1blks\$1read | I/O | Blocks | db.IO.storage\$1blks\$1read | Total number of shared blocks read from aurora storage. | Not applicable | 
| storage\$1blk\$1read\$1time | I/O | Milliseconds | db.IO.storage\$1blk\$1read\$1time | If track\$1io\$1timing is enabled, it tracks the total time spent reading data file blocks from Aurora storage, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING). | Not applicable | 
| num\$1blocked\$1sessions | Locks | db.Locks.num\$1blocked\$1sessions | The number of blocked sessions. | – | 
| active\$1count | State | Sessions | db.state.active\$1count | The number of sessions in the active state. | Not applicable | 
| idle\$1count | State | Sessions | db.state.idle\$1count | The number of sessions in the idle state. | Not applicable | 
| idle\$1in\$1transaction\$1aborted\$1count | State | Sessions | db.state.idle\$1in\$1transaction\$1aborted\$1count | The number of sessions in the idle in transaction (aborted) state. | Not applicable | 
| idle\$1in\$1transaction\$1count | State | Sessions | db.state.idle\$1in\$1transaction\$1count | The number of sessions in the idle in transaction state. | Not applicable | 
| idle\$1in\$1transaction\$1max\$1time | State | Seconds | db.state.idle\$1in\$1transaction\$1max\$1time | The duration of the longest running transaction in the idle in transaction state, in seconds. | Not applicable | 
| logical\$1reads | SQL | Blocks | db.SQL.logical\$1reads | The total number of blocks hit and read. | blks\$1hit \$1 blks\$1read | 
| queries\$1started | SQL | Queries | db.SQL.queries | The number of queries started. | Not applicable | 
| queries\$1finished | SQL | Queries | db.SQL.queries | The number of queries finished. | Not applicable | 
| total\$1query\$1time | SQL | Milliseconds | db.SQL.total\$1query\$1time | The total time spent executing statements, in milliseconds. | Not applicable | 
| active\$1transactions | Transactions | Transactions | db.Transactions.active\$1transactions | The number of active transactions. | Not applicable | 
| blocked\$1transactions | Transactions | Transactions | db.Transactions.blocked\$1transactions | The number of blocked transactions. | Not applicable | 
| commit\$1latency | Transactions | Microseconds | db.Transactions.commit\$1latency | The average duration of commit operations. | db.Transactions.duration\$1commits / db.Transactions.xact\$1commit | 
| duration\$1commits | Transactions | Milliseconds | db.Transactions.duration\$1commits | The total transaction time spent in the last minute, in milliseconds. | Not applicable | 
| max\$1used\$1xact\$1ids | Transactions | Transactions | db.Transactions.max\$1used\$1xact\$1ids | The number of transactions that haven't been vacuumed. | Not applicable | 
| oldest\$1inactive\$1logical\$1replication\$1slot\$1xid\$1age | Transactions | Length | db.Transactions.oldest\$1inactive\$1logical\$1replication\$1slot\$1xid\$1age | The age of the oldest transaction in an inactive logical replication slot. | Not applicable | 
| oldest\$1active\$1logical\$1replication\$1slot\$1xid\$1age | Transactions | Length | db.Transactions.oldest\$1active\$1logical\$1replication\$1slot\$1xid\$1age | The age of the oldest transaction in an active logical replication slot. | Not applicable | 
| oldest\$1reader\$1feedback\$1xid\$1age | Transactions | Length | db.Transactions.oldest\$1reader\$1feedback\$1xid\$1age | The age of the oldest transaction of a long‐running transaction on an Aurora reader instance or Aurora global DB reader instance. | Not applicable | 
| oldest\$1prepared\$1transaction\$1xid\$1age | Transactions | Length | db.Transactions.oldest\$1prepared\$1transaction\$1xid\$1age | The age of the oldest prepared transaction. | Not applicable | 
| oldest\$1running\$1transaction\$1xid\$1age | Transactions | Length | db.Transactions.oldest\$1running\$1transaction\$1xid\$1age | The age of the oldest running transaction. | Not applicable | 
| max\$1connections | Users | Users | db.User.max\$1connections | The maximum number of connections allowed for a database as configured in max\$1connections parameter. | Not applicable | 
| total\$1auth\$1attempts | Users | Users | db.User.total\$1auth\$1attempts | The number of connection attempts to this instance. | Not applicable | 
| archive\$1failed\$1count | WAL | Files per minute | db.WAL.archive\$1failed\$1count | The number of failed attempts for archiving WAL files, in files per minute. | Not applicable | 

# SQL statistics for Performance Insights
<a name="sql-statistics"></a>

*SQL statistics* are performance-related metrics about SQL queries that are collected by Performance Insights. Performance Insights gathers statistics for each second that a query is running and for each SQL call. The SQL statistics are an average for the selected time range.

A SQL digest is a composite of all queries having a given pattern but not necessarily having the same literal values. The digest replaces literal values with a question mark. For example, `SELECT * FROM emp WHERE lname= ?`. This digest might consist of the following child queries:

```
SELECT * FROM emp WHERE lname = 'Sanchez'
SELECT * FROM emp WHERE lname = 'Olagappan'
SELECT * FROM emp WHERE lname = 'Wu'
```

All engines support SQL statistics for digest queries.

For the region, DB engine, and instance class support information for this feature, see [ Amazon Aurora DB engine, Region, and instance class support for Performance Insights features](USER_PerfInsights.Overview.Engines.md#USER_PerfInsights.Overview.PIfeatureEngnRegSupport)

**Topics**
+ [SQL statistics for Aurora MySQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.md)
+ [SQL statistics for Aurora PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md)

# SQL statistics for Aurora MySQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL"></a>

Aurora MySQL collect SQL statistics only at the digest level. No statistics are shown at the statement level.

**Topics**
+ [Digest statistics for Aurora MySQL](#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.truncation)
+ [Per-second statistics for Aurora MySQL](#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.per-second)
+ [Per-call statistics for Aurora MySQL](#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.truncation.per-call)
+ [Primary statistics for Aurora MySQL](#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.primary)

## Digest statistics for Aurora MySQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.truncation"></a>

Performance Insights collects SQL digest statistics from the `events_statements_summary_by_digest` table. The `events_statements_summary_by_digest` table is managed by your database. 

The digest table doesn't have an eviction policy. When the table is full, the AWS Management Console shows the following message:

```
Performance Insights is unable to collect SQL Digest statistics on new queries because the table events_statements_summary_by_digest is full. 
Please truncate events_statements_summary_by_digest table to clear the issue. Check the User Guide for more details.
```

In this situation, Aurora MySQL doesn't track SQL queries. To address this issue, Performance Insights automatically truncates the digest table when both of the following conditions are met:
+ The table is full.
+ Performance Insights manages the Performance Schema automatically.

  For automatic management, the `performance_schema` parameter must be set to `0` and the **Source** must not be set to `user`. If Performance Insights isn't managing the Performance Schema automatically, see [Overview of the Performance Schema for Performance Insights on Aurora MySQL](USER_PerfInsights.EnableMySQL.md).

In the AWS CLI, check the source of a parameter value by running the [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) command.

## Per-second statistics for Aurora MySQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.per-second"></a>

The following SQL statistics are available for Aurora MySQL DB clusters.


| Metric | Unit | 
| --- | --- | 
| db.sql\$1tokenized.stats.count\$1star\$1per\$1sec | Calls per second | 
| db.sql\$1tokenized.stats.sum\$1timer\$1wait\$1per\$1sec | Average latency per second (in ms) | 
| db.sql\$1tokenized.stats.sum\$1select\$1full\$1join\$1per\$1sec | Select full join per second | 
| db.sql\$1tokenized.stats.sum\$1select\$1range\$1check\$1per\$1sec | Select range check per second | 
| db.sql\$1tokenized.stats.sum\$1select\$1scan\$1per\$1sec | Select scan per second | 
| db.sql\$1tokenized.stats.sum\$1sort\$1merge\$1passes\$1per\$1sec | Sort merge passes per second | 
| db.sql\$1tokenized.stats.sum\$1sort\$1scan\$1per\$1sec | Sort scans per second | 
| db.sql\$1tokenized.stats.sum\$1sort\$1range\$1per\$1sec | Sort ranges per second | 
| db.sql\$1tokenized.stats.sum\$1sort\$1rows\$1per\$1sec | Sort rows per second | 
| db.sql\$1tokenized.stats.sum\$1rows\$1affected\$1per\$1sec | Rows affected per second | 
| db.sql\$1tokenized.stats.sum\$1rows\$1examined\$1per\$1sec | Rows examined per second | 
| db.sql\$1tokenized.stats.sum\$1rows\$1sent\$1per\$1sec | Rows sent per second | 
| db.sql\$1tokenized.stats.sum\$1created\$1tmp\$1disk\$1tables\$1per\$1sec | Created temporary disk tables per second | 
| db.sql\$1tokenized.stats.sum\$1created\$1tmp\$1tables\$1per\$1sec | Created temporary tables per second | 
| db.sql\$1tokenized.stats.sum\$1lock\$1time\$1per\$1sec | Lock time per second (in ms) | 

## Per-call statistics for Aurora MySQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.truncation.per-call"></a>

The following metrics provide per call statistics for a SQL statement.


| Metric | Unit | 
| --- | --- | 
| db.sql\$1tokenized.stats.sum\$1timer\$1wait\$1per\$1call | Average latency per call (in ms)  | 
| db.sql\$1tokenized.stats.sum\$1select\$1full\$1join\$1per\$1call | Select full joins per call | 
| db.sql\$1tokenized.stats.sum\$1select\$1range\$1check\$1per\$1call | Select range check per call | 
| db.sql\$1tokenized.stats.sum\$1select\$1scan\$1per\$1call | Select scans per call | 
| db.sql\$1tokenized.stats.sum\$1sort\$1merge\$1passes\$1per\$1call | Sort merge passes per call | 
| db.sql\$1tokenized.stats.sum\$1sort\$1scan\$1per\$1call | Sort scans per call | 
| db.sql\$1tokenized.stats.sum\$1sort\$1range\$1per\$1call | Sort ranges per call | 
| db.sql\$1tokenized.stats.sum\$1sort\$1rows\$1per\$1call | Sort rows per call | 
| db.sql\$1tokenized.stats.sum\$1rows\$1affected\$1per\$1call | Rows affected per call | 
| db.sql\$1tokenized.stats.sum\$1rows\$1examined\$1per\$1call | Rows examined per call | 
| db.sql\$1tokenized.stats.sum\$1rows\$1sent\$1per\$1call | Rows sent per call | 
| db.sql\$1tokenized.stats.sum\$1created\$1tmp\$1disk\$1tables\$1per\$1call | Created temporary disk tables per call | 
| db.sql\$1tokenized.stats.sum\$1created\$1tmp\$1tables\$1per\$1call | Created temporary tables per call | 
| db.sql\$1tokenized.stats.sum\$1lock\$1time\$1per\$1call | Lock time per call (in ms) | 

## Primary statistics for Aurora MySQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.primary"></a>

The following SQL statistics are available for Aurora MySQL DB clusters.


| Metric | Unit | 
| --- | --- | 
| db.sql\$1tokenized.stats.count\$1star | Calls | 
| db.sql\$1tokenized.stats.sum\$1timer\$1wait | Wait time (in ms) | 
| db.sql\$1tokenized.stats.sum\$1select\$1full\$1join | Select full join | 
| db.sql\$1tokenized.stats.sum\$1select\$1range\$1check | Select range checks | 
| db.sql\$1tokenized.stats.sum\$1select\$1scan | Select scans | 
| db.sql\$1tokenized.stats.sum\$1sort\$1merge\$1passes | Sort merge passes | 
| db.sql\$1tokenized.stats.sum\$1sort\$1scan | Sort scans | 
| db.sql\$1tokenized.stats.sum\$1sort\$1range | Sort ranges | 
| db.sql\$1tokenized.stats.sum\$1sort\$1rows | Sort rows | 
| db.sql\$1tokenized.stats.sum\$1rows\$1affected | Rows affected | 
| db.sql\$1tokenized.stats.sum\$1rows\$1examined | Rows examined | 
| db.sql\$1tokenized.stats.sum\$1rows\$1sent | Rows sent | 
| db.sql\$1tokenized.stats.sum\$1created\$1tmp\$1disk\$1tables | Created temporary disk tables | 
| db.sql\$1tokenized.stats.sum\$1created\$1tmp\$1tables | Created temporary tables | 
| db.sql\$1tokenized.stats.sum\$1lock\$1time | Lock time (in ms) | 

# SQL statistics for Aurora PostgreSQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL"></a>

For each SQL call and for each second that a query runs, Performance Insights collects SQL statistics. All Aurora engines collect statistics only at the digest-level.

Following, you can find information about digest-level statistics for Aurora PostgreSQL. 

**Topics**
+ [Digest statistics for Aurora PostgreSQL](#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.digest)
+ [Per-second digest statistics for Aurora PostgreSQL](#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.per-second)
+ [Per-call digest statistics for Aurora PostgreSQL](#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.per-call)
+ [Primary statistics for Aurora PostgreSQL](#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.primary)

## Digest statistics for Aurora PostgreSQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.digest"></a>

To view SQL digest statistics, the `pg_stat_statements` library must be loaded. For Aurora PostgreSQL DB clusters that are compatible with PostgreSQL 10, this library is loaded by default. For Aurora PostgreSQL DB clusters that are compatible with PostgreSQL 9.6, you enable this library manually. To enable it manually, add `pg_stat_statements` to `shared_preload_libraries` in the DB parameter group associated with the DB instance. Then reboot your DB instance. For more information, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).

**Note**  
Performance Insights can only collect statistics for queries in `pg_stat_activity` that aren't truncated. By default, PostgreSQL databases truncate queries longer than 1,024 bytes. To increase the query size, change the `track_activity_query_size` parameter in the DB parameter group associated with your DB instance. When you change this parameter, a DB instance reboot is required.

## Per-second digest statistics for Aurora PostgreSQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.per-second"></a>

The following SQL digest statistics are available for Aurora PostgreSQL DB instances.


| Metric | Unit | 
| --- | --- | 
| db.sql\$1tokenized.stats.calls\$1per\$1sec | Calls per second | 
| db.sql\$1tokenized.stats.rows\$1per\$1sec | Rows per second | 
| db.sql\$1tokenized.stats.total\$1time\$1per\$1sec | Average active executions per second (AAE) | 
| db.sql\$1tokenized.stats.shared\$1blks\$1hit\$1per\$1sec | Block hits per second | 
| db.sql\$1tokenized.stats.shared\$1blks\$1read\$1per\$1sec | Block reads per second | 
| db.sql\$1tokenized.stats.shared\$1blks\$1dirtied\$1per\$1sec | Blocks dirtied per second | 
| db.sql\$1tokenized.stats.shared\$1blks\$1written\$1per\$1sec | Block writes per second | 
| db.sql\$1tokenized.stats.local\$1blks\$1hit\$1per\$1sec | Local block hits per second | 
| db.sql\$1tokenized.stats.local\$1blks\$1read\$1per\$1sec | Local block reads per second | 
| db.sql\$1tokenized.stats.local\$1blks\$1dirtied\$1per\$1sec | Local block dirtied per second | 
| db.sql\$1tokenized.stats.local\$1blks\$1written\$1per\$1sec | Local block writes per second | 
| db.sql\$1tokenized.stats.temp\$1blks\$1written\$1per\$1sec | Temporary writes per second | 
| db.sql\$1tokenized.stats.temp\$1blks\$1read\$1per\$1sec | Temporary reads per second | 
| db.sql\$1tokenized.stats.blk\$1read\$1time\$1per\$1sec | Average concurrent reads per second | 
| db.sql\$1tokenized.stats.blk\$1write\$1time\$1per\$1sec | Average concurrent writes per second | 

## Per-call digest statistics for Aurora PostgreSQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.per-call"></a>

The following metrics provide per call statistics for a SQL statement.


| Metric | Unit | 
| --- | --- | 
| db.sql\$1tokenized.stats.rows\$1per\$1call | Rows per call | 
| db.sql\$1tokenized.stats.avg\$1latency\$1per\$1call | Average latency per call (in ms) | 
| db.sql\$1tokenized.stats.shared\$1blks\$1hit\$1per\$1call | Block hits per call | 
| db.sql\$1tokenized.stats.shared\$1blks\$1read\$1per\$1call | Block reads per call | 
| db.sql\$1tokenized.stats.shared\$1blks\$1written\$1per\$1call | Block writes per call | 
| db.sql\$1tokenized.stats.shared\$1blks\$1dirtied\$1per\$1call | Blocks dirtied per call | 
| db.sql\$1tokenized.stats.local\$1blks\$1hit\$1per\$1call | Local block hits per call | 
| db.sql\$1tokenized.stats.local\$1blks\$1read\$1per\$1call | Local block reads per call | 
| db.sql\$1tokenized.stats.local\$1blks\$1dirtied\$1per\$1call | Local block dirtied per call | 
| db.sql\$1tokenized.stats.local\$1blks\$1written\$1per\$1call | Local block writes per call | 
| db.sql\$1tokenized.stats.temp\$1blks\$1written\$1per\$1call | Temporary block writes per call | 
| db.sql\$1tokenized.stats.temp\$1blks\$1read\$1per\$1call | Temporary block reads per call | 
| db.sql\$1tokenized.stats.blk\$1read\$1time\$1per\$1call | Read time per call (in ms) | 
| db.sql\$1tokenized.stats.blk\$1write\$1time\$1per\$1call | Write time per call (in ms) | 

## Primary statistics for Aurora PostgreSQL
<a name="USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.primary"></a>

The following SQL statistics are available for Aurora PostgreSQL DB instances.


| Metric | Unit | 
| --- | --- | 
| db.sql\$1tokenized.stats.calls | Calls  | 
| db.sql\$1tokenized.stats.rows | Rows  | 
| db.sql\$1tokenized.stats.total\$1time | Total time (in ms) | 
| db.sql\$1tokenized.stats.shared\$1blks\$1hit | Block hits  | 
| db.sql\$1tokenized.stats.shared\$1blks\$1read | Block reads  | 
| db.sql\$1tokenized.stats.shared\$1blks\$1dirtied | Blocks dirtied  | 
| db.sql\$1tokenized.stats.shared\$1blks\$1written | Block writes  | 
| db.sql\$1tokenized.stats.local\$1blks\$1hit | Local block hits  | 
| db.sql\$1tokenized.stats.local\$1blks\$1read | Local block reads  | 
| db.sql\$1tokenized.stats.local\$1blks\$1dirtied | Local blocks dirtied | 
| db.sql\$1tokenized.stats.local\$1blks\$1written | Local block writes  | 
| db.sql\$1tokenized.stats.temp\$1blks\$1written | Temporary writes  | 
| db.sql\$1tokenized.stats.temp\$1blks\$1read | Temporary reads  | 
| db.sql\$1tokenized.stats.blk\$1read\$1time | Average concurrent reads (in ms) | 
| db.sql\$1tokenized.stats.blk\$1write\$1time | Average concurrent writes (in ms) | 

For more information about these metrics, see [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) in the PostgreSQL documentation.

# OS metrics in Enhanced Monitoring
<a name="USER_Monitoring-Available-OS-Metrics"></a>

Amazon Aurora provides metrics in real time for the operating system (OS) that your DB cluster runs on. Aurora delivers the metrics from Enhanced Monitoring to your Amazon CloudWatch Logs account. The following tables list the OS metrics available using Amazon CloudWatch Logs.



**Topics**
+ [OS metrics for Aurora](#USER_Monitoring-Available-OS-Metrics-RDS)

## OS metrics for Aurora
<a name="USER_Monitoring-Available-OS-Metrics-RDS"></a>

<a name="cloudwatch-os-metrics"></a>[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Monitoring-Available-OS-Metrics.html)