AWS Glossary
Amazon S3 Tables
S3 Tables are managed Apache Iceberg tables on S3 — purpose-built table buckets with auto-compaction, snapshot management, and up to 3× better query performance than self-managed Iceberg on standard S3.
Definition
Amazon S3 Tables provides managed Apache Iceberg tables stored in table buckets — a bucket type optimized for tabular data with AWS-operated maintenance: compaction, snapshot expiration, and orphan file cleanup. You get Iceberg’s ACID transactions, schema evolution, hidden partitioning, and time travel without scheduling Glue Spark jobs to rewrite small files every night. S3 Tables reached GA at re:Invent 2024 and integrates with Athena, Amazon Redshift, EMR, Glue, and SageMaker Lakehouse through the AWS Glue Data Catalog or native table catalog APIs.
Compared to self-managed Iceberg on general-purpose S3, AWS claims materially higher write throughput and up to 3× faster selective queries on maintained tables because background compaction keeps file layouts query-friendly. Pricing includes storage, requests, compaction processing, and per-object monitoring — offset maintenance labor and often query compute savings on large datasets.
| Aspect | Self-managed Iceberg on S3 | S3 Tables |
|---|---|---|
| Compaction | Your Spark/Glue jobs | AWS-managed |
| Snapshot cleanup | Your scripts | Automatic policies |
| Catalog | Bring your own | Native + Glue integration |
| Bucket type | General purpose | Table bucket only |
When to use it
- New lakehouse or medallion architectures (bronze/silver/gold) where Iceberg is already the table format choice.
- Teams tired of operating compaction SLAs and snapshot retention cron jobs on open-table formats.
- Multi-engine analytics — same Iceberg table queried from Athena, Redshift Spectrum, and Spark without duplicate copies.
- Streaming ingest landing in Iceberg with concurrent writers needing snapshot isolation.
When not to use it
- Arbitrary binary objects, JSON logs, or media — use standard S3 buckets.
- Existing Delta Lake or Hudi estates without a migration program — format conversion has engineering cost.
- Ultra-low-latency keyed lookups — Iceberg is analytical; OLTP belongs in Aurora, DynamoDB, or RDS.
Tips
- Configure snapshot expiration and orphan-file policies at table creation — default snapshot retention grows storage silently on high-churn pipelines.
- Use table-level IAM grants on table buckets instead of blanket bucket admin for data-mesh ownership boundaries.
- Register tables in AWS Glue Data Catalog once for cross-engine discovery — avoid duplicate metastores per team.
- Model partition transforms (day/month) in Iceberg hidden partitioning so analysts do not write brittle
WHERE year=...paths. - Benchmark compaction costs vs query savings on a representative partition before migrating petabyte-scale legacy Hive tables.
Gotchas
- Serious: Placing non-tabular data in table buckets wastes specialized pricing and breaks tooling expectations — keep logs and assets in general-purpose buckets.
- Serious: Concurrent writers without Iceberg conflict handling can produce commit failures — implement retry semantics in streaming jobs.
- Regular: Time travel queries over long snapshot histories are expensive — cap retention to what auditors actually require.
- Regular: Cross-region analytics on table buckets needs explicit replication design — table buckets are regional.
- Regular: Engines cached old schemas after schema evolution until metadata refresh — automate
MSCK REPAIR/ catalog sync in pipelines.
Official references
- S3 Tables pricing — storage, requests, compaction, and monitoring meters.
- Query S3 Tables with Athena — SQL access patterns.
Related FactualMinds content
- Amazon S3 — object storage foundation
- AWS Data Analytics Services
- Lakehouse on AWS Pattern
Need help with this topic?
Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.