New See exactly what you're overpaying AWS in under 60 seconds. Try the Calculator for free →

Redshift data sharing pricing: what’s free and what actually costs money

A cost breakdown across same-account, cross-account, and cross-region sharing, plus the node type and encryption rules that decide whether you can use it at all.
Picture of Priyanka
Content Strategist

Priyanka

Content Strategist
October 5, 2026

·

17 min read
Redshift data sharing pricing: what's free and what actually costs money
In this article
Key takeaways
1
Redshift data sharing pricing is simple in one Region: no feature fee, each side just pays its own compute and managed storage.
2
Cross-region is the only tier with a variable charge: the consumer pays a transfer fee on bytes scanned per query, so query efficiency moves the bill.
3
It runs only on Redshift Managed Storage node types: RA3, the newer RG nodes, and Serverless. DC2 is not supported.
4
Cross-account and cross-region shares need both sides encrypted, keys need not match; same-account shares only need matching encryption state.
5
Set a cross-region usage limit before the first cross-region query, the one native guardrail against runaway scan-based charges.

Short answer

Redshift data sharing has no feature fee. Within the same AWS Region, whether same-account or cross-account, the only costs are each cluster’s normal compute and managed storage. Cross-region sharing adds a transfer charge billed to the consumer on the bytes scanned per successful query, near $0.02 per GB for US Region pairs but variable by route. DC2 cannot use data sharing at all; RA3, RG, or Serverless is required on both sides.

If both workloads run on the same Redshift cluster, you may not need a datashare at all: query another database on that cluster with three-part notation and the right permissions. Datashares apply only between separate clusters or Serverless workgroups.

How data sharing bills at each layer

When a consumer queries shared data, the query runs on its own compute nodes and never touches the producer’s local disk. It reads from Redshift Managed Storage (RMS), the S3-backed layer that RA3, RG, and Serverless share, as described in the AWS data sharing overview.

Two things follow. Consumer queries burn consumer compute, so they do not affect producer performance. And the data exists once, in the producer’s storage: the producer pays for it as always, the consumer pays nothing to store shared data, and the duplicate-storage cost of copy-based sharing disappears.
Two-row graphic showing Redshift data sharing has no transfer charge within a Region and a consumer per-query transfer charge across Regions.

Same-region sharing costs nothing extra

Inside one Region, sharing adds no charge beyond each cluster’s normal running cost. Same-account, same-region means the producer pays its own compute and RMS storage, the consumer pays its own compute when it queries, and no transfer or feature fee applies.

Cross-account, same-region is identical on cost. AWS confirms in its data sharing considerations that transfer charges do not apply within a Region, only across Regions. Cross-account adds a two-way handshake, where the producer authorizes the datashare and the consumer associates it, but that carries no per-use cost.
Amazon Redshift console Datashares page showing a same-account and a cross-account datashare with their status.

Cross-region sharing is the only paid tier

When a consumer queries data in another Region, it pays a transfer fee from the producer Region to its own. Per the AWS cross-region cost control documentation, the charge is based on bytes scanned per successful query, rounded up to the next megabyte with a 10 MB minimum. You do not pay once to move the dataset; you pay each time a query runs, based on what it scanned.

That flips the incentive: efficient queries that scan less through partitioning, sort keys, and filters cost less, and a query that rescans the same data is billed again. The per-byte rate varies by Region pair, landing near $0.02 per GB for US pairs but not universal, so confirm your route on the AWS Redshift pricing page. Long-haul pairs can run higher, and our guide to AWS data transfer costs explains why routes differ.

Illustrative example: cross-region transfer cost

Assume a consumer in us-west-2 runs 1,000 queries a month against a datashare in us-east-1, each scanning 100 GB on average, at $0.02 per GB.
1,000 queries x 100 GB x $0.02 = $2,000 / month
Improve partitioning so the average query scans 10 GB, and the same workload costs 1,000 x 10 GB x $0.02 = $200 per month. This is a hypothetical calculation, not a customer result, but it shows why query tuning belongs in any cross-region decision.

Which node types and encryption qualify

Data sharing works only on RMS node types: RA3 (ra3.xlplus, ra3.4xlarge, ra3.16xlarge), the newer RG nodes, and Serverless. The AWS data sharing considerations page confirms DC2 is unsupported, because it uses local SSD rather than the shared RMS layer.
Warning: DC2 does not support data sharing. If you need sharing, plan a migration to RG, RA3, or Serverless, then validate the target architecture and pricing before you migrate, as covered in the AWS DC2 migration guidance.
Encryption depends on the boundary. Same-account shares need the same encryption state on both sides, both encrypted or both unencrypted. Cross-account and cross-region shares need both sides encrypted, though the keys need not match, per the AWS considerations documentation.

 Serverless is encrypted by default and qualifies automatically. Enabling AWS KMS encryption on an existing provisioned cluster starts an automated migration to a new encrypted cluster: the cluster is read-only during the migration, and you must disable cross-region snapshot copy first.

Migrating off DC2 to unlock sharing changes the billing model, not necessarily the total. DC2 bills compute and storage as one node-hour rate; RA3 splits them into node-hour compute plus a separate RMS charge of $0.024 per GB-month in us-east-1.

Sizing the two independently is often more efficient, but a 10 TB dataset shows a new RMS line item near $245 a month, so model both rather than assuming a rise.

