Billing for Amazon Redshift Serverless - Amazon Redshift
Billing for compute capacityBilling for storage Using the Amazon Redshift Serverless free trialBilling usage notes
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Billing for Amazon Redshift Serverless

The following sections provide details on how billing works for Amazon Redshift Serverless. For pricing information, see Amazon Redshift pricing

Billing for compute capacity

Base capacity and its effect on billing

When queries run, you're billed according to the capacity used in a given duration, in RPU hours on a per-second basis. When no queries are running, you aren't billed for compute capacity. You are also charged for Redshift Managed Storage (RMS), based on the amount of data stored.

When you create your workgroup, you have the option to set the Base capacity for computing. To meet the price/performance requirements of your workload at a workgroup level, adjust the base capacity higher or lower for an existing workgroup. Select the workgroup from Workgroup configuration and choose the Limits tab to change the base capacity using the console.

As the number of queries increases, Amazon Redshift Serverless scales automatically to provide consistent performance.

Maximum RPU hours usage limit

To keep costs predictable for Amazon Redshift Serverless, you can set the Maximum RPU hours used per day, per week, or per month. You can set it using the console or with the API. When a limit is reached, you can specify that a log entry is written to a system table, or you receive an alert, or user queries are turned off. Setting the maximum RPU hours helps keep your cost under control. Settings for maximum RPU hours apply to your workgroup for both queries that access data in your data warehouse and queries that access external data, such as in an external table in Amazon S3.

The following is an example:

Assume you set a limit for 100 hours for each week. To do this on the console, you do the following:

  1. Choose your workgroup and then choose Manage usage limits under the Limits tab.

  2. Add a usage limit, choosing the Weekly frequency, a duration of 100 hours, and the setting the action to Turn off user queries.

In this example, if you reach the 100 RPU hour limit for a week, queries are turned off.

Setting the maximum RPU hours for the workgroup doesn't limit the performance or compute resources for the workgroup. You can adjust the settings at any time with no affect on query processing. The goal for setting maximum RPU hours is to help you meet your price and performance requirements. For more information about serverless billing, see Amazon Redshift pricing.

Another way to keep the cost for Amazon Redshift Serverless predictable is to use Amazon Cost Anomaly Detection to reduce the chance for billing surprises and provide more control.

Note

The Amazon Redshift pricing calculator is helpful for estimating pricing. You enter the compute resources you need and it provides a preview of the cost.

Setting Max capacity to control costs for compute resources

The Max capacity setting serves as the RPU ceiling that Amazon Redshift Serverless can scale up to. It helps control your cost for compute resources. In a similar way to how base capacity sets a minimum amount of compute resources available, Max capacity sets a ceiling on RPU usage. That way, it helps your spending adhere to your plans. Max capacity applies specifically to each workgroup and it limits compute usage at all times.

How Max capacity differs from RPU hour usage limits

The purpose of both maximum RPU hour limits and the Max capacity setting is to control cost. But they achieve this through different means. The following points explain the difference:

  • Max capacity – This setting establishes the highest count of RPUs that Amazon Redshift Serverless uses for scaling purposes. When automatic compute scaling is required, having a higher value for Max capacity can enhance query throughput. When the Max capacity limit is reached, the workgroup doesn't scale up resources any further.

  • Maximum RPU hours usage limit – Unlike Max capacity, this setting doesn't set a ceiling on capacity. But it does perform other actions to help you limit costs. These include adding an entry to a log, notifying you, or stopping queries from running, if you choose.

You can use Max capacity exclusively, or you can compliment it with actions from maximum RPU hour usage limits.

A Max capacity use case

Each workgroup can have a different Max capacity setting. It helps you enforce budgeting requirements. To illustrate how this works, assume the following:

  • You have a workgroup with the base capacity set to 256 RPUs. You have steady workloads at just over 256 RPUs for most of the month.

  • Max capacity is set to 512 RPUs.

Assume you have unexpected high use over a three-day period to generate ad-hoc statistical reports. In this case, you have Max capacity set to avoid compute costs beyond those for 512 RPUs. When you do this, you can be sure that compute capacity won't exceed this upper bound.

