Amazon Redshift will no longer support the creation of new Python UDFs starting Patch 198. Existing Python UDFs will continue to function until June 30, 2026. For more information, see the [ blog post ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
# Amazon Redshift provisioned clusters
Amazon Redshift provisioned clusters
An Amazon Redshift data warehouse is a collection of computing resources called *nodes*, which are organized into a group called a *cluster*. Each cluster runs an Amazon Redshift engine and contains one or more databases.
**Note**
At this time, Amazon Redshift version 1.0 engine is available. However, as the engine is updated, multiple Amazon Redshift engine versions might be available for selection.
## Clusters and nodes in Amazon Redshift
Clusters and nodes
An Amazon Redshift cluster consists of nodes. Each cluster has a leader node and one or more compute nodes. The *leader node* receives queries from client applications, parses the queries, and develops query execution plans. The leader node then coordinates the parallel execution of these plans with the compute nodes and aggregates the intermediate results from these nodes. It then finally returns the results back to the client applications.
*Compute nodes* run the query execution plans and transmit data among themselves to serve these queries. The intermediate results are sent to the leader node for aggregation before being sent back to the client applications. For more information about leader nodes and compute nodes, see [Data warehouse system architecture](https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html) in the *Amazon Redshift Database Developer Guide*.
**Note**
When you create a cluster on the Amazon Redshift console ([https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)), you can get a recommendation of your cluster configuration based on the size of your data and query characteristics. To use this sizing calculator, look for **Help me choose** on the console in AWS Regions that support RA3 node types. For more information, see [Creating a cluster](create-cluster.md).
When you launch a cluster, one option that you specify is the node type. The node type determines the CPU, RAM, storage capacity, and storage drive type for each node.
Amazon Redshift offers different node types to accommodate your workloads, and we recommend choosing RA3 or DC2 depending on the required performance, data size, and expected data growth.
RA3 nodes with managed storage enable you to optimize your data warehouse by scaling and paying for compute and managed storage independently. With RA3, you choose the number of nodes based on your performance requirements and only pay for the managed storage that you use. Size your RA3 cluster based on the amount of data you process daily. You launch clusters that use the RA3 node types in a virtual private cloud (VPC). For more information, see [Creating a Redshift provisioned cluster or Amazon Redshift Serverless workgroup in a VPC](getting-started-cluster-in-vpc.md).
Amazon Redshift managed storage uses large, high-performance SSDs in each RA3 node for fast local storage and Amazon S3 for longer-term durable storage. If the data in a node grows beyond the size of the large local SSDs, Amazon Redshift managed storage automatically offloads that data to Amazon S3. You pay the same low rate for Amazon Redshift managed storage regardless of whether the data sits in high-performance SSDs or Amazon S3. For workloads that require ever-growing storage, managed storage lets you automatically scale your data warehouse storage capacity separate from compute nodes.
DC2 nodes enable you to have compute-intensive data warehouses with local SSD storage included. You choose the number of nodes you need based on data size and performance requirements. DC2 nodes store your data locally for high performance, and as the data size grows, you can add more compute nodes to increase the storage capacity of the cluster. For datasets under 1 TB (compressed), we recommend DC2 node types for the best performance at the lowest price. If you expect your data to grow, we recommend using RA3 nodes so you can size compute and storage independently to achieve improved price and performance. You launch clusters that use the DC2 node types in a virtual private cloud (VPC). For more information, see [Creating a Redshift provisioned cluster or Amazon Redshift Serverless workgroup in a VPC](getting-started-cluster-in-vpc.md).
Node types are available in different sizes. Node size and the number of nodes determine the total storage for a cluster. For more information, see [Node type details](#rs-node-type-info).
Some node types allow one node (single-node) or two or more nodes (multi-node). The minimum number of nodes for clusters of some node types is two nodes. On a single-node cluster, the node is shared for leader and compute functionality. Single-node clusters are not recommended for running production workloads. On a multi-node cluster, the leader node is separate from the compute nodes. The leader node is the same node type as the compute nodes. You only pay for compute nodes.
Amazon Redshift applies quotas to resources for each AWS account in each AWS Region. A *quota* restricts the number of resources that your account can create for a given resource type, such as nodes or snapshots, within an AWS Region. For more information about the default quotas that apply to Amazon Redshift resources, see [Quotas and limits in Amazon Redshift](amazon-redshift-limits.md).
The cost of your cluster depends on the AWS Region, node type, number of nodes, and whether the nodes are reserved in advance. For more information about the cost of nodes, see the [Amazon Redshift pricing](https://aws.amazon.com/redshift/pricing/) page.
### Node type details
The following tables summarize the node specifications for each node type and size. The headings in the tables have these meanings:
+ *vCPU* is the number of virtual CPUs for each node.
+ *RAM* is the amount of memory in gibibytes (GiB) for each node.
+ *Default slices per node* is the number of slices into which a compute node is partitioned when a cluster is created or resized with classic resize.
The number of slices per node might change if the cluster is resized using elastic resize. However the total number of slices on all the compute nodes in the cluster remains the same after elastic resize.
When you create a cluster with the restore from snapshot operation, the number of slices of the resulting cluster might change from the original cluster if you change the node type.
+ *Storage* is the capacity and type of storage for each node.
+ *Node range* is the minimum and maximum number of nodes that Amazon Redshift supports for the node type and size.
**Note**
You might be restricted to fewer nodes depending on the quota that is applied to your AWS account in the selected AWS Region. For more information about the default quotas that apply to Amazon Redshift resources, see [Quotas and limits in Amazon Redshift](amazon-redshift-limits.md).
+ *Total capacity* is the total storage capacity for the cluster if you deploy the maximum number of nodes that is specified in the node range.
The following table describes specifications for RA3 nodes.
| Node type | vCPU | RAM (GiB) | Default slices per node | Managed storage limit per node 1 | Node range with create cluster | Total managed storage capacity 2 |
| --- | --- | --- | --- | --- | --- | --- |
| ra3.large (single-node) | 2 | 16 | 2 | 1 TB | 1 | 1 TB3 |
| ra3.large (multi-node) | 2 | 16 | 2 | 8 TB | 2-16 | 128 TB |
| ra3.xlplus (single-node) | 4 | 32 | 2 | 4 TB | 1 | 4 TB3 |
| ra3.xlplus (multi-node) | 4 | 32 | 2 | 32 TB | 2–324 | 1024 TB4 |
| ra3.4xlarge | 12 | 96 | 4 | 128 TB | 2–325 | 8192 TB5 |
| ra3.16xlarge | 48 | 384 | 16 | 128 TB | 2–128 | 16,384 TB |
1 The storage limit for Amazon Redshift managed storage. This is a hard limit.
2 Total managed storage limit is the maximum number of nodes times the managed storage limit per node.
3 To resize a single-node cluster to multi-node, only classic resize is supported.
4 You can create a cluster with the ra3.xlplus (multi-node) node type that has up to 32 nodes. For multiple-node clusters, you can resize with elastic resize to a maximum of 32 nodes.
5 You can create a cluster with the ra3.4xlarge node type with up to 32 nodes. You can resize it with elastic resize to a maximum of 64 nodes.
The following table describes specifications for dense compute nodes.
| Node type | vCPU | RAM (GiB) | Default slices per node | Storage per node | Node range | Total capacity |
| --- | --- | --- | --- | --- | --- | --- |
| dc2.large | 2 | 15 | 2 | 160 GB NVMe-SSD | 1–32 | 5.12 TB |
| dc2.8xlarge | 32 | 244 | 16 | 2.56 TB NVMe-SSD | 2–128 | 326 TB |
**Note**
Dense storage (DS2) node types are no longer available.
**Previous node type names**
In previous releases of Amazon Redshift, certain node types had different names. You can use the previous names in the Amazon Redshift API and AWS CLI. However, we recommend that you update any scripts that reference those names to use the current names instead. The current and previous names are as follows.
| Current name | Previous names |
| --- | --- |
| ds2.xlarge | ds1.xlarge, dw.hs1.xlarge, dw1.xlarge |
| ds2.8xlarge | ds1.8xlarge, dw.hs1.8xlarge, dw1.8xlarge |
| dc1.large | dw2.large |
| dc1.8xlarge | dw2.8xlarge |
### Determining the number of nodes
Because Amazon Redshift distributes and runs queries in parallel across all of a cluster’s compute nodes, you can increase query performance by adding nodes to your cluster. When you run a cluster with at least two compute nodes, data on each node is mirrored on disks of another node to reduce the risk of incurring data loss.
You can monitor query performance in the Amazon Redshift console and with Amazon CloudWatch metrics. You can also add or remove nodes as needed to achieve the balance between price and performance for your cluster. When you request an additional node, Amazon Redshift takes care of all the details of deployment, load balancing, and data maintenance. For more information about cluster performance, see [Monitoring Amazon Redshift cluster performance](metrics.md).
Reserved nodes are appropriate for steady-state production workloads, and offer significant discounts over on-demand nodes. You can purchase reserved nodes after running experiments and proof-of-concepts to validate your production configuration. For more information, see [Reserved nodes](purchase-reserved-node-instance.md).
When you pause a cluster, you suspend on-demand billing during the time the cluster is paused. During this paused time, you only pay for backup storage. This frees you from planning and purchasing data warehouse capacity ahead of your needs, and enables you to cost-effectively manage environments for development or test purposes.
For information about pricing of on-demand and reserved nodes, see [Amazon Redshift pricing](https://aws.amazon.com/redshift/pricing/).
## Use EC2 to create your cluster
Amazon Redshift clusters run in Amazon EC2 instances that are configured for the Amazon Redshift node type and size that you select. For more information about these networking platforms, see [Supported Platforms](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html) in the *Amazon EC2 User Guide*.
**Note**
To prevent connection issues between SQL client tools and the Amazon Redshift database, we recommend doing one of two things. You can configure an inbound rule that enables the hosts to negotiate packet size. Alternatively, you can disable TCP/IP jumbo frames by setting the maximum transmission unit (MTU) to 1500 on the network interface (NIC) of your Amazon EC2 instances. For more information about these approaches, see [Queries appear to hang and sometimes fail to reach the cluster](troubleshooting-connections.md#connecting-drop-issues).
### Amazon Virtual Private Cloud (Amazon VPC)
When using Amazon VPC, your cluster runs in a virtual private cloud (VPC) that is logically isolated to your AWS account. If you provision your cluster with Amazon VPC, you control access to your cluster by associating one or more VPC security groups with the cluster. For more information, see [Security Groups for Your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) in the *Amazon VPC User Guide*.
To create a cluster in a VPC, you must first create an Amazon Redshift cluster subnet group by providing subnet information of your VPC, and then provide the subnet group when launching the cluster. For more information, see [Subnets for Redshift resources](working-with-cluster-subnet-groups.md).
For more information about Amazon Virtual Private Cloud (Amazon VPC), see the [Amazon VPC product detail page](https://aws.amazon.com/vpc/).
## Default disk space alarm
When you create an Amazon Redshift cluster, you can optionally configure an Amazon CloudWatch alarm to monitor the average percentage of disk space that is used across all of the nodes in your cluster. We’ll refer to this alarm as the *default disk space alarm*.
The purpose of default disk space alarm is to help you monitor the storage capacity of your cluster. You can configure this alarm based on the needs of your data warehouse. For example, you can use the warning as an indicator that you might need to resize your cluster. You might resize either to a different node type or to add nodes, or perhaps to purchase reserved nodes for future expansion.
The default disk space alarm triggers when disk usage reaches or exceeds a specified percentage for a certain number of times and at a specified duration. By default, this alarm triggers when the percentage that you specify is reached, and stays at or above that percentage for five minutes or longer. You can edit the default values after you launch the cluster.
When the CloudWatch alarm triggers, Amazon Simple Notification Service (Amazon SNS) sends a notification to specified recipients to warn them that the percentage threshold is reached. Amazon SNS uses a topic to specify the recipients and message that are sent in a notification. You can use an existing Amazon SNS topic; otherwise, a topic is created based on the settings that you specify when you launch the cluster. You can edit the topic for this alarm after you launch the cluster. For more information about creating Amazon SNS topics, see [Getting Started with Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html).
After you launch the cluster, you can view and edit the alarm from the cluster’s **Status** window under **CloudWatch Alarms**. The name is **percentage-disk-space-used-default-<*string*>**. You can open the alarm to view the Amazon SNS topic that it is associated with and edit alarm settings. If you did not select an existing Amazon SNS topic to use, the one created for you is named **<*clustername*>-default-alarms (<*recipient*>)**; for example, **examplecluster-default-alarms (notify@example.com)**.
For more information about configuring and editing the default disk space alarm, see [Creating a cluster](create-cluster.md) and [Creating a disk space alarm](rs-mgmt-edit-default-disk-space-alarm.md).
**Note**
If you delete your cluster, the alarm associated with the cluster will not be deleted but it will not trigger. You can delete the alarm from the CloudWatch console if you no longer need it.
## Cluster status
The cluster status displays the current state of the cluster. The following table provides a description for each cluster status.
****
| Status | Description |
| --- | --- |
| available | The cluster is running and available. |
| available, prep-for-resize | The cluster is being prepared for elastic resize. The cluster is running and available for read and write queries, but cluster operations, such as creating a snapshot, are not available. |
| available, resize-cleanup | An elastic resize operation is completing data transfer to the new cluster nodes. The cluster is running and available for read and write queries, but cluster operations, such as creating a snapshot, are not available. |
| cancelling-resize | The resize operation is being cancelled. |
| creating | Amazon Redshift is creating the cluster. For more information, see [Creating a cluster](create-cluster.md). |
| deleting | Amazon Redshift is deleting the cluster. For more information, see [Shutting down and deleting a cluster](rs-mgmt-shutdown-delete-cluster.md). |
| final-snapshot | Amazon Redshift is taking a final snapshot of the cluster before deleting it. For more information, see [Shutting down and deleting a cluster](rs-mgmt-shutdown-delete-cluster.md). |
| hardware-failure | The cluster suffered a hardware failure. If you have a single-node cluster, the node cannot be replaced. To recover your cluster, restore a snapshot. For more information, see [Amazon Redshift snapshots and backups](working-with-snapshots.md). |
| incompatible-hsm | Amazon Redshift cannot connect to the hardware security module (HSM). Check the HSM configuration between the cluster and HSM. For more information, see [Encryption using hardware security modules](working-with-db-encryption.md#working-with-HSM). |
| incompatible-network | There is an issue with the underlying network configuration. Make sure that the VPC in which you launched the cluster exists and its settings are correct. For more information, see [Redshift resources in a VPC](managing-clusters-vpc.md). |
| incompatible-parameters | There is an issue with one or more parameter values in the associated parameter group, and the parameter value or values cannot be applied. Modify the parameter group and update any invalid values. For more information, see [Amazon Redshift parameter groups](working-with-parameter-groups.md). |
| incompatible-restore | There was an issue restoring the cluster from the snapshot. Try restoring the cluster again with a different snapshot. For more information, see [Amazon Redshift snapshots and backups](working-with-snapshots.md). |
| modifying | Amazon Redshift is applying changes to the cluster. For more information, see [Modifying a cluster](modify-cluster.md). |
| paused | The cluster is paused. For more information, see [Pausing and resuming a cluster](rs-mgmt-pause-resume-cluster.md). |
| rebooting | Amazon Redshift is rebooting the cluster. For more information, see [Rebooting a cluster](reboot-cluster.md). |
| renaming | Amazon Redshift is applying a new name to the cluster. For more information, see [Renaming a cluster](rs-mgmt-rename-cluster.md). |
| resizing | Amazon Redshift is resizing the cluster. For more information, see [Resizing a cluster](resizing-cluster.md). |
| rotating-keys | Amazon Redshift is rotating encryption keys for the cluster. For more information, see [Encryption key rotation](working-with-db-encryption.md#working-with-key-rotation). |
| storage-full | The cluster has reached its storage capacity. Resize the cluster to add nodes or to choose a different node size. For more information, see [Resizing a cluster](resizing-cluster.md). |
| updating-hsm | Amazon Redshift is updating the HSM configuration. |
# Considerations for using Amazon Redshift provisioned clusters
Considerations for using provisioned clusters
After your cluster is created, you can find information in this section about regions where features are available, maintenance tasks, node types, and usage limits.
## Region and Availability Zone considerations
Amazon Redshift is available in several AWS Regions. By default, Amazon Redshift provisions your cluster in a randomly selected Availability Zone (AZ) within the AWS Region that you choose. All the cluster nodes are provisioned in the same Availability Zone.
You can optionally request a specific Availability Zone if Amazon Redshift is available in that zone. For example, if you already have an Amazon EC2 instance running in one Availability Zone, you might want to create your Amazon Redshift cluster in the same zone to reduce latency. On the other hand, you might want to choose another Availability Zone for higher availability. Amazon Redshift might not be available in all Availability Zones within an AWS Region.
For a list of supported AWS Regions where you can provision an Amazon Redshift cluster, see [Amazon Redshift endpoints](https://docs.aws.amazon.com/general/latest/gr/redshift-service.html) in the *Amazon Web Services General Reference*.
## Cluster maintenance
Amazon Redshift periodically performs maintenance to apply upgrades to your cluster. During these updates, your Amazon Redshift cluster isn't available for normal operations. You have several ways to control how we maintain your cluster. For example, you can control when we deploy updates to your clusters. You can also choose whether your cluster runs the most recently released version, or the version released previously to the most recently released version. Finally, you have the option to defer non-mandatory maintenance updates for a period of time.
### Maintenance windows
Amazon Redshift assigns a 30-minute maintenance window at random from an 8-hour block of time per AWS Region, occurring on a random day of the week (Monday through Sunday, inclusive).
#### Default maintenance windows
The following list shows the time blocks for each AWS Region from which the default maintenance windows are assigned:
+ US East (N. Virginia) Region: 03:00–11:00 UTC
+ US East (Ohio) Region: 03:00–11:00 UTC
+ US West (N. California) Region: 06:00–14:00 UTC
+ US West (Oregon) Region: 06:00–14:00 UTC
+ Africa (Cape Town) Region: 20:00–04:00 UTC
+ Asia Pacific (Hong Kong) Region: 13:00–21:00 UTC
+ Asia Pacific (Hyderabad) Region: 16:30–00:30 UTC
+ Asia Pacific (Jakarta) Region: 15:00–23:00 UTC
+ Asia Pacific (Malaysia) Region: 14:00–22:00 UTC
+ Asia Pacific (Melbourne) Region: 12:00–20:00 UTC
+ Asia Pacific (Mumbai) Region: 16:30–00:30 UTC
+ Asia Pacific (New Zealand) Region: 10:00–18:00 UTC
+ Asia Pacific (Osaka) Region: 13:00–21:00 UTC
+ Asia Pacific (Seoul) Region: 13:00–21:00 UTC
+ Asia Pacific (Singapore) Region: 14:00–22:00 UTC
+ Asia Pacific (Sydney) Region: 12:00–20:00 UTC
+ Asia Pacific (Taipei) Region: 14:00–22:00 UTC
+ Asia Pacific (Thailand) Region: 15:00–23:00 UTC
+ Asia Pacific (Tokyo) Region: 13:00–21:00 UTC
+ Canada (Central) Region: 03:00–11:00 UTC
+ Canada West (Calgary) Region: 04:00–12:00 UTC
+ China (Beijing) Region: 13:00–21:00 UTC
+ China (Ningxia) Region: 13:00–21:00 UTC
+ Europe (Frankfurt) Region: 06:00–14:00 UTC
+ Europe (Ireland) Region: 22:00–06:00 UTC
+ Europe (London) Region: 22:00–06:00 UTC
+ Europe (Milan) Region: 21:00–05:00 UTC
+ Europe (Paris) Region: 23:00–07:00 UTC
+ Europe (Stockholm) Region: 23:00–07:00 UTC
+ Europe (Zurich) Region: 20:00–04:00 UTC
+ Israel (Tel Aviv) Region: 20:00–04:00 UTC
+ Mexico (Central) Region: 04:00–12:00 UTC
+ Europe (Spain) Region: 21:00–05:00 UTC
+ Middle East (Bahrain) Region: 13:00–21:00 UTC
+ Middle East (UAE) Region: 18:00–02:00 UTC
+ South America (São Paulo) Region: 19:00–03:00 UTC
If a maintenance event is scheduled for a given week, it starts during the assigned 30-minute maintenance window. While Amazon Redshift is performing maintenance, it terminates any queries or other operations that are in progress. Downtime experienced during planned maintenance is not considered monthly downtime or unavailability within the [Amazon Redshift Service Level Agreement](https://aws.amazon.com/redshift/sla/). Most maintenance completes during the 30-minute maintenance window, but some maintenance tasks might continue running after the window closes. If there are no maintenance tasks to perform during the scheduled maintenance window, your cluster continues to operate normally until the next scheduled maintenance window.
You can change the scheduled maintenance window by modifying the cluster, either programmatically or by using the Amazon Redshift console. You can find the maintenance window and set the day and time it occurs for the cluster under the **Maintenance** tab.
It is possible for a cluster to restart outside of a maintenance window. There are a few reasons this can occur. One more common reason is that an issue has been detected with the cluster and maintenance operations are being performed to bring it back to a healthy state. For more information, see the article [Why did my Amazon Redshift cluster reboot outside of the maintenance window?](https://repost.aws/knowledge-center/redshift-reboot-maintenance-window), which provides details regarding why this might occur.
### Deferring maintenance
To reschedule your cluster's maintenance window, you can defer maintenance by up to 60 days. For example, if your cluster's maintenance window is set to Wednesday 08:30 – 09:00 UTC and you need to access your cluster at that time, you can defer the maintenance to a later time period.
If you defer maintenance, Amazon Redshift will still apply hardware updates or other mandatory security updates to your cluster. Your cluster isn't available during these updates.
If a hardware update or other mandatory security update is scheduled during the upcoming maintenance window, Amazon Redshift sends you advance notifications under the *Pending* category. To learn more about *Pending* event notifications, see [Amazon Redshift provisioned cluster event notifications](working-with-event-notifications.md).
You can also choose to receive event notifications from Amazon Simple Notification Service (Amazon SNS). For more information about subscribing to event notifications from Amazon SNS, see [Amazon Redshift cluster event notification subscriptionsCluster event notification subscriptions](working-with-event-notifications-subscribe.md).
If you defer your cluster's maintenance, the maintenance window following the period of deferment can't be deferred.
**Note**
You can't defer maintenance after it has started.
For more information about cluster maintenance, see the following documentation:
+ [Maintenance windows](#rs-maintenance-windows)
+ [Cluster operations](managing-cluster-operations.md)
+ [Modifying a cluster](modify-cluster.md)
### Choosing cluster maintenance tracks
When Amazon Redshift releases a new cluster version, your cluster is updated during its maintenance window. You can control whether your cluster is updated to the most recent release or to the previous release.
The track controls which cluster version is applied during a maintenance window. When Amazon Redshift releases a new cluster version, that version is assigned to the *current* track, and the previous version is assigned to the *trailing* track.
For information about cluster tracks, see [Tracks for Amazon Redshift provisioned clusters and serverless workgroups](tracks.md).
### Understanding how RA3 nodes separate compute and storage
These sections detail tasks available for RA3 node types, showing their applicability to a collection of use cases and detailing their advantages over previously available node types.
#### Advantages and availability of RA3 nodes
RA3 nodes provide the following advantages:
+ They are flexible to grow your compute capacity without increasing your storage costs. And they scale your storage without over-provisioning compute capacity.
+ They use high performance SSDs for your hot data and Amazon S3 for cold data. Thus they provide ease of use, cost-effective storage, and high query performance.
+ They use high bandwidth networking built on the AWS Nitro System to further reduce the time taken for data to be offloaded to and retrieved from Amazon S3.
Consider choosing RA3 node types in these cases:
+ You need the flexibility to scale and pay for compute separate from storage.
+ You query a fraction of your total data.
+ Your data volume is growing rapidly or is expected to grow rapidly.
+ You want the flexibility to size the cluster based only on your performance needs.
To use RA3 node types, your AWS Region must support RA3. For more information, see [RA3 node type availability in AWS Regions](#ra3-regions).
**Important**
You can use ra3.xlplus node types only with cluster version 1.0.21262 or later. You can view the version of an existing cluster with the Amazon Redshift console. For more information, see [Determining the workgroup or cluster version](tracks.md#cluster-version).
Make sure that you use the new Amazon Redshift console when working with RA3 node types.
In addition, to use RA3 node types with Amazon Redshift operations that use the track, the maintenance track value must be set to a cluster version that supports RA3. For more information about tracks, see [Choosing cluster maintenance tracks](#rs-mgmt-maintenance-tracks).
Consider the following when using single-node RA3 node types.
+ Datasharing producers and consumers are supported.
+ To change node types, only classic resize is supported. Changing the node type with elastic resize or snapshot restore isn't supported. The following scenarios are supported:
+ Classic resize of a 1-node dc2.xlarge to a 1-node ra3.xlplus, and vice versa.
+ Classic resize of a 1-node dc2.xlarge to a multiple-node ra3.xlplus, and vice versa.
+ Classic resize of a multiple-node dc2.xlarge to a 1-node ra3.xlplus, and vice versa.
##### Working with Amazon Redshift managed storage
With Amazon Redshift managed storage, you can store and process all your data in Amazon Redshift while getting more flexibility to scale compute and storage capacity separately. You continue to ingest data with the COPY or INSERT command. To optimize performance and manage automatic data placement across tiers of storage, Amazon Redshift takes advantage of optimizations such as data block temperature, data block age, and workload patterns. When needed, Amazon Redshift scales storage automatically to Amazon S3 without requiring any manual action.
For information about storage costs, see [Amazon Redshift pricing](https://aws.amazon.com/redshift/pricing/).
##### Managing RA3 node types
To take advantage of separating compute from storage, you can create or upgrade your cluster with the RA3 node type. To use the RA3 node types, create your clusters in a virtual private cloud (EC2-VPC).
To change the number of nodes of Amazon Redshift cluster with an RA3 node type, do one of the following:
+ Add or remove nodes with the elastic resize operation. In some situations, removing nodes from a RA3 cluster isn't allowed with elastic resize. For example, when a 2:1 node count upgrade puts the number of slices per node at 32. For more information, see [Resizing a cluster](resizing-cluster.md). If elastic resize isn't available, use classic resize.
+ Add or remove nodes with the classic resize operation. Choose this option when you are resizing to a configuration that isn't available through elastic resize. Elastic resize is quicker than classic resize. For more information, see [Resizing a cluster](resizing-cluster.md).
### RA3 node type availability in AWS Regions
The RA3 node types are available only in the following AWS Regions:
+ US East (N. Virginia) Region (us-east-1)
+ US East (Ohio) Region (us-east-2)
+ US West (N. California) Region (us-west-1)
+ US West (Oregon) Region (us-west-2)
+ Africa (Cape Town) Region (af-south-1)
+ Asia Pacific (Hong Kong) Region (ap-east-1)
+ Asia Pacific (Hyderabad) Region (ap-south-2)
+ Asia Pacific (Jakarta) Region (ap-southeast-3)
+ Asia Pacific (Malaysia) Region (ap-southeast-5)
+ Asia Pacific (Melbourne) Region (ap-southeast-4)
+ Asia Pacific (Mumbai) Region (ap-south-1)
+ Asia Pacific (New Zealand) Region (ap-southeast-6)
+ Asia Pacific (Osaka) Region (ap-northeast-3)
+ Asia Pacific (Seoul) Region (ap-northeast-2)
+ Asia Pacific (Singapore) Region (ap-southeast-1)
+ Asia Pacific (Sydney) Region (ap-southeast-2)
+ Asia Pacific (Taipei) Region (ap-east-2)
+ Asia Pacific (Thailand) Region (ap-southeast-7)
+ Asia Pacific (Tokyo) Region (ap-northeast-1)
+ Canada (Central) Region (ca-central-1)
+ Canada West (Calgary) Region (ca-west-1)
+ China (Beijing) Region (cn-north-1)
+ China (Ningxia) Region (cn-northwest-1)
+ Europe (Frankfurt) Region (eu-central-1)
+ Europe (Zurich) Region (eu-central-2)
+ Europe (Ireland) Region (eu-west-1)
+ Europe (London) Region (eu-west-2)
+ Europe (Milan) Region (eu-south-1)
+ Europe (Spain) Region (eu-south-2)
+ Europe (Paris) Region (eu-west-3)
+ Europe (Stockholm) Region (eu-north-1)
+ Israel (Tel Aviv) Region (il-central-1)
+ Mexico (Central) Region (mx-central-1)
+ Middle East (Bahrain) Region (me-south-1)
+ Middle East (UAE) Region (me-central-1)
+ South America (São Paulo) Region (sa-east-1)
+ AWS GovCloud (US-East) (us-gov-east-1)
+ AWS GovCloud (US-West) (us-gov-west-1)
### Upgrading to RA3 node types
To upgrade your existing node type to RA3, you have the following options to change the node type:
+ Restore from a snapshot – Amazon Redshift uses the most recent snapshot of your cluster and restores it to create a new RA3 cluster. As soon as the cluster creation is complete (usually within minutes), RA3 nodes are ready to run your full production workload. As compute is separate from storage, hot data is brought in to the local cache at fast speeds thanks to a large networking bandwidth. If you restore from the latest DC2 snapshot, RA3 preserves hot block information of the DC2 workload and populates its local cache with the hottest blocks. For more information, see [Restoring a cluster from a snapshot](working-with-snapshot-restore-cluster-from-snapshot.md).
To keep the same endpoint for your applications and users, you can rename the new RA3 cluster with the same name as the original DC2 cluster. To rename the cluster, modify the cluster in the Amazon Redshift console or `ModifyCluster` API operation. For more information, see [Renaming a cluster](rs-mgmt-rename-cluster.md) or [`ModifyCluster` API operation](https://docs.aws.amazon.com/redshift/latest/APIReference/API_ModifyCluster.html) in the *Amazon Redshift API Reference*.
+ Elastic resize – resize the cluster using elastic resize. When you use elastic resize to change node type, Amazon Redshift automatically creates a snapshot, creates a new cluster, deletes the old cluster, and renames the new cluster. The elastic resize operation can be run on-demand or can be scheduled to run at a future time. You can quickly upgrade your existing DC2 node type clusters to RA3 with elastic resize. For more information, see [Elastic resize](resizing-cluster.md#elastic-resize).
The following table shows recommendations when upgrading to RA3 node types. (These recommendations also apply to reserved nodes.)
The recommendations in this table are starting cluster node types and sizes but depend on the computing requirements of your workload. To better estimate your requirements, consider conducting a proof of concept (POC) that uses [Test Drive](https://github.com/aws/redshift-test-drive/tree/main) to run potential configurations. Provision a cluster for your POC data warehouse instead of Redshift Serverless. For more information about conducting a proof of concept, see [Conduct a proof of concept (POC) for Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/proof-of-concept-playbook.html) in the *Amazon Redshift Database Developer Guide*.
| Existing node type | Existing number of nodes | Recommended new node type | Upgrade action |
| --- | --- | --- | --- |
| dc2.8xlarge | 2–15 | ra3.4xlarge | Start with 2 nodes of ra3.4xlarge for every 1 node of dc2.8xlarge1. |
| dc2.8xlarge | 16–128 | ra3.16xlarge | Start with 1 node of ra3.16xlarge for every 2 nodes of dc2.8xlarge1. |
| dc2.large | 1–4 | ra3.large | Start with 1 node of ra3.large for every 1 node of dc2.large1. Start with 2 nodes of ra3.large for every 2 nodes of dc2.large1. Start with 3 nodes of ra3.large for every 3 nodes of dc2.large1. Start with 3 nodes of ra3.large for every 4 nodes of dc2.large1. |
| dc2.large | 5–15 | ra3.xlplus | Start with 3 nodes of ra3.xlplus for every 8 nodes of dc2.large1. |
| dc2.large | 16–32 | ra3.4xlarge | Start with 1 node of ra3.4xlarge for every 8 nodes of dc2.large1,2. |
1Extra nodes might be needed depending on workload requirements. Add or remove nodes based on the compute requirements of your required query performance.
2Clusters with the dc2.large node type are limited to 32 nodes.
The minimum number of nodes for some RA3 node types is 2 nodes. Take this into consideration when creating an RA3 cluster.
### Networking features supported by RA3 nodes
RA3 nodes support a collection of networking features not available to other node types. This section provides brief descriptions of each feature and links to additional documentation:
+ **Provisioned-cluster VPC endpoint** – When you create or restore an RA3 cluster, Amazon Redshift uses a port within the ranges of 5431-5455 or 8191-8215. When the cluster is set to a port in one of these ranges, Amazon Redshift automatically creates a VPC endpoint in your AWS account for the cluster and attaches a private IP address to it. If you set the cluster to publicly-accessible, Redshift creates an elastic IP address in your AWS account and attaches it to the VPC endpoint. For more information, see [Configuring security group communication settings for an Amazon Redshift cluster or an Amazon Redshift Serverless workgroup](https://docs.aws.amazon.com/redshift/latest/mgmt/rs-security-group-public-private.html).
+ **Single-subnet RA3 clusters** – You can create an RA3 cluster with a single subnet, but it can't use disaster-recovery features. An exception occurs if you enable cluster relocation when the subnet doesn't have multiple Availability Zones (AZs).
+ **Multi-subnet RA3 clusters and subnet groups** – You can create an RA3 cluster with multiple subnets by creating a subnet group when you provision the cluster in your virtual private cloud (VPC). A cluster subnet group allows you to specify a set of subnets in your VPC and Amazon Redshift creates the cluster in one of them. After creating a subnet group, you can remove subnets you previously added, or add more. For more information, see [Amazon Redshift cluster subnet groups](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-cluster-subnet-groups.html).
+ **Cross-account or cross-VPC endpoint access** – You can access a provisioned cluster or Amazon Redshift Serverless workgroup by setting up a Redshift-managed VPC endpoint. You can set it up as a private connection between a VPC that contains a cluster or workgroup and a VPC where you run a client tool, for example. By doing this, you can access the data warehouse without using a public IP address and without routing traffic through the internet. For more information, see [Working with Redshift-managed VPC endpoints](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-cluster-cross-vpc.html).
+ **Cluster relocation** – You can move a cluster to another Availability Zone (AZ) without any loss of data when there is an interruption of service. You enable it on the console. For more information, see [Relocating a cluster](managing-cluster-recovery.md).
+ **Custom domain name** – You can create a custom domain name, also known as a custom URL, for your Amazon Redshift cluster. It's an easy-to-read DNS record that routes SQL-client connections to your cluster endpoint. For more information, see [Custom domain names for client connections](connecting-connection-CNAME.md).
# Cluster operations
Cluster operations
After you create a cluster, you can perform cluster operations to optimize performance, control costs, and ensure high availability. Cluster operations allow you to resize, pause, resume, or even recreate clusters as your data warehousing needs evolve.
Common use cases include scaling compute capacity for peak workloads, pausing clusters during inactive periods to reduce costs, and recreating clusters with different configurations or in different Availability Zones for disaster recovery. The following sections cover the details of performing various cluster operations to effectively manage your Amazon Redshift environment.
# Creating a cluster
With Amazon Redshift, you can create a provisioned cluster to launch a new data warehouse. A provisioned cluster is a collection of computing resources called nodes, which are organized into a single, massively parallel processing (MPP) system.
Before you create a cluster, read [Amazon Redshift provisioned clusters](working-with-clusters.md) and [Clusters and nodes in Amazon Redshift](working-with-clusters.md#rs-about-clusters-and-nodes).
**To create a cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list.
1. Choose **Create cluster** to create a cluster.
1. Follow the instructions on the console page to enter the properties for **Cluster configuration**.
The following step describes an Amazon Redshift console that is running in an AWS Region that supports RA3 node types. For a list of AWS Regions that support RA3 node types, see [Overview of RA3 node types](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-ra3-node-types) in the *Amazon Redshift Management Guide*.
If you don't know how large to size your cluster, choose **Help me choose**. Doing this starts a sizing calculator that asks you questions about the size and query characteristics of the data that you plan to store in your data warehouse. If you know the required size of your cluster (that is, the node type and number of nodes), choose **I'll choose**. Then choose the **Node type** and number of **Nodes** to size your cluster for the proof of concept.
**Note**
If your organization is eligible and your cluster is being created in an AWS Region where Amazon Redshift Serverless is unavailable, you might be able to create a cluster under the Amazon Redshift free trial program. Choose either **Production** or **Free trial** to answer the question **What are you planning to use this cluster for?** When you choose **Free trial**, you create a configuration with the dc2.large node type. For more information about choosing a free trial, see [Amazon Redshift free trial](https://aws.amazon.com/redshift/free-trial/). For a list of AWS Regions where Amazon Redshift Serverless is available, see the endpoints listed for the [Redshift Serverless API ](https://docs.aws.amazon.com/general/latest/gr/redshift-service.html) in the *Amazon Web Services General Reference*.
1. In the **Database configuration** section, specify a value for **Admin user name**. For **Admin password**, you can choose from the following options:
+ **Generate a password** – Use a password generated by Amazon Redshift.
+ **Manually add an admin password** – Use your own password.
+ **Manage admin credentials in AWS Secrets Manager** – Amazon Redshift uses AWS Secrets Manager to generate and manage your admin password. Using AWS Secrets Manager to generate and manage your password's secret incurs a fee. For information on AWS Secrets Manager pricing, see [AWS Secrets Manager Pricing](https://aws.amazon.com/secrets-manager/pricing/).
1. (Optional) Follow the instructions on the console page to enter properties for **Cluster permissions**. Provide cluster permissions if your cluster needs to access other AWS services for you, for example to load data from Amazon S3.
1. Choose **Create cluster** to create the cluster. The cluster might take several minutes to be ready to use.
## Additional configurations
When you create a cluster, you can specify additional properties to customize it. You can find more details about some of these properties in the following list.
**IP address type**
Choose the IP address type for your cluster. You can choose to have your resources communicate only over the IPv4 addressing protocol, or choose dual-stack mode, which lets your resources communicate over both IPv4 and IPv6. This feature is only available in the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions. For more information on AWS Regions, see [Regions and Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).
**Virtual private cloud (VPC)**
Choose a VPC that has a cluster subnet group. After the cluster is created, the cluster subnet group can't be changed.
**Parameter groups**
Choose a cluster parameter group to associate with the cluster. If you don't choose one, the cluster uses the default parameter group.
**Encryption**
Choose whether you want to encrypt all data within the cluster and its snapshots. If you leave the default setting, **None**, encryption is not enabled. If you want to enable encryption, choose whether you want to use AWS Key Management Service (AWS KMS) or a hardware security module (HSM), and then configure the related settings. For more information about encryption in Amazon Redshift, see [Amazon Redshift database encryption](working-with-db-encryption.md).
+ **KMS**
Choose **Use AWS Key Management Service (AWS KMS)** if you want to enable encryption and use AWS KMS to manage your encryption key. Also, choose the key to use. You can choose a default key, a key from the current account, or a key from a different account.
**Note**
If you want to use a key from another AWS account, then enter the Amazon Resource Name (ARN) for the key to use. You must have permission to use the key. For more information about access to keys in AWS KMS, see [Controlling access to your keys](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) in the *AWS Key Management Service Developer Guide*.
For more information about using AWS KMS encryption keys in Amazon Redshift, see [Encryption using AWS KMS](working-with-db-encryption.md#working-with-aws-kms).
+ **HSM**
Choose **HSM** if you want to enable encryption and use a hardware security module (HSM) to manage your encryption key.
If you choose **HSM**, choose values from **HSM Connection** and **HSM Client Certificate**. These values are required for Amazon Redshift and the HSM to form a trusted connection over which the cluster key can be passed. The HSM connection and client certificate must be set up in Amazon Redshift before you launch a cluster. For more information about setting up HSM connections and client certificates, see [Encryption using hardware security modules](working-with-db-encryption.md#working-with-HSM).
**Maintenance track**
You can choose whether the cluster version used is the **Current**, **Trailing**, or sometimes **Preview** track.
**Monitoring**
You can choose whether to create CloudWatch alarms.
**Configure cross-region snapshot**
You can choose whether to enable cross-Region snapshots.
**Automated snapshot retention period**
You can choose the number of days to retain these snapshots within 35 days. If the node type is DC2, you can choose zero (0) days to not create automated snapshots.
**Manual snapshot retention period**
You can choose the number of days or `Indefinitely` to retain these snapshots.
**Extra compute resources for automatic optimizations**
You can choose whether to allocate extra compute resources to perform automatic optimizations, even during periods of heavy usage. For more information, see [ Allocating extra compute resources for automatic database optimization ](https://docs.aws.amazon.com/redshift/latest/dg/t_extra-compute-autonomics.html) in the *Amazon Redshift Database Developer Guide*.
# Creating a disk space alarm
You can monitor disk space usage and set alarms to be notified when disk space exceeds a specified threshold for a cluster. Creating a disk space usage alarm allows you to proactively manage storage capacity and prevent issues caused by insufficient disk space, such as query failures or data ingestion errors. The following procedure guides you through the process of creating a disk space usage alarm.
**To create a disk space usage alarm for a cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Alarms**.
1. For **Actions**, choose **Create alarm**. The **Create alarm** page appears.
1. Follow the instructions on the page.
1. Choose **Create alarm**.
# Viewing a cluster
Viewing a cluster allows you to monitor and manage your cluster's configuration, status, and performance metrics. By viewing cluster details, you can gain insights into resource utilization, query execution times, and system health. The following procedure shows you how to access cluster information.
**To view a cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list. If you don't have any clusters, choose **Create cluster** to create one.
1. Choose the cluster name in the list to view more details about a cluster.
# Modifying a cluster
When you modify a cluster, changes to the following options are applied immediately:
+ **VPC security groups**
+ **Publicly accessible**
+ **Admin user password**
+ **HSM Connection**
+ **HSM Client Certificate**
+ **Maintenance detail**
+ **Snapshot preferences**
Changes to the following options take effect only after the cluster is restarted:
+ **Cluster identifier**
Amazon Redshift restarts the cluster automatically when you change **Cluster identifier**.
+ **Enhanced VPC routing**
Amazon Redshift restarts the cluster automatically when you change **Enhanced VPC routing**.
+ **Cluster parameter group**
+ **IP address type**
This feature is only available in the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions. For more information on AWS Regions, see [Regions and Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).
If you decrease the automated snapshot retention period, existing automated snapshots whose settings fall outside of the new retention period are deleted. For more information, see [Amazon Redshift snapshots and backups](working-with-snapshots.md).
For more information about cluster properties, see [Additional configurations](create-cluster.md#cluster-create-console-configuration).
**To modify a cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**.
1. Choose the cluster to modify.
1. Choose **Edit**. The **Edit cluster** page appears.
1. Update the cluster properties. Some of the properties you can modify are:
+ Cluster identifier
+ Snapshot retention
+ Cluster relocation
To edit settings for **Network and security**, **Maintenance**, and **Database configurations**, the console provides links to the appropriate cluster details tab.
1. Choose **Save changes**.
# Resizing a cluster
Resizing a cluster
As your data warehousing capacity and performance needs change, you can resize your cluster to make the best use of Amazon Redshift's computing and storage options.
When you resize a cluster, you specify a number of nodes or node type that is different from the current configuration of the cluster. While the cluster is in the process of resizing, you cannot run any write or read/write queries on the cluster; you can run only read queries.
For more information about resizing clusters, including walking through the process of resizing clusters using different approaches, see [Resizing a cluster](#resizing-cluster).
**To resize a cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**.
1. Choose the cluster to resize.
1. For **Actions**, choose **Resize**. The **Resize cluster** page appears.
1. Follow the instructions on the page. You can resize the cluster now, once at a specific time, or increase and decrease the size of your cluster on a schedule.
1. Depending on your choices, choose **Resize now** or **Schedule resize**.
If you have reserved nodes, you can upgrade to RA3 reserved nodes. You can do this when you use the console to restore from a snapshot or to perform an elastic resize. You can use the console to guide you through this process. For more information about upgrading to RA3 nodes, see [Upgrading to RA3 node types](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
When you perform a resize operation to upgrade from a DC2.large node type to an RA3.large node type, Amazon Redshift automatically converts interleaved sort keys to compound sort keys. This conversion enables access to the concurrency scaling feature, which does not support queries on tables with interleaved sort keys. While this automatic conversion ensures compatibility with RA3 features, it may impact your existing query performance patterns.
If you want to maintain interleaved sort keys after upgrading to RA3 nodes, you can recreate your tables with the desired sort key configuration after the resize operation completes. However, choosing this option means you won't be able to use concurrency scaling for these tables.
A resize operation comes in two types:
+ **Elastic resize** – You can add nodes to or remove nodes from your cluster. You can also change the node type, such as from DC2 nodes to RA3 nodes. An elastic resize typically completes quickly, taking ten minutes on average. For this reason, we recommend it as a first option. When you perform an elastic resize, it redistributes data slices, which are partitions that are allocated memory and disk space in each node. Elastic resize is appropriate when you:
+ *Add or reduce nodes in an existing cluster, but you don't change the node type* – This is commonly called an *in-place* resize. When you perform this type of resize, some running queries complete successfully, but others can be dropped as part of the operation.
+ *Change the node type for a cluster* – When you change the node type, a snapshot is created and data is redistributed from the source cluster to a cluster comprised of the new node type. On completion, running queries are dropped. Like the *in-place* resize, it completes quickly.
+ **Classic resize** – You can change the node type, number of nodes, or both, in a similar manner to elastic resize. Classic resize takes more time to complete, but it can be useful in cases where the change in node count or the node type to migrate to doesn't fall within the bounds for elastic resize. This can apply, for instance, when the change in node count is really large.
**Topics**
+ [
## Elastic resize
](#elastic-resize)
+ [
## Classic resize
](#classic-resize-faster)
## Elastic resize
An elastic resize operation, when you add or remove nodes of the same type, has the following stages:
1. Elastic resize takes a cluster snapshot. No-backup tables are only supported for DC2 nodes. For all other types of cluster, no-backup tables are included in the snapshot. For more information, see [Excluding tables from snapshots](working-with-snapshots.md#snapshots-no-backup-tables). If your cluster doesn't have a recent snapshot, because you disabled automated snapshots, the backup operation can take longer. (To minimize the time before the resize operation begins, we recommend that you enable automated snapshots or create a manual snapshot before starting the resize.) When you start an elastic resize and a snapshot operation is in progress, the resize can fail if the snapshot operation doesn't complete within a few minutes. For more information, see [Amazon Redshift snapshots and backups](working-with-snapshots.md).
1. The operation migrates cluster metadata. The cluster is unavailable for a few minutes. The majority of queries are temporarily paused and connections are held open. It is possible, however, for some queries to be dropped. This stage is short.
1. Session connections are reinstated and queries resume.
1. Elastic resize redistributes data to node slices, in the background. The cluster is available for read and write operations, but some queries can take longer to run.
1. After the operation completes, Amazon Redshift sends an event notification.
When you use elastic resize to change the node type, it works similarly to when you add or subtract nodes of the same type. First, a snapshot is created. A new target cluster is provisioned with the latest data from the snapshot, and data is transferred to the new cluster in the background. During this period, data is read only. When the resize nears completion, Amazon Redshift updates the endpoint to point to the new cluster and all connections to the source cluster are dropped.
It's unlikely that an elastic resize would fail. However, in the case of a failure, rollback happens automatically in the majority of cases without needing any manual intervention.
If you have reserved nodes, for example DC2 reserved nodes, you can upgrade to RA3 reserved nodes when you perform a resize. You can do this when you perform an elastic resize or use the console to restore from a snapshot. The console guides you through this process. For more information about upgrading to RA3 nodes, see [Upgrading to RA3 node types](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
Elastic resize doesn't sort tables or reclaims disk space, so it isn't a substitute for a vacuum operation. For more information, see [Vacuuming tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html).
Elastic resize has the following constraints:
+ *Elastic resize and data sharing clusters* - When you add or subtract nodes on a cluster that's a producer for data sharing, you can’t connect to it from consumers while Amazon Redshift migrates cluster metadata. Similarly, if you perform an elastic resize and choose a new node type, data sharing is unavailable while connections are dropped and transferred to the new target cluster. In both types of elastic resize, the producer is unavailable for several minutes.
+ *Data transfer from a shared snapshot* - To run an elastic resize on a cluster that is transferring data from a shared snapshot, at least one backup must be available for the cluster. You can view your backups on the Amazon Redshift console snapshots list, the `describe-cluster-snapshots` CLI command, or the `DescribeClusterSnapshots` API operation.
+ *Platform restriction* - Elastic resize is available only for clusters that use the EC2-VPC platform. For more information, see [Use EC2 to create your cluster](working-with-clusters.md#cluster-platforms).
+ *Storage considerations* - Make sure that your new node configuration has enough storage for existing data. You may have to add additional nodes or change configuration.
+ *Source vs target cluster size* - The number of nodes and node type that it's possible to resize to with elastic resize is determined by the number of nodes in the source cluster and the node type chosen for the resized cluster. To determine the possible configurations available, you can use the console. Or you can use the `describe-node-configuration-options` AWS CLI command with the `action-type resize-cluster` option. For more information about the resizing using the Amazon Redshift console, see [Resizing a cluster](#resizing-cluster).
The following example CLI command describes the configuration options available. In this example, the cluster named `mycluster` is a `dc2.large` 8-node cluster.
```
aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster
```
This command returns an option list with recommended node types, number of nodes, and disk utilization for each option. The configurations returned can vary based on the specific input cluster. You can choose one of the returned configurations when you specify the options of the `resize-cluster` CLI command.
+ *Ceiling on additional nodes* - Elastic resize has limits on the nodes that you can add to a cluster. For example, a dc2 cluster supports elastic resize up to double the number of nodes. To illustrate, you can add a node to a 4-node dc2.8xlarge cluster to make it a five-node cluster, or add more nodes until you reach eight.
**Note**
The growth and reduction limits are based on the original node type and the number of nodes in the original cluster or its last classic resize. If an elastic resize will exceed the growth or reduction limits, use a classic resize.
With some ra3 node types, you can increase the number of nodes up to four times the existing count. Specifically, suppose that your cluster consists of ra3.4xlarge or ra3.16xlarge nodes. You can then use elastic resize to increase the number of nodes in an 8-node cluster to 32. Or you can pick a value below the limit. (Keep in mind that the ability to grow the cluster by 4x depends on the source cluster size.) If your cluster has ra3.xlplus nodes, the limit is double.
All ra3 node types support a decrease in the number of nodes to a quarter of the existing count. For example, you can decrease the size of a cluster with ra3.4xlarge nodes from 12 nodes to 3, or to a number above the minimum.
The following table lists growth and reduction limits for each node type that supports elastic resize.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/redshift/latest/mgmt/resizing-cluster.html)
**Note**
**Choosing legacy node types when you resize an RA3 cluster** – If you attempt to resize from a cluster with RA3 nodes to another node type, such as DC2 , a validation warning message appears in the console, and the resize operation won't complete. This occurs because resize to legacy node types isn't supported. This is to prevent a customer from resizing to a node type that's deprecated or soon to be deprecated. This applies for both elastic resize and classic resize.
## Classic resize
Classic resize handles use cases where the change in cluster size or node type isn't supported by elastic resize. When you perform a classic resize, Amazon Redshift creates a target cluster and migrates your data and metadata to it from the source cluster.
### Classic resize to RA3 can provide better availability
Classic resize has been enhanced when the target node type is RA3. It does this by using a backup and restore operation between the source and target cluster. When the resize begins, the source cluster restarts and is unavailable for a few minutes. After that, the cluster is available for read and write operations while the resize continues in the background.
#### Checking your cluster
To ensure you have the best performance and results when you perform a classic resize to an RA3 cluster, complete this checklist. When you don't follow the checklist, you may not get some of the benefits of classic resizing with RA3 nodes, such as the ability to do read and write operations.
1. The size of the data must be below 2 petabytes. (A petabyte is equal to 1,000 terabytes.) To validate the size of your data, create a snapshot and check its size. You can also run the following query to check the size:
```
SELECT
sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
sum(size) as total_blocks,
((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
FROM svv_table_info;
```
The `svv_table_info` table is visible only to superusers.
1. Before you initiate a classic resize, make sure you have a manual snapshot that is no more than 10 hours old. If not, take a snapshot.
1. The snapshot used to perform the classic resize can't be used for a table restore or other purpose.
1. The cluster must be in a VPC.
#### Sorting and distribution operations that result from classic resize to RA3
During classic resize to RA3, tables with KEY distribution that are migrated as EVEN distribution are converted back to their original distribution style. The duration of this is dependent on the size of the data and how busy your cluster is. Query workloads are given higher priority to run over data migration. For more information, see [Distribution styles](https://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html). Both reads and writes to the database work during this migration process, but it can take longer for queries to complete. However, concurrency scaling can boost performance during this time by adding resources for query workloads. You can see the progress of data migration by viewing results from the [SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html) and [SYS\$1RESTORE\$1LOG](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_LOG.html) views. More information about monitoring follows.
After the cluster is fully resized, the following sort behavior occurs:
+ If the resize results in the cluster having more slices, KEY distribution tables become partially unsorted, but EVEN tables remain sorted. Additionally, the information about how much data is sorted may not be up to date, directly following the resize. After key recovery, automatic vacuum sorts the table over time.
+ If the resize results in the cluster having fewer slices, both KEY distribution and EVEN distribution tables become partially unsorted. Automatic vacuum sorts the table over time.
For more information about automatic table vacuum, see [Vacuuming tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html). For more information about slices in compute nodes, see [Data warehouse system architecture](https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html).
#### Classic resize steps when the target cluster is RA3
Classic resize consists of the following steps, when the target cluster type is RA3 and you've met the prerequisites detailed in the previous section.
1. Migration initiates from the source cluster to the target cluster. When the new, target cluster is provisioned, Amazon Redshift sends an event notification that the resize has started. It restarts your existing cluster, which closes all connections. If your existing cluster is a datasharing producer cluster, connections with consumer clusters are also closed. The restart takes a few minutes.
1. After the restart, the database is available for reads and writes. Additionally, data sharing resumes, which takes an additional few minutes.
1. Data is migrated to the target cluster. When the target node type is RA3, reads and writes are available during data migration.
1. When the resize process nears completion, Amazon Redshift updates the endpoint to the target cluster, and all connections to the source cluster are dropped. The target cluster becomes the producer for data sharing.
1. The resize completes. Amazon Redshift sends an event notification.
You can view the resize progress on the Amazon Redshift console. The time it takes to resize a cluster depends on the amount of data.
**Note**
**Choosing legacy node types when you resize an RA3 cluster** – If you attempt to resize from a cluster with RA3 nodes to another node type, such as DC2 , a validation warning message appears in the console, and the resize operation won't complete. This occurs because resize to legacy node types isn't supported. This is to prevent a customer from resizing to a node type that's deprecated or soon to be deprecated. This applies for both elastic resize and classic resize.
#### Monitoring a classic resize when the target cluster is RA3
To monitor a classic resize of a provisioned cluster in progress, including KEY distribution, use [SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html). It shows the percentage completed for the table being converted. You must be a super user to access the data.
Drop tables that you don't need when you perform a classic resize. When you do this, existing tables can be distributed more quickly.
### Classic resize steps when the target cluster isn't RA3
Classic resize consists of the following, when the target node type is anything other than RA3, like DC2, for instance.
1. Migration initiates from the source cluster to the target cluster. When the new, target cluster is provisioned, Amazon Redshift sends an event notification that the resize has started. It restarts your existing cluster, which closes all connections. If your existing cluster is a datasharing producer cluster, connections with consumer clusters are also closed. The restart takes a few minutes.
Note that any database relation, such as a table or materialized view, created with `BACKUP NO` is not retained during the classic resize. For more information, see [CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html).
1. Following the restart, the database is available as read only. Data sharing resumes, which takes an additional few minutes.
1. Data is migrated to the target cluster. The database remains read only.
1. When the resize process nears completion, Amazon Redshift updates the endpoint to the target cluster, and all connections to the source cluster are dropped. The target cluster becomes the producer for data sharing.
1. The resize completes. Amazon Redshift sends an event notification.
You can view the resize progress on the Amazon Redshift console. The time it takes to resize a cluster depends on the amount of data.
**Note**
It can take days or possibly weeks to resize a cluster with a large amount of data when the target cluster isn't RA3, or it doesn't meet the prerequisites for an RA3 target cluster detailed in the previous section.
Also note that used storage capacity for the cluster can go up after a classic resize. This is normal system behavior when the cluster has additional data slices that result from the classic resize. This use of additional capacity can occur even when the number of nodes in the cluster stays the same.
### Elastic resize vs classic resize
The following table compares behavior between the two resize types.
| Behavior | Elastic resize | Classic resize | Comments |
| --- | --- | --- | --- |
| System data retention | Elastic resize retains system log data. | Classic resize doesn't retain system tables and data. | If you have audit logging enabled in your source cluster, you can continue to access the logs in Amazon S3 or in CloudWatch, following a resize. You can keep or delete these logs as your data policies specify. |
| Changing node types | Elastic resize, when the node type doesn't change: In-place resize, and most queries are held. Elastic resize, with a new node type selected: A new cluster is created. Queries are dropped as the resize process completes. | Classic Resize: A new cluster is created. Queries are dropped during the resize process. | |
| Session and query retention | Elastic resize retains sessions and queries when the node type is the same in the source cluster and target. If you choose a new node type, queries are dropped. | Classic resize doesn't retain sessions and queries. Queries are dropped. | When queries are dropped, you can expect some performance degradation. It's best to perform a resize operation during a period of light use. |
| Cancelling a resize operation | You can't cancel an elastic resize. | You can cancel a classic resize operation before it completes by choosing **Cancel resize** from the cluster details in the Amazon Redshift console. | The amount of time it takes to cancel a resize depends on the stage of the resize operation when you cancel. When you do this, the cluster isn't available until the cancel operation completes. If the resize operation is in the final stage, you can't cancel. For classic resize to an RA3 cluster, you can't cancel. |
### Scheduling a resize
You can schedule resize operations for your cluster to scale up to anticipate high use or to scale down for cost savings. Scheduling works for both elastic resize and classic resize. You can set up a schedule on the Amazon Redshift console. For more information, see [Resizing a cluster](#resizing-cluster), under **Managing clusters using the console**. You can also use AWS CLI or Amazon Redshift API operations to schedule a resize. For more information, see [create-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/redshift/create-scheduled-action.html) in the *AWS CLI Command Reference* or [CreateScheduledAction](https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateScheduledAction.html) in the *Amazon Redshift API Reference*.
### Snapshot, restore, and resize
[Elastic resize](#elastic-resize) is the fastest method to resize an Amazon Redshift cluster. If elastic resize isn't an option for you and you require near-constant write access to your cluster, use the snapshot and restore operations with classic resize as described in the following section. This approach requires that any data that is written to the source cluster after the snapshot is taken must be copied manually to the target cluster after the switch. Depending on how long the copy takes, you might need to repeat this several times until you have the same data in both clusters. Then you can make the switch to the target cluster. This process might have a negative impact on existing queries until the full set of data is available in the target cluster. However, it minimizes the amount of time that you can't write to the database.
The snapshot, restore, and classic resize approach uses the following process:
1. Take a snapshot of your existing cluster. The existing cluster is the source cluster.
1. Note the time that the snapshot was taken. Doing this means that you can later identify the point when you need to rerun extract, transact, load (ETL) processes to load any post-snapshot data into the target database.
1. Restore the snapshot into a new cluster. This new cluster is the target cluster. Verify that the sample data exists in the target cluster.
1. Resize the target cluster. Choose the new node type, number of nodes, and other settings for the target cluster.
1. Review the loads from your ETL processes that occurred after you took a snapshot of the source cluster. Be sure to reload the same data in the same order into the target cluster. If you have ongoing data loads, repeat this process several times until the data is the same in both the source and target clusters.
1. Stop all queries running on the source cluster. To do this, you can reboot the cluster, or you can log on as a superuser and use the [PG\$1CANCEL\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_CANCEL_BACKEND.html) and the [PG\$1TERMINATE\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_TERMINATE_BACKEND.html) commands. Rebooting the cluster is the easiest way to make sure that the cluster is unavailable.
1. Rename the source cluster. For example, rename it from `examplecluster` to `examplecluster-source`.
1. Rename the target cluster to use the name of the source cluster before the rename. For example, rename the target cluster from preceding to `examplecluster`. From this point on, any applications that use the endpoint containing `examplecluster` connect to the target cluster.
1. Delete the source cluster after you switch to the target cluster, and verify that all processes work as expected.
Alternatively, you can rename the source and target clusters before reloading data into the target cluster. This approach works if you don't require that any dependent systems and reports be immediately up to date with those for the target cluster. In this case, step 6 moves to the end of the process described preceding.
The rename process is only required if you want applications to continue using the same endpoint to connect to the cluster. If you don't require this, you can instead update any applications that connect to the cluster to use the endpoint of the target cluster without renaming the cluster.
There are a couple of benefits to reusing a cluster name. First, you don't need to update application connection strings because the endpoint doesn't change, even though the underlying cluster changes. Second, related items such as Amazon CloudWatch alarms and Amazon Simple Notification Service (Amazon SNS) notifications are tied to the cluster name. This tie means that you can continue using the same alarms and notifications that you set up for the cluster. This continued use is primarily a concern in production environments where you want the flexibility to resize the cluster without reconfiguring related items, such as alarms and notifications.
# Renaming a cluster
You can rename a cluster if you want the cluster to use a different name. Because the endpoint to your cluster includes the cluster name (also referred to as the *cluster identifier*), the endpoint changes to use the new name after the rename finishes. For example, if you have a cluster named `examplecluster` and rename it to `newcluster`, the endpoint changes to use the `newcluster` identifier. Any applications that connect to the cluster must be updated with the new endpoint.
You may rename a cluster if you want to change the cluster your applications connect to without having to change the endpoint in those applications. In this case, you must first rename the original cluster and then change the second cluster to reuse the name of the original cluster before the rename. Doing this is necessary because the cluster identifier must be unique within your account and region, so the original cluster and second cluster cannot have the same name. You might do this if you restore a cluster from a snapshot and don't want to change the connection properties of any dependent applications.
**Note**
If you delete the original cluster, you are responsible for deleting any unwanted cluster snapshots.
When you rename a cluster, the cluster status changes to `renaming` until the process finishes. The old DNS name that was used by the cluster is immediately deleted, although it could remain cached for a few minutes. The new DNS name for the renamed cluster becomes effective within about 10 minutes. The renamed cluster is not available until the new name becomes effective. The cluster will be rebooted and any existing connections to the cluster will be dropped. After this completes, the endpoint will change to use the new name. For this reason, you should stop queries from running before you start the rename and restart them after the rename finishes.
Cluster snapshots are retained, and all snapshots associated with a cluster remain associated with that cluster after it is renamed. For example, suppose that you have a cluster that serves your production database and the cluster has several snapshots. If you rename the cluster and then replace it in the production environment with a snapshot, the cluster that you renamed still has those existing snapshots associated with it.
Amazon CloudWatch alarms and Amazon Simple Notification Service (Amazon SNS) event notifications are associated with the name of the cluster. If you rename the cluster, you must update these accordingly. You can update the CloudWatch alarms in the CloudWatch console, and you can update the Amazon SNS event notifications in the Amazon Redshift console on the **Events** pane. The load and query data for the cluster continues to display data from before the rename and after the rename. However, performance data is reset after the rename process finishes.
For more information, see [Modifying a cluster](modify-cluster.md).
# Upgrading the release version of a cluster
You can upgrade the release maintenance version of a cluster that has a **Release Status** value of **New release available**. When you upgrade the maintenance version, you can choose to upgrade immediately or upgrade in the next maintenance window.
**Important**
If you upgrade immediately, your cluster is offline until the upgrade completes.
**To upgrade a cluster to a new release version**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**.
1. Choose the cluster to upgrade.
1. For **Actions**, choose **Upgrade cluster version**. The **Upgrade cluster version** page appears.
1. Follow the instructions on the page.
1. Choose **Upgrade cluster version**.
# Pausing and resuming a cluster
If you have a cluster that only needs to be available at specific times, you can pause the cluster and later resume it. While the cluster is paused, on-demand billing is suspended. Only the cluster's storage incurs charges. For more information about pricing, see the [Amazon Redshift pricing page](https://aws.amazon.com/redshift/pricing/).
When you pause a cluster, Amazon Redshift creates a snapshot, begins terminating queries, and puts the cluster in a pausing state. If you delete a paused cluster without requesting a final snapshot, then you can't restore the cluster. You can't cancel or roll back a pause or resume operation after it's initiated.
You can pause and resume a cluster on the Amazon Redshift console, with the AWS CLI, or with Amazon Redshift API operations.
You can schedule actions to pause and resume a cluster. When you use the new Amazon Redshift console to create a recurring schedule to pause and resume, then two scheduled actions are created for the date range that you choose. The scheduled action names are suffixed with `-pause` and `-resume`. The total length of the name must fit within the maximum size of a scheduled action name.
You can't pause the following types of clusters:
+ EC2-Classic clusters.
+ Clusters that are not active, for example, a cluster that is currently modifying.
+ Hardware security module (HSM) clusters.
+ Clusters that have automated snapshots turned off.
When deciding to pause a cluster, consider the following:
+ Connections or queries to the cluster aren't available.
+ You can't see query monitoring information of a paused cluster on the Amazon Redshift console.
+ You can't modify a paused cluster. Any scheduled actions on the cluster aren't done. These include creating snapshots, resizing clusters, and cluster maintenance operations.
+ Hardware metrics aren't created. Update your CloudWatch alarms if you have alarms set on missing metrics.
+ You can't copy the latest automated snapshots of a paused cluster to manual snapshots.
+ While a cluster is pausing, it can't be resumed until the pause operation is complete.
+ When you pause a cluster, billing is suspended. However, the pause operation typically completes within 15 minutes, depending upon the size of the cluster.
+ Audit logs are archived and not restored on resume.
+ After a cluster is paused, traces and logs might not be available for troubleshooting problems that occurred before the pause.
+ If you're managing your admin credentials using AWS Secrets Manager and pause your cluster, your cluster's secret won't be deleted and you'll continue to be billed for the secret. For more information on managing your Redshift admin password with AWS Secrets Manager, see [Managing Amazon Redshift admin passwords using AWS Secrets Manager](redshift-secrets-manager-integration.md).
+ No-backup tables on the cluster are restored on resume for RA3 instance types. They aren't restored on resume for DC2 instance types. For more information about no-backup tables, see [Excluding tables from snapshots](working-with-snapshots.md#snapshots-no-backup-tables).
When you resume a cluster, consider the following:
+ The cluster version of the resumed cluster is updated to the maintenance version based on the maintenance window of the cluster.
+ If you delete the subnet associated with a paused cluster, you might have an incompatible network. In this case, restore your cluster from the latest snapshot.
+ If you delete an Elastic IP address while the cluster is paused, then a new Elastic IP address is requested.
+ If Amazon Redshift can't resume the cluster with its previous elastic network interface, then Amazon Redshift tries to allocate a new one.
+ When you resume a cluster, your node IP addresses might change. You might need to update your VPC settings to support these new IP addresses for features like COPY from Secure Shell (SSH) or COPY from Amazon EMR.
+ If you try to resume a cluster that isn't paused, the resume operation returns an error. If the resume operation is part of a scheduled action, modify or delete the scheduled action to prevent future errors.
+ Depending upon the size of the cluster, it can take several minutes to resume a cluster before queries can be processed. In addition, query performance can be impacted for some period of time while the cluster is being re-hydrated after resume completes.
# Rebooting a cluster
Rebooting a cluster is a cluster operation that restarts the cluster with the same configuration as before the reboot. You can reboot a cluster to apply pending maintenance updates, reset configuration changes, recover from certain issues, or troubleshoot cluster problems. Rebooting a cluster can help ensure optimal performance, security, and stability of the Amazon Redshift environment. The following procedure provides detailed steps for rebooting an Amazon Redshift cluster.
When you reboot a cluster, the cluster status is set to `rebooting` and a cluster event is created when the reboot is completed. Any pending cluster modifications are applied at this reboot.
**To reboot a cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**.
1. Choose the cluster to reboot.
1. For **Actions**, choose **Reboot cluster**. The **Reboot cluster** page appears.
1. Choose **Reboot cluster**.
# Relocating a cluster
By using *relocation* in Amazon Redshift, you allow Amazon Redshift to move a cluster to another Availability Zone (AZ) without any loss of data or changes to your applications. With relocation, you can continue operations when there is an interruption of service on your cluster with minimal impact.
When cluster relocation is turned on, Amazon Redshift might choose to relocate clusters in some situations. In particular, this happens where issues in the current Availability Zone prevent optimal cluster operation or to improve service availability. You can also invoke the relocation function in cases where resource constraints in a given Availability Zone are disrupting cluster operations. An example is the ability to resume or resize a cluster. Amazon Redshift offers the relocation feature at no extra charge.
When an Amazon Redshift cluster is relocated to a new Availability Zone, the new cluster has the same endpoint as the original cluster. Your applications can reconnect to the endpoint and continue operations without modifications or loss of data. However, relocation might not always be possible due to potential resource constraints in a given Availability Zone.
Amazon Redshift cluster relocation is supported for the RA3 instance types only. RA3 instance types use Redshift Managed Storage (RMS) as a durable storage layer. The latest copy of a cluster's data is always available in other Availability Zones in an AWS Region. In other words, you can relocate an Amazon Redshift cluster to another Availability Zone without any loss of data.
When you turn on relocation for your cluster, Amazon Redshift migrates your cluster to be behind a proxy. Doing this helps implement location-independent access to a cluster's compute resources. The migration causes the cluster to be rebooted. When a cluster is relocated to another Availability Zone, an outage occurs while the new cluster is brought back online in the new Availability Zone. However, you don't have to make any changes to your applications because the cluster endpoint remains unchanged even after the cluster is relocated to the new Availability Zone.
Cluster relocation is enabled by default on newly created or restored RA3 clusters whose subnet group includes multiple Availability Zones. Amazon Redshift assigns 5439 as the default port while creating a provisioned cluster. You can change to another port from the port range of 5431-5455 or 8191-8215. (Don't change to a port outside the ranges. It results in an error.) To change the default port for a provisioned cluster, use the Amazon Redshift console, AWS CLI, or Amazon Redshift API. To change the default port for a serverless workgroup, use the AWS CLI or the Amazon Redshift Serverless API.
If you turn on relocation and you currently use the leader node IP address to access your your cluster or Enhanced VPC Routing, make sure to change that access. Instead, use the IP address associated with the cluster's virtual private cloud (VPC) endpoint. To find this cluster IP address, find and use the VPC endpoint in the **Network and security** section of the cluster details page. To get more details on the VPC endpoint, sign in to the Amazon VPC console.
You can also use the AWS Command Line Interface (AWS CLI) command `describe-vpc-endpoints` to get the elastic network interface associated with the endpoint. You can use the `describe-network-interfaces` command to get the associated IP address. For more information on Amazon Redshift AWS CLI commands, see [ Available commands](https://docs.aws.amazon.com/cli/latest/reference/redshift/index.html) in the *AWS CLI Command Reference.*
## Limitations
When using Amazon Redshift relocation, be aware of the following limitations:
+ Cluster relocation might not be possible in all scenarios due to potential resource limitations in a given Availability Zone. If this happens, Amazon Redshift doesn't change the original cluster.
+ Relocation isn't supported on DC2 instance families of products.
+ You can't perform a relocation across AWS Regions.
+ Amazon Redshift relocation defaults to port number 5439. You can also change to another port in the ranges 5431-5455 or 8191-8215.
## Managing relocation using the console
You can manage the settings for cluster relocation using the Amazon Redshift console.
### Turning off relocation when creating a new cluster
Use the following procedure to turn off relocation when creating a new cluster.
**To turn off relocation for a new cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**.
1. Choose **Create cluster** to create a new cluster. For more information on how to create a cluster, see [Get started with Amazon Redshift provisioned data warehouses](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) in *Amazon Redshift Getting Started Guide*.
1. Under **Backup**, for **Cluster relocation**, choose **Disabled**. Relocation is turned on by default.
1. Choose **Create cluster**.
### Modifying relocation for an existing cluster
Use the following procedure to change the relocation setting for an existing cluster.
**To modify the relocation setting for an existing cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list.
1. Choose the name of the cluster that you want to modify from the list. The cluster details page appears.
1. Choose the **Maintenance** tab, then in the **Backup details** section choose **Edit**.
1. Under **Backup**, choose **Disabled**. Relocation is turned on by default.
1. Choose **Modify cluster**.
### Relocating a cluster
Use the following procedure to manually relocate a cluster to another Availability Zone. This is especially useful when you want to test your network setup in secondary Availability Zones or when you are running into resource constraints in the current Availability Zone.
**To relocate a cluster to another Availability Zone**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list.
1. Choose the name of the cluster that you want to move from the list. The cluster details page appears.
1. For **Actions**, choose **Relocate**. The **Relocate cluster** page appears.
1. (Optional) Choose an **Availability Zone**. If you don't choose an Availability Zone, Amazon Redshift chooses one for you.
Amazon Redshift starts the relocation and displays the cluster as relocating. After the relocation completes, the cluster status changes to available.
## Managing relocation using the Amazon Redshift CLI
You can manage the settings for cluster relocation using the AWS Command Line Interface (CLI).
With the AWS CLI, the following example command creates an Amazon Redshift cluster named **mycluster** that has relocation turned on.
```
aws redshift create-cluster --cluster-identifier mycluster --number-of-nodes 2 --master-username enter a username --master-user-password enter a password --node-type ra3.4xlarge --port 5439 --no-availability-zone-relocation
```
If your current cluster is using a different port, you must modify it to use from the port range of 5431-5455 or 8191-8215 before modifying it to turn on relocation. The default is 5439. The following example command modifies the port in case your cluster doesn't use one from the given range.
```
aws redshift modify-cluster --cluster-identifier mycluster --port 5439
```
The following example command includes the availability-zone-relocation parameter on the Amazon Redshift cluster.
```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone-relocation
```
The following example command turns off the availability-zone-relocation parameter on the Amazon Redshift cluster.
```
aws redshift modify-cluster --cluster-identifier mycluster --no-availability-zone-relocation
```
The following example command invokes relocation on the Amazon Redshift cluster.
```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone us-east-1b
```
# Setting a usage limit on a cluster
Setting a usage limit
You can add up to four usage limits to control usage for each of the following:
+ Concurrency scaling
+ Automatic optimizations run using extra compute resources
+ Redshift Spectrum usage
+ Cross-Region data sharing
## Setting a usage limit for a provisioned cluster
Following is the procedure for setting a usage limit on a provisioned cluster:
**To set a usage limit for a cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Navigate to the provisioned cluster that you want to set a limit for.
1. From the cluster’s details page, select **Manage usage limit** from the **Actions** drop-down menu. You can also select the **Maintenance** tab for a cluster, then scroll down and select **Create usage limits**.
1. Select **Add limit** for the usage limit that you want to set. You can add up to 4 limits for a given feature.
1. Set a **Time period** for the usage limit, which is either **Daily**, **Weekly**, or **Monthly**.
1. Set a **Usage limit**.
+ For concurrency scaling and automatic optimizations run using extra compute resources limits, the usage limit is the amount of time that Amazon Redshift spends using the feature in the given time period. In this case, the usage limit is set in hours and minutes.
+ For Redshift Spectrum, the usage limit is the amount of data scanned from Amazon S3. In this case, the usage limit is set in terabytes (TB).
+ For cross-Region data sharing, the usage limit is the amount of data transferred from the producer Region to consumer Regions that consumers can query. In this case, the usage limit is set in terabytes (TB).
1. Set the **Action** for Amazon Redshift to take when your cluster reaches the limit. These are the following:
+ **Log to system table** ‐ Adds a record to the system view [ SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html). You can query the usage\$1limit column in this view to determine if a query exceeded the limit.
+ **Alert** ‐ Uses Amazon SNS to set up notification subscriptions and send notifications if a limit is breached. You can choose an existing Amazon SNS topic, create a new topic, or proceed without one.
+ **Disable feature** ‐ Disables the feature. You can also choose to use Amazon SNS to send a notification. Users can continue to use the cluster for other tasks.
The first two actions are informational, but the last turns off use of the feature.
1. Choose **Save changes** at the bottom of the page to save the limit. If you set more than one limit at once, **Save changes** will save all of them at once.
# Shutting down and deleting a cluster
You can shut down your cluster if you want to stop it from running and incurring charges. When you shut it down, you can optionally create a final snapshot. If you create a final snapshot, Amazon Redshift will create a manual snapshot of your cluster before shutting it down. If you plan to provision a new cluster with the same data and configuration as the one you are deleting, you need a manual snapshot. By using a manual snapshot, you can restore the snapshot later and resume using the cluster.
If you no longer need your cluster and its data, you can shut it down without creating a final snapshot. In this case, the cluster and data are deleted permanently.
Regardless of whether you shut down your cluster with a final manual snapshot, all automated snapshots associated with the cluster will be deleted after the cluster is shut down. Any manual snapshots associated with the cluster are retained. Any manual snapshots that are retained, including the optional final snapshot, are charged at the Amazon Simple Storage Service storage rate if you have no other clusters running when you shut down the cluster, or if you exceed the available free storage that is provided for your running Amazon Redshift clusters. For more information about snapshot storage charges, see the [Amazon Redshift pricing page](https://aws.amazon.com/redshift/pricing/).
Deleting a cluster also deletes any associated AWS Secrets Manager secrets.
**To delete a cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**.
1. Choose the cluster to delete.
1. For **Actions**, choose **Delete**. The **Delete cluster** page appears.
1. Choose **Delete cluster**.
**Note**
When you delete a cluster and choose to create a final snapshot, Amazon Redshift will stop the delete request if a restore operation is in progress on the cluster. If this occurs, you can delete the cluster without a final snapshot, or you can delete it with a final snapshot after the restore completes.
# Amazon Redshift snapshots and backups
Snapshots and backups
Snapshots are point-in-time backups of a cluster. There are two types of snapshots: *automated* and *manual*. Amazon Redshift stores these snapshots internally in Amazon S3 by using an encrypted Secure Sockets Layer (SSL) connection.
Amazon Redshift automatically takes incremental snapshots that track changes to the cluster since the previous automated snapshot. Automated snapshots retain all of the data required to restore a cluster from a snapshot. You can create a snapshot schedule to control when automated snapshots are taken, or you can take a manual snapshot any time.
When you restore from a snapshot, Amazon Redshift creates a new cluster and makes the new cluster available before all of the data is loaded, so you can begin querying the new cluster immediately. The cluster streams data on demand from the snapshot in response to active queries, then loads the remaining data in the background.
When you launch a cluster, you can set the retention period for automated and manual snapshots. You can change the default retention period for automated and manual snapshots by modifying the cluster. You can change the retention period for a manual snapshot when you create the snapshot or by modifying the snapshot.
You can monitor the progress of snapshots by viewing the snapshot details in the AWS Management Console, or by calling [describe-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-cluster-snapshots.html) in the CLI or the [DescribeClusterSnapshots](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusterSnapshots.html) API action. For an in-progress snapshot, these display information such as the size of the incremental snapshot, the transfer rate, the elapsed time, and the estimated time remaining.
To ensure that your backups are always available to your cluster, Amazon Redshift stores snapshots in an internally managed Amazon S3 bucket that is managed by Amazon Redshift. To manage storage charges, evaluate how many days you need to keep automated snapshots and configure their retention period accordingly. Delete any manual snapshots that you no longer need. For more information about the cost of backup storage, see the [Amazon Redshift pricing](https://aws.amazon.com/redshift/pricing/) page.
You can also create and restore snapshots using AWS Backup, a fully managed service that helps you centralize and automate data protection across AWS services, in the cloud, and on premises. For more information, see [AWS Backup integration with Amazon Redshift](managing-aws-backup.md). For information on AWS Backup, see [What is AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) in the *AWS Backup Developer Guide*.
## Working with snapshots and backups in Amazon Redshift Serverless
Amazon Redshift Serverless, like a provisioned cluster, enables you to take a backup as a point-in-time representation of the objects and data in the namespace. There are two types of backups in Amazon Redshift Serverless: snapshots that are manually created and recovery points that Amazon Redshift Serverless creates automatically. You can find more information about working with snapshots for Amazon Redshift Serverless at [Snapshots and recovery points](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html).
You can also restore a snapshot from a provisioned cluster to a serverless namespace. For more information, see [Restoring a serverless namespace from a snapshot](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshot-restore.html).
## Automated snapshots
When automated snapshots are enabled for a cluster, Amazon Redshift periodically takes snapshots of that cluster. By default Amazon Redshift takes a snapshot about every eight hours or following every 5 GB per node of data changes, or whichever comes first. If your data is larger than 5 GB \$1 the number of nodes, the shortest amount of time in between automated snapshot creation is 15 minutes. Alternatively, you can create a snapshot schedule to control when automated snapshots are taken. If you're using custom schedules, the minimum amount of time between automated snapshots is one hour. Automated snapshots are enabled by default when you create a cluster.
Automated snapshots are deleted at the end of a retention period. The default retention period is one day, but you can modify it by using the Amazon Redshift console or programmatically by using the Amazon Redshift API or CLI.
To disable automated snapshots, set the retention period to zero. If you disable automated snapshots, Amazon Redshift stops taking snapshots and deletes any existing automated snapshots for the cluster. You can't disable automated snapshots for RA3 node types. You can set an RA3 node type automated retention period from 1–35 days.
Only Amazon Redshift can delete an automated snapshot; you cannot delete them manually. Amazon Redshift deletes automated snapshots at the end of a snapshot's retention period, when you disable automated snapshots for the cluster, or when you delete the cluster. *Amazon Redshift retains the latest automated snapshot until you disable automated snapshots or delete the cluster.*
If you want to keep an automated snapshot for a longer period, you can create a copy of it as a manual snapshot. The automated snapshot is retained until the end of the retention period, but the corresponding manual snapshot is retained until you manually delete it or until the end of the retention period.
## Automated snapshot schedules
To precisely control when snapshots are taken, you can create a snapshot schedule and attach it to one or more clusters. When you modify a snapshot schedule, the schedule is modified for all associated clusters. If a cluster doesn't have a snapshot schedule attached, the cluster uses the default automated snapshot schedule.
A *snapshot schedule* is a set of schedule rules. You can define a simple schedule rule based on a specified interval, such as every 8 hours or every 12 hours. You can also add rules to take snapshots on certain days of the week, at specific times, or during specific periods. Rules can also be defined using Unix-like cron expressions.
## Snapshot schedule format
On the Amazon Redshift console, you can create a snapshot schedule. Then, you can attach a schedule to a cluster to trigger the creation of a system snapshot. A schedule can be attached to multiple clusters, and you can create multiple cron definitions in a schedule to trigger a snapshot.
You can define a schedule for your snapshots using a cron syntax. The definition of these schedules uses a modified Unix-like [cron](http://en.wikipedia.org/wiki/Cron) syntax. You specify time in [Coordinated universal time (UTC)](http://en.wikipedia.org/wiki/Coordinated_Universal_Time). You can create schedules with a maximum frequency of one hour and minimum precision of one minute.
Amazon Redshift modified cron expressions have 3 required fields, which are separated by white space.
**Syntax**
```
cron(Minutes Hours Day-of-month Month Day-of-week Year)
```
| **Fields** | **Values** | **Wildcards** |
| --- | --- | --- |
| Minutes | 0–59 | , - \$1 / |
| Hours | 0–23 | , - \$1 / |
| Day-of-month | 1–31 | , - \$1 ? / L W |
| Month | 1–12 or JAN-DEC | , - \$1 / |
| Day-of-week | 1–7 or SUN-SAT | , - \$1 ? L \$1 |
| Year | 1970–2199 | , - \$1 / |
**Wildcards**
+ The **,** (comma) wildcard includes additional values. In the `Day-of-week` field, `MON,WED,FRI` would include Monday, Wednesday, and Friday. Total values are limited to 24 per field.
+ The **-** (dash) wildcard specifies ranges. In the `Hour` field, 1–15 would include hours 1 through 15 of the specified day.
+ The **\$1** (asterisk) wildcard includes all values in the field. In the `Hours` field, **\$1** would include every hour.
+ The **/** (forward slash) wildcard specifies increments. In the `Hours` field, you could enter **1/10** to specify every 10th hour, starting from the first hour of the day (for example, the 01:00, 11:00, and 21:00).
+ The **?** (question mark) wildcard specifies one or another. In the `Day-of-month` field you could enter **7**, and if you didn't care what day of the week the seventh was, you could enter **?** in the Day-of-week field.
+ The **L** wildcard in the `Day-of-month` or `Day-of-week` fields specifies the last day of the month or week.
+ The **W** wildcard in the `Day-of-month` field specifies a weekday. In the `Day-of-month` field, `3W` specifies the day closest to the third weekday of the month.
+ The **\$1** wildcard in the Day-of-week field specifies a certain instance of the specified day of the week within a month. For example, 3\$12 would be the second Tuesday of the month: the 3 refers to Tuesday because it is the third day of each week, and the 2 refers to the second day of that type within the month.
**Note**
If you use a '\$1' character, you can define only one expression in the day-of-week field. For example, "3\$11,6\$13" is not valid because it is interpreted as two expressions.
**Limits**
+ You can't specify the `Day-of-month` and `Day-of-week` fields in the same cron expression. If you specify a value in one of the fields, you must use a **?** (question mark) in the other.
+ Snapshot schedules don't support the following frequencies:
+ Snapshots scheduled more frequently than 1 per hour.
+ Snapshots scheduled less frequently than 1 per day (24 hours).
If you have overlapping schedules that result in scheduling snapshots within a 1 hour window, a validation error results.
When creating a schedule, you can use the following sample cron strings.
| Minutes | Hours | Day of week | Meaning |
| --- | --- | --- | --- |
| 0 | 14-20/1 | TUE | Every hour between 2pm and 8pm on Tuesday. |
| 0 | 21 | MON-FRI | Every night at 9pm Monday–Friday. |
| 30 | 0/6 | SAT-SUN | Every 6 hour increment on Saturday and Sunday starting at 30 minutes after midnight (00:30) that day. This results in a snapshot at [00:30, 06:30, 12:30, and 18:30] each day. |
| 30 | 12/4 | \$1 | Every 4 hour increment starting at 12:30 each day. This resolves to [12:30, 16:30, 20:30]. |
For example to run on a schedule on an every 2 hour increment starting at 15:15 each day. This resolves to [15:15, 17:15, 19:15, 21:15, 23:15] , specify:
```
cron(15 15/2 *)
```
You can create multiple cron schedule definitions within as schedule. For example the following AWS CLI command contains two cron schedules in one schedule.
```
create-snapshot-schedule --schedule-identifier "my-test" --schedule-definition "cron(0 17 SAT,SUN)" "cron(0 9,17 MON-FRI)"
```
## Manual snapshots
You can take a manual snapshot any time. By default, manual snapshots are retained indefinitely, even after you delete your cluster. You can specify the retention period when you create a manual snapshot, or you can change the retention period by modifying the snapshot. For more information about changing the retention period, see [Modifying the manual snapshot retention period](snapshot-manual-retention-period.md).
If a snapshot is deleted, you can't start any new operations that reference that snapshot. However, if a restore operation is in progress, that restore operation will run to completion.
Amazon Redshift has a quota that limits the total number of manual snapshots that you can create; this quota is per AWS account per AWS Region. The default quota is listed at [Quotas and limits in Amazon Redshift](amazon-redshift-limits.md).
## Snapshot storage
Because snapshots accrue storage charges, it's important that you delete them when you no longer need them. Amazon Redshift deletes automated and manual snapshots at the end of their respective snapshot retention periods. You can also delete manual snapshots using the AWS Management Console or with the [batch-delete-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/batch-delete-cluster-snapshots.html) CLI command.
You can change the retention period for a manual snapshot by modifying the manual snapshot settings.
You can get information about how much storage your snapshots are consuming using the Amazon Redshift Console or using the [describe-storage](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-storage.html) CLI command.
## Excluding tables from snapshots
By default, all user-defined permanent tables are included in snapshots. If a table, such as a staging table, doesn't need to be backed up, you can significantly reduce the time needed to create snapshots and restore from snapshots. You also reduce storage space on Amazon S3 by using a no-backup table. To create a no-backup table, include the BACKUP NO parameter when you create the table. For more information, see [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) and [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) in the *Amazon Redshift Database Developer Guide*.
**Note**
No-backup tables aren't supported for RA3 provisioned clusters and Amazon Redshift Serverless workgroups. A table marked as no-backup in an RA3 cluster or serverless workgroup is treated as a permanent table that will always be backed up while taking a snapshot, and always restored when restoring from a snapshot. To avoid snapshot costs for no-backup tables, truncate them before taking a snapshot.
# Creating a manual snapshot
You can create a manual snapshot of a cluster from the snapshots list as follows. Or, you can take a snapshot of a cluster in the cluster configuration pane. For more information, see [Amazon Redshift snapshots and backups](working-with-snapshots.md).
**Note**
No-backup tables aren't supported for RA3 provisioned clusters and Amazon Redshift Serverless workgroups. A table marked as no-backup in an RA3 cluster or serverless workgroup is treated as a permanent table that will always be backed up while taking a snapshot, and always restored when restoring from a snapshot. To avoid snapshot costs for no-backup tables, truncate them before taking a snapshot.
**To create a manual snapshot**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose **Create snapshot**. The snapshot page to create a manual snapshot is displayed.
1. Enter the properties of the snapshot definition, then choose **Create snapshot**. It might take some time for the snapshot to be available.
# Creating a snapshot schedule
Amazon Redshift takes automatic, incremental snapshots of your data periodically and saves them to Amazon S3. Additionally, you can take manual snapshots of your data whenever you want.
All snapshot tasks in the Amazon Redshift console start from the snapshot list. You can filter the list by using a time range, the snapshot type, and the cluster associated with the snapshot. In addition, you can sort the list by date, size, and snapshot type. Depending on the snapshot type that you select, you might have different options available for working with the snapshot.
To precisely control when snapshots are taken, you can create a snapshot schedule and attach it to one or more clusters. You can attach a schedule when you create a cluster or by modifying the cluster. For more information, see [Automated snapshot schedules](working-with-snapshots.md#automated-snapshot-schedules).
**To create a snapshot schedule**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the **Snapshot schedules** tab. The snapshot schedules are displayed.
1. Choose **Add schedule** to display the page to add a schedule.
1. Enter the properties of the schedule definition, then choose **Add schedule**.
1. On the page that appears, you can attach clusters to your new snapshot schedule, then choose **OK**.
# Sharing a snapshot
You can share an existing manual snapshot with other AWS customer accounts by authorizing access to the snapshot. You can authorize up to 20 for each snapshot and 100 for each AWS Key Management Service (AWS KMS) key. That is, if you have 10 snapshots that are encrypted with a single KMS key, then you can authorize 10 AWS accounts to restore each snapshot, or other combinations that add up to 100 accounts and do not exceed 20 accounts for each snapshot. A person logged in as a user in one of the authorized accounts can then describe the snapshot or restore it to create a new Amazon Redshift cluster under their account. For example, if you use separate AWS customer accounts for production and test, a user can log on using the production account and share a snapshot with users in the test account. Someone logged on as a test account user can then restore the snapshot to create a new cluster that is owned by the test account for testing or diagnostic work.
A manual snapshot is permanently owned by the AWS customer account under which it was created. Only users in the account owning the snapshot can authorize other accounts to access the snapshot, or to revoke authorizations. Users in the authorized accounts can only describe or restore any snapshot that has been shared with them; they cannot copy or delete snapshots that have been shared with them. An authorization remains in effect until the snapshot owner revokes it. If an authorization is revoked, the previously authorized user loses visibility of the snapshot and cannot launch any new actions referencing the snapshot. If the account is in the process of restoring the snapshot when access is revoked, the restore runs to completion. You cannot delete a snapshot while it has active authorizations; you must first revoke all of the authorizations.
AWS customer accounts are always authorized to access snapshots owned by the account. Attempts to authorize or revoke access to the owner account will receive an error. You cannot restore or describe a snapshot that is owned by an inactive AWS customer account.
After you have authorized access to an AWS customer account, no users in that account can perform any actions on the snapshot unless they assume a role with policies that allow them to do so.
+ Users in the snapshot owner account can authorize and revoke access to a snapshot only if they assume a role with an IAM policy that allows them to perform those actions with a resource specification that includes the snapshot. For example, the following policy allows a user or role in AWS account `012345678912` to authorize other accounts to access a snapshot named `my-snapshot20130829`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:AuthorizeSnapshotAccess",
"redshift:RevokeSnapshotAccess"
],
"Resource":[
"arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829"
]
}
]
}
```
------
+ Users in an AWS account with which a snapshot has been shared cannot perform actions on that snapshot unless they have permissions allowing those actions. You can do this by assigning the policy to a role and assuming the role.
+ To list or describe a snapshot, they must have an IAM policy that allows the `DescribeClusterSnapshots` action. The following code shows an example:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:DescribeClusterSnapshots"
],
"Resource":[
"*"
]
}
]
}
```
------
+ To restore a snapshot, a user must assume a role with an IAM policy that allows the `RestoreFromClusterSnapshot` action and has a resource element that covers both the cluster they are attempting to create and the snapshot. For example, if a user in account `012345678912` has shared snapshot `my-snapshot20130829` with account `219876543210`, in order to create a cluster by restoring the snapshot, a user in account `219876543210` must assume a role with a policy such as the following:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:RestoreFromClusterSnapshot"
],
"Resource":[
"arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829",
"arn:aws:redshift:us-east-1:219876543210:cluster:from-another-account"
]
}
]
}
```
------
+ After access to a snapshot has been revoked from an AWS account, no users in that account can access the snapshot. This is the case even if those accounts have IAM policies that allow actions on the previously shared snapshot resource.
## Sharing a cluster snapshot using the console
On the console, you can authorize other users to access a manual snapshot you own, and you can later revoke that access when it is no longer required.
**To share a snapshot with another account**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the manual snapshot to share.
1. For **Actions**, choose **Manual snapshot settings** to display the properties of the manual snapshot.
1. Enter the account or accounts to share with in the **Manage access** section, then choose **Save**.
## Security considerations for sharing encrypted snapshots
When you provide access to an encrypted snapshot, Redshift requires that the AWS KMS customer managed key used to create the snapshot is shared with the account or accounts performing the restore. If the key isn't shared, attempting to restore the snapshot results in an access-denied error. The receiving account doesn't need any extra permissions to restore a shared snapshot. When you authorize snapshot access and share the key, the identity authorizing access must have `kms:DescribeKey` permissions on the key used to encrypt the snapshot. This permission is described in more detail in [AWS KMS permissions](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html). For more information, see [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) in the Amazon Redshift API reference documentation.
The customer managed key policy can be updated programmatically or in the AWS Key Management Service console.
**Note**
If you're using a default KMS key, you don't need to take action or change anything in AWS KMS in order to share a snapshot.
### Allowing access to the AWS KMS key for an encrypted snapshot
To share the AWS KMS customer managed key for an encrypted snapshot, update the key policy by performing the following steps:
1. Update the KMS key policy with the Amazon Resource Name (ARN) of the AWS account that you are sharing to as `Principal` in the KMS key policy.
1. Allow the `kms:Decrypt` action.
In the following key-policy example, user `111122223333` is the owner of the KMS key, and user `444455556666` is the account that the key is shared with. This key policy gives the AWS account access to the sample KMS key by including the ARN for the root AWS account identity for user `444455556666` as a `Principal` for the policy, and by allowing the `kms:Decrypt` action.
------
#### [ JSON ]
****
```
{
"Id": "key-policy-1",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::444455556666:root"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```
------
After access is granted to the customer managed KMS key, the account that restores the encrypted snapshot must create an AWS Identity and Access Management (IAM) role, or user, if it doesn't already have one. In addition, that AWS account must also attach an IAM policy to that IAM role or user that allows them to restore an encrypted database snapshot, using your KMS key.
For more information about giving access to an AWS KMS key, see [Allowing users in other accounts to use a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html#cross-account-console), in the AWS Key Management Service developer guide.
For an overview of key policies, see [How Amazon Redshift uses AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html).
# Copying an automated snapshot
Automated snapshots are automatically deleted when their retention period expires, when you disable automated snapshots, or when you delete a cluster. If you want to keep an automated snapshot, you can copy it to a manual snapshot.
**To copy an automated snapshot**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to copy.
1. For **Actions**, choose **Copy automated snapshot** to copy the snapshot.
1. Update the properties of the new snapshot, then choose **Copy**.
# Copying a snapshot to another AWS Region
You can configure Amazon Redshift to automatically copy snapshots (automated or manual) for a cluster to another AWS Region. When a snapshot is created in the cluster's primary AWS Region, it's copied to a secondary AWS Region. The two AWS Regions are known respectively as the *source AWS Region* and *destination AWS Region*. If you store a copy of your snapshots in another AWS Region, you can restore your cluster from recent data if anything affects the primary AWS Region. You can configure your cluster to copy snapshots to only one destination AWS Region at a time. For a list of Amazon Redshift Regions, see [Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html) in the *Amazon Web Services General Reference*.
When you enable Amazon Redshift to automatically copy snapshots to another AWS Region, you specify the destination AWS Region to copy the snapshots to. For automated snapshots, you can also specify the retention period to keep them in the destination AWS Region. After an automated snapshot is copied to the destination AWS Region and it reaches the retention time period there, it's deleted from the destination AWS Region. Doing this keeps your snapshot usage low. To keep the automated snapshots for a shorter or longer time in the destination AWS Region, change this retention period.
The retention period that you set for automated snapshots that are copied to the destination AWS Region is separate from the retention period for automated snapshots in the source AWS Region. The default retention period for copied snapshots is seven days. That seven-day period applies only to automated snapshots. In both the source and destination AWS Regions, manual snapshots are deleted at the end of the snapshot retention period or when you manually delete them.
You can disable automatic snapshot copy for a cluster at any time. When you disable this feature, snapshots are no longer copied from the source AWS Region to the destination AWS Region. Any automated snapshots copied to the destination AWS Region are deleted as they reach the retention period limit, unless you create manual snapshot copies of them. These manual snapshots, and any manual snapshots that were copied from the destination AWS Region, are kept in the destination AWS Region until you manually delete them.
To change the destination AWS Region that you copy snapshots to, first disable the automatic copy feature. Then re-enable it, specifying the new destination AWS Region.
After a snapshot is copied to the destination AWS Region, it becomes active and available for restoration purposes.
To copy snapshots for AWS KMS–encrypted clusters to another AWS Region, create a grant for Amazon Redshift to use a customer managed key in the destination AWS Region. Then choose that grant when you enable copying of snapshots in the source AWS Region. For more information about configuring snapshot copy grants, see [Copying AWS KMS–encrypted snapshots to another AWS Region](working-with-db-encryption.md#configure-snapshot-copy-grant).
# Restoring a cluster from a snapshot
A snapshot contains data from any databases that are running on your cluster. It also contains information about your cluster, including the number of nodes, node type, and admin user name. If you restore your cluster from a snapshot, Amazon Redshift uses the cluster information to create a new cluster. Then it restores all the databases from the snapshot data.
**Note**
No-backup tables aren't supported for RA3 provisioned clusters and Amazon Redshift Serverless workgroups. A table marked as no-backup in an RA3 cluster or serverless workgroup is treated as a permanent table that will always be backed up while taking a snapshot, and always restored when restoring from a snapshot.
For the new cluster created from the original snapshot, you can choose the configuration, such as node type and number of nodes. The cluster is restored in the same AWS Region and a random, system-chosen Availability Zone, unless you specify another Availability Zone in your request. When you restore a cluster from a snapshot, you can optionally choose a compatible maintenance track for the new cluster.
**Note**
When you restore a snapshot to a cluster with a different configuration, the snapshot must have been taken on a cluster with cluster version 1.0.10013, or later.
When a restore is in progress, events are typically emitted in the following order:
1. RESTORE\$1STARTED – REDSHIFT-EVENT-2008 sent when the restore process begins.
1. RESTORE\$1SUCCEEDED – REDSHIFT-EVENT-3003 sent when the new cluster has been created.
The cluster is available for queries.
1. DATA\$1TRANSFER\$1COMPLETED – REDSHIFT-EVENT-3537 sent when data transfer complete.
**Note**
RA3 clusters only emit RESTORE\$1STARTED and RESTORE\$1SUCCEEDED events. There is no explicit data transfer to be done after a RESTORE succeeds because RA3 node types store data in Amazon Redshift managed storage. With RA3 nodes, data is continuously transferred between RA3 nodes and Amazon Redshift managed storage as part of normal query processing. RA3 nodes cache hot data locally and keep less frequently queried blocks in Amazon Redshift managed storage automatically.
You can monitor the progress of a restore by either calling the [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html) API operation, or viewing the cluster details in the AWS Management Console. For an in-progress restore, these display information such as the size of the snapshot data, the transfer rate, the elapsed time, and the estimated time remaining. For a description of these metrics, see [RestoreStatus](https://docs.aws.amazon.com/redshift/latest/APIReference/API_RestoreStatus.html).
You can't use a snapshot to revert an active cluster to a previous state.
**Note**
When you restore a snapshot into a new cluster, the default security group and parameter group are used unless you specify different values.
You might want to restore a snapshot to a cluster with a different configuration for these reasons:
+ When a cluster is made up of smaller node types and you want to consolidate it into a larger node type with fewer nodes.
+ When you have monitored your workload and determined the need to move to a node type with more CPU and storage.
+ When you want to measure performance of test workloads with different node types.
Restore has the following constraints:
+ The new node configuration must have enough storage for existing data. Even when you add nodes, your new configuration might not have enough storage because of the way that data is redistributed.
+ The restore operation checks if the snapshot was created on a cluster version that is compatible with the cluster version of the new cluster. If the new cluster has a version level that is too early, then the restore operation fails and reports more information in an error message.
+ The possible configurations (number of nodes and node type) you can restore to is determined by the number of nodes in the original cluster and the target node type of the new cluster. To determine the possible configurations available, you can use the Amazon Redshift console or the `describe-node-configuration-options` AWS CLI command with `action-type restore-cluster`. For more information about the restoring using the Amazon Redshift console, see [Restoring a cluster from a snapshot](#working-with-snapshot-restore-cluster-from-snapshot).
The following steps take a cluster with many nodes and consolidate it into a bigger node type with a smaller number of nodes using the AWS CLI. For this example, we start with a source cluster of 24 nodes. In this case, suppose that we already created a snapshot of this cluster and want to restore it into a bigger node type.
1. Run the following command to get the details of our 24-node cluster.
```
aws redshift describe-clusters --region eu-west-1 --cluster-identifier mycluster-123456789012
```
1. Run the following command to get the details of the snapshot.
```
aws redshift describe-cluster-snapshots --region eu-west-1 --snapshot-identifier mycluster-snapshot
```
1. Run the following command to describe the options available for this snapshot.
```
aws redshift describe-node-configuration-options --snapshot-identifier mycluster-snapshot --region eu-west-1 --action-type restore-cluster
```
This command returns an option list with recommended node types, number of nodes, and disk utilization for each option. For this example, the preceding command lists the following possible node configurations. We choose to restore into a three-node cluster.
```
{
"NodeConfigurationOptionList": [
{
"EstimatedDiskUtilizationPercent": 65.26134808858235,
"NodeType": "dc2.large",
"NumberOfNodes": 24
},
{
"EstimatedDiskUtilizationPercent": 32.630674044291176,
"NodeType": "dc2.large",
"NumberOfNodes": 48
},
{
"EstimatedDiskUtilizationPercent": 65.26134808858235,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 3
},
{
"EstimatedDiskUtilizationPercent": 48.94601106643677,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 4
},
{
"EstimatedDiskUtilizationPercent": 39.156808853149414,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 5
},
{
"EstimatedDiskUtilizationPercent": 32.630674044291176,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 6
}
]
}
```
1. Run the following command to restore the snapshot into the cluster configuration that we chose. After this cluster is restored, we have the same content as the source cluster, but the data has been consolidated into three `dc2.8xlarge` nodes.
```
aws redshift restore-from-cluster-snapshot --region eu-west-1 --snapshot-identifier mycluster-snapshot --cluster-identifier mycluster-123456789012-x --node-type dc2.8xlarge --number-of-nodes 3
```
If you have reserved nodes, for example DC2 reserved nodes, you can upgrade to RA3 reserved nodes. You can do this when you restore from a snapshot or perform an elastic resize. You can use the console to guide you through this process. For more information about upgrading to RA3 nodes, see [Upgrading to RA3 node types](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
**To restore a cluster from a snapshot on the console**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to restore.
1. Choose **Restore from snapshot** to view the **Cluster configuration** and **Cluster details** values of the new cluster to be created using the snapshot information.
1. Update the properties of the new cluster, then choose **Restore cluster from snapshot**.
After restoring your cluster snapshot, the restored data warehouse is encrypted with the same custom AWS KMS key that it was using at the time that the snapshot was taken. If the snapshot didn't have a custom KMS key, Amazon Redshift's backup encryption logic depends on the following factors:
+ The type of Amazon Redshift data warehouse you're restoring the snapshot to.
+ The encryption type of the cluster at the time the snapshot was taken.
To learn how your data warehouse is encrypted after you restore it from your cluster snapshot, see the following table:
| Destination type | Snapshot encryption type | Destination encryption type |
| --- | --- | --- |
| Provisioned cluster | Encrypted with an AWS managed key | Encrypted with an AWS managed key |
| Provisioned cluster | Encrypted with an AWS owned key | Encrypted with an AWS owned key |
| Serverless namespace | Encrypted with an AWS managed key | Encrypted with an AWS owned key |
| Serverless namespace | Encrypted with an AWS owned key | Encrypted with an AWS owned key |
If AWS Secrets Manager managed your cluster's admin password at the time the snapshot was taken, you must continue using AWS Secrets Manager to manage the admin password. You can opt out of using a secret after restoring the cluster by updating the cluster's admin credentials in the cluster detail page.
If you have reserved nodes, you can upgrade to RA3 reserved nodes. You can do this when you restore from a snapshot or perform an elastic resize. You can use the console to guide you through this process. For more information about upgrading to RA3 nodes, see [Upgrading to RA3 node types](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
# Restoring a table from a snapshot
You can restore a single table from a snapshot instead of restoring an entire cluster. When you restore a single table from a snapshot, you specify the source snapshot, database, schema, and table name, and the target database, schema, and a new table name for the restored table.
**Note**
No-backup tables aren't supported for RA3 provisioned clusters and Amazon Redshift Serverless workgroups. A table marked as no-backup in an RA3 cluster or serverless workgroup is treated as a permanent table that will always be backed up while taking a snapshot, and always restored when restoring from a snapshot. However, selective restoration of no-backup tables isn't supported.
The new table name cannot be the name of an existing table. To replace an existing table with a restored table from a snapshot, rename or drop the existing table before you restore the table from the snapshot.
The target table is created using the source table's column definitions, table attributes, and column attributes except for foreign keys. To prevent conflicts due to dependencies, the target table doesn't inherit foreign keys from the source table. Any dependencies, such as views or permissions granted on the source table, aren't applied to the target table.
If the owner of the source table exists, then that database user is the owner of the restored table, provided that the user has sufficient permissions to become the owner of a relation in the specified database and schema. Otherwise, the restored table is owned by the admin user that was created when the cluster was launched.
The restored table returns to the state it was in at the time the backup was taken. This includes transaction visibility rules defined by the Amazon Redshift adherence to [serializable isolation](https://docs.aws.amazon.com/redshift/latest/dg/c_serial_isolation.html), meaning that data will be immediately visible to in flight transactions started after the backup.
Restoring a table from a snapshot has the following limitations:
+ You can restore a table only to the current, active running cluster and from a snapshot that was taken of that cluster.
+ You can restore only one table at a time.
+ You can't restore a table from a cluster snapshot that was taken prior to a cluster being resized. An exception is that you can restore a table after an elastic resize if the node type didn't change.
+ Any dependencies, such as views or permissions granted on the source table, aren't applied to the target table.
+ If row-level security is turned on for a table being restored, Amazon Redshift restores the table with row-level security turned on.
**To restore a table from a snapshot**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster that you want to use to restore a table.
1. For **Actions**, choose **Restore table** to display the **Restore table** page.
1. Enter the information about which snapshot, source table, and target table to use, and then choose **Restore table**.
**Example: Restoring a table from a snapshot using the AWS CLI**
The following example uses the `restore-table-from-cluster-snapshot` AWS CLI command to restore the `my-source-table` table from the `sample-database` schema in the `my-snapshot-id`. You can use the AWS CLI command `describe-table-restore-status` to review the status of your restore operation. The example restores the snapshot to the `mycluster-example` cluster with a new table name of `my-new-table`.
```
aws redshift restore-table-from-cluster-snapshot --cluster-identifier mycluster-example
--new-table-name my-new-table
--snapshot-identifier my-snapshot-id
--source-database-name sample-database
--source-table-name my-source-table
```
# Restoring a serverless namespace from a snapshot
Restoring a serverless namespace from a snapshot replaces all of the namespace’s databases with databases in the snapshot. For more information about serverless snapshots, see [Snapshots and recovery points](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html). Amazon Redshift automatically converts tables with interleaved keys into compound keys when you restore a provisioned cluster snapshot to an Amazon Redshift Serverless namespace. For more information about sort keys, see [Working with sort keys](https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html).
To restore a snapshot from your provisioned cluster to your serverless namespace.
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to use.
1. Choose **Restore from snapshot**, **Restore to serverless namespace**.
1. Choose the namespace you want to restore to.
1. Confirm you want to restore from your snapshot. Choose **restore**. This action replaces all the databases in serverless namespace with the data from your provisioned cluster.
# Configuring cross-Region snapshot copy for a nonencrypted cluster
You can configure Amazon Redshift to copy snapshots for a cluster to another AWS Region. To configure cross-Region snapshot copy, you need to enable this copy feature for each cluster and configure where to copy snapshots and how long to keep copied automated or manual snapshots in the destination AWS Region. When cross-Region copy is enabled for a cluster, all new manual and automated snapshots are copied to the specified AWS Region. Copied snapshot names are prefixed with **copy:**.
**To configure a cross-Region snapshot**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster that you want to move snapshots for.
1. For **Actions**, choose **Configure cross-region snapshot**.
The Configure cross-Region dialog box appears.
1. For **Copy snapshots**, choose **Yes**.
1. In **Destination AWS Region**, choose the AWS Region to which to copy snapshots.
1. In **Automated snapshot retention period (days)**, choose the number of days for which you want automated snapshots to be retained in the destination AWS Region before they are deleted.
1. In **Manual snapshot retention period**, choose the value that represents the number of days for which you want manual snapshots to be retained in the destination AWS Region before they are deleted. If you choose **Custom value**, the retention period must be between 1 to 3653 days.
1. Choose **Save**.
# Configuring cross-Region snapshot copy for an AWS KMS–encrypted cluster
When you launch an Amazon Redshift cluster, you can configure a snapshot copy grant for a root key in your account in the destination AWS Region. If you don't configure a grant, snapshots in the destination region are encrypted with a default AWS-owned key. By doing this, you enable Amazon Redshift to perform encryption operations in the destination AWS Region.
The following procedure describes the process of enabling cross-Region snapshot copy for an AWS KMS-encrypted cluster. For more information about encryption in Amazon Redshift and snapshot copy grants, see [Copying AWS KMS–encrypted snapshots to another AWS Region](working-with-db-encryption.md#configure-snapshot-copy-grant).
**To configure a cross-Region snapshot for an AWS KMS–encrypted cluster**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster that you want to move snapshots for.
1. For **Actions**, choose **Configure cross-region snapshot**.
The Configure cross-Region dialog box appears.
1. For **Copy snapshots**, choose **Yes**.
1. In **Destination AWS Region**, choose the AWS Region to which to copy snapshots.
1. In **Automated snapshot retention period (days)**, choose the number of days for which you want automated snapshots to be retained in the destination AWS Region before they are deleted.
1. In **Manual snapshot retention period**, choose the value that represents the number of days for which you want manual snapshots to be retained in the destination AWS Region before they are deleted. If you choose **Custom value**, the retention period must be between 1 to 3653 days.
1. Choose **Save**.
# Modifying the manual snapshot retention period
You can change the retention period for a manual snapshot by modifying the snapshot settings.
**To change the manual snapshot retention period**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the manual snapshot to change.
1. For **Actions**, choose **Manual snapshot settings** to display the properties of the manual snapshot.
1. Enter the revised properties of the snapshot definition, then choose **Save**.
# Modifying the retention period for cross-Region snapshot copy
After you configure cross-Region snapshot copy, you might want to change the settings. You can easily change the retention period by selecting a new number of days and saving the changes.
**Warning**
You can't modify the destination AWS Region after cross-Region snapshot copy is configured.
If you want to copy snapshots to a different AWS Region, first disable cross-Region snapshot copy. Then re-enable it with a new destination AWS Region and retention period. Any copied automated snapshots are deleted after you disable cross-Region snapshot copy. Thus, you should determine if there are any that you want to keep and copy them to manual snapshots before disabling cross-Region snapshot copy.
**To modify a cross-Region snapshot**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster that you want to modify snapshots for.
1. For **Actions**, choose **Configure cross-region snapshot** to display the properties of the snapshot.
1. Enter the revised properties of the snapshot definition, then choose **Save**.
# Deleting a manual snapshot
You can delete manual snapshots by selecting one or more snapshots in the snapshot list.
**To delete a manual snapshot**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to delete.
1. For **Actions**, choose **Delete snapshot** to delete the snapshot.
1. Confirm the deletion of the listed snapshots, then choose **Delete**.
# Registering a cluster to the AWS Glue Data Catalog
You can register entire clusters to the AWS Glue Data Catalog and create catalogs managed by AWS Glue. You can access these catalogs with any SQL engine that supports the Apache Iceberg REST API. For more information on creating Apache Iceberg-compatible catalogs from Amazon Redshift see [ Apache Iceberg compatibility for Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/iceberg-integration_overview.html) in the Amazon Redshift Database Developer Guide.
**To register a cluster to the AWS Glue Data Catalog**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list. If you don't have any clusters, choose **Create cluster** to create one.
1. Choose the name of the cluster that you want to register.
1. From **Actions**, choose **Register to AWS Glue Data Catalog**. The **Register to AWS Glue Data Catalog** pop-up box appears.
1. Enter the AWS account ID that you want to register the cluster to under **Destination account ID**. This is the account ID that will hold the catalog in the AWS Glue Data Catalog.
1. Enter a name under **Register namespace as**. This will be the cluster’s name in the Data Catalog.
1. Choose **Register**. You’ll be taken to the AWS Lake Formation console.
1. Follow the catalog creation process in AWS Lake Formation. For information about creating a catalog, see [ Bringing Amazon Redshift data into the AWS Glue Data Catalog](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-namespaces-datacatalog.html) in the AWS Lake Formation Developer Guide.
# Multi-AZ deployment
Multi-AZ deployment
Amazon Redshift supports multiple Availability Zones (Multi-AZ) deployments for provisioned RA3 clusters. By using Multi-AZ deployments, your Amazon Redshift data warehouse can continue operating in failure scenarios when an unexpected event happens in an Availability Zone. A Multi-AZ deployment deploys compute resources in two Availability Zones (AZs) and these compute resources can be accessed through a single endpoint. In the event of an entire Availability Zone failure, the remaining compute resources in the second Availability Zone are available to continue processing workloads. Amazon Redshift charges the same hourly compute rates for RA3 when running a Multi-AZ data warehouse. Storage costs remain the same as it is shared across all Availability Zones within and AWS Region.
Currently, Amazon Redshift supports zero Recovery Point Objective (RPO) that allows data to be current and up-to-date in the event of a failure. With Multi-AZ deployment, Amazon Redshift further enhances its existing recovery capabilities and reduces its Recovery Time Objective (RTO). This is possible because a Multi-AZ deployment can recover faster from a failure or disaster thereby elevating the Amazon Redshift Service Level Agreement (SLA) to 99.99% as compared to 99.9% with a Single-AZ data warehouse.
# Setting up Multi-AZ deployment
To set up a Multi-AZ deployment, select the **Multi-AZ** option and specify the number of compute nodes to provision in each Availability Zone. Amazon Redshift automatically deploys equal compute resources across two Availability Zones and all compute resources are always available for both read and write processing during normal operation. This allows a Multi-AZ deployment to act as a single data warehouse with a single endpoint, removing the need for application changes when a disaster occurs. Although a Multi-AZ deployment processes an individual query using the compute resources residing in only one Availability Zone, it can automatically distribute processing of multiple simultaneous queries to both Availability Zones to boost overall throughput for high concurrency workloads.
You can also convert an existing Single-AZ data warehouse into a Multi-AZ data warehouse or vice versa. Everything remains the same except that additional compute resources are provisioned in the second Availability Zone. When migrating to Multi-AZ from an existing Single-AZ cluster, you might be required to double the number of cluster nodes needed, to facilitate that single query performance is maintained. Most workloads observe an increase in overall query processing throughput with a Multi-AZ data warehouse as there is twice the amount of compute resources available.
In the event of a failure in an Availability Zone, Amazon Redshift continues operating by using the resources in the remaining Availability Zone automatically. However, user connections might be lost and must be re-established. In addition, queries that were running in the failed Availability Zone can fail and must be retried. However, you can reconnect to your cluster and reschedule queries immediately, and Amazon Redshift will process the queries in the remaining Availability Zone. Queries issued at or after a failure occurs might experience runtime delays while the Multi-AZ data warehouse is recovering.
**Note**
To achieve better performance and higher availability, we recommend that you use SNAPSHOT ISOLATION with your Multi-AZ clusters. For more information, see [CREATE DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html).
## Limitations
A Multi-AZ data warehouse has the same functional capabilities as a Single-AZ data warehouse, except for the following limitations that apply to a Multi-AZ data warehouse:
+ You can't create an unencrypted Multi-AZ data warehouse. Make sure to add an encryption when creating a new Multi-AZ data warehouse, converting a Single-AZ data warehouse into a Multi-AZ data warehouse, or converting a Single-AZ data warehouse into a Multi-AZ data warehouse.
+ You can't create a single node Multi-AZ deployment for any of the RA3 instance types. Choose 2 or more nodes per Availability Zone while creating a Multi-AZ deployment.
+ Amazon Redshift doesn't support a subnet configuration that can support fewer than three Availability Zones. In other words, the configured subnet group requires three or more subnets.
+ You can't relocate a Multi-AZ deployment to another Availability Zone. Relocation will be automatically determined and conducted by Amazon Redshift when using Multi-AZ deployment.
+ You can't pause or resume a Multi-AZ deployment.
+ You can't run your Multi-AZ deployment outside of the supported port ranges 5431 to 5455 and 8191 to 8215.
+ You can't use STL, SVCS, SVL, SVV, STV views with Multi-AZ deployments as they only support system monitoring views (SYS\$1\$1 views). Change your monitoring queries to use system monitoring views (SYS\$1\$1 views).
+ You can't attach an Elastic IP address to an existing cluster with Multi-AZ enabled.
+ You can't convert a cluster with an attached Elastic IP address from Single-AZ to Multi-AZ.
+ Amazon Redshift Multi-AZ deployment is available in the following AWS Regions:
+ US East (Ohio) (us-east-2)
+ US East (N. Virginia) (us-east-1)
+ US West (Oregon) (us-west-2)
+ Africa (Cape Town) (af-south-1)
+ Asia Pacific (Hong Kong) (ap-east-1)
+ Asia Pacific (Taipei) (ap-east-2)
+ Asia Pacific (Hyderabad) (ap-south-2)
+ Asia Pacific (Jakarta) (ap-southeast-3)
+ Asia Pacific (Malaysia) (ap-southeast-5)
+ Asia Pacific (Melbourne) (ap-southeast-4)
+ Asia Pacific (Mumbai) (ap-south-1)
+ Asia Pacific (Osaka) (ap-northeast-3)
+ Asia Pacific (Seoul) (ap-northeast-2)
+ Asia Pacific (Singapore) (ap-southeast-1)
+ Asia Pacific (Sydney) (ap-southeast-2)
+ Asia Pacific (New Zealand) (ap-southeast-6)
+ Asia Pacific (Thailand) (ap-southeast-7)
+ Asia Pacific (Tokyo) (ap-northeast-1)
+ Canada (Central) (ca-central-1)
+ China (Beijing) (cn-north-1)
+ China (Ningxia) (cn-northwest-1)
+ Europe (Frankfurt) (eu-central-1)
+ Europe (Ireland) (eu-west-1)
+ Europe (London) (eu-west-2)
+ Europe (Milan) (eu-south-1)
+ Europe (Paris) (eu-west-3)
+ Europe (Spain) (eu-south-2)
+ Europe (Stockholm) (eu-north-1)
+ Europe (Zurich) (eu-central-2)
+ Israel (Tel Aviv) (il-central-1)
+ Mexico (Central) (mx-central-1)
+ Middle East (Bahrain) (me-south-1)
+ Middle East (UAE) (me-central-1)
+ South America (São Paulo) (sa-east-1)
+ AWS GovCloud (US-East) (us-gov-east-1)
+ AWS GovCloud (US-West) (us-gov-west-1)
+ Publicly accessible Multi-AZ data warehouses support 1 less VPC security group than Single-AZ and privately accessible Multi-AZ warehouses.
# Setting up Multi-AZ when creating a new cluster
Amazon Redshift Multi-AZ supports two Availability Zones at a time. Amazon Redshift automatically selects the Availability Zones based on the selected subnet group configuration. You can convert an existing single Availability Zone data warehouse into a Multi-AZ data warehouse or restore from a snapshot to configure it into a Multi-AZ data warehouse.
Using the Amazon Redshift console, you can easily create new Multi-AZ deployments. To create a new Multi-AZ deployment using the Amazon Redshift console, select the Multi-AZ option when creating the data warehouse. Specify the number of compute nodes required in a single Availability Zone, and Amazon Redshift will deploy that number of nodes in each of two Availability Zones. All nodes will be used to read and write workload processing during normal operation. You can also use the AWS CLI `create-cluster` command to create a new Multi-AZ data warehouse using the `multi-az` parameter.
You can convert an existing Single-AZ data warehouse into a Multi-AZ data warehouse, you can use either the Amazon Redshift console or the AWS CLI `modify-cluster` command using the `multi-az` parameter. Or, you can restore from a snapshot to configure a Single-AZ data warehouse into a Multi-AZ data warehouse either using the Amazon Redshift console or the AWS CLI `restore-from-cluster-snapshot` command using the `multi-az` parameter.
Multi-AZ deployment only supports RA3 node types that use Amazon Redshift Managed Storage (RMS). Amazon Redshift stores data in RMS, which uses Amazon S3 and is accessible in all Availability Zones in an AWS Region, without having to replicate the data at the Amazon Redshift level.
You can set up Multi-AZ deployment when creating a new cluster either using the Amazon Redshift console or the AWS Command Line Interface.
## Using the console
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Provisioned clusters dashboard**, and choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list.
1. Choose the button **Create cluster** to open the create cluster page.
1. Enter properties for your cluster. For general information about creating clusters, see [Creating a cluster](create-cluster.md).
1. Choose one of the RA3 node types from the **Node type** drop-down list. The AZ configuration option becomes available only when you chose an RA3 node type.
1. Under **AZ configuration**, choose **Multi-AZ**.
1. Under **Number of nodes per AZ**, enter at least two nodes for your cluster.
1. You have the option to load sample data or bring your own data:
+ In **Sample data**, choose **Load sample data** to load the sample dataset into your Amazon Redshift cluster. Amazon Redshift loads the sample dataset Tickit into the default dev database and public schema. Amazon Redshift automatically loads the sample dataset into your Amazon Redshift cluster. You can start using the query editor v2 to query data.
+ To bring your own data to your Amazon Redshift cluster, follow the steps in [Bringing your own data to Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/bring-own-data.html).
1. Scroll down to **Additional configurations**, expand **Network and security**, and make sure that you either accept the default **Cluster subnet group** or choose another one. If you choose another cluster subnet group, make sure that there are 3 Availability Zones in the subnet group you selected.
1. Under **Additional configurations**, expand **Database configurations**.
1. To use a custom AWS KMS key instead of the default AWS-owned key, click **Customize encryption settings** under **Database encryption**.
1. Under **Choose an KMS key**, you can either choose an AWS Key Management Service key or enter an ARN. Or, you can click **Create an AWS Key Management Service key** in the AWS Key Management Service console. For more information about creating KMS keys, see [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*.
1. Click **Create cluster**. When the cluster creation succeeds, you can view the details in the cluster details page. You can use your SQL client to load and query data.
## Using the AWS Command Line Interface
**To set up Multi-AZ when creating a cluster using the AWS Command Line Interface**
+ From the AWS CLI use the `create-cluster` command and the `multi-az` parameter as follows.
```
aws redshift create-cluster
--port 5439
--master-username master
--master-user-password #####
--node-type ra3.4xlarge
--number-of-nodes 2
--profile maz-test
--endpoint-url https://redshift.eu-west-1.amazonaws.com
--region eu-west-1
--cluster-identifier test-maz
--multi-az
--maintenance-track-name CURRENT
--encrypted
```
# Setting up Multi-AZ for a data warehouse restored from a snapshot
To create a new Multi-AZ cluster by restoring it from a snapshot, complete the following procedure.
## Using the console
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to use.
1. Choose **Restore snapshot**, **Restore to a provisioned cluster**.
1. Enter properties for your cluster. For general information about creating clusters, see [Creating a cluster](create-cluster.md).
1. Choose one of the RA3 node types from the **Node type** drop-down list. The AZ configuration option becomes available only when you chose an RA3 node type.
1. Under **AZ configuration**, choose **Multi-AZ**.
1. Under **Number of nodes per AZ**, enter at least two nodes for your cluster.
1. You have the option to load sample data or bring your own data:
+ In **Sample data**, choose **Load sample data** to load the sample dataset into your Amazon Redshift cluster. Amazon Redshift loads the sample dataset Tickit into the default dev database and public schema. Amazon Redshift automatically loads the sample dataset into your Amazon Redshift cluster. You can start using the query editor v2 to query data.
+ To bring your own data to your Amazon Redshift cluster, follow the steps in [Load data from Amazon S3 to Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html).
1. Scroll down to **Additional configurations**, expand **Network and security**, and make sure that you either accept the default **Cluster subnet group** or choose another one. If you choose another cluster subnet group, make sure that there are 3 Availability Zones in the subnet group you selected.
1. Under **Additional configurations**, expand **Database configurations**.
1. Under **Database encryption**, to use a custom KMS key other than the default AWS-owned key, click **Customize encryption settings**. This option is deselected by default.
1. Under **Choose an KMS key**, you can either choose an AWS Key Management Service key or enter an ARN. Or, you can click **Create an AWS Key Management Service key** in the AWS Key Management Service console. For more information about creating KMS keys, see [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*.
1. Click **Restore cluster from snapshot**. When the cluster restoration succeeds, you can view the details in the cluster details page.
## Using the AWS Command Line Interface
+ From the AWS CLI, use the `restore-from-cluster-snapshot` command as follows.
```
aws redshift restore-from-cluster-snapshot
--region eu-west-1
--multi-az
--snapshot-identifier test-snap1
--cluster-identifier test-saz-11
--endpoint-url https://redshift.eu-west-1.amazonaws.com/
```
# Converting a Single-AZ data warehouse to a Multi-AZ data warehouse
By converting a Single-AZ data warehouse to a Multi-AZ data warehouse, your data warehouse will be highly available with 99.99% SLA guarantee. The performance of an individual query will remain same even with a Multi-AZ data warehouse. For higher concurrency workloads, you will see a boost in overall throughput as Amazon Redshift can execute requests using compute resources in two Availability Zones.
**Note**
Amazon Redshift will not allow you to split existing compute resources while converting from Single-AZ to Multi-AZ, or vice versa. This operation isn't supported to maintain consistent individual query performance.
## Using the console
**To convert a Single-AZ cluster to a Multi-AZ data warehouse using the console**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Provisioned clusters dashboard**, and choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list.
1. Choose the cluster you want to convert to a Multi-AZ deployment. The cluster details page appears.
1. For **Actions**, choose **Activate Multi-AZ**. The modification summary appears. Click **Activate Multi-AZ**.
1. When there is an error, do one of the following, then click **Activate Multi-AZ**.
+ Cluster encryption — Choose **Properties** to edit the encryption settings in the Database configuration section under the Properties tab of the cluster details page.
+ Subnet group — Choose **Subnet group** to edit the cluster subnet group settings by clicking the subnet group link. If you choose another cluster subnet group, make sure that there are 3 Availability Zones in the subnet group you selected.
+ Port settings — Choose **Properties** to edit the port setting in the Database configuration section under the Properties tab of the cluster details page.
1. You can use your SQL client to load and query data.
## Using the AWS Command Line Interface
+ From the AWS CLI, use the `modify-cluster` command and the `multi-az` parameter as follows.
```
aws redshift modify-cluster
--profile maz-test
--endpoint-url https://redshift.eu-west-1.amazonaws.com
--region eu-west-1
--cluster-identifier test-maz-11
--multi-az
```
You can't use STL, SVCS, SVL, SVV, or STV views with Multi-AZ deployments because they only support system monitoring views (SYS\$1\$1 views). Change your monitoring queries to use system monitoring views (SYS\$1\$1 views).
# Converting a Multi-AZ data warehouse to a Single-AZ data warehouse
By converting a Multi-AZ data warehouse to a Single-AZ data warehouse, your data warehouse will not get the 99.99% SLA guarantee which Multi-AZ offers. The performance of an individual query will remain same but the overall throughput will be affected because compute resources in the second Availability Zone won't be available. You have the option to enable concurrency scaling to automatically scale throughput for consistent performance even with Single-AZ.
**Note**
Amazon Redshift will not allow you to split existing compute resources while converting from Single-AZ to Multi-AZ, or vice versa. This operation isn't supported to maintain consistent individual query performance.
## Using the console
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Provisioned clusters dashboard**, and choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list.
1. Choose the cluster you want to convert to a Multi-AZ deployment. The cluster details page appears.
1. For **Actions**, choose **Deactivate Multi-AZ**. The modification summary appears. Click **Deactivate Multi-AZ**.
## Using the AWS Command Line Interface
+ From the AWS CLI, use the `modify-cluster` command and the `no-multi-az` parameter as follows.
```
aws redshift modify-cluster
--profile maz-test
--endpoint-url https://redshift.eu-west-1.amazonaws.com
--region eu-west-1
--cluster-identifier test-maz-11
--no-multi-az
```
Once your data warehouse is converted to Single-AZ, it will lose the 99.99 SLA guarantee. Overall throughput will also be impacted. When the changes are saved, you can view the details in the cluster details page.
# Resizing a Multi-AZ data warehouse
You can resize a Multi-AZ data warehouse and specify a number of nodes or node type that is different from the current configuration of the data warehouse.
## Using the console
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Provisioned clusters dashboard**, and choose **Clusters**. The clusters for your account in the current AWS Region are listed. A subset of properties of each cluster is displayed in columns in the list.
1. Choose the cluster you want to resize the Multi-AZ data warehouse. The cluster details page appears.
1. For **Actions**, choose **Resize**. The Resize cluster page appears.
1. Follow the instructions on the page. You can resize the cluster now, once at a specific time, or increase and decrease the size of your cluster on a schedule.
1. Under **New configurations**, choose one of the RA3 node types from the Node type drop-down list.
1. Click **Resize cluster**.
## Using the AWS Command Line Interface
**To resize a Multi-AZ data warehouse using the AWS Command Line Interface**
+ From the AWS CLI, use the `resize-cluster` command to change the number of nodes for a single Availability Zone as follows.
```
aws redshift resize-cluster \
--cluster-identifier test-maz-11
--cluster-type multi-node
--node-type ra3.4xlarge
--number-of-nodes 6
```
# Failing over Multi-AZ deployment
Your Multi-AZ data warehouse is a collection compute resources deployed simultaneously in two Availability Zones. The compute resources deployed in the primary Availability Zone are referred to as primary compute and those in the secondary Availability Zones are referred as secondary compute. A Multi-AZ data warehouse can automatically recover without any user intervention during an unlikely event such as an Availability Zone or infrastructure failure. The recovery process involves failing over from primary compute to secondary compute and designating secondary compute resources as primary. Additionally, new secondary compute resources are provisioned in a third Availability Zone. The automatic recovery process is measured in terms of RTO and RPO.
+ **Recovery time objective (RTO)** — The time it takes a system to return to a working state after a disaster. In other words, RTO measures downtime.
+ **Recovery point objective (RPO)** — The amount of data that can be lost (measured in time). For an Amazon Redshift Multi-AZ data warehouse, RPO is typically is zero as all the data is stored in Amazon Redshift Managed Storage (RMS), backed by Amazon Simple Storage Service, which is a highly durable and available by default.
**Note**
The performance of an individual query performance will not change after a failover has occurred. The overall throughput of your data warehouse will be reduced for a short time due to unavailability of compute resources in one of the Availability Zones. However, Amazon Redshift will automatically acquire capacity in another Availability Zone to ensure the same data warehouse processing capacity is restored.
In addition to the automatic recovery process, you can also trigger this process manually for your data warehouse using the **Failover primary compute** option. You can use this approach to test how Multi-AZ would help your application for higher high availability and better continuity.
## Using the console
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Do one of the following:
+ On the navigation menu, choose **Clusters**. Under **Clusters**, choose a cluster. The cluster details page appears.
+ From the cluster dashboard, choose a cluster.
1. From **Actions**, choose **Failover primary compute**.
1. When prompted, click **Confirm**.
## Using the AWS Command Line Interface
+ From the AWS CLI, use the `failover-primary-compute` command as follows.
```
aws redshift failover-primary-compute
--profile maz-test
--endpoint-url https://redshift.eu-west-1.amazonaws.com
--region eu-west-1
--cluster-identifier test-maz-11
```
After the above operation is confirmed, Amazon Redshift will perform the same steps as an automatic recovery from an Availability Zone or infrastructure failure. The process will cause compute nodes in the primary Availability Zone to become unavailable and compute resources in the secondary Availability Zone will be designated as primary compute. When the cluster recovery successfully completes, Multi-AZ deployment becomes available. Your Multi-AZ data warehouse will also automatically provision new secondary compute in another third Availability Zone as soon as it is available.
During this process, the cluster status on the console shows as modifying for the entire time, as the cluster automatically recovers and reconfigures back to the Multi-AZ deployment setup. The cluster can accept new connections immediately. Existing connections and inflight queries might be dropped. You can retry them immediately.
# Viewing queries and loads for Multi-AZ data warehouses
You can view information on queries that ran in the past 7 days irrespective of the type, size, and status (pause or resume) of your cluster.
The information shown on the queries and loads page is populated with information from Amazon Redshift system tables (SYS\$1\$1 views). This information lets you display additional information about your queries and offers rolling 7 days of retention. Query diagnostics become faster, letting you filter data by database, username, or SQL statement type. To see these additional filters and information on all queries that ran, note the following prerequisites:
+ You must connect to a database by choosing **Connect to database**.
+ Your database user must have the sys:operator or sys:monitor roles and permissions to perform query monitoring. For information about system roles, see [Amazon Redshift system-defined roles](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) in the *Amazon Redshift Database Developer Guide*.
You will see these additional filters and query information once you connect to a database.
**To display query performance data from Queries and loads**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Queries and loads** to display the list of queries for your account.
1. You might have to connect to a database to see additional filter. If required, click **Connect to database** and follow the prompts to connect to a database.
By default, the list displays queries for all your clusters over the past 24 hours. You can change the scope of the displayed date in the console.
**To display query performance data from Query monitoring**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**. Under **Clusters**, select a cluster.
1. Choose **Query monitoring**.
1. Depending on the configuration or version of your cluster, you might have to connect to a database to see additional filters. If required, click **Connect to database** and follow the prompts to connect to a database.
# Monitoring a query in a Multi-AZ deployment
A Multi-AZ deployment uses compute resources that are deployed in both Availability Zones and can continue operating in the event that the resources in a given Availability Zone aren't available. All the compute resources will be used at all times. This allows full operation across two Availability Zones in an active-active fashion for both read and write operations.
You can query SYS\$1 views in pg\$1catalog schema to monitor query runtime in a Multi-AZ deployment. The SYS\$1 views display query runtime activities or statistics from primary and secondary clusters. For a list of monitoring views, see [Monitoring views](https://docs.aws.amazon.com/redshift/latest/dg/serverless-monitoring.html).
Follow these steps to monitor query runtime for each Availability Zone within the Multi-AZ deployment:
1. Navigate to the Amazon Redshift console and connect to the database in your Multi-AZ deployment and run queries through the query editor.
1. Run any sample query on the Multi-AZ Amazon Redshift deployment.
1. For a Multi-AZ deployment, you can identify a query and the Availability Zone where it is run by using the compute\$1type column in the SYS\$1QUERY\$1HISTORY table. *primary* stands for queries run on the primary cluster in the Multi-AZ deployment, and *secondary* stands for queries run on the secondary cluster in the Multi-AZ deployment.
The following query uses compute\$1type column to monitor a query.
```
select (compute_type) as compute_type, left(query_text, 50) query_text from sys_query_history order by start_time desc;
compute_type | query_text
--------------+-------------------------
secondary | select count(*) from t1;
```
# Terminating a query for a cluster
The procedure is applicable to both Multi-AZ and Single-AZ clusters.
**To terminate a query**
You can also use the **Queries** page to end a query that is currently in progress.
Your database user must have the sys:operator role and permissions to end a running query. For information about system roles, see [Amazon Redshift system-defined roles](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) in the *Amazon Redshift Database Developer Guide*.
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Queries and loads** to display the list of queries for your account.
1. Choose the running query that you want to end in the list, and then choose **Terminate query**.
# Monitoring Amazon Redshift cluster performance
Monitoring cluster performance
Amazon Redshift provides performance metrics and data so that you can track the health and performance of your clusters and databases. In this section, we discuss the types of data that you can work with in Amazon Redshift, specifically in the Amazon Redshift console.
The performance data that you can use in the Amazon Redshift console falls into two categories:
+ **Amazon CloudWatch metrics – **Amazon CloudWatch metrics help you monitor physical aspects of your cluster, such as CPU utilization, latency, and throughput. Metric data is displayed directly in the Amazon Redshift console. You can also view it in the CloudWatch console. Alternatively, you can consume it in any other way you work with metrics, such as with the AWS CLI or one of the AWS SDKs.
+ **Query/Load performance data – **Performance data helps you monitor database activity and performance. This data is aggregated in the Amazon Redshift console to help you easily correlate what you see in CloudWatch metrics with specific database query and load events. You can also create your own custom performance queries and run them directly on the database. Query and load performance data is displayed only in the Amazon Redshift console. It is not published as CloudWatch metrics.
Performance data is integrated into the Amazon Redshift console, yielding a richer experience in the following ways:
+ Performance data associated with a cluster is displayed contextually when you view a cluster, where you might need it to make decisions about the cluster such as resizing.
+ Some performance metrics are displayed in more appropriately scaled units in the Amazon Redshift console as compared to CloudWatch. For example, `WriteThroughput`, is displayed in GB/s (as compared to bytes/s in CloudWatch), which is a more relevant unit for the typical storage space of a node.
+ You can easily display performance data for the nodes of a cluster together on the same graph. This way, you can easily monitor the performance of all nodes of a cluster. You can also view performance data for each node.
Amazon Redshift provides performance data (both CloudWatch metrics and query and load data) at no additional charge. Performance data is recorded every minute. You can access historical values of performance data in the Amazon Redshift console. For detailed information about using CloudWatch to access the Amazon Redshift performance data that is exposed as CloudWatch metrics, see [What is CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html.html) in the *Amazon CloudWatch User Guide*.
# Performance data in Amazon Redshift
Performance data
Using CloudWatch metrics for Amazon Redshift, you can get information about your cluster's health and performance and see information at the node level. When working with these metrics, keep in mind that each metric has one or more dimensions associated with it. These dimensions tell you what the metric is applicable to, that is the scope of the metric. Amazon Redshift has the following two dimensions:
+ Metrics that have a `NodeID` dimension are metrics that provide performance data for nodes of a cluster. This set of metrics includes leader and compute nodes. Examples of these metrics include `CPUUtilization`, `ReadIOPS`, `WriteIOPS`.
+ Metrics that have only a `ClusterIdentifier` dimension are metrics that provide performance data for clusters. Examples of these metrics include `HealthStatus` and `MaintenanceMode`.
**Note**
In some metric cases, a cluster-specific metric represents an aggregation of node behavior. In these cases, take care in the interpretation of the metric value because the leader node's behavior is aggregated with the compute node.
For general information about CloudWatch metrics and dimensions, see [CloudWatch concepts](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/cloudwatch_concepts.html) in the *Amazon CloudWatch User Guide*.
For a further description of CloudWatch metrics for Amazon Redshift, see the following sections.
**Topics**
+ [
## Amazon Redshift metrics
](#redshift-metrics)
+ [
## Dimensions for Amazon Redshift metrics
](#metrics-filterable-dimensions)
+ [
## Amazon Redshift query and load performance data
](#custom-metrics-listing)
## Amazon Redshift metrics
The `AWS/Redshift` namespace includes the following metrics. Unless stated otherwise, metrics are collected at 1-minute intervals.
| Metric | Description |
| --- | --- |
| CommitQueueLength | The number of transactions waiting to commit at a given point in time. Units: Count Dimensions: `ClusterIdentifier` |
| ConcurrencyScalingActiveClusters | The number of concurrency scaling clusters that are actively processing queries at any given time. Units: Count Dimensions: `ClusterIdentifier` |
| ConcurrencyScalingSeconds | The number of seconds used by concurrency scaling clusters that have active query processing activity. Units: Count Dimensions: `ClusterIdentifier` |
| CPUUtilization | The percentage of CPU utilization. For clusters, this metric represents an aggregation of all nodes (leader and compute) CPU utilization values. Units: Percent Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| DatabaseConnections | The number of database connections to a cluster. Units: Count Dimensions: `ClusterIdentifier` |
| HealthStatus | Indicates the health of the cluster. Every minute the cluster connects to its database and performs a simple query. If it is able to perform this operation successfully, the cluster is considered healthy. Otherwise, the cluster is unhealthy. An unhealthy status can occur when the cluster database is under extremely heavy load or if there is a configuration problem with a database on the cluster. In Amazon CloudWatch, this metric is reported as 1 or 0 whereas in the Amazon Redshift console, this metric is displayed with the words `HEALTHY` or `UNHEALTHY` for convenience. When this metric is displayed in the Amazon Redshift console, sampling averages are ignored and only `HEALTHY` or `UNHEALTHY` are displayed. In Amazon CloudWatch, values different than 1 and 0 might occur because of sampling issue. Any value below 1 for `HealthStatus` is reported as 0 (`UNHEALTHY`). Units: Count (1/0) (`HEALTHY`/`UNHEALTHY` in the Amazon Redshift console) Dimensions: `ClusterIdentifier` |
| MaintenanceMode | Indicates whether the cluster is in maintenance mode. In Amazon CloudWatch, this metric is reported as 1 or 0 whereas in the Amazon Redshift console, this metric is displayed with the words `ON` or `OFF` for convenience. When this metric is displayed in the Amazon Redshift console, sampling averages are ignored and only `ON` or `OFF` are displayed. In Amazon CloudWatch, values different than 1 and 0 might occur because of sampling issues. Any value greater than 0 for `MaintenanceMode` is reported as 1 (`ON`). Units: Count (1/0) (`ON`/`OFF` in the Amazon Redshift console). Dimensions: `ClusterIdentifier` |
| MaxConfiguredConcurrencyScalingClusters | Maximum number of concurrency scaling clusters configured from the parameter group. For more information, see [Amazon Redshift parameter groups](working-with-parameter-groups.md). Units: Count Dimensions: `ClusterIdentifier` |
| NetworkReceiveThroughput | The rate at which the node or cluster receives data. Units: Bytes/Second (MB/s in the Amazon Redshift console) Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| NetworkTransmitThroughput | The rate at which the node or cluster writes data. Units: Bytes/Second (MB/s in the Amazon Redshift console) Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| PercentageDiskSpaceUsed | The percent of disk space used. Units: Percent Dimensions: `ClusterIdentifier` Dimensions: `ClusterIdentifier`, `NodeID` |
| QueriesCompletedPerSecond | The average number of queries completed per second. Reported in 5-minute intervals. This metric isn't supported on single-node clusters. Units: Count/Second Dimensions: `ClusterIdentifier`, `latency` Dimensions: `ClusterIdentifier`, `wlmid` |
| QueryDuration | The average amount of time to complete a query. Reported in 5-minute intervals. This metric isn't supported on single-node clusters. Units: Microseconds Dimensions: `ClusterIdentifier`, `NodeID`, `latency` Dimensions: `ClusterIdentifier`, `latency` Dimensions: `ClusterIdentifier`, `NodeID`, `wlmid` |
| QueryRuntimeBreakdown | The total time queries spent running by query stage. Reported in 5-minute intervals. Units: Milliseconds Dimensions: ClusterIdentifier, NodeID, stage Dimensions: ClusterIdentifier, stage |
| ReadIOPS | The average number of disk read operations per second. Units: Count/Second Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| ReadLatency | The average amount of time taken for disk read I/O operations. Units: Seconds Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| ReadThroughput | The average number of bytes read from disk per second. Units: Bytes (GB/s in the Amazon Redshift console) Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| RedshiftManagedStorageTotalCapacity | Total managed storage capacity. Units: Megabytes Dimensions: `ClusterIdentifier` |
| TotalTableCount | The number of user tables open at a particular point in time. This total doesn't include Amazon Redshift Spectrum tables. Units: Count Dimensions: `ClusterIdentifier` |
| WLMQueueLength | The number of queries waiting to enter a workload management (WLM) queue. Units: Count Dimensions: `ClusterIdentifier`, `service class` Dimensions: `ClusterIdentifier`, `QueueName` |
| WLMQueueWaitTime | The total time queries spent waiting in the workload management (WLM) queue. Reported in 5-minute intervals. Units: Milliseconds. Dimensions: `ClusterIdentifier`, `QueryPriority` Dimensions: `ClusterIdentifier`, `wlmid` Dimensions: `ClusterIdentifier`, `QueueName` |
| WLMQueriesCompletedPerSecond | The average number of queries completed per second for a workload management (WLM) queue. Reported in 5-minute intervals. This metric isn't supported on single-node clusters. Units: Count/Second Dimensions: `ClusterIdentifier`, `wlmid` Dimensions: `ClusterIdentifier`, `QueueName` |
| WLMQueryDuration | The average length of time to complete a query for a workload management (WLM) queue. Reported in 5-minute intervals. This metric isn't supported on single-node clusters. Units: Microseconds Dimensions: `ClusterIdentifier`, `wlmid` Dimensions: `ClusterIdentifier`, `QueueName` |
| WLMRunningQueries | The number of queries running from both the main cluster and concurrency scaling cluster per WLM queue. Units: Count Dimensions: `ClusterIdentifier`, `wlmid` Dimensions: `ClusterIdentifier`, `QueueName` |
| WriteIOPS | The average number of write operations per second. Units: Count/Second Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| WriteLatency | The average amount of time taken for disk write I/O operations. Units: Seconds Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| WriteThroughput | The average number of bytes written to disk per second. Units: Bytes (GB/s in the Amazon Redshift console) Dimensions: `ClusterIdentifier`, `NodeID` Dimensions: `ClusterIdentifier` |
| SchemaQuota | The configured quota for a schema. Units: Megabytes Dimensions: `ClusterIdentifier`, `Database`, `Schema` Periodic/Push: `Periodic` Frequency: `5 minutes` Stop criteria: Schema dropped or quota removed |
| NumExceededSchemaQuotas | The number of schemas with exceeded quotas. Units: Count Dimensions: `ClusterIdentifier` Periodic/Push: `Periodic` Frequency: `5 minutes` Stop criteria: N/A |
| StorageUsed | The disk or storage space used by a schema. Units: Megabytes Dimensions: `ClusterIdentifier`, `Database`, `Schema` Periodic/Push: `Periodic` Frequency: `5 minutes` Stop criteria: Schema dropped or quota removed |
| PercentageQuotaUsed | The percentage of disk or storage space used relative to the configured schema quota. Units: Percent Dimensions: `ClusterIdentifier`, `Database`, `Schema` Periodic/Push: `Periodic` Frequency: `5 minutes` Stop criteria: Schema dropped or quota removed |
| UsageLimitAvailable | Depending on the FeatureType, UsageLimitAvailable returns the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/redshift/latest/mgmt/metrics-listing.html) Units: Minutes or TBs Dimensions: `ClusterIdentifier`, `FeatureType`, `UsageLimitId` |
| UsageLimitConsumed | Depending on the FeatureType, UsageLimitConsumed returns the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/redshift/latest/mgmt/metrics-listing.html) Units: Minutes or TBs Dimensions: `ClusterIdentifier`, `FeatureType`, `UsageLimitId` |
## Dimensions for Amazon Redshift metrics
Amazon Redshift data can be filtered along any of the dimensions in the table following.
| Dimension | Description |
| --- | --- |
| latency | Possible values are as follows: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/redshift/latest/mgmt/metrics-listing.html) |
| NodeID | Filters requested data that is specific to the nodes of a cluster. `NodeID` is either "Leader", "Shared", or "Compute-N" where N is 0, 1, ... for the number of nodes in the cluster. "Shared" means that the cluster has only one node, that is the leader node and compute node are combined. Metrics are reported for the leader node and compute nodes only for `CPUUtilization`, `NetworkTransmitThroughput`, and `ReadIOPS`. Other metrics that use the `NodeId` dimension are reported only for compute nodes. |
| ClusterIdentifier | Filters requested data that is specific to the cluster. Metrics that are specific to clusters include `HealthStatus`, `MaintenanceMode`, and `DatabaseConnections`. General metrics for this dimension (for example, `ReadIOPS`) that are also metrics of nodes represent an aggregate of the node metric data. Take care in interpreting these metrics because they aggregate behavior of leader and compute nodes. |
| service class | The identifier for a `WLM` service class. |
| stage | The execution stages for a query. The possible values are as follows: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/redshift/latest/mgmt/metrics-listing.html) |
| wlmid | The identifier for a workload management queue. |
| QueryPriority | The priority of the query. Possible values are `CRITICAL`, `HIGHEST`, `HIGH`, `NORMAL`, `LOW`, and `LOWEST`. |
| QueueName | The name of the workload management queue. |
| FeatureType | The feature that is limited by a usage limit. Possible values are `CONCURRENCY_SCALING`, `CROSS_REGION_DATASHARING`, and `SPECTRUM`. |
| UsageLimitId | The identifier for a usage limit. |
## Amazon Redshift query and load performance data
In addition to the CloudWatch metrics, Amazon Redshift provides query and load performance data. Query and load performance data can be used to help you understand the relation between database performance and cluster metrics. For example, if you notice that a cluster's CPU spiked, you can find the spike on the cluster CPU graph and see the queries that were running at that time. Conversely, if you are reviewing a specific query, metric data (like CPU) is displayed in context so that you can understand the query's impact on cluster metrics.
Query and load performance data are not published as CloudWatch metrics and can only be viewed in the Amazon Redshift console. Query and load performance data are generated from querying with your database's system tables (for more information, see [System tables reference](https://docs.aws.amazon.com/redshift/latest/dg/cm_chap_system-tables.html) in the *Amazon Redshift Developer Guide*). You can also generate your own custom database performance queries, but we recommend starting with the query and load performance data presented in the console. For more information about measuring and monitoring your database performance yourself, see [Managing performance](https://docs.aws.amazon.com/redshift/latest/dg/c-optimizing-query-performance.html) in the *Amazon Redshift Developer Guide.*
The following table describes different aspects of query and load data you can access in the Amazon Redshift console.
| Query/Load data | Description |
| --- | --- |
| Query summary | A list of queries in a specified time period. The list can be sorted on values such as query ID, query runtime, and status. View this data in the **Query monitoring** tab of the cluster detail page. |
| Query detail | Provides details on a particular query including: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/redshift/latest/mgmt/metrics-listing.html) |
| Load summary | Lists all the loads in a specified time period. The list can be sorted on values such as query ID, query runtime, and status. View this data in the **Query monitoring** tab of the cluster detail page. |
| Load detail | Provides details on a particular load operation including: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/redshift/latest/mgmt/metrics-listing.html) |
# Viewing performance data
Viewing performance data
In this section, you can find how to view performance data in the Amazon Redshift console, which includes information about cluster and query performance. Additionally, you can create alarms on cluster metrics directly from the Amazon Redshift console.
When you view performance data in the Amazon Redshift console, you view it by cluster. The performance data graphs for a cluster are designed to give you access to data to answer your most common performance questions. For some performance data (see [Performance data in Amazon Redshift](metrics-listing.md)), you can also use CloudWatch to further customize your metrics graphs. For example, you can choose longer times or combine metrics across clusters. For more information about working with the CloudWatch console, see [Performance metrics in the CloudWatch console](using-cloudwatch-console.md).
To learn how to monitor, isolate, and optimize your queries using the query monitoring features on the Amazon Redshift console, watch the following video.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/Wdvb5iYVnLg)
**Topics**
+ [
# Viewing cluster performance data
](performance-metrics-perf.md)
+ [
# Viewing query history data
](performance-metrics-query-history.md)
+ [
# Viewing database performance data
](performance-metrics-database-performance.md)
+ [
# Viewing workload concurrency and concurrency scaling data
](performance-metrics-concurrency-scaling.md)
+ [
# Viewing automatic optimization data
](performance-metrics-autonomics.md)
+ [
# Viewing queries and loads
](performance-metrics-queries.md)
+ [
# Viewing and analyzing query details
](performance-metrics-query-execution-details.md)
+ [
# Viewing cluster performance as queries run
](performance-metrics-query-cluster.md)
+ [
# Viewing cluster metrics during load operations
](performance-metrics-loads.md)
+ [
# Viewing the cluster workload breakdown chart
](analyze-workload-performance.md)
# Viewing cluster performance data
By using cluster metrics in Amazon Redshift, you can do the following common performance tasks:
+ Determine if cluster metrics are abnormal over a specified time range and, if so, identify the queries responsible for the performance hit.
+ Check if historical or current queries are impacting cluster performance. If you identify a problematic query, you can view details about it including the cluster performance during the query's execution. You can use this information in diagnosing why the query was slow and what can be done to improve its performance.
**To view performance data**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the name of a cluster from the list to open its details. The details of the cluster are displayed, which can include **Cluster performance**, **Query monitoring**, **Databases**, **Datashares**, **Schedules**, **Maintenance**, and **Properties** tabs.
1. Choose the **Cluster performance** tab for performance information including the following:
+ **CPU utilization**
+ **Percentage disk space used**
+ **Database connections**
+ **Health status**
+ **Query duration**
+ **Query throughput**
+ **Concurrency scaling activity**
Many more metrics are available. To see the available metrics and choose which are displayed, choose the **Preferences** icon.
## Cluster performance graphs
The following examples show some of the graphs that are displayed in the new Amazon Redshift console.
+ **CPU utilization** – Shows the percentage of CPU utilization for all nodes (leader and compute). To find a time when the cluster usage is lowest before scheduling cluster migration or other resource-consuming operations, monitor this chart to see CPU utilization per individual or all of nodes.
![\[An image of the CPU utilization graph in the Amazon Redshift console that shows the percentage of CPU utilization for each node.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-cpu-utilization.png)
+ **Maintenance mode** – Shows whether the cluster is in the maintenance mode at a chosen time by using `On` and `Off` indicators. You can see the time when the cluster is undergoing maintenance. You can then correlate this time to operations that are done to the cluster to estimate its future downtimes for recurring events.
![\[An image of the graph in the Amazon Redshift console that shows whether maintenance mode is On or Off.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-maintenance-mode.png)
+ **Percentage disk space used** – Shows the percentage of disk space usage per each compute node, and not for the cluster as a whole. You can explore this chart to monitor the disk utilization. Maintenance operations like VACUUM and COPY use intermediate temporary storage space for their sort operations, so a spike in disk usage is expected.
![\[An image of the graph in the Amazon Redshift console that shows the percentage of disk space used for each node.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-percentage-disk-space-used.png)
+ **Read throughput** – Shows the average number of megabytes read from disk per second. You can evaluate this chart to monitor the corresponding physical aspect of the cluster. This throughput doesn't include network traffic between instances in the cluster and its volume.
![\[An image of the graph in the Amazon Redshift console that shows the read throughput for each node.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-read-throughput.png)
+ **Read latency** – Shows the average amount of time taken for disk read I/O operations per millisecond. You can view the response times for the data to return. When latency is high, it means that the sender spends more time idle (not sending any new packets), which reduces how fast throughput grows.
![\[An image of the graph in the Amazon Redshift console that shows the read latency for each node.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-read-latency.png)
+ **Write throughput** – Shows the average number of megabytes written to disk per second. You can evaluate this metric to monitor the corresponding physical aspect of the cluster. This throughput doesn't include network traffic between instances in the cluster and its volume.
![\[An image of the graph in the Amazon Redshift console that shows the write throughput for each node.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-write-throughput.png)
+ **Write latency** – Shows the average amount of time in milliseconds taken for disk write I/O operations. You can evaluate the time for the write acknowledgment to return. When latency is high, it means that the sender spends more time idle (not sending any new packets), which reduces how fast throughput grows.
![\[An image of the graph in the Amazon Redshift console that shows the write latency for each node.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-write-latency.png)
+ **Database connections** – Shows the number of database connections to a cluster. You can use this chart to see how many connections are established to the database and find a time when the cluster usage is lowest.
![\[Graph in the Amazon Redshift console that shows the number of database connections to a cluster.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-database-connections.png)
+ **Total table count** – Shows the number of user tables open at a particular point in time within a cluster. You can monitor the cluster performance when open table count is high.
![\[An image of the graph in the Amazon Redshift console that shows the total table count for a cluster.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-total-table-count.png)
+ **Health status** – Indicates the health of the cluster as `Healthy` or `Unhealthy`. If the cluster can connect to its database and performs a simple query successfully, the cluster is considered healthy. Otherwise, the cluster is unhealthy. An unhealthy status can occur when the cluster database is under extremely heavy load or if there is a configuration problem with a database on the cluster.
![\[An image of the graph in the Amazon Redshift console that shows the health status for a cluster.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-health-status.png)
+ **Query duration** – Shows the average amount of time to complete a query in microseconds. You can benchmark the data on this chart to measure I/O performance within the cluster and tune its most time-consuming queries if necessary.
![\[An image of the graph in the Amazon Redshift console that shows the query duration for a cluster.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-query-duration.png)
+ **Query throughput** – Shows the average number of completed queries per second. You can analyze data on this chart to measure database performance and characterize the ability of the system to support a multiuser workload in a balanced way.
![\[An image of the graph in the Amazon Redshift console that shows the query throughput for a cluster.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-query-throughput.png)
+ **Query duration per WLM queue** – Shows the average amount of time to complete a query in microseconds. You can benchmark the data on this chart to measure I/O performance per WLM queue and tune its most time-consuming queries if necessary.
![\[An image of the graph in the Amazon Redshift console that shows the query duration per WLM queue.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-query-duration-per-wlm-queue.png)
+ **Query throughput per WLM queue** – Shows the average number of completed queries per second. You can analyze data on this chart to measure database performance per WLM queue.
![\[An image of the graph in the Amazon Redshift console that shows the query throughput per WLM queue.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-query-throughput-per-wlm-queue.png)
+ **Concurrency scaling activity** – Shows the number of active concurrency scaling clusters. When concurrency scaling is enabled, Amazon Redshift automatically adds additional cluster capacity when you need it to process an increase in concurrent read queries.
![\[An image of the graph in the Amazon Redshift console that shows the number of active concurrency scaling clusters.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/cluster-performance-concurrency-scaling-activity.png)
# Viewing query history data
You can use query history metrics in Amazon Redshift to do the following:
+ Isolate and diagnose query performance problems.
+ Compare query runtime metrics and cluster performance metrics on the same timeline to see how the two might be related. Doing so helps identify poorly performing queries, look for bottleneck queries, and determine if you need to resize your cluster for your workload.
+ Drill down to the details of a specific query by choosing it in the timeline. When **Query ID** and other properties are displayed in a row below the graph, then you can choose the query to see query details. Details include, for example, the query's SQL statement, execution details, and query plan. For more information, see [Viewing and analyzing query details](performance-metrics-query-execution-details.md).
+ Determine if your load jobs complete successfully and meet your service level agreements (SLAs).
**To display query history data**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster name from the list to open its details. The details of the cluster are displayed, which can include **Cluster performance**, **Query monitoring**, **Databases**, **Datashares**, **Schedules**, **Maintenance**, and **Properties** tabs.
1. Choose the **Query monitoring** tab for metrics about your queries.
1. In the **Query monitoring** section, choose the **Query history** tab.
Using controls on the window, you can toggle between **Query list** and **Cluster metrics**.
When you choose **Query list**, the tab includes the following graphs:
+ **Query runtime** – The query activity on a timeline. Use this graph to see which queries are running in the same timeframe. Choose a query to view more query execution details. The x-axis shows the selected period. You can filter the graphed queries by running, completed, loads, and so on. Each bar represents a query, and the length of the bar represents its runtime from the start of the bar to the end. The queries can include SQL data manipulation statements (such as SELECT, INSERT, DELETE) and loads (such as COPY). By default, the top 100 longest running queries are shown for the selected time period.
+ **Queries and loads** – List of queries and loads that ran on the cluster. The window includes an option to **Terminate query** if a query is currently running.
When you choose **Cluster metrics**, the tab includes the following graphs:
+ **Query runtime** – The query activity on a timeline. Use this graph to see which queries are running in the same timeframe. Choose a query to view more query execution details.
+ **CPU utilization** – The CPU utilization of the cluster by leader node and average of compute nodes.
+ **Storage capacity used** – The percent of the storage capacity used.
+ **Active database connections** – The number of active database connections to the cluster.
Consider the following when working with the query history graphs:
+ Choose a bar that represents a specific query on the **Query runtime** chart to see details about that query. You can also, choose a query ID on **Queries and loads** list to see its details.
+ You can swipe to select a section of the **Query runtime** chart to zoom in to display a specific time period.
+ On the **Query runtime** chart, to have all data considered by your chosen filter, page forward through all pages listed on the **Queries and loads** list.
+ You can change which columns and the number of rows displayed on the **Queries and loads** list using the preferences window displayed by the **settings gear icon**.
+ The **Queries and loads** list can also be displayed by navigating from the left navigator **Queries** icon, **Queries and loads**. For more information, see [Viewing queries and loads](performance-metrics-queries.md).
## Query history graphs
The following examples show graphs that are displayed in the new Amazon Redshift console.
**Note**
The Amazon Redshift console graphs only contain data for the latest 100,000 queries.
+ **Query runtime**
![\[Graph showing the query activity on a timeline to illustrate which queries are running in the same timeframe.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-history-query-runtime.png)
+ **Queries and loads**
![\[Table showing a list of queries and loads, with attributes such as start time, duration, status, and query ID as the columns.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-history-queries-and-loads.png)
+ **CPU utilization**
![\[Line graph showing the CPU utilization in increments of 15 minutes.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-history-cpu-utilization.png)
+ **Storage capacity used**
![\[Line graph showing the percentage of storage capacity used in increments of 15 minutes.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-history-storage-capacity-used.png)
+ **Active database connections**
![\[Line graph showing the number of active database connections in increments of 15 minutes.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-history-active-database-connections.png)
# Viewing database performance data
You can use database performance metrics in Amazon Redshift to do the following:
+ Analyze the time spent by queries by processing stages. You can look for unusual trends in the amount of time spent in a stage.
+ Analyze the number of queries, duration, and throughput of queries by duration ranges (short, medium, long).
+ Look for trends in the about of query wait time by query priority (Lowest, Low, Normal, High, Highest, Critical).
+ Look for trends in the query duration, throughput, or wait time by WLM queue.
**To display database performance data**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster name from the list to open its details. The details of the cluster are displayed, including **Cluster performance**, **Query monitoring**, **Databases**, **Datashares**, **Schedules**, **Maintenance**, and **Properties** tabs.
1. Choose the **Query monitoring** tab for metrics about your queries.
1. In the **Query monitoring** section, choose **Database performance** tab.
Using controls on the window, you can toggle between **Cluster metrics** and **WLM queue metrics**.
When you choose **Cluster metrics**, the tab includes the following graphs:
+ **Workload execution breakdown** – The time used in query processing stages.
+ **Queries by duration range** – The number of short, medium, and long queries.
+ **Query throughput** – The average number of queries completed per second.
+ **Query duration** – The average amount of time to complete a query.
+ **Average queue wait time by priority** – The total time queries spent waiting in the WLM queue by query priority.
When you choose **WLM queue metrics**, the tab includes the following graphs:
+ **Query duration by queue** – The average query duration by WLM queue.
+ **Query throughput by queue** – The average number of queries completed per second by WLM queue.
+ **Query wait time by queue** – The average duration of queries spent waiting by WLM queue.
## Database performance graphs
The following examples show graphs that are displayed in the new Amazon Redshift console.
+ **Workload execution breakdown**
![\[Vertical bar graph showing duration of query processing stages in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-workload-execution-breakdown.png)
+ **Queries by duration range**
![\[Vertical bar graph showing number of queries in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-queries-by-duration.png)
+ **Query throughput**
![\[Line graph showing the average query throughput in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-query-throughput.png)
+ **Query duration**
![\[Line graph showing the average query duration in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-query-duration.png)
+ **Average queue wait time by priority**
![\[Line graph showing the average queue wait time in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-queue-wait-by-priority.png)
+ **Query duration by queue**
![\[Line graph showing the average query duration by queue in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-query-duration-by-queue.png)
+ **Query throughput by queue**
![\[Line graph showing the average query throughput by queue in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-query-throughput-by-queue.png)
+ **Query wait time by queue**
![\[Line graph showing the average query wait time by queue in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-queue-wait-by-queue.png)
# Viewing workload concurrency and concurrency scaling data
By using concurrency scaling metrics in Amazon Redshift, you can do the following:
+ Analyze whether you can reduce the number of queued queries by enabling concurrency scaling. You can compare by WLM queue or for all WLM queues.
+ View concurrency scaling activity in concurrency scaling clusters. This can tell you if concurrency scaling is limited by the `max_concurrency_scaling_clusters`. If so, you can choose to increase the `max_concurrency_scaling_clusters` in the DB parameter.
+ View the total usage of concurrency scaling summed across all concurrency scaling clusters.
**To display concurrency scaling data**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster name from the list to open its details. The details of the cluster are displayed, which can include **Cluster performance**, **Query monitoring**, **Databases**, **Datashares**, **Schedules**, **Maintenance**, and **Properties** tabs.
1. Choose the **Query monitoring** tab for metrics about your queries.
1. In the **Query monitoring** section, choose **Workload concurrency** tab.
The tab includes the following graphs:
+ **Queued vs. Running queries on the cluster** – The number of queries running (from the main cluster and concurrency scaling cluster) compared to the number of queries waiting in all WLM queues in the cluster.
+ **Queued vs. Running queries per queue** – The number of queries running (from the main cluster and concurrency scaling cluster) compared to the number or queries waiting in each WLM queue.
+ **Concurrency scaling activity** – The number of concurrency scaling clusters that are actively processing queries.
+ **Concurrency scaling usage** – The usage of concurrency scaling clusters that have active query processing activity.
## Workload concurrency graphs
The following examples show graphs that are displayed in the new Amazon Redshift console. To create similar graphs in Amazon CloudWatch, you can use the concurrency scaling and WLM CloudWatch metrics. For more information about CloudWatch metrics for Amazon Redshift, see [Performance data in Amazon Redshift](metrics-listing.md).
+ **Queued vs. Running queries on the cluster**
![\[Vertical bar graph in increments of days, with each bar divided into two different colors, one showing the average queued queries on a cluster, and the other showing the average running queries on the same cluster.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/workload-concurrency-queued-vs-running-cluster.png)
+ **Queued vs. Running queries per queue**
![\[Vertical bar graph in increments of days showing the number of queries running compared to the number of queries waiting in each queue.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/workload-concurrency-queued-vs-running-per-queue.png)
+ **Concurrency scaling activity**
![\[Horizontal dot graph in increments of days showing the number of concurrency scaling clusters that are actively processing queries.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/workload-concurrency-concurrency-scaling-activity.png)
+ **Concurrency scaling usage**
![\[Horizontal line graph in increments of days showing the usage of concurrency scaling clusters that have active query processing activity.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/workload-concurrency-concurrency-scaling-usage.png)
# Viewing automatic optimization data
The Amazon Redshift console provides information about automatic optimizations, or autonomics, run using extra compute resources. You can use this information to track usage and monitor whether usage limits have been reached. Though Amazon Redshift doesn't bill you for autonomics run on the provisioned cluster itself, it does bill you for autonomics run using extra compute resources. For more information, see [ Allocating extra compute resources for automatic database optimizations](https://docs.aws.amazon.com/redshift/latest/dg/t_extra-compute-autonomics.html) in the *Amazon Redshift Database Developer Guide*.
**To view extra compute autonomics data**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the name of a cluster from the list to open its details.
1. From the cluster's details page, select **Manage usage limit** from the **Actions** drop-down menu. You can also select the **Maintenance** tab for a cluster, then scroll down and select **Create usage limits**.
1. The graph showing extra compute autonomics data appears under the section titled **Usage limit for extra compute for automatic optimization**. The graph displays the amount of time that Amazon Redshift runs autonomics using extra compute resources in a given time period.
# Viewing queries and loads
The Amazon Redshift console provides information about queries and loads that run in the database. You can use this information to identify and troubleshoot queries that take a long time to process and that create bottlenecks preventing other queries from processing efficiently. You can use the queries information in the Amazon Redshift console to monitor query processing.
**To display query performance data**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Queries and loads** to display the list of queries for your account.
By default, the list displays queries for all your clusters over the past 24 hours. You can change the scope of the displayed date in the console.
**Important**
The **Queries and loads** list displays the longest running queries in the system, up to 100 queries.
# Viewing and analyzing query details
With a query identifier, you can view details of a query. Details can include, for example, the query's completion status, duration, SQL statement and whether it's a user query or one that was rewritten by Amazon Redshift. A *user query* is a query that is submitted to Amazon Redshift, either from an SQL client or generated by a business intelligence tool. Amazon Redshift might rewrite the query to optimize it, and this can result in multiple rewritten queries. Although the process is done by Amazon Redshift, you see the rewritten queries on the query details page along with the user query.
**To view a query**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Queries and loads** to display the list of queries for your account. You might need to change settings on this page to find your query.
1. Choose the **Query** identifier in the list to display **Query details**.
The **Query details** page includes **Query details** and **Query plan** tabs with metrics about the query.
Metrics include details about a query such as start time, query ID, status, and duration. Other details include whether a query ran on a main cluster or a concurrency scaling cluster, and if it's a parent or rewritten query.
# Viewing cluster performance as queries run
You can monitor the performance of your clusters as queries run to identify potential bottlenecks and optimize query execution. Viewing cluster performance as queries run provides a real-time view of the system-level metrics, such as CPU utilization, disk I/O, and network traffic, as well as query-level details like execution time, data processed, and query steps. The following procedures guides you through accessing and interpreting the performance metrics to effectively manage and optimize your provisioned clusters.
**To display cluster performance as queries run**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster name from the list to open its details. The details of the cluster are displayed, which can include **Cluster performance**, **Query monitoring**, **Databases**, **Datashares**, **Schedules**, **Maintenance**, and **Properties** tabs.
1. Choose the **Query monitoring** tab for more details.
For more information, see [Viewing query history data](performance-metrics-query-history.md).
# Viewing cluster metrics during load operations
When you view cluster performance during load operations, you can identify queries that are consuming resources and act to mitigate their effect. You can terminate a load if you don't want it to run to completion.
**Note**
The ability to terminate queries and loads in the Amazon Redshift console requires specific permission. If you want users to be able to terminate queries and loads, make sure to add the `redshift:CancelQuerySession` action to your AWS Identity and Access Management (IAM) policy. This requirement applies whether you select the **Amazon Redshift Read Only** AWS-managed policy or create a custom policy in IAM. Users who have the **Amazon Redshift Full Access** policy already have the necessary permission to terminate queries and loads. For more information about actions in IAM policies for Amazon Redshift, see [Managing access to resources](redshift-iam-access-control-overview.md#redshift-iam-accesscontrol-managingaccess).
**To display cluster performance during load operations**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster name from the list to open its details. The details of the cluster are displayed, which can include **Cluster performance**, **Query monitoring**, **Databases**, **Datashares**, **Schedules**, **Maintenance**, and **Properties** tabs.
1. Choose the **Query monitoring** tab for more details.
1. In the **Queries and loads** section, choose **Loads** to view the load operations of a cluster. If a load is running, you can end it by choosing **Terminate query**.
# Viewing the cluster workload breakdown chart
You can get a detailed view of your workload's performance by looking at the Workload execution breakdown chart in the console. We build the chart with data provided by the QueryRuntimeBreakdown metric. With this chart, you can see how much time your queries spend in the various processing stages, such as waiting and planning.
**Note**
The Workload execution breakdown chart isn't shown for single-node clusters.
The following list of metrics describes the various processing stages:
+ `QueryPlanning`: Time spent parsing and optimizing SQL statements.
+ `QueryWaiting`: Time spent waiting in the workload management (WLM) queue.
+ `QueryExecutingRead`: Time spent running read queries.
+ `QueryExecutingInsert`: Time spent running insert queries.
+ `QueryExecutingDelete`: Time spent running delete queries.
+ `QueryExecutingUpdate`: Time spent running update queries.
+ `QueryExecutingCtas`: Time spent running CREATE TABLE AS queries.
+ `QueryExecutingUnload`: Time spent running unload queries.
+ `QueryExecutingCopy`: Time spent running copy queries.
For example, the following graph in the Amazon Redshift console shows the amount of time that queries have spent in the plan, wait, read, and write stages. You can combine the findings from this graph with other metrics for further analysis. In some cases, your graph might show that queries with a short duration (as measured by the `QueryDuration` metric) are spending a long time in the wait stage. In these cases, you can increase the WLM concurrency rate for a particular queue to increase throughput.
Following, is an example of the workload execution breakdown chart. In the chart, the y-axis value is the average duration of each stage at the specified time shown as a stacked bar graph.
![\[Vertical bar graph showing duration of query processing stages in increments of days.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/database-performance-workload-execution-breakdown.png)
The following diagram illustrates how Amazon Redshift aggregates query processing for concurrent sessions.
![\[Horizonal bar graph showing session number on the x-axis and time on the y-axis. Each session is a horizontal bar that's divided into different query statuses.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/querybreakdownschematic.png)
**To view the cluster workload breakdown chart**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Clusters**, then choose the cluster name from the list to open its details. The details of the cluster are displayed, which can include **Cluster performance**, **Query monitoring**, **Databases**, **Datashares**, **Schedules**, **Maintenance**, and **Properties** tabs.
1. Choose the **Query monitoring** tab for metrics about your queries.
1. In the **Query monitoring** section, choose **Database performance**, and choose **Cluster metrics**.
The following metrics are graphed for the chosen time range as a stacked bar chart:
+ **Plan** time
+ **Wait** time
+ **Commit** time
+ **Execution** time
# Analyzing query execution
You can analyze the execution details of a query to understand how it performed and identify potential areas for optimization. Analyzing a query provides insights into the query plan, including the steps involved, the time taken by each step, and the amount of data processed. Common use cases include troubleshooting slow-running queries, optimizing data distribution strategies, and identifying opportunities for query rewriting or indexing.
**To analyze a query**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Queries and loads** to display the list of queries for your account. You might need to change settings on this page to find your query.
1. Choose the **Query** identifier in the list to display **Query details**.
The **Query details** page includes **Query details** and **Query plan** tabs with metrics about the query.
**Note**
You can also navigate to the **Query details** page from a **Cluster details** page, **Query history** tab when you drill down into a query in a **Query runtime** graph.
The **Query details** page contains the following sections:
+ A list of **Rewritten queries**, as shown in the following screenshot.
![\[Table showing a list of rewritten queries, with attributes such as start time, duration, status, and query ID as the column names.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-details-rewritten-queries.png)
+ A **Query details** section, as shown in the following screenshot.
![\[The query details section in the console showing attributes for a specific query.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-details-query.png)
+ A **Query details** tab that contains the **SQL** that was run and **Execution details** about the run.
+ A **Query plan** tab that contains the **Query plan** steps and other information about the query plan. This table also contains graphs about the cluster when the query ran.
+ **Cluster health status**
![\[The cluster health status section of the console showing the cluster health during the workload.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-details-cluster-health-status.png)
+ **CPU utilization**
![\[The CPU utilization section in the console showing a line graph of CPU utilization of the cluster in increments of minutes.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-details-cpu-utilization.png)
+ **Storage capacity used**
![\[The storage capacity used section in the console showing a line graph of the percent of stoage capacity used in increments of minutes.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-details-storage-capacity-used.png)
+ **Active database connections**
![\[The active database connections section in the console showing a line graph of the number of active database connections to the cluster over time.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/query-details-active-database-connections.png)
# Creating an alarm
Alarms you create in the Amazon Redshift console are CloudWatch alarms. They are useful because they help you make proactive decisions about your cluster or serverless instance. You can set one or more alarms on any of the metrics listed in [Performance data in Amazon Redshift](metrics-listing.md). For example, setting an alarm for high `CPUUtilization` on a cluster node helps indicate when the node is overutilized. An alarm for high `DataStorage` would keep track of the storage space that your serverless namespace is using for your data.
From **Actions**, you can modify or delete alarms. You can also create a chime or slack alert to send an alert from CloudWatch to Slack or Amazon Chime by specifying a Slack or Amazon Chime webhook URL.
In this section, you can find how to create an alarm using the Amazon Redshift console. You can create an alarm using the CloudWatch console or any other way you work with metrics, such as with the AWS CLI or an AWS SDK.
**To create a CloudWatch alarm with the Amazon Redshift console**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
If you're using Amazon Redshift Serverless, Choose **Go to Serverless ** on the upper right of the dashboard.
1. On the navigation menu, choose **Alarms**, then choose **Create alarm**.
1. On the **Create alarm** page, enter the properties to create a CloudWatch alarm.
1. Choose **Create alarm**.
# Ending a running query
You can also use the **Queries** page to end a query that is currently in progress.
**Note**
The ability to terminate queries and loads in the Amazon Redshift console requires specific permission. If you want users to be able to terminate queries and loads, make sure to add the `redshift:CancelQuerySession` action to your AWS Identity and Access Management (IAM) policy. This requirement applies whether you select the **Amazon Redshift Read Only** AWS managed policy or create a custom policy in IAM. Users who have the **Amazon Redshift Full Access** policy already have the necessary permission to terminate queries and loads. For more information about actions in IAM policies for Amazon Redshift, see [Managing access to resources](redshift-iam-access-control-overview.md#redshift-iam-accesscontrol-managingaccess).
**To end a running query**
1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. On the navigation menu, choose **Queries and loads** to display the list of queries for your account.
1. Choose the running query that you want to end in the list, and then choose **Terminate query**.
# Performance metrics in the CloudWatch console
When working with Amazon Redshift metrics in the CloudWatch console, keep a couple of things in mind:
+ Query and load performance data is only available in the Amazon Redshift console.
+ Some Metrics in the CloudWatch have different units than those used in the Amazon Redshift console. For example, `WriteThroughput` is displayed in GB/s (as compared to Bytes/s in CloudWatch), which is a more relevant unit for the typical storage space of a node.
When working with Amazon Redshift metrics in the CloudWatch console, command line tools, or an Amazon SDK, keep these concepts in mind:
1. First, specify the metric dimension to work with. A dimension is a name-value pair that helps you to uniquely identify a metric. The dimensions for Amazon Redshift are `ClusterIdentifier` and `NodeID`. In the CloudWatch console, the `Redshift Cluster` and `Redshift Node` views are provided to easily select cluster and node-specific dimensions. For more information about dimensions, see [Dimensions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/cloudwatch_concepts.html#Dimension) in the *CloudWatch Developer Guide*.
1. Then, specify the metric name, such as `ReadIOPS`.
The following table summarizes the types of Amazon Redshift metric dimensions that are available to you. Depending on the metric, data is available in either 1-minute or 5-minute intervals at no charge. For more information, see [Amazon Redshift metrics](metrics-listing.md#redshift-metrics).
| CloudWatch namespace | Dimension | Description |
| --- | --- | --- |
| AWS/Redshift | NodeID | Filters requested data that is specific to the nodes of a cluster. `NodeID` is either "Leader", "Shared", or "Compute-N" where N is 0, 1, ... for the number of nodes in the cluster. "Shared" means that the cluster has only one node, that is the leader node and compute node are combined. |
| AWS/Redshift | ClusterIdentifier | Filters requested data that is specific to the cluster. Metrics that are specific to clusters include `HealthStatus`, `MaintenanceMode`, and `DatabaseConnections`. General metrics for this dimension (for example, `ReadIOPS`) that are also metrics of nodes represent an aggregate of the node metric data. Take care in interpreting these metrics because they aggregate behavior of leader and compute nodes. |
Working with gateway and volume metrics is similar to working with other service metrics. Many of the common tasks are outlined in the CloudWatch documentation, including the following:
+ [View available metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)
+ [Get statistics for a metric](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/getting-metric-statistics.html)
+ [Creating CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
# Query profiler
This document describes Query profiler, a graphical tool for analyzing a query's components and performance.
Query profiler is a query monitoring and troubleshooting feature that's viewable through the Amazon Redshift console. It's helpful for analyzing query performance. Its primary purpose is to show a visual and graphical run order, execution plan, and statistics about a query, and make them easier to understand and troubleshoot. Query profiler helps you analyze the following types of query components:
+ **Child queries** – A child query is a portion of work from a query. Amazon Redshift may split a query into multiple child queries if it's more efficient than processing it as a single large query. In the profiler you can see the properties of each child query. A child query is made up of streams and additional sub-components.
The types of child query that Query profiler shows typically include the following:
+ **Temp table query**: The text of this child query starts with the `CREATE TEMP TABLE` command. This child query creates temporary tables for other child queries to process.
+ **Statistics query**: Query profiler adds the following comment to the start of this child query to help identify it:
```
-- collect statistics of child query queryID
```
This child query collects information that the Amazon Redshift query engine uses to optimize performance.
**Note**
Query Profiler shows the query that the user provides as the final child query that Amazon Redshift runs.
+ **Streams** – A stream is a collection of segments parceled over available compute-node slices. Each child query is made up of one or more segments. In Query profiler, you can see the properties of each stream, such as its execution time. By glancing through the list of streams, it's likely that you can quickly find performance bottlenecks.
+ **Segments** – A segment is a combination of several steps that a single process can run. A segment is also the smallest compilation unit executable by a compute node slice. A slice is the unit of parallel processing in Amazon Redshift. The segments in a stream run in parallel. Query profiler doesn't show segments graphically, but you can access the segment information for a step in that step's details pane.
+ **Steps** – Each segment is made up of a collection of steps. A step is a piece of work in a query. Steps can include a *hashjoin*, for example, or a *scan*, which is the reading of records from a table.
For more information about streams, segments, and steps, see [ Query planning and execution workflow](https://docs.aws.amazon.com/redshift/latest/dg/c-query-planning.html) in the *Amazon Redshift Database Developer Guide*.
Query profiler displays information returned by the `SYS_QUERY_HISTORY`, `SYS_QUERY_DETAIL`, `SYS_QUERY_EXPLAIN`, and `SYS_CHILD_QUERY_TEXT` views. For more information about these views, see [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY), [SYS\$1QUERY\$1DETAIL](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_DETAIL.html), [SYS\$1QUERY\$1EXPLAIN](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_EXPLAIN.html), and [SYS\$1CHILD\$1QUERY\$1TEXT](https://docs.aws.amazon.com/redshift/latest/dg/SYS_CHILD_QUERY_TEXT.html) in the *Amazon Redshift Database Developer Guide*.
Query profiler only displays query information for queries that have recently run on the database. A query that completes using prepopulated cache data rather than running against the database won't have a query profile if information wasn't previously available for it. This is because Amazon Redshift doesn't generate a query plan for it.
## Prerequisites for using Query profiler
The SYS monitoring views are designed for ease of use and reduced complexity, providing a complete array of metrics for effective monitoring and troubleshooting. The SYS monitoring views also guarantee query history for the past seven days regardless of the size or activity of the cluster. Users only have visibility for queries that they ran, while super users have visibility for queries from all users.
Your IAM user account or role needs permissions to access the **Query and database monitoring** section of the console. This section describes how to add permissions to a user account or role.
Use the following policy to add minimum permissions to your IAM user account or role:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"redshift:DescribeClusters",
"redshift-serverless:ListNamespaces",
"redshift-serverless:ListWorkgroups",
"redshift-data:ExecuteStatement",
"redshift-data:DescribeStatement",
"redshift-data:GetStatementResult"
],
"Resource": [
"arn:aws:redshift-serverless:us-east-1:111122223333:*",
"arn:aws:redshift:us-east-1:111122223333:*"
]
}
]
}
```
------
**Topics**
+ [
### Granting query monitoring permissions for a role
](#using-query-plan-profiler-prereqs-role)
+ [
### Granting query monitoring permissions for a user
](#using-query-plan-profiler-prereqs-user)
+ [
### Temporary credentials using your IAM identity
](#using-query-plan-profiler-prereqs-temp-iam)
### Granting query monitoring permissions for a role
Users with a role that has the `sys:monitor` permission can view all queries. Users with a role that has the `sys:operator` permission can cancel queries, analyze query history, and perform vacuum operations.
**To grant query monitoring permission for a role**
1. Use the following command to provide system monitor access, where *role-name* is the name of the role for which you want to provide access.
```
grant role sys:monitor to "IAMR:role-name";
```
1. (Optional) Use the following command to provide system operator access, where *role-name* is the name of the role for which you want to provide access.
```
grant role sys:operator to "IAMR:role-name";
```
### Granting query monitoring permissions for a user
Users with the `sys:monitor` permission can view all queries. Users with the `sys:operator` permission can cancel queries, analyze query history, and perform vacuum operations.
**To grant query monitoring permission for a user**
1. Use the following command to provide system monitor access, where *user-name* is the name of the user for which you want to provide access.
```
grant role sys:monitor to "IAMR:user-name";
```
1. (Optional) Use the following command to provide system operator access, where *-name* is the name of the user for which you want to provide access.
```
grant role sys:operator to "IAMR:user-name";
```
### Temporary credentials using your IAM identity
This option is only available when connecting to a cluster. With this method, Query Profiler maps a user name to your IAM identity and generates a temporary password to connect to the database as your IAM identity. A user using this method to connect must be allowed IAM permission to `redshift:GetClusterCredentialsWithIAM`. To prevent users from using this method, modify their IAM user or role to deny this permission.
## Accessing Query profiler in the Amazon Redshift console to analyze a query
You can access Query Profiler for either Amazon Redshift serverless or Amazon Redshift provisioned. See the following sections for details:
**Topics**
+ [
### Accessing Query profiler in the Amazon Redshift console for Amazon Redshift Serverless
](#using-query-plan-profiler-accessing-serverless)
+ [
### Accessing Query profiler in the Amazon Redshift console for Amazon Redshift Provisioned
](#using-query-plan-profiler-accessing-provisioned)
### Accessing Query profiler in the Amazon Redshift console for Amazon Redshift Serverless
To access Query profiler for Amazon Redshift Serverless, do the following:
+ Open the Amazon Redshift serverless console.
+ On the navigation pane, under **Monitoring**, choose **Query and database monitoring**.
+ Choose a workgroup.
+ Choose **Queries and database monitoring**.
+ Choose a query.
+ Choose the **Query plan** tab in the **Query details** page.
If a query plan is available, you will see a list of child queries. Choose a query to view it in Query profiler.
### Accessing Query profiler in the Amazon Redshift console for Amazon Redshift Provisioned
To access Query profiler for Amazon Redshift Provisioned, do the following:
+ Open the the Amazon Redshift Provisioned clusters dashboard.
+ Choose a cluster
+ Choose **Query monitoring**.
+ Connect to a database
+ Choose **Queries and database monitoring.**
+ Choose a query.
If a query plan is available, you will see a list of child queries. Choose a query to view it in Query profiler.
## Query profiler user interface
Query profiler uses the following pages to display information about your query:
+ ** [Query details page](#using-query-plan-profiler-ui-query-details) ** – This page displays statistics and child queries for your query.
+ ** [Child query page](#using-query-plan-profiler-ui-child-query) ** – This page displays statistics, streams, and a visual representation of the execution plan for a child query. The console displays this page when you choose a child query from the **Child queries** list in the **Query and database monitoring** page.
### Query details page
![\[Query details interface showing execution time, data returned, and performance breakdown for query 4960.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/metrics_qp_query_details.png)
The Query details page has the following components:
+ **Top pane** – The pane at the top of the page shows details about the query, such as the status and type. For information about the source of the information that the top pane shows, see [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html) in the *Amazon Redshift Database Developer Guide*.
+ **SQL tab** – This tab of the bottom panel shows the SQL text for the original user query.
+ **Query plan tab** – This tab of the bottom panel shows a list of the child queries that Amazon Redshift uses to prepare data and statistics for the user query. By default, the **Child queries** list shows information and aggregated statistics about each child query. For information about the source of the information that this page shows, see [SYS\$1QUERY\$1DETAIL](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_DETAIL.html) in the *Amazon Redshift Database Developer Guide*.
You can add or remove columns from the **Child queries** list using the Preferences menu.
+ **Related metrics** – This tab of the bottom panel shows the following CloudWatch metrics for the query:
+ **RPU capacity used** (for serverless workgroups): The compute capacity used by the query, measured in Redshift Processing Units (RPUs). For more information, see [Compute capacity for Amazon Redshift Serverless](serverless-capacity.md).
+ **Cluster health status**, **CPU Utilization**, **Storage capacity used** (for provisioned clusters): The status and system resources the query used.
+ **Active database connections**: the `DatabaseConnections` metric for the query.
For more information about CloudWatch metrics, see [Performance data in Amazon Redshift](metrics-listing.md).
### Child query page
![\[Query execution plan showing stages from Distribute to Aggregate with execution times.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/metrics_qp_child_query_plan.png)
The Child query page has the following components:
+ **Child queries pulldown** – This control shows the sequence name and the execution time for each child query. You can navigate to other child queries by selecting them in this control.
+ **Side panel** – This panel contains tabs for displaying the child query streams and the child query text.
+ **Child query streams tab** – This tab of the top panel displays the following:
+ **Streams** – This pane shows the list of streams in the child query. This pane shows information and aggregated data about the streams that Amazon Redshift uses to optimize the query. For information about the details in this pane, see [SYS\$1QUERY\$1DETAIL](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_DETAIL.html) in the *Amazon Redshift Database Developer Guide*.
You can add or remove columns from the **Streams** pane using the Preferences menu. You access the Preferences menu using the gear icon in the **Streams** pane.
+ **Child query pane** – A graphical representation of the steps in the child query. For information about the **Child query** pane, see [Child query pane](#using-query-plan-profiler-child-query-pane) following.
+ **Child query text tab** – This tab of the top panel shows the SQL code for the child query.
+ **Child query details pane** – This pane in the right panel shows details about the child query. For information about the details in this pane, see [SYS\$1QUERY\$1DETAIL](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_DETAIL.html) in the *Amazon Redshift Database Developer Guide*.
+ **Stream details pane** – When you choose a stream in the **Streams** pane, the **Stream details** pane shows information about the stream. For information about the details in this panel, see [SYS\$1QUERY\$1DETAIL](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_DETAIL.html) in the *Amazon Redshift Database Developer Guide*.
+ **Step details pane** – When you choose a step in either the **Streams** pane or the graph in the **Child query plan**, the **Step details** pane shows information about the step, For information about the details in this pane, see [SYS\$1QUERY\$1DETAIL](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_DETAIL.html) in the *Amazon Redshift Database Developer Guide*.:
## Child query pane
Query profiler displays the child query in the **Child query** pane as a graphical representation of the steps in the selected child query.
The **Child query** pane displays the run order and the relationships between the steps. For example, if a step joins the output from two other steps, the **Child query** pane shows the step as a tree node with two nodes feeding into it:
![\[Tree diagram showing Hashjoin step with Scan + Item and Hash steps as child nodes.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/metrics_qp_hashjoin.png)
The **Child query** pane doesn't show the streams that contain the steps by default. To show the streams that Amazon Redshift uses to logically partition the steps in the child query, choose **View streams**. When you choose **View streams**, the **Child query** pane shows the steps contained by the query's streams.
The **Child query** pane doesn't show segment information. To see the segment for a step, choose the step. The **Step details** pane then shows the segment for the step.
### Navigation in the Child query pane
In the **Child query** pane, you can choose steps to see detailed information about them. You can also pan and zoom the workspace to better visualize the steps in your query plan.
You can choose nodes, pan, and zoom in the **Child query** plan using the following methods:
+ **Using the mouse** – You can choose nodes, click and drag the workspace to pan, and hold **Ctrl** (Windows) or **CMD** (Mac) and mousewheel to zoom. Choosing a node causes the workspace to zoom and pan to highlight that node. If you choose a stream in the workspace, that stream highlights in the **Streams** list. If you choose a step in the workspace, the **Step details** pane shows information about that step.
+ **Using the zoom and fit controls in the upper left of the workspace** – These controls let you zoom in, zoom out, zoom to fit the entire workspace, and enter fullscreen mode. When you zoom to fit the entire query plan, the workspace centers the query plan both horizontally and vertically.
+ **Using the minimap in the lower right of the workspace** – You can pan or zoom the workspace by using the minimap control in the lower left corner of the workspace.
+ **Choosing a stream in the **Streams** pane** – If you choose a stream in the **Streams** pane, the workspace pans and zooms to show the selected stream, and shows information about the stream in the **Stream details** pane.
+ **Choosing a step in the **Stream details** pane** – If you choose a step in the **Stream details** pane, the workspace pans and zooms to show the selected step, and shows information about the step in the **Step details** pane.
**Note**
When you choose a step, either in the workspace or a different pane, the workspace attempts to zoom and pan such that the selected step is best visible.
When you choose a stream or step from either the workspace or another pane, the workspace will only zoom and pan to that stream or step if you have **Pan & Zoom** selected in the upper right control in the workspace. You can restrict this behavior to panning and zooming, panning only, or no movement by choosing the appropriate setting in the pulldown.
![\[Dropdown menu showing pan and zoom options for workspace navigation control.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/metrics_qp_pan_zoom.png)
## Troubleshooting queries with Query profiler
If you're troubleshooting a query, you can choose a child query to determine which stream uses the highest **Percentage of total query time**. This is a quick way to determine which part of your query should be analyzed further.
After you know which child query is taking the most time, view its steps to see which join or scan might be causing slow performance.
# Query and Database Monitoring
This document describes the Query and Database Monitoring page, an AWS Management Console feature for analyzing the performance of an Amazon Redshift provisioned cluster or serverless workgroup, and the queries run against them.
You can investigate the following scenarios using the Queries and Database Monitoring page:
+ Monitor data warehouse metrics during a specified time period
+ How a query contribues to the overall performance of a data warehouse
+ See a breakdown of a query run time into its life cycle events such as lock wait time, compile time, and execution time
+ Which users run the most resource-intensive queries during a specified time period
+ Monitor how patch events affect query performance
**Topics**
+ [
## Permissions
](#metrics-enhanced-query-monitoring-permissions)
+ [
## Query and Database Monitoring Console
](#metrics-enhanced-query-monitoring-console)
## Permissions
The privileges of the AWS account you use to access the console affects which queries the **Query and Database Monitoring** page shows. By default, you can only view your own queries. To view queries owned by other users, grant the `SYS:MONITOR` role to your account. To allow a user to end running queries from the **Query and Database Monitoring** page, grant the user the `SYS:OPERATOR` privilege.
To automatically assign the `sys:monitor` role to an IAM user or role for Amazon Redshift Serverless or provisioned, run the following commands:
```
create role monitor;
grant role sys:monitor to role monitor;
```
To update the IAM role used for query monitoring, do the following:
1. Choose the **Tags** tab.
1. Choose **Manage tags**.
1. Add a tag with key **RedshiftDbRoles** and value **monitor**.
1. Save changes
To add database credentials to a user, run the following command:
```
grant role sys:monitor to
```
For information about using the GRANT command, see [GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html) in the *Amazon Redshift Database Developer Guide*.
To use query monitoring, your IAM user needs permissions to access the Amazon Redshift data plane. Ensure that your IAM user has the following permissions in their permissions policy:
```
{
"Sid": "DataAPIPermissions",
"Action": [
"redshift-data:ExecuteStatement",
"redshift-data:CancelStatement",
"redshift-data:GetStatementResult",
"redshift-data:DescribeStatement",
"redshift-data:ListDatabases"
],
"Effect": "Allow",
"Resource": "arn:aws:redshift-serverless:us-west-2:123456789012:workgroup/01234567-89ab-cdef-0123-456789abcdef"
},
```
### Temporary credentials using your IAM identity
This option is only available when connecting to a cluster. With this method, Query and Database Monitoring maps a user name to your IAM identity and generates a temporary password to connect to the database as your IAM identity. A user using this method to connect must be allowed IAM permission to `redshift:GetClusterCredentialsWithIAM`. To prevent users from using this method, modify their IAM user or role to deny this permission.
## Query and Database Monitoring Console
This section describes using the Query and Database Monitoring console page.
You can use the Query and Database Monitoring console to quickly get an overview of your data warehouse's performance. You can monitor your data warehouse's performance over time, and examine the performance of a data warehouse's provisioned clusters or individual queries, so as to best identify bottlenecks and other areas to improve.
The **Query and Database Monitoring** page has the following features:
+ **Increased security** — You need elevated privileges to monitor queries for other users. For more information, see [Permissions](#metrics-enhanced-query-monitoring-permissions).
+ **Seven-day query history** — Guaranteed access to seven days of query history
+ **Query monitoring** — You can monitor queries in provisioned clusters and serverless workgroups at the user query level.
+ **Query trend analysis** — You can compare the performance of similar queries that match specified criteria.
To access the Query and Database Monitoring page, do the following:
1. Sign in to the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Choose **Query and database monitoring** from the navigation pane.
The **Query and database monitoring** console page appears as follows:
![\[Query and database monitoring dashboard showing data warehouse overview, performance summary, and profiler sections.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/metrics_eqm_homepage.png)
The **Query and database monitoring** page has the following components:
+ **Data warehouse overview** — Monitor the average query performance for your provisioned clusters and serverless workgroups. You can quickly see performance issues for a specific cluster or workgroup by examining the statistics on this page for spikes or periods of high activity.
+ **Query performance summary** — Monitor the average query performance for a specific provisioned cluster or serverless workgroup. You can also acccess the **Query performance summary** page by clicking on one of the clusters or workgroups in the **Data warehouse overview** list.
**Topics**
+ [
### Query performance summary
](#metrics-enhanced-query-monitoring-console-summary)
+ [
### Query details
](#metrics-enhanced-query-monitoring-console-query-details)
+ [
### Query pattern
](#metrics-enhanced-query-monitoring-console-query-pattern)
### Query performance summary
When you choose **Query performance summary** from the **Query and database monitoring** page, or a cluster or workgroup from the **Data warehouse overview** page, the console shows a summary of the performance for an individual provisioned cluster or serverless workgroup.
![\[Query and database monitoring interface showing performance graph and query history for redshift-cluster-1.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/metrics_eqm_clusterdetails.png)
This page has the following components:
+ **Cluster or workgroup dropdown** — Choose the cluster or workgroup you want to analyze.
+ **Data warehouse performance** — This pane shows a history of the cluster or workgroup within the specified time period, showing the amount of time spent on each phase of queries. If you see a spike in a certain query phase, such as the increased planning and execution time on January 20 in the preceding graphic, you can use this information to identify issues with the performance of your queries. The default time period shown is the last seven days, but you can adjust the time period according to your analysis needs.
+ **Query history** — This pane shows a history of the performance of every query run within the specified filters. You can use this information to troubleshoot the performance of an individual query. To further analyze a specific query, you can choose it from this graph or from the **Data warehouse performance** graph.
When you hover over a data point on the chart, a popup appears. This popup displays the breakdown of time metrics for that data point. If a data point contains query data, you can choose **Drill down** to update the time range of the chart to the next smallest time unit of the data point. These time units are as follows:
+ Day
+ Hour
+ 15 minutes
+ 5 minutes
+ 1 minute
For example, if you choose **Drill down** on a data point, the range of the graph changes to one day. Choosing **Drill down** again changes the range of the graph to one hour.
+ **Query profiler** — A graphical tool for monitoring query performance. For more information, see [Query profiler](using-query-plan-profiler.md).
### Query details
When you choose a query from the **Data warehouse performance** or **Query history** pane of the cluster or workgroup detail page, the **Query details** page opens.
![\[Query details page showing query information, elapsed time breakdown, and SQL details.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/metrics_eqm_querydetails.png)
For information about the **Query details** page, see [Query details page](using-query-plan-profiler.md#using-query-plan-profiler-ui-query-details).
### Query pattern
You can see a history of queries with the same pattern by choosing the **View query pattern** button in the **Query history** pane of the **Query performance summary** page. The **Query pattern** page shows all of the queries from the past week that are retrieved by a SQL statement that you specify.
![\[Query pattern page showing performance trend graph and history table of queries.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/metrics_eqm_querypattern.png)
The **Query pattern** page has the following components:
+ **Query pattern** — The SQL statement that retrieves the queries being analyzed.
+ **Query performance trend analysis** — A bar graph showing the elapsed time of all the queries that the query pattern selects. The results are grouped by day.
+ **History of queries with the same pattern** — The time taken for each phase of the queries that the query pattern selects.
Using the **Query pattern** page, you can gain the following insights:
+ Trends for queries that run at a specific time every day
+ Spikes in run time for queries that you run regularly against the data warehouse.
# Sys View-based Queries and Database Monitoring
This document describes the `SYS` views that provide data for the Queries and Database Monitoring page in the Amazon Redshift Console, a tool for analyzing a query's components and performance. For information about the Queries and Database Monitoring page, see [Query and Database Monitoring](metrics-enhanced-query-monitoring.md).
The **Queries and Database Monitoring** page has a functionality that displays information provided by `SYS` views. The console view includes the query profiler, which shows the graphical execution plan of a query. To switch to the `SYS`-based view, follow the steps here to grant the right access and permissions for the new **Queries and Database Monitoring** page.
The `SYS`-based view feature of the **Queries and Database Monitoring** page has the following functionality:
+ **Increased security** — You need elevated privileges to monitor queries for other users
+ **Seven-day query history** — Guaranteed access to seven days of query history
+ **Query profiler** — A graphical tool for monitoring query performance. For more information, see [Query profiler](using-query-plan-profiler.md)
By default, you can only view your own queries. To view queries owned by other users, grant the `SYS:MONITOR` role to your account. To allow a user to end running queries, grant the user the `SYS:OPERATOR` privilege.
To grant the privilege to view queries owned by all users to a database user or role, run the following commands:
```
grant role sys:monitor to "IAM:role-name";
grant role sys:monitor to "IAM:user-name";
```
To automatically assign the `sys:monitor` role to an IAM user or role for Amazon Redshift Serverless or provisioned, run the following commands:
```
create role monitor;
grant role sys:monitor to role monitor;
```
To update the IAM role used for query monitoring, do the following:
1. Choose the **Tags** tab.
1. Choose **Manage tags**.
1. Add a tag with key **RedshiftDbRoles** and value **monitor**.
1. Save changes
To add database credentials to a user, run the following command:
```
grant role sys:monitor to
```
## Permissions
To use query monitoring, your IAM user needs permissions to access the Amazon Redshift data plane. Ensure that your IAM user has the following permissions in their permissions policy:
```
{
"Sid": "DataAPIPermissions",
"Action": [
"redshift-data:ExecuteStatement",
"redshift-data:CancelStatement",
"redshift-data:GetStatementResult",
"redshift-data:DescribeStatement",
"redshift-data:ListDatabases"
],
"Effect": "Allow",
"Resource": "arn:aws:redshift-serverless:us-west-2:123456789012:workgroup/01234567-89ab-cdef-0123-456789abcdef"
},
```
## Connect to the database
Before using the enhanced query monitoring feature, you must first connect to your database for access to `SYS` view-based information. To connect to the database, use one of the following credentials:
+ Username and password
+ Temporary credentials associated with your IAM role
+ A database user
Note the following about using enhanced query monitoring:
+ For provisioned clusters, you must connect to a database, because enhanced query monitoring uses `SYS` views. These views have increased security, and require elevated privileges to access data about queries owned by other users.
+ When using the `SYS` view-based queries and database monitoring page, only your `user_id` is visible if your user account doesn't have the database superuser role. Usernames are hidden from non-superusers.
+ As part of the sys view-based queries and database monitoring page experience, the query execution process ID (`p_id`) appears under the column heading `session_id`.