Controlling cross-region cost

Scan-based billing can drift, so AWS gives you a guardrail: a cross-region usage limit that tracks transfer on a daily, weekly, or monthly cycle and, when the threshold is reached, can either alert you or disable further cross-region sharing.

 The alert action sends an SNS notification and a CloudWatch signal, and it does not stop charges; the disable action turns off cross-region sharing for the rest of the period.

Usage limits are off by default, so enabling cross-region sharing without one means no automatic cap. Pair the limit with the console’s cross-region usage view to see transferred bytes by query, then tune or reroute the highest-cost patterns. This mirrors the approach behind Redshift concurrency scaling cost control: set a threshold, monitor, and intervene before the invoice.

Write access and Data Exchange

Data sharing began read-only, but AWS made multi-data warehouse writes generally available at re:Invent 2024. A producer can grant INSERT and UPDATE on shared tables, plus USAGE and CREATE on shared schemas.

For write-enabled shares, size and monitor each participating warehouse, since AWS supports separate warehouses for write workloads with their own version, isolation, consumer-sizing, and transaction requirements set out in the AWS reads and writes considerations.

Datashares can also be published through AWS Data Exchange, which can create a paid distribution model. Assess AWS Data Exchange data-grant charges and any applicable Redshift fees on top of producer and consumer compute before treating it as a revenue stream.

When sharing is cheaper than a snapshot copy

For cross-region access, data sharing is not always the cheapest pattern. Compare two numbers: for data sharing, monthly bytes scanned times your Region-pair rate; for a snapshot copy, incremental transfer times the rate plus monthly destination storage. Whichever is lower wins, and rates vary by Region, so pull both from the pricing page.
Pattern What you pay Best fit
Data sharing, same Region Each cluster's own compute and storage, no transfer Live shared access inside one Region
Data sharing, cross Region Consumer transfer, billed on bytes scanned per query Live cross-region access at low or moderate volume
Cross-region snapshot copy Incremental cross-region snapshot transfer, plus destination snapshot storage High-volume, high-frequency cross-region querying
UNLOAD to S3 with Athena or Spectrum S3 storage plus per-query scan charges Data-lake publishing to SQL-on-S3 consumers
Decision rule. Sharing serves live data, while a snapshot copy is only as fresh as the last snapshot, so heavy cross-region volume that tolerates lag may find recurring scan charges exceed incremental copy plus storage, as our Redshift cross-region snapshot cost breakdown covers.

Pre-implementation checklist

1

Confirm producer and consumer both run RA3, RG, or Serverless, not DC2.

2

Verify encryption matches your boundary: same state for same-account, both encrypted for cross-account or cross-region.

3

Decide read-only versus write-enabled, and size each writing warehouse if writes are enabled.

4

For cross-region, look up the exact per-GB rate for your Region pair on the AWS pricing page.

5

Set a cross-region usage limit in alert mode before the first cross-region query.

6

Tune partitioning and sort keys on shared tables to cut bytes scanned.

7

Size reserved node coverage on each cluster separately, since sharing does not change the compute bill.

Where data sharing fits your cost strategy

Data sharing is a governance and access feature, not a discount, so rate optimization stays a separate job. Getting the commitment layer right on each cluster, starting with the choice of Redshift reserved node types and terms, moves the bill more than the datashare will.

That is the layer we work on. We analyze your Redshift utilization and recommend qualifying commitments only after the node type and count hold stable through an observation window.

With Flex Insured Commitments, teams can capture up to 42% savings of a one-year Redshift reserved node commitment with none of the commitment risk, and if a qualifying Flex Commitment ever costs more than equivalent on-demand usage, we provide cashback protection on that difference, subject to program terms. Our fee is a percentage of realized savings, so no savings means no fee.
Rate optimization, handled
Capture more Redshift compute savings.

Sharing doesn’t change your Redshift node bill. Explore commitment options and potential savings.

Frequently asked questions

What drives Redshift data sharing pricing?

Region boundaries. Within one AWS Region it is free of transfer and feature fees, same-account or cross-account, with each cluster paying only its own compute and storage. Cross-region sharing adds a transfer charge billed to the consumer on bytes scanned per successful query.

Which node types support data sharing?

Only RMS types: RA3 (ra3.xlplus, ra3.4xlarge, ra3.16xlarge), the newer RG nodes, and Serverless. DC2 is not supported, so any DC2 workload must move to one of those first.

How is the cross-region charge calculated?

On bytes scanned per successful query, rounded up to the next megabyte with a 10 MB minimum, not as a bulk copy. Rates vary by Region pair and run near $0.02 per GB for US pairs, so efficient queries cost less.

What encryption is required?

Same-account sharing needs the same encryption state on both sides. Cross-account and cross-region sharing needs both sides encrypted, though the keys need not match. Serverless is encrypted by default and qualifies automatically.

Can consumers write to shared data?

Yes, since multi-data warehouse writes went generally available at re:Invent 2024. The producer grants table privileges like INSERT and UPDATE plus schema privileges like CREATE, and each writing warehouse uses its own compute, subject to version and sizing requirements.

Share
Facebook
X
LinkedIn
Reddit
See cloud commitment management in action.
More from Usage.ai
Latest from our blogs