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/).
# Billing for Amazon Redshift Serverless
## Billing for compute capacity
You can purchase capacity for Amazon Redshift Serverless in two ways:
+ **You can purchase on-demand capacity** – When you choose on-demand compute capacity, you pay for resources as you go. This is the best choice if you're just beginning to use Amazon Redshift Serverless or if you don't have a good sense yet of your steady usage patterns. On-demand offers the most flexibility. For more information, see [Billing for on-demand compute capacity](serverless-billing-on-demand.md).
+ **You can purchase reservations** – A reservation provides a discount when you buy a preset amount of compute resources for a specific amount of time, for example for a year. It's a good idea when you know you're going to use an amount of capacity steadily. It's helpful for saving money when you can forecast some of your capacity needs. For more information, see [Billing for serverless reservations](serverless-billing-reserved.md).
You can use reservations and on-demand resources together. It isn't required that you use one or the other.
For detailed pricing information, see [Amazon Redshift pricing](https://aws.amazon.com/redshift/pricing/).
# Billing for on-demand 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.
1. 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](https://aws.amazon.com/redshift/pricing/).
Another way to keep the cost for Amazon Redshift Serverless predictable is to use AWS [Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) to reduce the chance for billing surprises and provide more control.
**Note**
The [Amazon Redshift pricing calculator](https://calculator.aws/#/addService/Redshift) 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](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-dashboard.html).
+ 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\$1SERVERLESS\$1USAGE system table to track usage and get the charges for queries:
```
select trunc(start_time) "Day",
(sum(charged_seconds)/3600::double
precision) * 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\$1serverless\$1usage system table show cost incurred in 1-minute time intervals. Understanding the following columns is important:
The charged\$1seconds 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\$1seconds 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\$1seconds is 0 but charged\$1seconds 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\$1SERVERLESS\$1USAGE.
For more information about monitoring tables and views, see [Monitoring queries and workloads with Amazon Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-monitoring.html).
### 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?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
# Billing for serverless reservations
Amazon Redshift Serverless allows you to run and scale analytics without having to provision and manage clusters with a pay-as-you-go pricing model. Now with serverless reservations, you can further optimize your compute costs and improve cost predictability of existing and new workloads on Redshift Serverless.
Amazon Redshift manages serverless reservations at the AWS payer account level, and reservations can be shared between multiple AWS accounts, letting you reduce your compute costs by up to 24% on all Redshift Serverless workloads in your AWS account. Amazon Redshift bills serverless reservations hourly and meters reservations per second, offering a consistent billing model, 24 hours a day, seven days a week, while maintaining flexibility offered by Redshift Serverless. Amazon Redshift charges any usage exceeding the specified RPU level is at standard on-demand rates.
**Note**
If you want to limit on-demand usage, you can use the **Max capacity** setting to set resource-usage limits for your workgroups. For more information, see [Billing for Amazon Redshift Serverless](serverless-billing.md).
## Benefits of serverless reservations
Serverless reservations are a discounted pricing option for Amazon Redshift Serverless. Serverless reservations give you the option to commit to a specified number of Redshift Processing Units (RPUs) for a year at a discount from on-demand (OD) rates, with no upfront payment. You can receive a greater discount with an upfront payment. With serverless reservations, you can optimize your compute costs and improve cost predictability of existing and new workloads on Serverless.
Each serverless reservation is purchased at the AWS account level and can be shared between multiple Amazon Redshift Serverless workgroups in the same payer account. This gives you flexibility in how the discount is applied. Multiple workgroups with different workload patterns can share the reservation.
## How a serverless reservation works
Reserving RPUs is a simple process that takes only a few minutes to complete. It includes specifying the RPU level to reserve and the payment type. Amazon Redshift Serverless uses the standard AWS billing and cost management tool that helps you determine the reservation level you need and to monitor your usage continuously. Serverless reservations are managed at the AWS payer account level and can be shared under the same payer account, and let you reduce your compute costs by up to 24% on all Redshift Serverless workloads in your AWS account. Serverless reservations are billed hourly and metered per second, offering a consistent billing model, 24 hours a day, seven days a week, while maintaining flexibility offered by Redshift Serverless. Any usage exceeding the specified RPU level is charged at standard Redshift Serverless on-demand rates.
You can purchase multiple serverless reservations within the same AWS account. When you purchase additional serverless reservations, they layer on each other. For instance, if you purchase two reservations and choose 100 RPUs for each, it gives you a total of 200 RPUs at a discounted rate.
**Note**
If you want to set a limit for on-demand usage, you can set the maximum RPUs in the Amazon Redshift Serverless console for a workgroup by choosing the **Limits** tab and then selecting **Manage usage limits**.
After you purchase a serverless reservation, it goes into effect immediately and shows up in the Redshift console in the Serverless reservations dashboard.
## Analyzing your RPU (Redshift Processing Unit) use to determine the reservation level you need
Redshift Serverless Reservations let you lock in predictable, lower compute costs by committing to a specific number of Redshift Processing Units (RPUs) for one year, giving you discounts over on-demand pricing. These discounts can be up to 20 percent with the no-upfront option, or up to 24 percent when you pay all-upfront. You purchase Redshift Serverless Reservations at the AWS payer-account level, and your savings automatically apply to any Redshift Serverless workgroup in any AWS linked account, so you can centrally manage budgets while supporting multiple teams. Redshift Serverless meters the usage at per-second granularity, averaged across each hour, and then billed hourly, ensuring you pay only for the capacity you use. Redshift Serverless Reservations combine flexible application across accounts with term-based savings, giving you predictable analytics prices without sacrificing the agility of Redshift Serverless.
### Analyzing RPU Use for Reservations
You can determine your RPU usage levels in one of two ways: You can use the Redshift Serverless dashboard for a seven-day view, or use Cost Explorer for long term analysis. The following procedures demonstrate how to analyze your RPU use:
**Method 1: Redshift Serverless Dashboard (7-day view)**
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. Open the Serverless dashboard.
1. Choose your workgroup.
1. View RPU capacity usage for a period in length from the last hour up to one week.
**Method 2: AWS Cost Explorer (Long-term analysis)**
1. Sign in to the AWS Management Console and open the Cost Explorer console at [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/).
1. Set Granularity to **Hourly**
1. Group by **Usage type**
1. Apply the following filters:
+ Service: Redshift
+ Region: Your local region
+ Usage type: Filter for **Redshift:ServerlessUsage**
1. Review the Cost and usage graph for hourly serverless usage in your chosen region
## Purchasing a serverless reservation using the console
When you purchase a reservation, you choose the RPU level that will be discounted. Prior to selecting your RPU level, it’s good to know your base capacity and the on-demand capacity you use over time. This section shows you how to determine your capacity and reserve a serverless reservation.
To start, in the Redshift console, choose **Serverless**, and then **Serverless reservations** from the menu.
![\[Amazon Redshift console showing Serverless dashboard with Serverless reservations option highlighted.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/capacity-reservations-menu-selection.png)
The console shows a description of the feature and a list of existing reservations. From here you can purchase a reservation, or you can use the reports and monitoring tools available to check your current usage. These help you determine your RPU levels and how many RPUs are appropriate to reserve.
To purchase a reservation, complete the following steps:
1. Choose **Purchase serverless reservations**.
![\[Reservation overview showing 1 RPU total, 0 expiring, with option to purchase Serverless reservations.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/capacity-reservations-list-purchase.png)
1. A walk through appears, which has a series of selections. Enter the **Serverless reservation** RPU level to reserve. If you are unsure what this level should be, you can use the tools described further along in this section.
![\[Input field for entering reserved RPU capacity, with a range from 1 to any number.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/capacity-reservations-RPU-level.png)
1. Set the payment type. You can choose to pay upfront for your reserved RPUs, or you can pay monthly. If you choose to pay up front, you get a bigger discount.
![\[Payment type options: All Upfront with 24% discount or No Upfront with 20% discount.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/capacity-reservations-payment-type.png)
1. When you finish making the selections, choose **Purchase serverless reservations** and then **Confirm**.
After you confirm the reservation, it appears in the list of reservations.
![\[Serverless reservations table showing one payment-pending reservation with details.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/capacity-reservations-list-created.png)
## Usage notes
+ You can't change or delete a reservation. But you can create additional reservations to get more coverage.
+ Redshift Serverless uses reserved RPUs for a workload prior to using on-demand RPUs, to ensure cost savings. If you exceed the number of RPUs that you have reserved, you begin to accrue charges for those additional RPUs at the Redshift Serverless on-demand rate.
+ Free credits for Amazon Redshift Serverless aren't applied to serverless reservations, only to RPUs billed on-demand.
## Serverless reservation examples
In this scenario, your AWS payer/ linked account has two Amazon Redshift workgroups:
+ Workgroup 1 has steady state usage, such as for a business-intelligence team.
+ Workgroup 2 has unpredictable workloads with spikes in usage, such as for ETL operations.
You want to optimize the costs for these workgroups, so you purchase a one-year serverless reservation. Based on historical data, you determine that both workgroups consume 64 RPUs at a steady state. Workgroup 2, however, occasionally increases from 32 RPUs to 48 RPUs and drops to 24 RPUs for short periods. You set the RPU level of your reservation at 64 RPUs to start, which is aligned with historical trends. The per-hour billing details are as follows:
+ For the first hour, similar to historical usage trends, both workgroups use 32 RPUs for total account usage of 64 RPUs. For this hour, all the RPUs are charged at the serverless reservations discounted rate. This is because the usage level of 64 RPUs is equal to the 64 RPU serverless reservation.
+ For the second hour, workgroup 1 continues to use 32 RPUs. However, workgroup 2 spikes to 48 RPUs, for a total account usage of 80 RPUs. For this hour, 64 RPUs are charged at the serverless reservations discounted rate, and 16 RPUs are charged at the Redshift Serverless on-demand rate.
+ For the third hour, workgroup 1 continues to consume 32 RPUs and workgroup 2 decreases to 8 RPUs. In this hour, the account is charged at the 64 RPU serverless reservation rate, even though the account total is 40 RPU.
See the following diagram for workgroup usage evolution, and on-demand and serverless reservation rates billing details:
![\[Graph showing total account usage, on-demand usage, and workgroup trends over three time periods.\]](http://docs.aws.amazon.com/redshift/latest/mgmt/images/capacity-reservation-example.png)
## Purchasing a serverless reservation using the AWS CLI or Amazon Redshift API
You use `create-reservation` to create an RPU reservation. The following shows the command:
```
create-reservation
--capacity
--offering-id
```
You set `capacity` to the number of RPUs you want to reserve.
## 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 AWS Regions are billed at the transfer rates outlined on the pricing page. For more information, see [Amazon Redshift pricing](https://aws.amazon.com//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?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
## 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\$1SERVERLESS\$1USAGE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_SERVERLESS_USAGE.html) 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](https://aws.amazon.com//redshift/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](https://aws.amazon.com//redshift/pricing/).
+ **Automatic optimizations run using extra compute resources** ‐ Amazon Redshift Serverless usually runs automatic optimization operations alongside user queries. These operations are known as autonomics, and you aren’t charged for them.
If you enable allocating extra compute resources, Amazon Redshift will run autonomics when necessary even in periods of high user activity. In such cases, you can be billed for the time spent running autonomics. 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*.
### Amazon Redshift Serverless best practices for keeping billing predictable
The following 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](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_USER.html) 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](amazon-redshift-limits.md#serverless-limits-account).
## Amazon Redshift Serverless billing with connection pooling
Amazon Redshift Serverless treats all incoming queries as billable user activity, including lightweight health-check queries sent by connection pools. This behavior applies regardless of whether the query originates from an application, a JDBC/ODBC driver, or a connection pooling framework. Each health-check query triggers compute usage, and charges are incurred regardless of query purpose or origin. As a result, maintaining open connection pools can generate costs even when no actual user workloads are running.
Connection pooling maintains a pool of persistent connections between applications and the Amazon Redshift Serverless endpoint. To ensure these connections remain healthy and available, pooling mechanisms often send lightweight or empty queries (for example, `SELECT 1`) at regular intervals. These automated queries verify connection status.
When you use connection pooling, consider these best practices to minimize unintended charges:
+ Adjust health check frequency by reviewing and optimizing the frequency of health check or keep-alive queries in your connection pooling configuration.
+ Optimize idle system settings by configuring connection pooling to minimize unnecessary connection churn or background query activity during system idle times.
+ Implement application-level pooling or improved connection lifecycle management if it can reduce overhead.
+ Disable heartbeat or validation queries if your connection pooling configuration allows it. Check your specific connection string parameters or configuration files to adjust these settings.
+ Fine-tune TCP keepalive settings: If you can't disable the driver's internal heartbeat mechanisms, adjust Transmission Control Protocol (TCP) keepalive settings at the operating system or application level to address connection timeout issues. Refer to your operating system, JDBC/ODBC driver, or connection pool documentation for details.
+ Optimize database connection pooling: Configure your connection pool (HikariCP, Apache Database Connection Pool) to manage connections and minimize connection overhead. Focus on parameters such as maximum connections, idle timeout, and validation queries (if necessary). This optimization helps align Amazon Redshift Serverless compute usage with actual workload demand, potentially reducing costs.
## Cost optimization for Amazon Redshift Serverless with zero-ETL
To optimize costs while running zero-ETL integrations on Amazon Redshift Serverless, you can right-size your environments and adjust your refresh settings based on workload needs. Consider making the following adjustments:
+ Use the lower base RPU capacity of 8 RPU where available for workloads.
+ Configure the REFRESH\$1INTERVAL of your target Redshift instance to balance freshness with cost. Shorter intervals ensure near real-time updates but drive up compute costs. Longer intervals (5 minutes or longer) reduce charges for workloads where immediate freshness is not critical, such as reporting or historical analysis. To edit your Redshift target REFRESH\$1INTERVAL, see the refresh interval clause in the [ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_DATABASE.html) description.
+ Maximize utilization of your Amazon Redshift Serverless environment by concurrently running analytics workloads while zero-ETL data is being ingested. This ensures that compute capacity is actively serving multiple business purposes.