DynamoDB Zero-ETL to OpenSearch and Redshift: Analytics Without Pipeline Cost
AWS will tell you there is no additional charge for DynamoDB zero-ETL integrations. That is technically true: the integration activation itself has no line item on your bill. What nobody mentions in the same breath is the list of underlying services that the integration enables and requires, each with its own billing clock ticking the moment you click Create.
For the OpenSearch path, you need DynamoDB PITR ($0.20/GB-month), DynamoDB Streams reads ($0.02 per 100K reads), an OpenSearch Ingestion pipeline billed per OCU-hour ($0.24/OCU-hour with a minimum of 1 OCU running continuously), and an OpenSearch cluster or Serverless collection for the indexed data. For the Redshift path, PITR is also mandatory, data exports add $0.10/GB for the initial load and ongoing incremental exports, and Redshift compute runs at $0.375/RPU-hour for Serverless or provisioned node costs. None of these are the zero-ETL fee. They are just what the integration needs to function.
This guide names every cost, quantifies it at three scale tiers, and flags the two billing traps that have surprised production teams. By the end, you will know whether zero-ETL is genuinely cheaper than your current ETL pipeline, and what it will actually cost each month.
What Is DynamoDB Zero-ETL and How Does Each Integration Work?
DynamoDB zero-ETL refers to two separate AWS-managed integrations that automatically replicate data from your DynamoDB tables to analytics services without you building or running data pipelines.
DynamoDB Zero-ETL to OpenSearch
The DynamoDB zero-ETL OpenSearch integration uses DynamoDB Streams to capture every change to your table (inserts, updates, deletes) and an OpenSearch Ingestion pipeline to transform and index those changes into an OpenSearch managed cluster or Serverless collection. You get full-text search, fuzzy matching, vector search, and aggregation queries on your DynamoDB data in near-real-time (typically seconds of lag). You do not write any pipeline code; AWS runs the OpenSearch Ingestion pipeline for you.
Requirement: DynamoDB PITR must be enabled on the source table. DynamoDB Streams must be enabled. Same-region and same-account only (cross-region and cross-account are not yet supported as of April 2026). Maximum pipeline throughput: 1 OCU handles approximately 2 MiB per second. For a table processing 20,000 WRUs per second, you need at least 10 OCUs.
Also read: DynamoDB On-Demand vs Provisioned: Cost Comparison at Every Scale
DynamoDB Zero-ETL to Redshift
The DynamoDB zero-ETL Redshift integration performs an initial full export of your DynamoDB table to seed Redshift, then continuously replicates changes using a CDC mechanism that reads from DynamoDB’s internal change stream without consuming your table’s RCUs. Your DynamoDB data lands in Redshift as a read-only replicated database, queryable with full SQL, including joins to other Redshift tables. The minimum latency for DynamoDB-to-Redshift replication is 15 minutes, making this unsuitable for near-real-time analytics but well-suited for reporting, dashboards, and batch analytics workloads.
Requirement: DynamoDB PITR required. DynamoDB table must be encrypted. Table size limit: up to 100 tebibytes. Target: Redshift Serverless workgroup or RA3 provisioned cluster. Same-account cross-region is supported; cross-account is supported via ARN.

