AWS redshift documentation change
Summary
Expanded documentation about maintenance tracks (including preview tracks), added section for managing usage limits with cost control actions, updated RA3 node type guidance, and restructured sections for clarity
Security assessment
Changes focus on operational management (maintenance tracks, version rollbacks) and cost control (usage limits). While usage limits help prevent unexpected costs, there's no explicit mention of security vulnerabilities or security-specific features. The updates are operational/cost management improvements rather than security fixes or security feature documentation.
Diff
diff --git a/redshift/latest/mgmt/managing-cluster-considerations.md b/redshift/latest/mgmt/managing-cluster-considerations.md index 73066731d..8f2813f73 100644 --- a/redshift/latest/mgmt/managing-cluster-considerations.md +++ b/redshift/latest/mgmt/managing-cluster-considerations.md @@ -5 +5 @@ -Region and Availability Zone considerationsCluster maintenance +Region and Availability Zone considerationsCluster maintenanceManaging usage limitsUnderstanding how RA3 nodes separate compute and storageRA3 node type availability in AWS RegionsUpgrading to RA3 node typesNetworking features supported by RA3 nodes @@ -137 +137 @@ For more information about cluster maintenance, see the following documentation: -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. +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 approved release or to the previous release. @@ -139 +139 @@ When Amazon Redshift releases a new cluster version, your cluster is updated dur -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. +The maintenance 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. To set the maintenance track for the cluster, specify one of the following values: @@ -141 +141 @@ The track controls which cluster version is applied during a maintenance window. -For information about cluster tracks, see [Tracks for Amazon Redshift provisioned clusters and serverless workgroups](./tracks.html). + * **Current** – Use the most current approved cluster version. @@ -143 +143,151 @@ For information about cluster tracks, see [Tracks for Amazon Redshift provisione -### Understanding how RA3 nodes separate compute and storage + * **Trailing** – Use the cluster version before the current version. + + * **Preview** – Use the cluster version that contains new features available for preview. + + + + +For example, suppose that your cluster is currently running version 1.0.2762 and the Amazon Redshift current version is 1.0.3072. If you set the maintenance track value to **Current** , your cluster is updated to version 1.0.3072 (the next approved release) during the next maintenance window. If you set the maintenance track value to **Trailing** , your cluster isn't updated until there is a new release after 1.0.3072. + +**Preview tracks** + +A **Preview** track might not always be available to choose. When you choose a **Preview** track, a track name must also be selected. Preview tracks and its related resources are temporary, have functional limitations, and might not contain all current Amazon Redshift features available in other tracks. When working with preview tracks: + + * Use the new Amazon Redshift console when working with preview tracks. For example, when you create a cluster to use with preview features. + + * You can't switch a cluster from one preview track to another. + + * You can't switch a cluster to a preview track from a current or trailing track. + + * You can't switch a cluster from a preview track to a current or trailing track. + + * You can't restore from a snapshot created from a different preview track. + + * You can only use the preview track when creating a new cluster, or when restoring from a snapshot. + + * You can't restore from a snapshot created from a different preview track, or with a cluster maintenance version later than the preview track cluster version. For example, when you restore a cluster to a preview track, you can only use a snapshot created from an earlier cluster maintenance version than that of the preview track. + + + + +**Switching between maintenance tracks** + +Changing tracks for a cluster is generally a one-time decision. You should exercise caution in changing tracks. If you change the maintenance track from **Trailing** to **Current** , we will update the cluster to the **Current** track release version during the next maintenance window. However, if you change the cluster's maintenance track to **Trailing** we won't update your cluster until there is a new release after the **Current** track release version. + +**Maintenance tracks and restore** + +A snapshot inherits the source cluster's maintenance track. If you change the source cluster's maintenance track after you take a snapshot, the snapshot and the source cluster are on different tracks. When you restore from the snapshot, the new cluster will be on the maintenance track that was inherited from the source cluster. You can change the maintenance track after the restore operation completes. Resizing a cluster doesn't affect the cluster's maintenance track. + +### Managing cluster versions + +A maintenance track is a series of releases. You can decide if your cluster is on the **Current** track or the **Trailing** track. If you put your cluster on the **Current** track, it will always be upgraded to the most recent cluster release version during its maintenance window. If you put your cluster on the **Trailing** track, it will always run the cluster release version that was released immediately before the most recently released version. + +The **Release status** column in the Amazon Redshift console list of clusters indicates whether one of your clusters is available for upgrade. + +### Rolling back the cluster version + +If your cluster is up to date with the latest cluster version, you can choose to roll it back to the previous version. + +###### To roll back to a previous cluster 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/). + + 2. On the navigation menu, choose **Clusters**. + + 3. Choose the cluster to roll back. + + 4. For **Actions** , choose **Roll back cluster version**. The **Roll back cluster version** page appears. + + 5. If there is a version available for roll back, follow the instructions on the page. + + 6. Choose **Roll back now**. + + + + +### Determining the cluster maintenance version + +You can determine the Amazon Redshift engine and database version with the Amazon Redshift console. + +###### To find the version of 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/). + + 2. 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. + + 3. Choose the **Maintenance** tab for more details. + + 4. In the **Maintenance** section, find **Current cluster version**. + + + + +###### Note + +Although the console displays this information in one field, it's two parameters in the Amazon Redshift API, `ClusterVersion` and `ClusterRevisionNumber`. For more information, see [Cluster](https://docs.aws.amazon.com/redshift/latest/APIReference/API_Cluster.html) in the _Amazon Redshift API Reference_. + +## Managing usage limits in Amazon Redshift + +You can define limits to monitor and control your usage and associated cost of some Amazon Redshift features. You can create daily, weekly, and monthly usage limits, and define actions that Amazon Redshift automatically takes if those limits are reached. Actions include such things as logging an event to a system table to record usage exceeding your defined limits. Other possible actions include raising alerts with Amazon SNS and Amazon CloudWatch to notify an administrator and disabling further usage to control costs. + +You can define usage limits for each cluster. After your cluster is created, you can define usage limits for the following features: + + * Amazon Redshift Spectrum + + * Amazon Redshift Concurrency Scaling + + * Amazon Redshift cross-Region datasharing + + + + +Usage limits are available with release version 1.0.14677 or later in the AWS Regions where Amazon Redshift Spectrum and Amazon Redshift Concurrency Scaling are available. + +A Redshift Spectrum limit specifies the threshold of the total amount of data scanned in 1-TB increments. A concurrency scaling limit specifies the threshold of the total amount of time used by concurrency scaling in 1-minute increments. A cross-Region datasharing limit specifies the threshold of the total amount of data scanned in 1-TB increments. + +A limit can be specified for a daily, weekly, or monthly period (using UTC to determine the start and end of the period). If you create a limit in the middle of a period, then the limit is measured from that point to the end of the period. For example, if you create a monthly limit on March 15, then the first monthly period is measured from March 15 through March 31. + +You can define multiple usage limits for each feature. Each limit can have a different action. Possible actions include the following: + + * **Log to system table** – This is the default action. Information is logged to the STL_USAGE_CONTROL table. Logging is helpful when evaluating past usage and in deciding on future usage limits. For more information about what is logged, see [STL_USAGE_CONTROL](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_USAGE_CONTROL.html) in the _Amazon Redshift Database Developer Guide_. + + * **Alert** – Amazon Redshift emits CloudWatch metrics for available and consumed usage. You can define up to three usage limits for each feature. If you enable the alert action using the Amazon Redshift console, a CloudWatch alarm is automatically created on these metrics. You can optionally attach an Amazon SNS subscription to that alarm. If you are using an AWS CLI or API operation, make sure that you create the CloudWatch alarm manually. When the threshold is reached, events are also logged to a system table. + + * **Disable feature** – When the threshold is reached, Amazon Redshift disables the feature until the quota is refreshed for the next time period (daily, weekly, or monthly). Only one limit for each feature can have the disable action. Events are also logged to a system table, and alerts can be emitted. + + + + +Usage limits persist until the usage limit definition itself or the cluster is deleted. + +You can define and manage usage limits with the new Amazon Redshift console, the AWS CLI, or with Amazon Redshift API operations. To define a limit on the Amazon Redshift console, navigate to your cluster and choose **Configure usage limit** for **Actions**. To view previously defined usage limits for your cluster, navigate to your cluster, and choose the **Maintenance** tab, **Usage limits** section. To view the amount of usage available and consumed for your cluster, navigate to your cluster. Choose the **Cluster performance** tab, then view the graphs for the usage consumed for a feature. + +You can use the following Amazon Redshift CLI operations to manage usage limits. For more information, see the _AWS CLI Command Reference_. + + * [create-usage-limit](https://docs.aws.amazon.com/cli/latest/reference/redshift/create-usage-limit.html) + + * [describe-usage-limits](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-usage-limits.html) + + * [modify-usage-limit](https://docs.aws.amazon.com/cli/latest/reference/redshift/modify-usage-limit.html) + + * [delete-usage-limit](https://docs.aws.amazon.com/cli/latest/reference/redshift/delete-usage-limit.html) + + + + +You can use the following Amazon Redshift API operations to manage usage limits. For more information, see the _Amazon Redshift API Reference_. + + * [CreateUsageLimit](https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateUsageLimit.html) + + * [DescribeUsageLimits](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeUsageLimits.html) + + * [ModifyUsageLimit](https://docs.aws.amazon.com/redshift/latest/APIReference/API_ModifyUsageLimit.html) + + * [DeleteUsageLimit](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DeleteUsageLimit.html) + + + + +To learn how to create and monitor usage limits using the Amazon Redshift console, watch the following video. + +## Understanding how RA3 nodes separate compute and storage @@ -147 +297 @@ These sections detail tasks available for RA3 node types, showing their applicab -#### Advantages and availability of RA3 nodes +### Advantages and availability of RA3 nodes @@ -177 +327 @@ To use RA3 node types, your AWS Region must support RA3. For more information, s -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.html#cluster-version). +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 cluster maintenance version. @@ -181 +331 @@ Make sure that you use the new Amazon Redshift console when working with RA3 nod -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. +In addition, to use RA3 node types with Amazon Redshift operations that use the maintenance track, the maintenance track value must be set to a cluster version that supports RA3. For more information about maintenance tracks, see Choosing cluster maintenance tracks. @@ -198 +348 @@ Consider the following when using single-node RA3 node types. -##### Working with Amazon Redshift managed storage +#### Working with Amazon Redshift managed storage @@ -204 +354 @@ For information about storage costs, see [Amazon Redshift pricing](https://aws.a -##### Managing RA3 node types +#### Managing RA3 node types @@ -217 +367 @@ To change the number of nodes of Amazon Redshift cluster with an RA3 node type, -### RA3 node type availability in AWS Regions +## RA3 node type availability in AWS Regions @@ -296 +446 @@ The RA3 node types are available only in the following AWS Regions: -### Upgrading to RA3 node types +## Upgrading to RA3 node types @@ -327 +477 @@ The minimum number of nodes for some RA3 node types is 2 nodes. Take this into c -### Networking features supported by RA3 nodes +## Networking features supported by RA3 nodes