The "Zero" in AWS Zero-ETL Is Marketing: What It Actually Does and When to Use It

A team I was advising deleted a Glue job the week after they turned on Aurora-to-Redshift zero-ETL. The reasoning made sense on the surface: the old job read from the same Aurora tables, landed them in Redshift, and now zero-ETL was doing that automatically — so the job was redundant, right? Two days later the finance dashboard went blank. The Glue job wasn't just moving data; it was also deduplicating late-arriving rows, casting a nightmare of a legacy timestamp column, and rolling transactions up into the summary tables the dashboard actually queried. Zero-ETL had faithfully replicated the raw operational tables into Redshift and done exactly none of that. The word "zero" had done its job a little too well.

That's the whole tension with AWS zero-ETL, and it's why I wanted to write this: the feature is genuinely good and I reach for it often, but the name oversells it in a way that gets teams into trouble. Zero-ETL removes the extract and the load — the plumbing nobody wanted to own — and touches the transform not at all. Understanding precisely where that line sits is the difference between it saving you a month of pipeline work and it quietly serving your business raw, unmodeled operational data behind a dashboard that used to be correct.

What is AWS zero-ETL, actually?

AWS zero-ETL is a fully managed, no-code change-data-capture replication service that continuously mirrors data from a transactional source into an analytics destination, with no pipeline for you to build, run, or scale. That's the precise definition, and every word in it matters. It is replication (the destination is a copy that tracks the source), driven by change data capture (it reads the source's transaction log, not the tables), and it is managed (there's no Glue job, no Lambda, no DMS instance you patch). What it is not, and never claims to be in the fine print, is a transformation engine.

The mental model that keeps me honest about it: zero-ETL is a very good CREATE TABLE ... AS that stays live forever. It gives you a fresh, queryable replica of your operational tables in your warehouse a few seconds behind production. Everything you'd normally do after landing raw data — modeling, cleaning, conforming, aggregating — is still yours to do, now inside the destination instead of in a pipeline on the way there. If anything, zero-ETL pushes the transformation work later and more clearly into the warehouse, which is where the modern analytics-engineering-with-dbt crowd wanted it anyway.

What's actually available today?

The integration map has grown well past the original Aurora-to-Redshift launch into a genuine matrix of sources and destinations. Here's the state of it as of early 2026 — the combinations I'd actually consider in an architecture, with their maturity:

Two things worth calling out from that table. First, the SageMaker Lakehouse destination is the strategically interesting one — it lands your operational data in Apache Iceberg tables in your own S3, so it's queryable by Redshift, Athena, EMR, and anything else that speaks Iceberg, not locked into one engine. Second, the SaaS sources matter more than they look: getting Salesforce or ServiceNow data into a warehouse used to mean buying Fivetran or writing brittle API pollers, and zero-ETL quietly ate a chunk of that category.

How does it work under the hood?

Zero-ETL is change data capture with the operational burden removed, and knowing that the CDC is really there — not some magic — is what lets you reason about its failure modes. On the source side, the service reads the database's replication log: the MySQL binlog, the PostgreSQL write-ahead log, or DynamoDB Streams. Every insert, update, and delete committed to the source becomes a change event. AWS ships those events through a managed, invisible pipeline into the destination, where they're applied to a mirror of the source tables. An initial seeding copies the existing data; from then on it's a continuous stream of deltas.

flowchart LR
    subgraph SRC["Transactional source"]
        DB[("Aurora / RDS / DynamoDB")]
        LOG["binlog / WAL / DynamoDB Streams"]
        DB --> LOG
    end
    LOG --> CDC["Managed CDC pipeline
— no infra you run"]
    CDC --> SEED["Initial snapshot
then continuous deltas"]
    SEED --> DEST[("Redshift / SageMaker Lakehouse
replica of source tables")]
    DEST --> T["Your transform layer
dbt / SQL / Spark — still yours"]
    T --> BI["Marts · BI · ML features"]
          

Because it's log-based CDC, it inherits the same properties as any log-based CDC system, which I went deep on in the Debezium piece: it captures every change in commit order, it's low-impact on the source (reading a log the database already writes), and it handles deletes and updates correctly rather than the append-only approximation you get from timestamp-polling. The difference is purely operational — with Debezium you run Kafka Connect, manage connectors, and own the plumbing; with zero-ETL, AWS runs all of it and you never see a broker.

Where does the "zero" break down?

The "zero" refers to zero pipeline infrastructure, not zero work, and four specific gaps are where I've watched teams get surprised.

It replicates schema, not model. Your Redshift replica has the exact table structure of your operational database — third-normal-form, application-oriented, full of columns the app needs and analysts don't. Turning that into star schemas, conformed dimensions, and the summary tables a BI tool should hit is dimensional modeling work that happens after zero-ETL, in the warehouse. Zero-ETL got the data there; it didn't make it analyzable.

Freshness is near-real-time, not real-time. Typical replication lag is seconds to low minutes, which is superb for analytics and completely wrong for anything transactional. If a use case can't tolerate a several-second-old view — inventory decrements at checkout, fraud holds mid-authorization — zero-ETL is the wrong tool, and you want the operational store or a true streaming path instead.

Schema changes propagate, sometimes awkwardly. A DDL change on the source — a new column, a type change, a dropped table — flows through to the destination, but the exact handling and any manual intervention depends on the change. A backward-incompatible type change is exactly the kind of thing that can pause or degrade an integration, and you find out from a monitoring alert, not a compile error. Own the source schema deliberately once analytics depends on it.

Zero-ETL vs Debezium vs DMS: which do I reach for?

All three move change data from an operational store to somewhere else, and the choice is almost entirely about control-versus-convenience and where your data needs to go. Here's how I actually decide:

My default heuristic: if the source is Aurora/RDS/DynamoDB and the destination is Redshift or a SageMaker Lakehouse, zero-ETL wins on effort every time — there's no reason to hand-run CDC infrastructure to do what AWS now does for free. The moment I need the change stream to fan out to multiple consumers, land somewhere zero-ETL doesn't reach, or get transformed mid-flight, I'm back to Debezium and Kafka, because that flexibility is exactly what the managed service trades away. DMS I mostly keep for migrations and for source engines outside the zero-ETL matrix.

How does this fit a real architecture?

The pattern I like: zero-ETL for ingestion, dbt for everything after. Zero-ETL lands raw operational tables in Redshift or the lakehouse continuously; a medallion-style transformation layer (bronze = the raw replica, silver = cleaned and conformed, gold = business marts) runs on a schedule or on change inside the warehouse. This cleanly separates the two concerns the name conflates: AWS owns keeping the bronze layer fresh, you own turning bronze into something worth querying.

-- The raw zero-ETL replica lands here, application-shaped, seconds fresh.
-- This is bronze. Nobody's dashboard should point at it directly.
SELECT * FROM aurora_zeroetl.public.orders LIMIT 5;

-- Silver: a dbt incremental model conforms and dedups the raw replica.
-- THIS is the "T" zero-ETL never did for you.
CREATE MATERIALIZED VIEW analytics.orders_clean AS
SELECT
    order_id,
    customer_id,
    CAST(order_ts AS TIMESTAMP)        AS ordered_at,
    UPPER(status)                       AS status,
    amount_cents / 100.0                AS amount_usd
FROM aurora_zeroetl.public.orders
WHERE is_deleted = false;

This is also the cleanest answer to the "zero" confusion from the opening story: had that team drawn the bronze/silver line explicitly, deleting the Glue job would have obviously meant deleting the silver transforms, and the mistake would have been impossible to make by accident. The pipeline they deleted was the transform layer; zero-ETL only ever replaced the ingestion half.

What to carry away

AWS zero-ETL is one of the better "boring infrastructure I no longer have to run" wins of the last few years, and I turn it on without hesitation when the source is AWS-native and the destination is Redshift or a SageMaker Lakehouse. Just hold the definition precisely: it eliminates the extract and the load, gives you a CDC-fresh replica of your operational tables, and leaves the entire transform — modeling, cleaning, aggregating — exactly where it was, now living in the warehouse. Scope what you replicate so the destination bill doesn't surprise you, keep a real transformation layer between the raw replica and anything a human queries, and never let the word "zero" convince a teammate that the modeling work went away. It didn't move to AWS. It moved one step downstream, and it's still yours.