What Does Each DynamoDB Zero-ETL Integration Actually Cost?
Here is every billable component for both zero-ETL paths. No line items omitted. April 2026 rates, US East (N. Virginia). Verify at aws.amazon.com/dynamodb/pricing and aws.amazon.com/opensearch-service/pricing and aws.amazon.com/redshift/pricing — rates change.
| Cost Component | OpenSearch Path | Redshift Path | Rate | Zero Traffic Cost | Notes |
| DynamoDB PITR | Required | Required | $0.20/GB-month | Charged on table size | Cannot be avoided for either integration |
| DynamoDB Streams reads | Required (CDC source) | Not charged (uses internal CDC) | $0.02/100K reads | Minimal when idle | Free tier: 2.5M reads/month |
| OpenSearch Ingestion OCUs | Required — pipeline compute | Not applicable | $0.24/OCU-hour | $175/month (1 OCU min) | Billed even when no data is flowing |
| OpenSearch cluster / Serverless | Required — indexed data | Not applicable | From $0.036/hr (managed) or $0.24/OCU-hr (Serverless) | $350/month min (Serverless, 2 OCU) | Serverless min = 2 OCU (1 search + 1 index) |
| DynamoDB Export to S3 (initial load) | Not required | Required (one-time + incremental) | $0.10/GB | One-time only | Paid once for initial seed; incremental ongoing |
| Redshift compute | Not applicable | Required | $0.375/RPU-hr (Serverless) | Varies if CDC prevents pause | CDC writes prevent Serverless from auto-pausing |
| Redshift Managed Storage | Not applicable | Required | $0.024/GB-month | Charged on replicated data size | Same rate for Serverless and RA3 |
| Cross-AZ data transfer | Minimal (intra-region) | Applies if source and target in different AZs | $0.01/GB (same region, cross-AZ) | Often under $5/month | Easy to miss in budget planning |
| Zero-ETL integration activation | $0.00 | $0.00 | Free | $0.00 | This is the only truly free part |
What Does DynamoDB Zero-ETL to OpenSearch Cost at Three Scales?
Let us model three real workload profiles for the DynamoDB zero-ETL OpenSearch path to show what the monthly bill actually looks like.
Small Workload: 5 GB Table, Low Write Traffic
Table size: 5 GB. Write volume: 500K WRUs per month. Search queries: 100K per month. OCU setting: 1 minimum, 2 maximum.
DynamoDB PITR: 5 GB x $0.20 = $1.00/month. DynamoDB Streams reads: 500K records, processed by 1 OCU. Streams read cost (Lambda-free path with OSIS): small. OSIS OCU: 1 OCU minimum x $0.24/hr x 730 hrs = $175.20/month. OpenSearch Serverless (dev, redundancy disabled): 1 OCU x $0.24/hr x 730 = $175.20/month. OpenSearch Serverless storage: 5 GB x $0.024 = $0.12/month. Total: approximately $351/month.
This is the number that surprises most teams. A 5 GB table with light traffic, using the simplest DynamoDB zero-ETL OpenSearch configuration, costs over $350/month in steady state because the minimum OCU floors on both the Ingestion pipeline and the Serverless collection run 24 hours a day.
Medium Workload: 100 GB Table, Moderate Traffic
Table size: 100 GB. Write volume: 10 million WRUs per month. Search queries: 1 million per month. OCU setting: 2 minimum, 8 maximum.
DynamoDB PITR: 100 GB x $0.20 = $20.00/month. DynamoDB Streams reads: included in OCU compute. OSIS OCU: 2 minimum OCU x $0.24/hr x 730 = $350.40/month. OpenSearch managed cluster (r6g.large.search, 2 nodes): approximately $245/month. OpenSearch storage: 100 GB x $0.10/GB = $10.00/month. Total: approximately $625/month.
Large Workload: 1 TB Table, High Traffic
Table size: 1,000 GB. Write volume: 100 million WRUs per month (approximately 38 WRUs/sec average). Search queries: 10 million per month. OCU setting: 10 minimum, 30 maximum (10 OCUs to handle 20+ MiB/sec peak throughput).
DynamoDB PITR: 1,000 GB x $0.20 = $200/month. OSIS OCU: 10 minimum OCU x $0.24/hr x 730 = $1,752/month. OpenSearch managed cluster (r6g.xlarge.search, 3 nodes + dedicated masters): approximately $900/month. OpenSearch storage: 1,000 GB x $0.10/GB = $100/month. Total: approximately $2,952/month.
At a large scale, the OSIS OCU cost dominates. At 10 minimum OCUs, the pipeline alone costs $1,752/month before the OpenSearch cluster itself. This is a significant ongoing cost that must be justified by the search and analytics value it delivers compared to your existing ETL infrastructure.
Also read: DynamoDB Single-Table Design: Does It Actually Save Money?
What Does DynamoDB Zero-ETL to Redshift Cost at Three Scales?
Small Workload: 5 GB Table, Reporting Use Case
Table size: 5 GB. Initial export: one-time $0.50 (5 GB x $0.10/GB). DynamoDB PITR: $1.00/month. Incremental export (5% daily change rate): approximately $0.50/month. Redshift Serverless (8 RPU base, queries 2 hrs/day): 2 hrs x $3.00/hr (8 RPU x $0.375) x 30 days = $180/month. But if CDC writes prevent auto-pause: 8 RPU x $0.375/hr x 730 hrs = $2,190/month. Redshift storage: 5 GB x $0.024 = $0.12/month. Cross-AZ transfer: negligible.
This is the most important cost trap in the entire blog. Teams plan for $180/month (queries only) and discover $2,190/month (CDC prevents pause). Zero-ETL replication writes continuously to Redshift to keep the data current. Redshift Serverless cannot auto-pause while these writes are active, which means the workgroup runs 24 hours a day at your base RPU capacity even when nobody is querying. To avoid this, AWS recommends setting the REFRESH_INTERVAL to a longer cadence (5 minutes or more) and right-sizing the base RPU, but the pause behavior requires careful configuration, or the cost runs far above expectations.