Usage notes for Max capacity

These notes can help you set Max capacity appropriately:

  • Each Amazon Redshift Serverless workgroup can have a different Max capacity setting.

  • If you have a period of very high resource usage and Max capacity is set to a low RPU level, it can delay workload processing and result in a user experience that isn't optimal.

  • Configuring the Max capacity setting doesn't interfere with running queries, even during times of high RPU usage. It doesn't work like a usage limit, which can stop queries from running. It only limits compute resources available to the workgroup. You can view capacity used over a period of time on the Amazon Redshift Serverless dashboard. For more information about viewing summary data, see Checking Amazon Redshift Serverless summary data using the dashboard.

  • The top Max capacity setting is 5632 RPUs.

How to set Max capacity

You can set Max capacity in the console. For an existing workgroup, you can change the setting under Workgroup configuration. You can also use the CLI to set it by using a command like the following sample:

aws redshift-serverless update-workgroup --workgroup-name myworkgroup --max-capacity 512

This sets the Max capacity setting for the workgroup with the given name. After setting it, you can check the value on the console to verify it. You can also check the value using the CLI by running the get-workgroup command.

You can turn off the Max capacity setting by setting it to -1, like the following:

aws redshift-serverless update-workgroup --workgroup-name myworkgroup --max-capacity -1

Monitoring Amazon Redshift Serverless usage and cost

There are several ways you can estimate usage and billing for Amazon Redshift Serverless. System views can be helpful because the system metadata, including query and usage data, is timely and you don't have to do any setup to query it. CloudWatch can also be useful for monitoring usage for your Amazon Redshift Serverless instance, and has additional features to provide insights and set actions.

Visualizing usage by querying a system view

Query the SYS_SERVERLESS_USAGE system table to track usage and get the charges for queries:

select trunc(start_time) "Day", 
(sum(charged_seconds)/3600::double 
precision) * <Price for 1 RPU> as cost_incurred 
from sys_serverless_usage 
group by 1 
order by 1

This query provides the cost per day incurred for Amazon Redshift Serverless, based on usage.

Usage notes for determining usage and cost

  • You pay for the workloads you run in RPU-hours on a per-second basis, with a 60-second minimum charge.

  • Records from the sys_serverless_usage system table show cost incurred in 1-minute time intervals. Understanding the following columns is important:

    The charged_seconds column:

    • Provides the compute unit (RPU) seconds that were charged during the time interval. The results include any minimum charges in Amazon Redshift Serverless.

    • Has information about compute-resource usage after transactions complete. Thus, this column value may be 0 if transactions haven't finished.

    The compute_seconds column:

    • Provides real-time compute usage information. This doesn't include any minimum charges in Amazon Redshift Serverless. Thus it can differ to some degree from the charged seconds billed during the interval.

    • Shows usage information during each transaction (even if a transaction hasn’t ended), and hence the data provided is real-time.

  • There are situations where compute_seconds is 0 but charged_seconds is greater than 0, or vice versa. This is normal behavior resulting from the way data is recorded in the system view. For a more accurate representation of serverless usage details, we recommend aggregating the data in SYS_SERVERLESS_USAGE.

For more information about monitoring tables and views, see Monitoring queries and workloads with Amazon Redshift Serverless.

Visualizing usage with CloudWatch

You can use the metrics available in CloudWatch to track usage. The metrics generated for CloudWatch are ComputeSeconds, indicating the total RPU seconds used in the current minute and ComputeCapacity, indicating the total compute capacity for that minute. Usage metrics can also be found on the Redshift console on the Redshift Serverless dashboard. For more information about CloudWatch, see What is Amazon CloudWatch?

Billing for storage

Primary storage capacity is billed as Redshift Managed Storage (RMS). Storage is billed by GB / month. Storage billing is separate from billing for compute capacity. Storage used for user snapshots is billed at the standard backup billing rates, depending on your usage tier.

Data transfer costs and machine learning (ML) costs apply separately, the same as provisioned clusters. Snapshot replication and data sharing across Amazon Regions are billed at the transfer rates outlined on the pricing page. For more information, see Amazon Redshift pricing.

