Amazon Kinesis Data Streams now writes Apache Iceberg tables directly

August 31, 2026. AWS launches streaming tables for Amazon Kinesis Data Streams: a stream pours continuously into an Apache Iceberg table on S3 Tables, with no application in between. July 30, 2026. Amazon MSK Express had already received the same capability. August 2026. The feature is available in every region, including GovCloud and the China regions. Why it matters: the most tedious part of a streaming platform — delivering well-formed files to a lakehouse — becomes a managed option, with a price attached.

What streaming tables actually do

The promise fits in one sentence: Kinesis Data Streams now delivers records from a stream to two destinations — Apache Iceberg tables backed by S3 Tables, or general-purpose S3 buckets. No connector to maintain, no Flink or Glue application to deploy to write the files. The data becomes queryable within minutes via Amazon Athena, Amazon Redshift or Apache Spark, with automatic registration in the Glue Data Catalog.

The architecture removes exactly what made self-managed Iceberg delivery expensive to operate. A homegrown pipeline has to handle record conversion, destination table creation, partitioning, data freshness, the dead-letter queue and encryption. Here those responsibilities shift to AWS, under a usage-based pricing model — both capacity modes, On Demand Standard and On Demand Advantage, remain supported.

The most interesting detail is inline compaction: the small files that are the classic scourge of a continuously writing stream are compacted automatically on arrival. That is what explains the two savings figures the vendor cites: up to 50% on delivery and up to 30% on downstream queries, since better-sized files are cheaper to scan.

Why this is an architecture decision, not a feature

Place the launch in AWS’s trajectory. On July 30, 2026, MSK Express — the express-priced variant of Managed Streaming for Kafka — had already received delivery into Iceberg tables. With Kinesis, the same capability now covers the other major stream family, the one that imposes no Kafka cluster.

The consequence for a data team is a question of boundary. Until now, two worlds coexisted: the streaming world, which pushes events, and the lakehouse world, which waits for tables. The bridge between them was an engineering asset in its own right — code, retries, supervision. By turning it into a managed service, AWS moves the boundary: the Iceberg table becomes a native destination of a stream, the same way an S3 bucket is.

That is not without a dependency cost. The Apache Iceberg format stays open, but delivery, compaction and schema are now AWS-managed. For a team that already owns its delivery pipeline — often written for fine-grained control or compliance — the service replaces nothing: it arrives as an option.

Under the hood: schema, catalog and dead-letter queue

Delivery into an Iceberg table is not a plain byte copy. The service handles record-to-row conversion, destination table creation when it does not exist, partitioning, data freshness and a dead-letter queue for records that fail the schema. Tables are registered automatically in the Glue Data Catalog, which makes them immediately visible to Athena, Redshift Spectrum and Spark.

The point that deserves attention is the schema. The service leans on a registry — in the sense of Glue Schema Registry — to infer column structure. If your stream is heterogeneous, that is where the final table’s quality is decided: a malformed record goes to the dead-letter queue rather than corrupting a partition. The behavior is predictable, but it needs watching, because a dead-letter queue filling up is the symptom of a producer drifting.

When to switch, and when not to

The obvious use case is the team that has not yet built its Iceberg delivery pipeline. The cost-to-value ratio is cleanest there: you get a queryable table in minutes, with compaction and a dead-letter queue included, without writing a line of infrastructure code.

The opposite case is a platform that has already industrialized its delivery, with upstream business transformations, strict partitioning control, or residency and encryption requirements handled in custom code. There, the service does not remove the existing pipeline — it only offers an alternative to the most mechanical part.

The right reflex is to reason about freshness and volume. Continuous delivery suits click streams, telemetry or fraud detection, where a table a few minutes behind is acceptable. For a millisecond-level need, direct stream consumption remains necessary; the Iceberg table is the analytics layer, not the real-time bus.

What changes for cost and operations

The two figures — 50% on delivery, 30% on queries — must be read as a comparison against an equivalent self-hosted pipeline, not as a blanket discount. Pricing stays usage-based, meaning cost grows with the volume of records delivered and compacted.

The real operational win is elsewhere: the disappearance of code to maintain. Retries, failure recovery, delivery supervision and compaction leave your backlog. For a small data team, that is often worth more than the raw cost saving, because it is engineering time that returns to analysis rather than infrastructure.

Finally, one detail matters for teams that automate: AWS pairs the launch with a Kinesis Data Streams Agent Skill, an assistant that guides integration setup — schema registry, IAM role, validation — including in agentic workflows and infrastructure-as-code patterns at scale. It is the first time a streaming service’s tooling has shipped in this form.

Start in five minutes

Getting started follows a short path, with no application code to write.

• Pick the Kinesis stream and the capacity mode — On Demand is enough to begin.
• Choose the destination: an Iceberg table on S3 Tables, or a general-purpose S3 bucket.
• Validate the schema and the IAM role — the Kinesis Agent Skill guides this step, including in infrastructure-as-code patterns.
• Let the service create the table and catalog, then query it through Athena within minutes.

The first query is the moment to check the expected freshness and the fill rate of the dead-letter queue. Those two signals tell you within hours whether the stream is healthy or a producer is drifting.

There is a latency caveat worth stating plainly: this is a near-real-time layer, not a real-time bus. Records are delivered continuously, but the Iceberg table is built for analytics at minutes-level freshness, not for sub-second consumers. Keep your low-latency path on direct stream consumption, and treat the table as the durable, queryable shadow of the stream.

Verdict

Kinesis Data Streams streaming tables turn an engineering project — delivering a stream to a lakehouse — into a checkbox, at the price of deeper AWS dependency.

If you have no Iceberg delivery pipeline yet, enable streaming tables: you gain months of development and inherit compaction without operating it. If you already run an industrialized pipeline, keep it for heavy-transformation streams and measure the service on simple streams where minutes-level freshness is enough. If latency is your first constraint, the Iceberg table remains the analytics layer — the real-time bus itself does not change.

References

• AWS News Feed — Amazon Kinesis Data Streams announces streaming tables, August 31, 2026
• AWS — What’s New: data delivery to S3 Tables, August 2026
• AWS Big Data Blog — Deliver real-time data to streaming tables for Apache Iceberg
• ReleaseBytes — Kinesis Data Streams now supports Apache Iceberg streaming tables, August 31, 2026