Medium Workload: 100 GB Table, BI Dashboard Use Case
Table size: 100 GB. Initial export: $10.00 (one-time). DynamoDB PITR: $20.00/month. Incremental export: ~$5.00/month (5% daily change). Redshift Serverless (32 RPU base, assuming CDC prevents full pause, 16 hours active per day): 32 RPU x $0.375/hr x 730 hrs x 70% active = $6,132/month. This number is why most teams at this scale move to Redshift provisioned RA3 nodes. Redshift RA3.xlplus (1 node, on-demand): $1.086/node-hr x 730 hrs = $793/month. Storage: 100 GB x $0.024 = $2.40/month. Total: approximately $820/month on provisioned. Total on Serverless (70% active): $6,157/month.
The provisioned versus Serverless decision for Redshift in a Zero-ETL context almost always favors provisioned RA3 once your base RPU requirement exceeds 16 RPUs, because Serverless cannot pause during active replication.
Large Workload: 1 TB Table, Analytics Platform
Table size: 1,000 GB. DynamoDB PITR: $200/month. Initial export: $100.00 (one-time). Incremental export: $50/month. Redshift RA3.4xlarge cluster (2 nodes + reserved 1-year): approximately $1,800/month after RI discount. Redshift storage: 1,000 GB x $0.024 = $24/month. Cross-AZ transfer: ~$10/month. Total: approximately $2,084/month. The Reserved Node discount on Redshift provisioned is up to 45% for 3-year terms, making provisioned RA3 significantly more cost-effective than Serverless for high-throughput steady-state Zero-ETL workloads.
What Is the Total Cost Comparison: Zero-ETL vs Traditional ETL?
Before committing to Zero-ETL, it is worth understanding what you are actually replacing. The traditional DynamoDB to analytics pipeline typically uses DynamoDB Streams plus a Lambda consumer plus Kinesis Data Firehose or a custom ETL script. Here is how the costs compare for the medium workload (100 GB table, 10 million WRUs/month).
| Component | DynamoDB Zero-ETL OpenSearch | DynamoDB Zero-ETL Redshift (RA3) | Traditional: Streams + Lambda + Firehose | Notes |
| DynamoDB PITR | $20/month | $20/month | Optional ($20/month) | Only truly required for zero-ETL paths |
| DynamoDB Streams | $2/month (included in OCU billing) | Internal CDC (free) | $2/month (Lambda reads free) | Lambda streams reads are free |
| Pipeline compute | $350/month (2 OCU) | $50/month (RPU portion only) | $30/month (Lambda + Firehose) | Biggest cost difference |
| Analytics service | $245/month (OpenSearch managed) | $793/month (RA3.xlplus 1-node) | $30-100/month (S3 + Athena) | Athena is cheapest analytics layer |
| Engineering time/month | ~2 hrs (monitoring only) | ~2 hrs (monitoring only) | ~8-16 hrs (pipeline maintenance) | Zero-ETL saves significant eng time |
| Total monthly cost | ~$617 | ~$863 | ~$82-152 | Traditional ETL wins on pure cost |
The honest conclusion: DynamoDB zero-ETL is not cheaper than a well-run traditional ETL pipeline on pure cost. The value is in operational simplicity, reduced engineering time, and eliminating the maintenance burden of custom pipeline code. If your team spends 8-16 hours per month on ETL maintenance, zero-ETL can pay for its OCU and RPU premium. If your ETL runs on autopilot, the cost premium is harder to justify.
The Two Cost Traps That Catch Production Teams Off-Guard
Trap 1: Idle OpenSearch Ingestion Pipelines Bill Continuously
An enabled OpenSearch Ingestion pipeline bills OCU minimums every hour, regardless of whether data is flowing. If you set a minimum of 2 OCUs and your DynamoDB table has zero writes for a weekend, you still pay 2 OCUs x $0.24/hr x 48 hrs = $23.04 for the idle weekend. Over a month, a 2 OCU minimum costs $350.40, whether the pipeline processes 1 record or 10 million.
The fix: disable the pipeline during known idle periods and re-enable before traffic resumes. AWS supports pipeline pause and resume via the console and CLI. For testing and development integrations that do not need 24/7 operation, disabling the pipeline when not in use can cut OCU costs by 50-80%.
Trap 2: Redshift Serverless CDC Writes Prevent Auto-Pause
Teams choose Redshift Serverless because it auto-pauses when idle, saving money on quiet periods. Zero-ETL replication writes continuously to keep data current, and Redshift Serverless cannot auto-pause while writes are active. This turns a pay-per-query Serverless model into effectively always-on billing at your base RPU capacity.
A team budgeting $180/month for a reporting workgroup that queries 2 hours per day can easily end up with a $2,190/month bill because the CDC writes keep the 8 RPU base active around the clock. AWS recommends setting a longer REFRESH_INTERVAL (5 minutes or more) in the target Redshift database configuration to batch replication writes, which can create windows where the workgroup enters a lower-activity state. However, complete auto-pause is not guaranteed with active Zero-ETL integrations. For cost-controlled environments, consider Redshift provisioned RA3 with Reserved Nodes, which eliminates the auto-pause ambiguity entirely.