Visualizing billing usage with CloudWatch

The metric SnapshotStorage, which tracks snapshot storage usage, is generated and sent to CloudWatch. For more information about CloudWatch, see What is Amazon CloudWatch?

Using the Amazon Redshift Serverless free trial

Amazon Redshift Serverless offers a free trial. If you participate in the free trial, you can view the free trial credit balance in the Redshift console, and check free trial usage in the SYS_SERVERLESS_USAGE system view. Note that billing details for free trial usage does not appear in the billing console. You can only view usage in the billing console after the free trial ends. For more information about the Amazon Redshift Serverless free trial, see Amazon Redshift Serverless free trial.

Billing usage notes

  • Recording usage - A query or transaction is only metered and recorded after the transaction completes, is rolled back, or stopped. For instance, if a transaction runs for two days, RPU usage is recorded after it completes. You can monitor ongoing use in real time by querying sys_serverless_usage. Transaction recording may reflect as RPU usage variation and effect costs for specific hours and for daily use.

  • Writing explicit transactions - It's important as a best practice to end transactions. If you don't end or roll back an open transaction, Amazon Redshift Serverless continues to use RPUs. For example, if you write an explicit BEGIN TRAN, it's important to have corresponding COMMIT and ROLLBACK statements.

  • Cancelled queries - If you run a query and cancel it before it finishes, you are still billed for the time the query ran.

  • Scaling - The Amazon Redshift Serverless instance may initiate scaling for handling periods of higher load, in order to maintain consistent performance. Your Amazon Redshift Serverless billing includes both base compute and scaled capacity at the same RPU rate.

  • Scaling down - Amazon Redshift Serverless scales up from its base RPU capacity to handle periods of higher load. In some cases, RPU capacity can remain at a higher setting for a period after query load falls. We recommend that you set maximum RPU hours in the console to guard against unexpected cost.

  • System tables - When you query a system table, the query time is billed.

  • Redshift Spectrum - When you have Amazon Redshift Serverless, and you run queries, there isn't a separate charge for data-lake queries. For queries on data stored in Amazon S3, the charge is the same, by transaction time, as queries on local data.

  • Federated queries - Federated queries are charged in terms of RPUs used over a specific time interval, in the same manner as queries on the data warehouse or data lake.

  • Storage - Storage is billed separately, by GB / month.

  • Minimum charge - The minimum charge is for 60 seconds of resource usage, metered on a per-second basis.

  • Snapshot billing - Snapshot billing doesn't change. It's charged according to storage, billed at a rate of GB / month. You can restore your data warehouse to specific points in the last 24 hours at a 30 minute granularity, free of charge. For more information, see Amazon Redshift pricing.

Amazon Redshift Serverless best practices for keeping billing predictable

The follwing are best practices and built-in settings that help keep your billing consistent.

  • Make sure to end each transaction. When you use BEGIN to start a transaction, it's important to END it as well.

  • Use best-practice error handling to respond gracefully to errors and end each transaction. Minimizing open transactions helps to avoid unnecessary RPU use.

  • Use SESSION TIMEOUT to help end open transactions and idle sessions. It causes any session kept idle or inactive for more than 3600 seconds (1 hour) to time out. It causes any transaction kept open and inactive for more than 21600 seconds (6 hours) to time out. This timeout setting can be changed explicitly for a specific user, such as when you want to keep a session open for a long-running query. The topic CREATE USER shows how to adjust SESSION TIMEOUT for a user.

    • In most cases, we recommend that you don't extend the SESSION TIMEOUT value, unless you have a use case that requires it specifically. If the session remains idle, with an open transaction, it can result in a case where RPUs are used until the session is closed. This will result in unnecessary cost.

    • Amazon Redshift Serverless has a maximum time of 86,399 seconds (24 hours) for a running query. The maximum period of inactivity for an open transaction is six hours before Amazon Redshift Serverless ends the session associated with the transaction. For more information, see Quotas for Amazon Redshift Serverless objects.