AI training and inference pipelines live or die on how fast and how cheaply a query engine can scan petabytes of data. For years, that meant data teams hand-managed Apache Iceberg or Hudi tables on top of raw S3 buckets, running their own compaction and metadata-cleanup jobs. Amazon S3 Tables, which AWS announced as a fully managed Apache Iceberg offering built directly into S3, is AWS’s bet that open table formats — not proprietary warehouse formats — are the right foundation for AI-scale data lakes, and that managing the operational overhead of those tables is a service AWS should sell rather than a chore customers should own.
At a Glance
| Attribute | Detail |
|---|---|
| What it is | A fully managed Apache Iceberg table service built into Amazon S3, using a new bucket type called a “table bucket” |
| Who it’s for | Data engineering and analytics teams running large-scale, high-ingest data lakes queried by multiple engines (Athena, EMR, Redshift, Spark) — including AI training and feature-pipeline workloads |
| Launched | Announced December 3, 2024; regional availability and Glue Data Catalog integration have expanded through 2025–2026 (initially US East N. Virginia, US East Ohio, US West Oregon, “more Regions coming soon”) |
| Pricing model | Pay-as-you-go: per-GB storage, per-1,000-request charges, plus S3 Tables–specific object monitoring and compaction fees not present on general purpose S3 buckets |
| Performance claim | AWS states S3 Tables can deliver up to 3x faster query throughput and support up to 10x more transactions per second than tables customers manage themselves on S3 |
The Verdict
S3 Tables is a sound, if narrow, piece of infrastructure: it takes a specific, well-understood pain point — the constant background maintenance that open table formats like Iceberg require (compaction, snapshot expiration, orphan-file cleanup) — and turns it into a managed service with its own line-item pricing. It’s not a new query engine or a new storage class so much as an operations layer bolted onto S3 specifically for tabular analytics data, which makes it a genuinely useful default for teams already committed to Iceberg, and a non-event for anyone storing unstructured objects, media, or backups.
What It Is
According to AWS’s own December 2024 announcement, Amazon S3 Tables are “fully managed Apache Iceberg tables optimized for analytics workloads” — and AWS describes the launch as the first time a cloud object store has shipped with built-in Apache Iceberg support. The core new concept is the table bucket, a distinct S3 bucket type purpose-built for tabular data rather than arbitrary objects. Table buckets support:
- Fast table creation, without manually wiring up a separate catalog and storage layer
- Table-level permissions, so access control can be scoped to a specific table rather than only a bucket or prefix
- Continuous, policy-driven maintenance — automatic compaction of small files into larger ones, snapshot management, and removal of unreferenced files as data changes over time
Because the tables speak the Apache Iceberg open standard — including row-level transactions, queryable historical snapshots, and schema evolution without rewriting data — any Iceberg-compatible engine, from AWS-native services to third-party tools like Apache Spark or Trino, can read and write them. AWS says this managed maintenance is what produces the throughput and transaction-rate gains over self-managed Iceberg-on-S3 setups.
How It Differs From a Regular S3 Bucket
A general purpose S3 bucket stores objects — files, images, logs, model checkpoints — with no inherent concept of rows, schemas, or transactions. If you wanted an Iceberg table on a general purpose bucket before S3 Tables existed, you (or a tool like a Glue job or an open-source compaction utility) had to run the housekeeping yourself: periodically rewriting small files into larger ones, expiring old snapshots, and deleting orphaned data files so storage costs and query latency didn’t creep up as the table grew. A table bucket does that maintenance automatically and bills for it as a distinct, metered service, while also exposing table-level (not just object- or prefix-level) permissions. In short: a general purpose bucket is a filesystem-like object store; a table bucket is a managed database-like layer for structured, transactional data sitting on the same underlying S3 durability guarantees.
Integration With Glue, Athena, EMR, and Other Engines
AWS’s announcement names Amazon Data Firehose, Athena, Redshift, EMR, and QuickSight as services that can stream, query, and visualize data in S3 Tables. The connective tissue is the AWS Glue Data Catalog, which AWS has continued building out — including a 2026 preview enabling Glue Data Catalog metadata exports to S3 Tables and simplified permissions for S3 Tables and Iceberg materialized views. Practically, this means a team can write Iceberg tables once into an S3 table bucket and then query the same data from Athena for ad hoc SQL, from EMR or Spark for large-scale ETL and feature engineering, and from Redshift for BI — without copying the data into each engine’s own storage format. For AI pipelines specifically, this matters because training and evaluation datasets are frequently assembled by joining and filtering large fact tables across many sources; having one Iceberg-native copy that every engine can read consistently (with the same snapshot and schema state) avoids the classic data-lake problem of multiple, slightly inconsistent copies drifting out of sync.
Pricing and Economics
Pricing comes directly from AWS’s S3 pricing page, which breaks S3 Tables charges into several distinct line items beyond standard storage and request fees:
| Charge | Rate (as published) |
|---|---|
| Standard storage (first 50 TB/month) | $0.0265 per GB (AWS’s own example; example region US West Oregon) |
| PUT requests | $0.005 per 1,000 requests |
| GET requests | $0.0004 per 1,000 requests |
| Object monitoring | $0.025 per 1,000 objects |
| Compaction (objects processed) | $0.002 per 1,000 objects |
| Compaction (data processed) | $0.005 per GB |
| Migration (existing Iceberg/Hive tables) | $0.005 per 1,000 PUT requests + $0.002 per 1,000 source objects per sync (first 500 syncs within 3 months are free) |
| Cross-Region replication | $0.005 per 1,000 PUT requests + $0.010 per 1,000 table updates + standard inter-Region data transfer rates |
AWS’s own worked example — a 1 TB table with a 100 MB average object size in US West (Oregon) — comes to roughly $28.54 per month: about $27.14 in storage, $0.15 in PUT requests, $0.20 in GET requests, $0.26 in object monitoring, and $0.79 combined for compaction. Compaction runs by default unless disabled, so budgeting should assume it’s on. Replication is not available in AWS GovCloud (US) Regions. AWS’s pricing page notes that compaction costs themselves dropped by up to 90% as of a July 2025 update, which matters because compaction — not raw storage — is often the line item that surprises teams with high-ingest, small-file workloads typical of streaming AI feature pipelines.
One caveat worth flagging explicitly: AWS’s public pricing page does not display a clean side-by-side per-GB rate for general purpose S3 Standard storage next to the S3 Tables rate on the same page view, so a precise “S3 Tables costs X% more than a plain bucket” comparison can’t be stated with certainty from the publicly fetched content alone — the extra cost comes specifically from the added object monitoring and compaction fees layered on top of otherwise standard storage and request pricing, not from a materially different base storage rate.
Why This Matters for AI Training and Inference Pipelines
Modern AI workloads — especially large-scale training set construction, feature stores, and retrieval pipelines for retrieval-augmented generation — depend on being able to version, filter, and incrementally update enormous tabular datasets without re-copying everything on every change. Apache Iceberg’s row-level transactions and snapshot model let a pipeline add a day’s new training examples, correct a labeling error, or roll back a bad ingest, all while multiple query engines read a consistent view of the data. Doing this maintenance by hand at scale — compacting millions of small Parquet files produced by streaming ingestion, for instance — is exactly the kind of undifferentiated operational work that becomes a bottleneck as data volume grows. By managing that maintenance as a billed service, AWS is explicitly targeting the operational overhead that sits between “we have the raw data in S3” and “every team’s query engine can efficiently read a governed, up-to-date version of it” — a gap that matters more, not less, as AI data pipelines scale. This storage-layer investment sits alongside AWS’s compute-side AI infrastructure bets, such as the custom Trainium and Inferentia AI chips and the Nitro-based networking stack that feeds data to large GPU and accelerator clusters — a well-governed, consistently updated Iceberg data lake is only useful for AI if the compute layer reading it can keep up.
Pros
- Removes manual Iceberg maintenance (compaction, snapshot expiry, orphan-file cleanup) as an engineering burden
- Open Iceberg standard means no lock-in to a single AWS query engine — Spark, Trino, and other third-party tools can read the same tables
- Table-level permissions give finer-grained access control than bucket- or prefix-level policies alone
- AWS reports meaningful throughput and transaction-rate gains over self-managed Iceberg-on-S3 setups
- Compaction costs have already been reduced once (up to 90%, per AWS’s July 2025 update), suggesting ongoing cost optimization
Cons
- Adds distinct billing line items (object monitoring, compaction) that a plain S3 bucket doesn’t incur
- Only useful for tabular, Iceberg-structured data — irrelevant for unstructured objects, media, or general file storage
- Regional availability, while expanding, was limited to three US Regions at launch; teams needing other Regions should check current coverage before committing
- Glue Data Catalog integration for streaming exports has moved through preview status, meaning parts of the integration surface are still maturing
- AWS does not publish a direct side-by-side comparison of S3 Tables storage pricing versus plain S3 Standard storage on the same page, making exact incremental cost estimation harder without a real workload test
Who It’s a Good Fit For
Data engineering teams already standardized on Apache Iceberg, or actively migrating from Hive-style tables, who want AWS to own ongoing table maintenance rather than running their own compaction jobs. It’s a particularly strong fit for high-ingest streaming pipelines (common in AI feature stores and training-data assembly) where small-file proliferation would otherwise require constant manual cleanup, and for organizations that query the same dataset from multiple engines (Athena, EMR/Spark, Redshift) and want one consistent, governed copy.
Who Should Look Elsewhere
Teams storing primarily unstructured data — images, video, model checkpoints, logs, backups — get no benefit from S3 Tables and should stick with general purpose S3 buckets and appropriate storage classes. Organizations already heavily invested in a different open table format’s managed tooling (or a proprietary warehouse that already handles these problems well, like a fully managed Snowflake or BigQuery deployment) may not see enough incremental value to justify re-architecting around S3 Tables specifically, especially while some AWS integrations remain in preview.
The Bottom Line
S3 Tables is AWS formalizing something many data teams were already doing manually — running Apache Iceberg on top of S3 — and selling the maintenance work as a managed, metered service. The pricing is transparent and published directly on AWS’s own pricing page, which is more than can be said for some competing agentic AI pricing models; the trade-off is a handful of new, workload-dependent charges (object monitoring and compaction) on top of otherwise-standard S3 storage and request pricing. For AI-scale data lakes where multiple engines need a consistent, transactionally-correct view of constantly updated tabular data, that trade generally looks worthwhile. For everything else S3 already does well, it’s simply not the right tool.
FAQ
Do I need to migrate all my data to use S3 Tables?
No. S3 Tables use a new “table bucket” type specifically for tabular Iceberg data; existing general purpose S3 buckets with unstructured objects are unaffected and can continue as before. AWS also offers a migration path for existing Iceberg or Hive tables into S3 Tables, billed per PUT request and per source object synced, with the first 500 syncs within three months free.
Which query engines can read S3 Tables?
Any engine that supports the Apache Iceberg open standard, including AWS services like Athena, Redshift, and EMR, plus third-party tools such as Apache Spark and Trino, via the AWS Glue Data Catalog integration.
Is compaction mandatory, and does it cost extra?
Compaction runs by default and is billed separately — $0.002 per 1,000 objects processed plus $0.005 per GB processed, per AWS’s pricing page — though AWS reduced these costs by up to 90% in a July 2025 update.
How is this different from just running Iceberg myself on a regular S3 bucket?
You still can — Iceberg is an open format and doesn’t require S3 Tables. The difference is that S3 Tables automates the ongoing maintenance (compaction, snapshot management, orphan-file removal) and adds table-level permissions and faster table creation, as a billed managed service, instead of you running and monitoring that maintenance yourself.
Is S3 Tables available in all AWS Regions?
Not initially — it launched in US East (N. Virginia), US East (Ohio), and US West (Oregon), with AWS stating more Regions would follow. Check AWS’s current documentation for up-to-date regional availability before planning a deployment.
Sources
- AWS: “Announcing Amazon S3 Tables – Fully managed Apache Iceberg tables optimized for analytics workloads”
- AWS: Amazon S3 Pricing (including S3 Tables pricing)
- AWS: “Amazon S3 Tables reduce compaction costs by up to 90%”
- AWS: “AWS Glue Data Catalog now supports metadata exports to S3 Tables (Preview)”