Also read: DynamoDB Reserved Capacity: Pricing for Read & Write Throughput
What Are the Technical Limitations of DynamoDB Zero-ETL Integrations?
Understanding the limitations before you build is important for avoiding a costly rearchitecture later. Here are the key constraints that affect both the OpenSearch and Redshift integration paths.
OpenSearch Zero-ETL Limitations
Cross-region and cross-account not supported as of April 2026. This means your DynamoDB table and OpenSearch cluster must be in the same AWS account and region. For multi-region DynamoDB deployments using Global Tables, you need a separate zero-ETL pipeline in each region where you want OpenSearch search functionality, multiplying your OCU costs by the number of regions.
Initial load for large tables can take hours. When you first create a DynamoDB zero-ETL OpenSearch integration, an initial export loads all existing table data into OpenSearch. For a 100 GB table, this initial load can take 2-6 hours. During this time, OCUs are consuming at higher rates than steady-state, and your OpenSearch index is not yet fully populated. Plan for the initial load time in your deployment schedule.
Sparse fields and mapping inference. When the pipeline creates an OpenSearch index, it infers field types from the first batch of records it processes. If a field is null or absent for all records in the initial load, no mapping is created for it. Future records with that field will not be indexed unless you manually update the mapping via the _mapping API or rebuild the index. For tables with many optional attributes, this is a common operational gotcha that requires ongoing attention.
Redshift Zero-ETL Limitations
The 15-minute minimum latency is the hardest constraint for teams coming from near-real-time ETL pipelines. If your dashboard needs data that is less than 15 minutes old, DynamoDB zero-ETL to Redshift cannot meet that SLA. Consider DynamoDB zero-ETL to OpenSearch for near-real-time requirements, or maintain a traditional Kinesis Data Streams plus Lambda plus Redshift path for sub-minute latency.
Read-only replicated database. The Redshift database created by zero-ETL is read-only. You cannot write to it, update it, or perform DML operations on it. Your SQL analytics can SELECT and JOIN, but any transformations must happen in materialized views or separate Redshift tables that you populate from the replicated data. dbt models or Redshift materialized views are the standard pattern for building analytics-ready tables from the raw zero-ETL replica.
DDL changes in DynamoDB require reseeding. If you make significant schema changes to your DynamoDB table (adding new GSIs, changing the partition key structure), the zero-ETL integration may require a reseed, which reloads the entire table into Redshift from scratch. A reseed on a large table can take hours and generate additional export and compute costs. Design your DynamoDB schema for stability before enabling zero-ETL.
Concurrency Scaling does not apply to zero-ETL writes. Redshift Concurrency Scaling adds temporary cluster capacity to handle burst read queries. This capacity does not apply to the background write process of zero-ETL replication. If your Redshift cluster is handling heavy analytics workloads while simultaneously ingesting from DynamoDB zero-ETL, the replication write throughput competes with query read throughput for cluster resources rather than benefiting from Concurrency Scaling.
When Should You Choose Zero-ETL vs Building Your Own Pipeline?
This is the question that every team considering DynamoDB zero-ETL should answer before they start. The answer depends on three factors: your engineering capacity, your latency requirements, and your budget.
Choose DynamoDB Zero-ETL to OpenSearch When:
Your team does not have dedicated data engineering resources to build and maintain a DynamoDB Streams to OpenSearch ingestion pipeline. You need full-text search, vector search, or aggregation queries on DynamoDB data within seconds of the write. You can absorb the $175-700/month OCU minimum cost for the value of managed pipeline operations. You are doing initial exploration and want search functionality running within hours, not weeks. Your DynamoDB table is in the same region and account as your OpenSearch cluster.
Choose DynamoDB Zero-ETL to Redshift When:
You need SQL analytics across DynamoDB data without maintaining an ETL codebase. Your analytics queries can tolerate 15-60 minutes of data latency. Your team is comfortable with Redshift SQL but not with Python ETL frameworks. You want to join DynamoDB data with data from other sources already in Redshift (Aurora, S3, Salesforce) without writing join logic in application code. You plan to use Redshift provisioned RA3 nodes (not Serverless) to avoid the auto-pause trap.
Build Your Own ETL Pipeline When:
Your budget is tight, and $600-900/month for a medium workload is not justified by the search or analytics value. You need sub-15-minute latency for Redshift or sub-second for analytics. You already have a working Kinesis Data Streams, Lambda, plus S3 pipeline, and it runs reliably. Your team has data engineering capacity and prefers control over pipeline logic, schema transformations, and error handling. You need cross-region replication of analytics data, which zero-ETL does not support yet.
Also read: DynamoDB Reserved Read Capacity: When & How Much to Commit
How Do You Optimize DynamoDB Zero-ETL Costs?
Right-Size Your OCU Minimum for OpenSearch Ingestion
The OCU minimum is the biggest lever for OpenSearch zero-ETL cost. Start with 1 OCU and monitor the pipeline’s throughput metrics in CloudWatch. If the pipeline processes less than 2 MiB per second at steady state, 1 OCU is sufficient. Only increase the minimum when you see pipeline lag growing, which indicates the current OCU count cannot keep up with write throughput. Setting OCU minimum to 4 when 1 would suffice wastes $525/month ($350 extra x 1.5 OCUs) indefinitely.
Use OpenSearch Managed Clusters Instead of Serverless for Steady Workloads
OpenSearch Serverless has a 2 OCU minimum (approximately $350/month for just the collection) and scales automatically. OpenSearch managed clusters start at $0.036/hour for a t3.small.search (approximately $26/month). For steady DynamoDB Zero-ETL workloads, a managed cluster is almost always cheaper than Serverless once the data volume exceeds a few GB. The $350/month Serverless floor versus a $100-200/month managed cluster for the same indexed data size is a significant difference.
Set REFRESH_INTERVAL on the Redshift Target
For the Redshift path, configure a REFRESH_INTERVAL of 300 seconds (5 minutes) or longer on the target database. This batches replication writes, reduces the continuous write pressure on the Serverless workgroup, and may allow brief auto-pause windows during very low-activity periods. The trade-off is staleness: a 5-minute interval means your Redshift data is up to 5 minutes behind DynamoDB. For reporting and batch analytics, this is usually acceptable.
Enable DynamoDB TTL to Reduce PITR Costs
PITR is charged based on table size. Every GB of expired data that TTL removes from your table reduces the PITR cost by $0.20/GB-month. For tables with time-series or session data, enabling TTL can reduce the table size significantly, cutting both the PITR cost and the amount of data the Zero-ETL pipeline must replicate to OpenSearch or Redshift.
Use DynamoDB Reserved Capacity to Reduce the Base Table Cost
The Zero-ETL integration does not change your DynamoDB table’s WCU cost. If your table uses provisioned mode with consistent traffic, DynamoDB reserved capacity (54-77% savings) reduces the largest line item in your overall DynamoDB bill. Optimizing the source table cost is just as important as optimizing the Zero-ETL pipeline cost when evaluating total analytics infrastructure spend.
See how much you can save on DynamoDB with Usage.ai
Frequently Asked Questions
How much does DynamoDB zero-ETL to OpenSearch cost?
The integration itself is free. The real costs are DynamoDB PITR ($0.20/GB-month, required), DynamoDB Streams reads ($0.02/100K), OpenSearch Ingestion OCUs ($0.24/OCU-hour with a minimum 1 OCU running 24/7 = $175/month minimum), and your OpenSearch cluster or Serverless collection. A small table with a minimal setup costs approximately $350-400/month in steady state (verify at aws.amazon.com/opensearch-service/pricing — rates change).
How much does DynamoDB zero-ETL to Redshift cost?
The integration itself is free. Costs include DynamoDB PITR ($0.20/GB-month, required), initial data export ($0.10/GB one-time), incremental exports, and Redshift compute. Redshift Serverless runs at $0.375/RPU-hour. The key warning: continuous CDC writes from DynamoDB zero-ETL may prevent Redshift Serverless from auto-pausing, turning per-query billing into effectively always-on billing (verify at aws.amazon.com/redshift/pricing — rates change).
What is the minimum latency for DynamoDB zero-ETL to Redshift?
The minimum latency for DynamoDB zero-ETL to Redshift is 15 minutes. This makes it unsuitable for near-real-time dashboards but appropriate for reporting, historical analytics, and batch workloads. Aurora MySQL zero-ETL achieves seconds-to-minutes latency. DynamoDB to OpenSearch zero-ETL achieves near-real-time (seconds) latency via Streams-based CDC.
Does DynamoDB zero-ETL to Redshift consume RCUs?
No. The Redshift zero-ETL integration reads from DynamoDB using an internal CDC mechanism that does not consume your table’s provisioned or on-demand read capacity units. Your application’s read capacity is unaffected by the replication. DynamoDB Streams reads for the OpenSearch path also do not consume RCUs (Streams reads are billed separately at $0.02/100K).
Can you use DynamoDB zero-ETL across regions or accounts?
For the OpenSearch integration: cross-region and cross-account are not supported as of April 2026. For the Redshift integration: cross-region is not supported, but cross-account is supported by providing the Redshift ARN from another account. AWS is actively expanding support for these configurations.
Is DynamoDB zero-ETL cheaper than building your own ETL pipeline?
On pure infrastructure cost, usually not. A traditional DynamoDB Streams plus Lambda plus S3 plus Athena pipeline costs $82-152/month for a medium workload compared to $617-863/month for zero-ETL. The zero-ETL premium pays for eliminating 8-16 hours of engineering maintenance per month. The financial case depends on your engineering cost and the value of reduced operational complexity.
How much does OpenSearch serverless cost?
OpenSearch Serverless charges $0.24 per OCU-hour for both indexing and search. A production collection requires a minimum of 2 OCUs (1 indexing + 1 search), costing approximately $350/month at minimum. Storage is billed separately at $0.024/GB-month. For small, predictable workloads, a managed OpenSearch cluster is typically cheaper than Serverless (verify at aws.amazon.com/opensearch-service/pricing — rates change).
What are the main hidden costs of DynamoDB zero-ETL?
Two cost traps catch most teams: first, OpenSearch Ingestion pipeline OCU minimums bill 24/7 even when no data flows, making an idle pipeline cost $175/month for a 1-OCU setting. Second, Redshift Serverless CDC writes may prevent auto-pause, turning a pay-per-query model into always-on RPU billing. Budget for both before choosing zero-ETL over a traditional pipeline.